Microsoft's 2026 Digital Defense Report put a number on something most defenders already felt. It reports that the median time from a vulnerability being discovered in the wild to being weaponized is now well below 24 hours, while remediation of a critical externally exposed vulnerability can still take 30 to 60 days. That gap is real, it is getting worse, and the reaction it produces, patch faster and shrink the window, is correct as far as it goes.
It does not go as far as the report does. In the same telemetry, user execution accounted for 30 percent of observed initial access and valid accounts for another 20 percent. And once an attacker was inside on a valid account, 52.2 percent of those intrusions led to further credential theft, while 78 percent of the techniques observed against critical infrastructure involved cloud-identity abuse. Those are three different measurements with three different denominators, and I am not going to collapse them into one scary statistic. Read together, though, they describe a second clock the patch conversation does not touch.
The first clock measures how long a vulnerability stays reachable. The second measures how long compromised authority stays useful after someone has it. Patching closes the vulnerable path. It does not, by itself, revoke authority an attacker already acquired through it.
You cannot patch a valid account
When the way in is a software flaw, removing the flaw closes the path. Once access has shifted to a valid credential, closing the original entry path does not eject the attacker who already crossed it. The authentication still works, the token is still real, and the API call is still cryptographically valid. The attacker is no longer breaking in. They are operating through authority the system continues to recognize as its own. Microsoft's framing for this is that attackers follow trust, moving through the identities, services, and workflows an organization already relies on rather than forcing their way past them.
That is why the 20 percent and the 52.2 percent matter more than they look. You cannot patch the fact that a credential is still valid. There is no version to upgrade and no condition to remove. The only thing that changes the situation is changing the authority state itself, and that turns out to be a harder, slower, and less reliable operation than the word "revoke" suggests.
The second clock has a shape
The 52.2 percent is the tell. More than half of valid-account intrusions involved follow-on credential theft, which means an initial identity foothold can become a platform for acquiring additional authority, some of it derived from the original identity and some captured from entirely different systems, potentially reaching additional systems and adding another surface that has to be found and revoked. By the time anyone notices, "reset the password" has quietly become "stop a process that has spread," and those are not the same size of problem.
I spent recent weeks building a small harness to measure exactly this in an agent system, where an operator tries to shut down an action that has already started, and the shape it exposed gives me a useful way to reason about enterprise identity. In the harness, revoking a credential stopped new use only at the places that actually checked revocation on each request. Work already authorized under that credential completed anyway, because authorization was decided once, at the start, and nothing re-checked it mid-flight. And authority that had been delegated out of the original identity, issued as its own credential, outlived the revoke entirely, because revoking the parent did not revoke what descended from it unless something was built to make it. Real identity systems are not my miniature, so the point is not that they behave identically. The point is that they raise the same question: after the revoke, which sessions, tokens, delegated credentials, already-accepted operations, and descendant authorities actually honor it.
Translate that out of the lab and "revoke the account" stops being one action. It fractures into a list of separate things that may or may not stop when you disable the login: active sessions, refresh tokens, service principals, delegated permissions, cloud access keys, work already sitting in a queue, workloads already running under an assumed role, and downstream credentials that were minted from the original identity and now stand on their own. Each has its own lifetime and its own enforcement point. Disabling the account is the beginning of containment, not the end of it.
So the second clock has a name worth using. Call it revocation latency: the time from initiating a revoke to the point at which the compromised authority can no longer authorize new work at any relevant enforcement point. That is still not the end of containment. Work that was already authorized can have its own residual window before the last effect completes, which is the difference between closing authority and closing effects. An IAM console can tell you the account is disabled. It cannot, by that fact alone, establish that every session, delegated credential, or already-authorized operation derived from it has stopped. What you still have to establish is what remained usable after the account went dark, and for how long.
Two clocks, and both are running
None of this argues that patching does not matter. Microsoft's own recommendations ask for both: faster remediation of internet-facing vulnerabilities and tighter limits on standing and privileged access. The report calls identity the primary control plane, and the two-clock reading is why that phrase has teeth. Vulnerability remediation reduces future reachability. Identity containment reduces authority already acquired. They are different work against different clocks, and a mature program runs both.
The failure mode is treating the first as if it covers the second. When an attacker has moved from a vulnerability into a valid account, patching the entry point closes the door behind someone who is already inside. It is necessary and it is not containment. Patch latency is comparatively easy to express as a single interval. Residual authority fragments across identity providers, session stores, cloud roles, service principals, tokens, queues, and downstream systems, and that fragmentation is exactly why disabling the originating account can be necessary without being sufficient.
What the numbers are, and are not
These figures come from Microsoft's telemetry, which means its customer population, its sensors, and its detection taxonomy. The 52.2 percent and the 78 percent are rates inside that population, not a census of the internet, and they would move with a different sensor set or a different definition of a technique. I would not present them as universal constants, and neither should anyone citing them.
The argument does not need them to be universal. It needs the pattern to be credible, which telemetry at Microsoft's scale strongly supports, and it needs the mechanics of revocation, which do not depend on Microsoft's denominator at all. Whether follow-on credential theft happens in half of valid-account intrusions or a third, the need to account for residual authority remains, and that is not a checkbox.
The part most runbooks skip
If identity is the control plane, then revocation is not a button in an admin console. It is a distributed containment operation with its own latency and its own residual window, and it raises a question an incident procedure needs to ask explicitly. After we revoke, what remains usable, through which session, token, delegated role, or downstream credential, and how long does each remain useful? A program that can answer that is measuring the second clock. A program that disables the account and closes the ticket has not.
The patch window is a real clock and it is worth shrinking. It is just not the only one running, and the second one starts the moment an attacker is holding authority the system still trusts.