What do security teams get wrong about session tokens and MFA?

Why This Matters for Security Teams

Session tokens are often treated as a harmless byproduct of successful MFA, but that mindset leaves a dangerous gap. Once an attacker steals a valid token through proxying, AiTM phishing, or a compromised endpoint, they can inherit the user’s authenticated state without triggering a fresh challenge. The practical mistake is assuming the login event is the security boundary, when the token is the real credential in use.

This is why teams increasingly pair token hygiene with behaviour-focused detection and tighter identity governance. The issue is visible in breach reporting such as the Salesloft OAuth token breach, where credential theft, not password guessing, created the path to access. It also reflects a wider secrets problem: GitGuardian reports that 44% of NHI tokens are exposed in the wild, which means session artifacts and service credentials are frequently discoverable well outside approved identity systems. Current guidance from NIST Cybersecurity Framework 2.0 supports stronger identity verification and continuous monitoring, but the operational lesson is sharper: successful MFA does not guarantee trustworthy post-authentication use. In practice, many security teams discover token abuse only after data access, mailbox activity, or privilege escalation has already occurred, rather than through intentional MFA alerts.

How It Works in Practice

The defensive shift is to treat session tokens as high-value secrets with their own lifecycle, not as proof that the job is done. That means tightening issuance, binding, monitoring, and revocation. A token should be short-lived where possible, scoped narrowly, and invalidated when risk changes, such as device loss, impossible travel, or suspicious proxy characteristics. For browser-based flows, conditional access and token binding reduce replay value, while backend systems should verify that the token is still valid for the current context instead of trusting the original login alone.

Operationally, teams should combine identity controls with post-authentication detection. That includes:

• Monitoring for new geographies, user agents, and session anomalies after MFA success.
• Revoking sessions when tokens appear in logs, tickets, chat tools, or code, as seen in the Guide to the Secret Sprawl Challenge.
• Using phishing-resistant MFA so the attacker cannot easily steal both the challenge and the resulting token.
• Separating human authentication from service-to-service trust, because NHI tokens need different controls than employee logins.

For implementation guidance, NIST Cybersecurity Framework 2.0 provides the monitoring and access-control anchors, while the practical compromise is that many environments still rely on bearer tokens that cannot be fully bound to device state. That is especially true in legacy SSO, cross-domain SaaS, and remote access architectures where token replay can look identical to legitimate use.

These controls tend to break down when high-trust sessions must survive long-lived browser activity or third-party integrations because the token remains usable even after the original MFA context has gone stale.

Common Variations and Edge Cases

Tighter session control often increases helpdesk load, friction for mobile users, and the risk of false positives, so organisations must balance security gains against operational continuity. Best practice is evolving here, and there is no universal standard for how aggressively to re-challenge users after MFA.

One common edge case is “remember this device” or persistent sign-in. Those features improve usability, but they also extend the life of the session artifact that an attacker wants. Another is service desk escalation, where an attacker who steals a token may not need to break MFA at all if downstream tools trust the existing session too broadly. The Dropbox Sign breach illustrates how downstream access can become the real exposure once a token or API credential is accepted as authoritative. Similarly, the Cisco Active Directory credentials breach shows that identity compromise often cascades across systems that trust the same credential set.

There is also a practical distinction between human sessions and NHI sessions. Human tokens can often be shortened and revalidated more aggressively; workload tokens may need automation-friendly renewal, but still require strict scope and rotation. Security teams should avoid treating all token abuse the same. The real question is whether the token can be replayed, whether it is tied to a device or workload identity, and whether the environment can revoke it fast enough when behaviour changes.

Related resources from NHI Mgmt Group

• How should security teams implement phishing-resistant MFA for privileged SaaS access?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams respond when they discover stolen OAuth or session tokens?