Traditional SSO has become an enterprise attack surface

At a glance

What this is: This is an analysis of how traditional SSO shifted from a convenience layer into a concentrated identity attack surface, with token replay and federated trust abuse as the key failure modes.

Why it matters: It matters because IAM teams, PAM teams, and identity architects must treat federation, session material, and transitive trust as blast-radius issues, not just login controls.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Unixi's analysis of why traditional SSO has become an attack surface

Context

Traditional SSO was built to reduce login friction, not to eliminate the security value of reusable authentication material. Once identity, sessions, and federation trust are concentrated in one place, compromise of that layer can create disproportionate access across the enterprise, especially where SaaS sprawl and cloud integrations have expanded the trust boundary.

The problem is not authentication alone, but the assumptions behind it. Modern SSO often depends on bearer tokens, federation assertions, and implicit trust between systems, which means a stolen session can outlive the original login event and be accepted elsewhere without new identity proof.

For IAM and NHI programmes, this creates a shared governance problem. Human identity flows, service account tokens, and federated application access now intersect in the same trust fabric, so blast-radius control must extend beyond passwords and MFA into session, token, and privilege containment.

Key questions

Q: What breaks when traditional SSO is treated as a safe default?

A: The main failure is blast-radius expansion. One authenticated session can unlock multiple downstream services, so compromise of a single token or assertion can cascade across the enterprise. That makes SSO a trust propagation problem, not just a login convenience problem, especially when applications accept upstream identity context without further containment.

Q: Why do MFA and SSO still fail against AiTM attacks?

A: MFA protects the login event, but AiTM attacks steal the approved session after the user has already passed verification. The attacker reuses cookies or tokens that the identity provider and downstream apps still trust. In practice, the weak point is session reuse, not the original password check.

Q: How do security teams know if federated trust is too broad?

A: Look for one identity event that can access many systems with little or no additional policy enforcement. If a compromise of the IdP, token, or assertion would expose email, SaaS admin tools, and sensitive business systems at once, the federation scope is too wide.

Q: How should organisations reduce the impact of a compromised SSO identity?

A: They should reduce the blast radius of a single authenticated session by limiting SaaS connectors, removing stale delegated access, and monitoring for unusual post-login activity. A compromised SSO identity becomes far more dangerous when it can reach multiple cloud apps without additional checks.

Technical breakdown

Why SSO concentrates blast radius

Single sign-on works by turning one authenticated identity event into access across multiple services. That makes operational sense, but it also means the security boundary moves from each application to the federation layer. If the IdP, assertion, or session context is compromised, the attacker does not need to reauthenticate for every downstream system. The problem is structural: the system is designed to propagate trust. In practice, that turns a successful compromise into a multiplier event, especially when applications accept upstream identity context without additional containment or revalidation.

Practical implication: map which downstream systems accept transitive trust from a single identity event and reduce how far that trust can propagate.

How token replay defeats MFA in SSO environments

MFA can stop password-only compromise, but it does not stop reuse of a valid session token. In AiTM attacks, the victim completes the login flow, including MFA, through a reverse proxy controlled by the attacker. The attacker then captures bearer artifacts such as cookies or OAuth tokens and reuses them until they expire or are revoked. Because these artifacts represent already-approved sessions, downstream services usually treat them as legitimate. This is why token replay is now a first-class identity attack primitive rather than a side effect of phishing.

Practical implication: treat session tokens and OAuth artifacts as high-value credentials and monitor for replay patterns, unusual issuance paths, and abnormal session reuse.

Federated trust and valid-account abuse in cloud identity

Federation was meant to reduce credential duplication, but it also creates a chain of trust that attackers can abuse once they obtain a valid identity artifact. Golden SAML, Seamless SSO abuse, and similar techniques show that the attacker does not need to break cryptography if they can mint or replay acceptable identity assertions. At that point, the issue is not access by force but access by trust. In cloud and SaaS environments, that means identity compromise often looks like normal traffic until the scope of lateral movement becomes visible.

Practical implication: build detection around anomalous federation use, impossible trust paths, and access patterns that do not fit normal identity propagation.

Threat narrative

Attacker objective: The attacker aims to turn one trusted login into broad, reusable access across the tenant without needing to crack credentials repeatedly.

