How should security teams detect session token replay when MFA and conditional access never trigger?

Security teams should combine sign-in controls with session behavior analysis. A stolen session cookie can replay an authenticated session without a password or MFA prompt, so the key signal is what happens after access is granted. Compare repository access, time of day, device posture, and application sequence against the user’s normal pattern, then challenge or revoke sessions that diverge sharply.

Why This Matters for Security Teams

Session token replay is dangerous precisely because MFA and conditional access often already succeeded before the attack begins. A stolen browser cookie or bearer token can impersonate a valid user without triggering another login challenge, which means perimeter-style controls can look healthy while an attacker is already inside. Security teams need to watch the session after authentication, not just the authentication event. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s analysis of token exposure in the The 2025 State of NHIs and Secrets in Cybersecurity both point to the same operational problem: long-lived, replayable tokens create an authentication gap that identity systems do not reliably detect.

That gap matters because replay attacks usually blend into normal access paths. A token can be reused from a new device, a different network, or an automated script that behaves just enough like the original session to avoid obvious alarms. Teams that only alert on failed MFA, impossible travel, or blocked sign-ins will miss the more common case: a valid session being reused quietly. In practice, many security teams encounter replay only after sensitive data has already been accessed through a session that never looked suspicious at login time.

How It Works in Practice

Detection starts by treating the session as the security boundary. Instead of asking whether the user authenticated, ask whether the session is behaving like the authenticated user would. That means correlating session telemetry with repository access patterns, application sequence, time of day, device posture, geo-velocity, and request cadence. If a token suddenly reads source code, exports data, and then pivots into admin screens in a pattern the user has never shown, that is stronger evidence of replay than another MFA prompt ever would be.

Security teams should also distinguish between user identity and workload identity. A valid browser session, API bearer token, or refresh token may not prove that the same human or device is still present. For that reason, controls such as step-up challenges, session binding, token family invalidation, and short TTLs are more effective than static allowlists alone. NHIMG’s Salesloft OAuth token breach shows how OAuth tokens can be abused after the initial grant, while the Guide to the Secret Sprawl Challenge highlights how widely exposed credentials create the conditions for replay.

• Baselining should focus on session-level behaviour, not just login success.
• Detection rules should flag impossible application sequences, not only impossible travel.
• High-value sessions should be short-lived and revalidated when context changes.
• Token revocation must be automated, because detection alone is too slow for active replay.

When possible, pair SIEM alerts with IdP logs, reverse proxy telemetry, endpoint posture, and app-layer audit events so the attack chain can be reconstructed end to end. These controls tend to break down in SSO-heavy environments with sparse application logging because the replayed token looks legitimate at the identity layer while the real abuse is visible only inside the application.

Common Variations and Edge Cases

Tighter session controls often increase friction for legitimate users, so organisations have to balance replay resistance against help desk load and workflow interruption. That tradeoff becomes sharper in high-velocity environments where users move between managed laptops, VDI, mobile devices, and browser-based SaaS within the same day.

There is no universal standard for this yet, but current guidance suggests a layered approach: shorten token lifetimes for sensitive apps, bind sessions to device or client characteristics where feasible, and invalidate sessions when risk signals change materially. The NHI Lifecycle Management Guide is relevant here because stale or overextended credentials make replay much easier, especially when offboarding and rotation are inconsistent.

Edge cases matter. Shared kiosks, service desks, CI/CD runners, and automated browser tasks can all look like replay if the detection model is too rigid. That is where policy tuning and exception handling become essential. The NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this kind of continuous monitoring and access enforcement, but best practice is evolving around exactly how much behavioural deviation should trigger revocation versus review.

Related resources from NHI Mgmt Group

• How should security teams detect token theft if MFA was already completed?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?