Every organization feels the identity gap, whether or not it gets named or discussed openly. The same question surfaces across industries and security teams. How do we know the person resetting this password is who they say they are?
The tools most teams rely on, identity providers, MFA, and helpdesk runbooks, do real and necessary work. They were built to confirm that a valid account is acting. AI has made the harder question, whether the right human is acting, both cheaper to get wrong and more expensive to ignore.
This is a shared problem, not a local failure. It isn't the result of one team cutting a corner or one program falling behind. It's structural. The identity stack nearly every enterprise runs was designed around the account as the unit of trust, long before convincing impersonation became cheap and scalable. So most teams are working on some version of this at once, and what's usually missing isn't effort. It's a shared way to frame the question, so you can see where your program is already strong, where the next gap sits, and what to look for when you evaluate a way to close it.
Identity programs tend to mature through four stages, each organized around a single question. Knowing which question your program answers cleanly today, and which one comes next, turns identity from a reactive scramble into something you can build deliberately.
Stage 1: Is this the right account?
Answering whether the right account is acting is what most enterprise identity infrastructure already does well. Passwords, MFA, conditional access, role-based controls, and identity providers like Okta and Microsoft Entra ID all resolve the same thing. Were valid credentials presented by an account allowed to act?
The assumption underneath is the part worth naming. When someone has the password and clears the MFA prompt, the system treats them as the authorized person. Authentication, confirming a valid account is acting, becomes a stand-in for verification, confirming the human behind it. That was a reasonable substitution when impersonating an employee at scale was hard. AI is what changed it. An attacker who has bought a working credential and can clear the MFA prompt passes every Stage 1 control cleanly, because they're presenting exactly what those controls were built to check. The account is valid. The human is not.
What to evaluate. Can your controls tell the difference between a valid credential and a verified person? Map where in your environment a correct password and a passed MFA prompt are treated as proof of identity. Those are the points where an account check is standing in for a human check. They aren't failures, they're the boundary of what Stage 1 was designed to do, and knowing where that boundary falls tells you exactly where the next three questions apply.
Stage 2: Is this the right person?
Some moments carry far more risk than a routine login. Password resets, MFA resets, account Some moments carry far more risk than a routine login. Password resets, MFA resets, account unlocks, and privilege escalation are the points where the distance between the right account and the right person matters most, because they're the points an attacker with stolen or borrowed credentials will use.
A Stage 2 program adds a human verification layer at exactly those moments. The helpdesk verifies the caller before resetting anything, rather than relying on knowledge-based questions, which can be researched, and manager callbacks, which can be socially engineered. The 2023 attacks on MGM Resorts and Caesars Entertainment showed why this layer matters. Both started with a phone call to the helpdesk and a credential reset, not a technical exploit. With Gartner reporting that 62% of organizations experienced a deepfake attack in 2025, asking an agent to catch an impersonation by judgment alone is no longer realistic. Verifying the human is what closes it.
What to evaluate. Make a list of every action that grants or restores meaningful access, then ask what actually stands between a requester and a yes. If the answer is a security question, a callback, or an agent's read on whether a caller sounds legitimate, you're inferring identity, not verifying it. The goal is to know which of your sensitive actions rest on verification and which rest on a judgment call someone shouldn't have to make.
Stage 3: Can we trust this identity continuously?
While Stage 2 verifies at discrete moments, Stage 3 asks what happens between them. For most organizations, identity is verified once at onboarding, and from then on the organization interacts with the account, not the person. Every action afterward is authenticated against credentials, never re-confirmed against the human who was originally verified.
That single verification carries an enormous amount of weight over an employee's entire tenure. The person confirmed on day one is assumed to be the same person logging in, recovering access, and approving requests months or years later. When that assumption holds, nothing is lost. When it doesn't, nothing in the stack notices, because nothing asks the question again.
In practice, a mature Stage 3 program treats verification as a property of the identity rather than a one-time event. A returning employee re-confirms they're the same verified person through a quick biometric check, fast enough to use at a device change or a recovery moment without repeating the full onboarding process. The trust established once carries forward instead of resetting to an assumption.
What to evaluate. Trace a single employee from hire through a device change, a recovery event, and a role change, and note how many of those moments re-confirm the human versus simply trusting the account. The pattern you find is your real continuity posture.
Stage 4: Can we extend verified identity to automated decisions?
As AI agents move into production, they're being granted access to sensitive systems and authorized to initiate high-risk actions on their own. When one of those actions fires, the audit trail shows which account authorized it. It rarely shows which verified human stood behind that account. Okta reports that fewer than 33% of organizations currently extend human-level governance to AI, which is why this question is landing on roadmaps now rather than later.
A Stage 4 program requires verified human authorization before a sensitive automated action proceeds, and records who that human was. The link runs from the action back to a specific verified person at a specific moment, whether the action was initiated by an agent or by a person requesting elevated privilege.
What to evaluate. Can you connect an automated action back to the verified human accountable for it? Look at where AI agents or automated workflows can take consequential action in your environment, and ask what your logs would show if you had to answer "who authorized this" under audit. If the honest answer is the account or credential that launched the workflow, you have visibility into the machine but not the person behind it. Stage 4 is about making sure accountability survives automation.
Building toward a stronger posture
The four questions build on one another. Stage 2 doesn't replace Stage 1, it adds a human verification layer where it matters most. Stage 3 makes that verification persistent across the lifecycle. Stage 4 extends the same verified trust into automated workflows. Each stage assumes the one before it and reaches further.
Zoom out, and the progression is the point. A program that can answer all four questions has trust anchored to the human at every moment that matters, from a routine login to an AI-initiated approval. That's the most defensible identity posture available, and the framework is how you get there one deliberate question at a time rather than all at once.
There's a real cost to leaving the later questions unanswered, and choosing not to act on identity is itself a decision with a price. What Unverified Identity Costs Enterprises Every Year quantifies that cost across four dimensions every organization recognizes. The IT time spent running manual verification. The workforce hours lost to identity friction. The actuarial breach exposure carried on the risk register. The hiring fraud that arrives before an employee's first day. For a 15,000-employee organization, those stack to roughly $7.8M a year, a cost that accrues quietly because it never lands on a single budget line.
Answering the four questions in order is how that cost comes down. Each stage you reach closes off a way the wrong person can act as the right one, strengthens the posture you present to auditors and boards, and recovers the time and exposure the unanswered questions were quietly costing you. You don't have to solve all four at once. You have to know which one you're answering next.
Put a number on what it costs to trust the wrong person.
What Unverified Identity Costs Enterprises Every Year breaks down the operational, productivity, breach, and hiring-fraud cost of being unable to verify the human behind an account, a helpdesk ticket, an application, or an AI agent, across six industries.
