IdentityOps Questions Clients Ask on Day One, Answered Plainly

A few months ago a client asked me, halfway through a kickoff call, a question that stopped the whole room: “How many people can log in to our systems right now who no longer work here?” Nobody knew. The silence lasted long enough that someone offered to get coffee. That moment is where most conversations about IdentityOps begin in a consulting engagement, and it is why this article is built around the questions clients actually ask. The answers lean on the Ops Atlas, the xOps School reference, and on the plain experience of watching teams discover their own gaps.

Some framing before the questions. The Atlas is candid that IdentityOps is a young label with no agreed definition, and that vendors scope it differently. What follows is one defensible reading, not gospel.

What is IdentityOps, in the words a finance director would accept?

It is the routine upkeep of the list of everyone and everything that can sign in, plus the proof they offer when they do. The Atlas separates it from two neighbours: deciding what each identity may do, and managing how extra access is requested and checked. Our consulting shorthand is “the register and the doorbell”. The register says who exists. The doorbell checks they are who they claim to be.

If you would like the long version, the Ops Atlas description of IdentityOps and where its edges lie is thorough, and it is honest about what it leaves out, including customer identity and detection work.

Why does our pipeline team need to care about HR data?

Because the starting gun for almost everything is an HR event. A hire, a team move or a departure should trigger changes in the directory and then in applications. In Atlas vocabulary that is the joiner-mover-leaver loop, and the entry argues that a poor feed from HR is the reason many automation projects underperform. Its advice is blunt: do not buy a governance product until the underlying HR records are clean, because automation simply moves wrong data faster.

In one engagement I watched a team spend a quarter on tooling while the job-title field in the HR system was free text. Every rule they wrote had to guess. The fix was a week of data cleanup that nobody had budgeted for.

We disabled the account. Why is the person still reading email on their phone?

This is the question that surprises people most. Anything issued before the disablement, such as a session or token, may stay valid. The Atlas quotes default access-token lifetimes of roughly sixty to ninety minutes on one large cloud identity service, stretching to around twenty-eight hours when continuous evaluation is enabled. The platform’s session-revocation call exists to close that gap, though even it may need a few minutes. Revoking at the identity provider also may not clear sessions inside downstream apps.

So our recommended leaver sequence has five beats. HR logs the departure. The directory login is switched off. Live sessions and tokens are cancelled. Each application receives a deactivation instruction. A clock time is written beside every step. A leaver sequence without timestamps cannot be audited later.

How do we know the leaver process works?

Measure it end to end. The Atlas offers a worked example worth repeating to every client. Take forty departures. Thirty-six had their directory login closed inside the target, which gives a comfortable-looking ninety percent. But three among that group kept a working account in a minor application, so the end-to-end result is eighty-two and a half percent. Both figures are correct; only one is useful.

We usually ask clients to pick targets before measuring. The Atlas gives examples: four hours for the directory, twenty-four for every application, ninety days before a quiet account is disabled, and ninety days maximum age for a machine credential. They are starting points. The real value is agreeing a number so a miss becomes visible.

Is multi-factor sign-in not already solved?

Usually not, and the reason is how it gets counted. A dashboard saying every employee is enrolled hides which method they use. The Atlas treats text-message codes and push approvals as weaker, since both can be phished, relayed or worn down by repeated prompts. Only FIDO2 or WebAuthn security keys and smart-card style certificates qualify as phishing resistant under the standards it cites. The CISA fact sheet on the topic dates from October 2022, while the July 2025 NIST revision asks that a phishing-resistant choice be on offer at the second assurance level.

Our rollout order mirrors the Atlas: identity and cloud administrators first, then people with email, remote and finance access, then everyone else. Admins are few, high-value and easy to equip, which makes them the right pilot group.

What about service accounts and automation credentials?

These are the quiet majority. In most engagements I have joined, machine identities outnumber humans, and the owner field is often blank. The Atlas lifecycle is simple to explain on a whiteboard: list them, record who owns each and why it exists, give it an expiry and a review rhythm, use credentials that expire quickly, replace them on a calendar, and when something is retired, disable it, wait, then delete. That wait is not procrastination; it is how you learn what quietly depended on it.

Public incidents show why. The Atlas recounts a 2023 case in which a service-account credential sat in somebody’s personal cloud storage and later let attackers hijack sessions at several customers. One affected firm had failed to rotate a token and three accounts it believed unused. The point the Atlas draws from each cited incident is that process failed, not cryptography.

Our help desk resets passwords all day. Is that a problem?

It can be, since help desks are a favoured target. The Atlas references the CISA advisory on the Scattered Spider group, which lists impersonation of staff to win credential resets, SIM swapping, repeated push prompts and even a rogue federated provider. Phone call-backs are called unreliable because of SIM swapping. A tiered process answers this: self-service through a second enrolled authenticator first; for assisted recovery, a one-time code is released only once the person’s manager has seen them on a live video call or face to face; and for privileged accounts, supervised proofing plus a second administrator. Each recovery should notify the account owner.

Where do we start, and how long will it take?

We use the Atlas ninety-day outline almost verbatim. Thirty days: owners named, an application register started, security keys for administrators, a recovery script written. Sixty days: HR-driven provisioning for one group of staff, SCIM for the ten most used applications, a first machine-identity inventory. Ninety days: session revocation in place, the first leaver drill completed, alerts on resets and federation changes. If the engagement also touches pipelines, our walkthrough of weaving security checks into delivery pipelines shows where these controls attach.

For the broader shape of an engagement, from assessment to hand-over, see the engagement blueprint we published, which starts at assessment and ends in team enablement. Identity work fits the assessment stage naturally, because a roster audit takes days and exposes real findings.

Do we need a dedicated team?

Often not. The Atlas says a small organisation can skip a separate practice and assign the routines to people already running the platform. What matters is cadence: a daily reconciliation of the directory against HR, a weekly sample of recoveries, a monthly report on machine credentials near expiry, and a quarterly drill with a review of outside identity providers you trust.

One more habit from the field: we ask clients to name an owner for the quarterly drill before we leave the room. Drills die when they belong to everybody. A calendar invite with a single name, a one-page script and a place to paste the timestamps turns a good intention into a routine. Teams that do this tend to be the ones who later answer the opening question with a number instead of a shrug, and who can say which of their sign-in methods would survive a determined phishing campaign.

That kickoff silence, by the way, ended well. Two weeks later the client had a number, and it was not zero. It was a smaller number the month after, and they could explain why.

Kabir Malhotra