1. Entry begins with phishing, AiTM interception, or another method that captures authentication material after a legitimate login flow completes.
2. Escalation occurs when the attacker reuses session cookies, OAuth tokens, or federated assertions to move from a single account into multiple connected services.
3. Impact follows when the compromised identity is used for mailbox access, internal phishing, business email compromise, or wider SaaS lateral movement.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSO has become an identity blast-radius amplifier. The original design goal was convenience, but modern federation has turned one successful login into a broad access multiplier. Once the attack surface includes session tokens, bearer assertions, and transitive trust, the relevant question is no longer whether authentication succeeded. It is how far that success can propagate before containment fails.

Token replay is now the operational weak point in many identity programmes. MFA does not meaningfully reduce risk when the attacker can replay the approved session after the user has authenticated. That means the control failure is not password strength or user verification alone, but the assumption that a successful login remains trustworthy for its full lifetime. Practitioners should treat this as a session governance problem, not just an authentication problem.

Federated trust was designed for pre-cloud access patterns. That assumption fails when a single IdP event unlocks dozens of SaaS services, each with its own business-critical data and administrative reach. The implication is that identity governance has to account for propagation scope, not only identity proof at the front door.

Transitive authentication trust is the named concept that best captures this failure mode. Once one identity event is automatically accepted by every connected application, compromise scales through the architecture instead of stopping at the first boundary. That is why traditional SSO often turns local compromise into tenant-wide exposure, and why blast-radius reduction must be treated as an identity design requirement.

Human IAM and NHI governance are converging on the same structural problem. Whether the credential is a user session, an OAuth token, or a service account secret, the issue is reusable trust with limited containment. The strongest programmes now govern identity propagation as a common risk across human, machine, and federated access paths.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how weak lifecycle governance remains.
• Read Ultimate Guide to NHIs , Static vs Dynamic Secrets for the lifecycle controls that reduce reusable-credential exposure.

What this signals

Transitive authentication trust is the design flaw that teams now need to measure directly. If a single login or token can move laterally across many SaaS services, the programme is relying on propagation rather than containment, and that should be treated as a governance defect rather than a convenience feature.

With 92% of organisations exposing NHIs to third parties, per Ultimate Guide to NHIs, identity programmes increasingly fail at the boundary between internal trust and external access. That same pattern is now visible in federated SSO, where the original access event outlives the security assumptions that created it.

For practitioners

• Contain federation trust paths Inventory which applications accept upstream identity assertions or tokens without additional checks, then reduce the number of systems that can be unlocked from a single authentication event. Focus on high-value SaaS, admin consoles, and mailbox access.
• Monitor for token replay indicators Add detection for impossible session reuse, unusual token issuance patterns, and access that originates from a different device or network context than the original login. Token replay is often the earliest sign that a valid session has been stolen.
• Shorten the lifetime of reusable identity material Review the lifetime and revocation path for session cookies, OAuth tokens, and SAML assertions. Where possible, reduce token validity windows and make revocation effective across all dependent applications, not only the original identity provider.
• Separate authentication success from authorization scope Do not assume a completed login justifies broad downstream access. Use conditional access, step-up controls, and application-specific policy checks for sensitive actions so compromise of one session does not automatically expose the full estate.
• Apply NHI-style blast-radius controls to federated access Treat tokens and assertions as non-human identity assets with lifecycle, containment, and offboarding requirements. The same governance discipline used for service accounts should apply to session-bearing access where transitive trust can expand impact.

Key takeaways

• Traditional SSO reduces friction but also centralises trust, which makes compromise of a session or assertion far more damaging than a single login event.
• The most important failure mode is not password cracking, but token replay and federated trust abuse that let attackers reuse legitimate identity material.
• IAM teams should measure how far one authenticated identity can propagate and then reduce that blast radius with tighter session, token, and authorization controls.

Key terms

• Transitive Authentication Trust: A trust model where one successful authentication event is accepted by multiple downstream systems without fresh verification. In SSO environments, this can create oversized blast radius because compromise of one session, token, or assertion can propagate access across the connected application estate.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
• AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.

What's in the full article

Unixi's full analysis covers the operational detail this post intentionally leaves for the source:

• The article's attack-mapping discussion of T1566, T1557, T1550.001, and T1078.004 in the SSO context
• The real-world Microsoft 365 AiTM campaign breakdown, including how session cookies and OAuth tokens were captured
• The comparison of Golden SAML, Seamless SSO abuse, SolarWinds, and Okta as examples of transitive trust failure
• The vendor's localisation and containment model for reducing replay and lateral movement in federated identity

👉 Unixi's full post covers the AiTM workflow, token replay mechanics, and the federation trust patterns behind lateral movement.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.