Because the attacker is often not authenticating at all. They are replaying a credential that was already issued and accepted, so MFA is not part of the second transaction. That makes token lifecycle, revocation speed, and scope control more important than the authentication ceremony that created the token.
Why This Matters for Security Teams
Stolen access tokens bypass MFA risk controls because the security event has already moved past the login ceremony. The token is a bearer credential: whoever holds it can often act as the original identity until expiry or revocation. That shifts the real control problem from authentication to token governance, which is why the industry keeps seeing token replay in incidents like the Salesloft OAuth token breach and the Internet Archive breach.
This is not just a human identity problem. NHI tokens and API keys are frequently copied into tickets, chats, and code, which makes replay much easier once one copy is exposed. In The 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reported that 44% of NHI tokens are exposed in the wild, and 91% of former employee tokens remain active after offboarding. That combination turns MFA into a weak signal if the downstream token is still valid. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 points in the same direction: control the credential lifecycle, not only the sign-in event.
In practice, many security teams discover token replay only after data access has already occurred, rather than through intentional revocation testing.
How It Works in Practice
A stolen token bypasses MFA because the token is the proof, not the authentication challenge. Once an identity provider or application issues an access token, that token may be accepted by downstream APIs without asking for MFA again. If the token is scoped broadly, long-lived, or copied into a system that the attacker can reach, the attacker inherits the original session context.
Effective defenses focus on making replay less useful. That means short token TTLs, scoped privileges, continuous revocation, device or workload binding where possible, and strong separation between interactive authentication and API authorisation. For NHIs, the operational pattern is to issue only the minimum token needed for a task, then revoke it automatically when the job ends. Where agentic systems are involved, this starts to look like just-in-time credential provisioning and workload identity rather than human login workflows.
- Use short-lived access tokens and rotate refresh credentials aggressively.
- Bind tokens to workload identity, where the platform can prove what the caller is.
- Limit token scope so a stolen credential cannot enumerate unrelated systems.
- Revoke on offboarding, pipeline completion, or task completion, not on a fixed calendar alone.
- Monitor token use for impossible travel, unusual fan-out, and privilege escalation paths.
The 52 NHI Breaches Analysis shows how often exposed credentials become an initial access path, while the Guide to the Secret Sprawl Challenge illustrates why duplicated storage makes revocation slow and incomplete. This aligns with the Anthropic — first AI-orchestrated cyber espionage campaign report, which reinforces that automated tool use and chained actions can magnify one valid credential quickly. These controls tend to break down in environments with shared service accounts, legacy API gateways, or tokens cached in CI/CD runners because revocation and traceability are too weak.
Common Variations and Edge Cases
Tighter token controls often increase operational overhead, so organisations must balance faster revocation against application reliability and developer friction. Best practice is evolving, and there is no universal standard for every platform, especially where OAuth integrations, legacy SaaS connectors, and machine-to-machine workflows all coexist.
One common edge case is “authenticated once, trusted everywhere.” Some platforms treat a valid access token as sufficient for the full session, even when the original MFA step happened hours earlier on a different device. Another is overuse of shared tokens across multiple services, which makes revocation disruptive and encourages teams to delay it. In NHI-heavy environments, the problem is compounded when a token is embedded in automation, copied into chat systems, or stored in a pipeline variable. Those pathways make replay easier than credential theft from the primary identity provider itself.
The practical answer is layered: use JetBrains GitHub plugin token exposure as a reminder that developer tooling can leak valid credentials outside normal IAM controls, and apply NHI-specific governance from the Ultimate Guide to NHIs — Key Challenges and Risks. For standards alignment, the issue maps well to OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, because both emphasise reducing exposure, constraining privilege, and improving recovery after compromise.
These controls tend to break down when long-lived tokens are embedded in automation that cannot tolerate frequent reauthentication because business teams resist the required workflow changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token lifecycle and rotation failures are central to this issue. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits damage after token theft. |
| NIST AI RMF | AI RMF helps govern automated systems that reuse stolen or issued credentials. |
Assign accountability for credential use, monitoring, and revocation in automated workflows.
