Ten years ago, the question of who could sign in to which system was handled, in most offices, by whoever answered the phone at the IT desk. Today it has a growing body of standards, a set of public incident reports and a name that is still settling: IdentityOps. This piece looks at where that field stands, written for administrators and managers in service businesses who want a calm, non-technical overview. It is informational only, it has nothing to say about clinical matters, and it should not be taken as professional guidance.
A field still finding its edges
The honest opening point comes from the Ops Atlas itself: the label is young, nobody wrote the original charter, and no agreed wording exists. One vendor describes it as the daily running of an identity system already in place; another body notes that definitions vary across suppliers; a third describes it as the place where access management, security work and IT automation overlap. Some large organisations use “Identity Operations” simply as the name of a team. Against that backdrop the Atlas proposes its own dividing lines. One discipline covers the existence of each identity and its proof; a second covers the permissions attached to it; a third handles requests, elevation and review.
The standards timeline in brief
What is not unsettled is the plumbing. The Atlas lists a handful of milestones that administrators may meet in vendor brochures. SAML 2.0 arrived in 2005 and still carries many corporate sign-ins. SCIM 2.0, the format for telling an application about new and departing users, was published in 2015. A security guidance document for OAuth, RFC 9700, now says one older flow should not be used and another must not be used. NIST’s identity guidance reached its fourth edition in July 2025, and the authentication volume now expects a phishing-resistant choice to be offered at the middle assurance level. The OpenID shared-signals specifications, through which systems alert one another to account changes, were finalised in September 2025, and the Atlas notes a NIST report on token protection dated September 2026.
For readers who prefer one sentence: the standards mostly describe how to say who someone is, how to tell other systems when that changes, and how to keep the proof from being stolen.
What the incident record keeps showing
The Atlas collects four public cases. A software giant’s legacy test tenant lacked a second factor and an old application had broad rights. A sign-in vendor’s support files contained session tokens, and service credentials had been stored in an employee’s personal cloud folder. A data platform’s customers were hit through accounts without a second factor and credentials unchanged for as long as four years. A criminal group repeatedly talked help desks into resets. Reading across them, the Atlas concludes that routines gave way while the cryptography held. That is good news in a way, because processes are something an office can improve by Friday.
Trends worth watching
- Machine accounts move to the foreground. A top-ten list of risks for non-human identities appeared from the OWASP community in 2025, a sign that software logins now draw the attention people accounts always had.
- Stronger second steps are becoming the expected baseline. Government fact sheets and guidance push hardware keys and certificate cards, though the Atlas points out that passkeys synced between devices cannot reach the very top tier, since their keys are exportable.
- Signals replace schedules. Instead of waiting for a sync cycle of around forty minutes, systems increasingly tell each other at once that something changed.
- Maturity models appear. The Atlas proposes five rungs, from ad hoc to continuous, calibrated against a federal zero-trust maturity model, and attaches measurable gates such as leaver completion of ninety percent or better.
A story from a typical service business
Imagine an administrator, new to the role, who inherits a spreadsheet of logins. She notices three accounts belonging to people she has never met. Instead of deleting them she disables them, waits a fortnight, and hears nothing. Then she deletes them and records the date. That small, careful sequence is the practice in miniature, and it matches the Atlas’s retirement order for machine accounts. It takes patience rather than money.
What this means for a small service business
None of these trends demands a new department. The Atlas itself allows a small firm to fold these duties into roles it already has instead of creating a dedicated practice, provided somebody owns each of them. What changes is the vocabulary you hear from suppliers. When a salesperson mentions shared signals, ask whether their product can end a session the moment you disable a person. When they mention provisioning, ask whether removals are sent as reliably as additions.
Reading the state of IdentityOps sensibly
Three lessons seem safe. First, expect vendors to use the term differently and ask what each one means. Second, expect licence tiers to matter, since the Atlas observes that features such as automated lifecycle workflows and provisioning often sit behind higher plans. Third, treat any single percentage with suspicion until you know whether it spans every application. If you like seeing the same habit of record-keeping applied to money, see the article about holding festival spending in check with a planner, or the village-focused note on keeping a simple written budget book.
The long-form reference behind much of this overview is the Ops Atlas IdentityOps page, which is candid about what remains debated. Check specific dates and requirements there and with your own advisers before acting on them.