Security teams should monitor sessions across SaaS applications, not just the identity provider, because stolen cookies can bypass login controls after MFA succeeds. Effective defense depends on correlating authentication and activity events, detecting abnormal IPs or user agents, and revoking all affected application tokens during response. Shorter session timeouts also reduce the attacker’s window for persistence.
Why Pass-The-Cookie Works in SaaS
Pass-The-Cookie attacks exploit the fact that a valid session cookie can function as a bearer credential after authentication has already succeeded. In SaaS, that means the attacker is not trying to log in the normal way, they are trying to replay a trusted session and inherit the application’s existing trust, often without triggering the same checks that protect initial sign-in.
The practical problem is that many teams centralise visibility around the identity provider and miss what happens inside the SaaS application itself. A session can remain useful even after the original login has ended, especially if the application accepts the cookie across devices, geographies, or long-lived browser sessions.
That is why session telemetry matters as much as authentication telemetry. A Salesloft OAuth token breach shows the same basic pattern of stolen bearer material being replayed to reach SaaS data, while Snowflake breach illustrates how access can persist when defenders do not treat the session itself as the security boundary.
What Defenders Need to Monitor and Control
Defence starts with correlating identity events, session events, and application activity. Security teams should look for a session that appears valid but behaves unlike the user who created it, such as a sudden change in IP range, user agent, device fingerprint, or request cadence. Those are not proof of compromise by themselves, but they are strong indicators that the session is being replayed or shared.
It is also important to treat SaaS token and cookie invalidation as a response action, not just an identity-provider action. If an attacker has already captured the cookie, password resets or MFA prompts may not be enough unless the active application session is also revoked. That principle is consistent with cases such as Dropbox Sign breach, where exposed session-related material and tokens broadened the impact beyond the original access path, and Sisense breach, where stolen access material became the real enabler of downstream access.
Shorter session lifetimes, step-up authentication for sensitive actions, and tighter SaaS session policies all reduce the attacker’s usable window. If the platform allows conditional reauthentication for high-risk actions, that can also limit what a replayed cookie can accomplish even before it is fully invalidated.
Risk and Threat Considerations
Pass-The-Cookie is dangerous because it turns one successful login into a reusable access path. The highest risk appears in SaaS tenants with long session duration, weak session binding, poor device visibility, or response playbooks that only target the identity provider while leaving the application session alive.
Failure mechanism: An attacker steals a valid browser cookie or similar session artifact, replays it from another context, and inherits the authenticated state without needing to defeat MFA again.
Impact: The attacker can access data, perform actions as the user, and persist until the application session is expired or explicitly revoked, which can extend blast radius well beyond the original sign-in event.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5.1 — Account Management | Session replay defense depends on active account and session lifecycle control in SaaS. |
| 6.3 — Access Control Management | Cookie replay bypasses normal sign-in, so access enforcement must include session state. | |
| 8.2 — Audit Log Management | Detection requires correlating identity and application activity to spot anomalous session use. | |
| Recommendation — Inventory active SaaS sessions and revoke compromised access paths immediately during response. Apply access controls that evaluate session context and revoke risky sessions promptly. Correlate SaaS activity logs with authentication events to detect abnormal session replay. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Protecting SaaS sessions requires managing authenticated access beyond initial login. |
| DE.CM-01 — Monitoring for Anomalous Events | Abnormal IPs and user agents are anomalous session signals requiring detection. | |
| RS.MI-01 — Incidents are Contained | Stolen cookies must be invalidated quickly to contain active SaaS compromise. | |
| Recommendation — Extend identity controls to session monitoring and revocation across SaaS applications. Monitor SaaS session anomalies and alert on replay-like activity patterns. Contain compromise by terminating affected SaaS sessions and related tokens fast. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Session cookies are bearer material whose theft enables unauthorized access. |
| NHI-06 — Overprivileged Non-Human and Machine Identities | SaaS session abuse is worse when stolen access inherits excessive privilege. | |
| NHI-09 — Lack of Visibility and Monitoring | The attack is missed when teams cannot see application session behaviour. | |
| Recommendation — Protect bearer session material and rotate or revoke it immediately after exposure. Reduce blast radius by limiting privileges reachable through valid session material. Add SaaS session visibility so anomalous replay can be detected and investigated. | ||
| OWASP Agentic AI Top 10 | A7 — Tool and Action Authorization | Bearer session abuse is a form of unauthorized action through trusted access. |
| Recommendation — Constrain what any authenticated session can do and require step-up for sensitive actions. | ||
Practitioner Guidance
What to prioritise: Build response around session revocation coverage, not just account recovery. If your team can reset credentials but cannot terminate live SaaS sessions quickly, the containment model is incomplete.
What to verify: Confirm that you can enumerate active SaaS sessions, correlate them to users and devices, and revoke them centrally during incident response. If that visibility does not exist, treat the application as a blind spot rather than assuming the identity provider is enough.
Common mistake: Teams often overfit to MFA success or failed login alerts and miss post-authentication abuse. The compromise may begin after authentication, so the decisive evidence is usually abnormal session behaviour, not failed sign-in noise.
Practitioner takeaway: The control objective is to make stolen session material short-lived, observable, and easy to invalidate across the SaaS estate, because that is what actually breaks the attacker’s ability to keep using it.
Related resources from NHI Mgmt Group
- How should security teams defend against device code phishing in SaaS environments?
- How should security teams defend text classifiers against backdoor attacks in high-risk environments?
- How should security teams defend cloud-native environments against zero-day attacks when patches are not yet available?
- How should security teams defend against password spraying in hybrid identity environments?
