Many organizations use identity providers to centralize and manage login to a wide variety of applications and resources across the enterprise. Rather than maintaining separate credentials for every tool, platform, or cloud service, most companies route authentication through a common identity layer that serves as the authoritative source of who a user is and how they should be treated.

Within this model, identity providers are not merely login portals; they function as the control plane for access to much of the organization’s digital environment. By consolidating authentication in one place, enterprises can apply consistent security policies—such as multi-factor authentication, device checks, and risk-based access—while reducing friction for users who would otherwise face dozens of separate sign-ins. The practical benefits of this approach are clear, but they come with an important tradeoff: trust becomes concentrated in a relatively small number of systems that many applications depend upon.

Among the protocols that enable this delegation, SAML 2.0 remains one of the most widely deployed mechanisms for federating identity to cloud and SaaS applications. For millions of users, SAML operates invisibly whenever they click “Sign in with company account.” Precisely because it is so pervasive, any fundamental weakness in how SAML establishes trust can have consequences that extend across an organization’s entire application ecosystem.

The Golden SAML attack illustrates this dynamic. Rather than stealing passwords or tricking users, it shows how compromising the cryptographic foundation of SAML can allow an attacker to fabricate legitimacy at scale. First publicly detailed by CyberArk researchers in 2017, Golden SAML was initially treated as a theoretical concern by many in the industry. That changed in 2020, when the SolarWinds/SUNBURST investigation revealed that APT29 (Cozy Bear), a sophisticated Russian state-sponsored threat actor, had deployed this technique at scale against U.S. government agencies and enterprises as part of one of the most consequential supply chain attacks in history. Golden SAML was no longer hypothetical—it was a weapon of choice for nation-state adversaries operating at the highest levels of sophistication.

Understanding this attack is therefore a way to understand both the strength and the fragility of modern federated identity. This article builds from first principles: what SAML is and how it works, why the trust model is powerful, how Golden SAML undermines it, and what organizations can do to protect themselves.

The Role of the Identity Provider

In traditional authentication architectures, each application is responsible for verifying user identity. A user presents credentials—typically a username and password—and the application checks them against a local directory. This model is conceptually simple but operationally brittle. Every new application requires a new account, new credentials, and new security controls. Over time, this leads to sprawl: duplicate identities, inconsistent policies, and a large attack surface.

Federated identity replaces this pattern with delegation. Instead of authenticating users itself, an application (the Service Provider, or SP) relies on a trusted third party—the Identity Provider (IdP)—to perform authentication and attest to the user’s identity. The application’s job shifts from “prove who you are” to “trust what the IdP says about who you are.”

This delegation creates significant benefits. Administrators can manage access centrally. Users enjoy a seamless experience across services. Security teams can enforce consistent controls, such as MFA, without modifying each application individually. From an architectural standpoint, the IdP becomes a control plane for identity.

But this design also concentrates risk. The more systems that rely on a single identity provider, the more consequential its compromise becomes. If an attacker gains access to a single application, the damage may be localized. If they undermine the identity provider itself, they gain leverage over many systems at once.

In this sense, identity providers are both enablers of security and potential single points of failure. How they communicate trust to applications therefore matters enormously. For many organizations, that communication happens primarily through SAML.

How SAML 2.0 Works

At a high level, SAML 2.0 is the protocol many organizations use to translate a local authentication event—“this user successfully logged in”—into a portable, verifiable statement that other applications are willing to trust. Instead of every application maintaining its own credential database or prompting users for passwords, SAML creates a standardized way for an identity provider to make an authoritative claim about a user and for a service provider to accept that claim without ever seeing the user’s secrets. What is exchanged across the network is not a username and password, but a structured, cryptographically signed XML document that represents identity at a specific moment in time. Understanding this shift—from shared secrets to signed assertions—is the foundation for understanding both why SAML works so well in practice and why the Golden SAML attack is so consequential.

What is SAML?

SAML is best understood as a language for delegated authentication. Rather than asking each application to prove who a user is, SAML allows one trusted system—the identity provider—to authenticate the user once and then speak authoritatively about that user to many different applications.

In a typical SAML interaction, the user still experiences something that looks like a normal login, but the trust boundary has moved. When a user tries to access an application, that application redirects the user’s browser to the identity provider. The identity provider performs whatever authentication the organization requires—password, multi-factor authentication, device checks, or risk evaluation. Once satisfied, the identity provider does not send credentials to the application. Instead, it creates a SAML assertion: a formal XML document that says, in effect, “this is who the user is, they authenticated at this time, and these are their attributes.”

That assertion is returned through the user’s browser and presented to the application. From that point forward, the application’s confidence in the user is entirely based on the assertion it receives from the identity provider. In other words, SAML replaces repeated credential checks with a single, signed statement that can be reused across multiple services.

This design is what makes SAML powerful at scale. A user can authenticate once to the identity provider and then access many applications, each of which relies on the same cryptographically protected message rather than performing its own login process.

Digital Signatures

The trustworthiness of a SAML assertion does not come from its content alone—it comes from how it is signed. Every identity provider maintains a private cryptographic signing key that is used specifically for SAML.

When the identity provider creates an assertion, it first builds a structured XML document describing the user and the context of authentication. It then applies a standard XML Digital Signature process: the relevant parts of the document are normalized, hashed, and signed with the IdP’s private key. That signature is embedded directly inside the SAML message.

This design has two critical effects. First, it proves origin: only someone in possession of the private key could have produced that signature. Second, it protects integrity: if any part of the assertion were modified in transit, the signature would no longer validate.

The corresponding public certificate for this signing key is shared in advance with each service provider when the federation relationship is configured. Applications are pre-provisioned with this certificate so they know exactly which key they should trust when validating incoming assertions.

The entire SAML trust model therefore rests on a single operational assumption: the identity provider’s private signing key remains secret and under its exclusive control. If that key is exposed, the system can no longer reliably distinguish real assertions from forged ones.

How Assertions Are Verified

When the application receives a SAML assertion, it does not re-authenticate the user and it does not check a password. Instead, it acts purely as a verifier of the identity provider’s claim.

The service provider performs three primary checks. First, it validates the digital signature using the IdP’s public certificate. If the signature is valid, the application knows the assertion must have been created using the trusted private key. Second, it confirms that the assertion is intended for this specific application, typically by checking the audience field in the XML. Third, it ensures the assertion is within its valid time window so that old tokens cannot be replayed indefinitely.

If these checks succeed, the service provider treats the user as authenticated and creates a local session for them. From that moment on, access is granted based on the attributes in the assertion rather than any direct proof from the user.

The key takeaway is that in SAML, authentication is effectively outsourced to the identity provider, and the application’s confidence in the user is mediated entirely by cryptography and prior configuration—not by the user’s credentials. This is what makes SAML both efficient and, in the case of a compromised signing key, dangerously powerful.

The Golden SAML Problem

Having established how SAML is designed to work, the weakness in the model becomes easier to see. The protocol itself is not flawed in any obvious way: assertions are structured, digitally signed, time-bound, and explicitly scoped to specific applications. The service provider does exactly what it is supposed to do—it validates the signature, checks the audience, and ensures the token is still within its validity window. If those checks pass, it grants access.

The problem is not in these steps; it is in the single operational assumption that underpins all of them: only the identity provider should ever possess the private signing key used to create valid SAML assertions. As long as that key remains secret and under the IdP’s exclusive control, the system functions as intended. But if that assumption fails, everything built on top of it collapses.

If an attacker were able to obtain the identity provider’s private signing key—even temporarily—they would no longer need to compromise users, guess passwords, or defeat multi-factor authentication. With the key in hand, they could construct their own SAML assertions that look, from a cryptographic standpoint, indistinguishable from those issued by the real identity provider.

This is the essence of the Golden SAML problem. A “Golden SAML” token is not a new kind of protocol artifact; it is simply a forged SAML assertion that happens to be signed with the legitimate signing key. Because the signature validates correctly, every federated application that trusts that key will treat the token as authentic, regardless of how it was created.

The implication is profound. Password resets do nothing, because the attacker never uses a password. Multi-factor authentication offers no protection at the service provider layer, because the application believes authentication has already occurred at the identity provider. From the perspective of downstream systems, a Golden SAML token is functionally equivalent to a real one.

In other words, once the private signing key is compromised, the boundary between legitimate and illegitimate authentication effectively disappears. At that point, the attacker does not need to “log in” at all—they can simply mint identity.

This insight sets the stage for understanding the attack itself: if the signing key is the linchpin of SAML trust, then stealing it enables an adversary to fabricate valid identity assertions at will.

The Golden SAML Attack

Golden SAML is best understood as an attack on delegated trust, not on authentication prompts. In a normal SAML flow, the identity provider authenticates the user and then produces a signed assertion that downstream applications accept as proof of identity. The Golden SAML attack inverts this relationship: rather than persuading the identity provider to issue a token, the attacker steals the identity provider’s signing authority and uses it to manufacture tokens directly. Once the attacker can produce a correctly signed assertion, the service provider has no cryptographic basis to distinguish a forged token from a legitimate one.

Obtaining the Identity Provider’s Private Key

The decisive prerequisite for Golden SAML is control of the identity provider’s private token-signing key. This key is what gives SAML assertions their authority. It is the cryptographic root of trust that service providers rely on when they validate incoming assertions. In other words, the key is not just a credential—it is the identity provider’s ability to speak convincingly on behalf of users.

In practical terms, obtaining this key generally implies that the attacker has already achieved a meaningful level of compromise. Golden SAML is rarely an initial access technique; it is typically an escalation and persistence technique that becomes viable once an attacker reaches the identity layer. In the SolarWinds intrusions, for example, APT29 first established a foothold through a trojanized software update, then moved laterally over weeks or months until reaching identity infrastructure—at which point they extracted ADFS signing certificates and began forging assertions for cloud services including Microsoft 365. The patient, methodical nature of that intrusion illustrates why Golden SAML is categorized under MITRE ATT&CK as technique T1606.002 (Forge Web Credentials: SAML Tokens), sitting firmly in the credential access phase rather than initial access.

The critical point is that the attacker does not need to “break” cryptography. They need to do something far more operational: extract or access the private key material that the identity provider uses to sign assertions. Once that key is exposed, the attacker inherits the identity provider’s authority in the federation.

There is an important conceptual nuance here. Many organizations focus their identity threat model on accounts, passwords, and MFA. Golden SAML demonstrates that the signing key is often a higher-value target than any individual user credential. Credentials prove identity once; a signing key can create identity assertions repeatedly. It is a credential multiplier.

Understanding What the Service Provider Expects

Possessing the signing key is necessary, but not sufficient. To forge an assertion that an application will accept, the attacker must understand the shape of the federated relationship: what the service provider expects to see, what identifiers it relies on, and what claims drive authorization.

In real environments, service providers do not accept arbitrary assertions. They expect assertions with a specific issuer identity, a specific audience, a recognizable subject format (how users are represented—email, UPN, persistent identifier, and so on), a set of attributes that the application uses for access control (roles, groups, entitlements), and valid time conditions and other protocol-level constraints that match normal SAML behavior.

An attacker who wants to impersonate a user must therefore craft an assertion that matches these expectations. This is not especially difficult once the attacker has visibility into federation configuration, application metadata, or observed SAML traffic, but it is a real step. It is the difference between forging a document that is “signed” and forging a document that is “accepted.”

This is also where Golden SAML becomes more than simple impersonation. If an application uses claims to determine privileges—such as administrative roles or group-derived access—the attacker can craft assertions that not only identify them as a target user, but also embed attributes that elevate what that identity can do in the application. In environments where authorization is heavily claim-driven, a forged assertion can be used not only to “be” a user, but to be a more privileged version of that user.

Constructing a Forged SAML Assertion

Once the attacker understands the federation expectations, they can construct a SAML assertion as if they were the identity provider, mirroring the same elements a legitimate assertion would contain. The attacker selects a target identity—often a high-privilege user—and sets the assertion’s subject accordingly. They bound the assertion to the service provider by setting the appropriate audience. They set validity conditions that make the token appear timely and plausible. They include whatever attributes are required for the application to accept and authorize the session.

The forged assertion then becomes operationally dangerous the moment it is signed. The attacker computes the signature in the same way the identity provider would: the assertion is canonicalized, hashed, and signed with the stolen private key. The resulting signature is embedded into the XML document.

From the service provider’s perspective, the verification process is straightforward: it validates the signature using the public certificate it already trusts, checks audience and timing constraints, and grants access. The service provider has no concept of “who actually generated this” beyond the cryptographic fact that the trusted signing key was used.

It is worth noting that tooling to automate this process exists and is accessible to attackers with moderate technical capability. Golden SAML is not exclusively a nation-state technique; the barrier to execution, given access to the signing key, is relatively low. This makes protecting the key itself—rather than relying on the complexity of the attack—the correct defensive orientation.

Replaying Assertion Against the Service Provider

With a signed forged assertion in hand, the attacker’s final step is to present it to the service provider’s SAML assertion consumer endpoint—the receiving surface where valid SAML responses are delivered. This replay step bypasses every control that defenders typically associate with “the login flow.” Password checks, MFA prompts, and device challenges all occur at the identity provider during interactive authentication. Golden SAML skips that process entirely.

As a result, the service provider’s behavior is indistinguishable from normal SAML SSO. It receives an assertion, verifies it, and creates a session. The user identity inside the assertion becomes the attacker’s identity inside the application, even though the real user never authenticated.

This is also where the attack gains its practical persistence. As long as the service provider continues trusting the compromised signing certificate, the attacker can mint new assertions at will—for any user, at any time, without maintaining malware on endpoints or repeatedly phishing users.

The Practical Consequence

At the end of the sequence, the attacker’s advantage is not merely access—it is legitimacy. The service provider is not behaving incorrectly. It is doing exactly what it was designed to do: trust assertions signed by a configured identity provider. The assertion validates. The session is created. Authorization decisions are made based on claims that appear legitimate.

Golden SAML is therefore fundamentally different from phishing or password theft. In those attacks, the attacker acquires authentication artifacts that already exist and reuses them. In Golden SAML, the attacker manufactures a new identity artifact from first principles. The core of the attack can be summarized simply: steal the IdP signing key, sign your own assertions, and replay them to service providers to gain access as any user.

Cloud Identity Providers and OIDC

The attack described above has been most extensively documented in the context of on-premises identity providers, particularly Active Directory Federation Services (ADFS). However, the underlying risk is not unique to on-premises deployments.

Cloud-hosted identity providers—including Microsoft Entra ID (formerly Azure AD), Okta, and Ping Identity—manage signing keys on behalf of their customers. In many respects, this reduces risk: the cloud provider applies hardened key storage, manages rotation, and abstracts direct access to key material in ways that on-premises deployments often do not. An attacker who compromises an enterprise’s Okta tenant, for example, may not be able to extract the underlying SAML signing key in the same way they could from an exposed ADFS server.

That said, cloud IdPs introduce their own attack surfaces. Compromising a highly privileged cloud IdP administrator account, abusing API access, or exploiting misconfigurations in federation trust relationships can achieve analogous outcomes without ever touching a private key directly. The principle remains the same: whoever controls the identity layer controls access.

Similarly, organizations migrating from SAML to OpenID Connect (OIDC) should not assume they have eliminated the category of risk. OIDC uses JSON Web Tokens (JWTs) signed with the IdP’s private key in an architecturally similar way. A compromised OIDC signing key enables analogous token forgery. The protocol differs; the threat model does not.

Why Golden SAML Matters

Golden SAML is significant not because it exploits a subtle bug in SAML, but because it exposes a deeper truth about how modern enterprises are built. Over the past decade, organizations have deliberately concentrated trust in identity providers to make security and access management more manageable. That decision has delivered enormous benefits—fewer passwords, consistent policies, and a more coherent security posture—but it also means that identity has become a form of critical infrastructure. When the trust anchor of that infrastructure is compromised, the impact is not localized; it is systemic.

In many environments, dozens or even hundreds of applications rely on a single identity provider and a single SAML signing key. Under normal circumstances, this is an elegant design: one authentication event can unlock access to an entire ecosystem of services. Golden SAML turns that same design into a liability. If an attacker controls the signing key, they effectively control the enterprise’s identity layer. What began as a tool for convenience becomes a universal impersonation mechanism.

What makes Golden SAML particularly disruptive is that it undermines many of the assumptions defenders rely on. Password resets are irrelevant—the attacker never needs them. MFA is bypassed at the application layer because the service provider believes authentication has already occurred. And there is no single session to invalidate, no obvious foothold to evict. The attacker can generate new signed assertions on demand, for any user, for as long as the compromised key remains trusted.

Golden SAML also changes how we should think about persistence. Traditional intrusions often depend on malware, stolen sessions, or compromised accounts that can be detected and revoked. Signing key compromise is different: it is quieter, more durable, and harder to fully recover from without a complete rekeying of federation trust.

Detection Challenges

Detecting Golden SAML attacks is difficult precisely because the artifacts involved are designed to be trusted. From the service provider’s perspective, a forged token is not anomalous in a cryptographic sense—it is correctly signed, properly formatted, and scoped to the right application. The systems are behaving as intended; what is broken is the assumption about who controls the signing key.

This creates a fundamental visibility problem. Many security monitoring tools focus on suspicious behavior at authentication: failed logins, unusual password attempts, MFA fatigue patterns, or risky device characteristics. Golden SAML largely bypasses these signals because the attacker does not participate in an interactive login flow. There may be no authentication event at the identity provider at all, even though the service provider records a successful sign-in.

Some of the most promising detection approaches rely on cross-system correlation. Defenders may look for instances where a service provider records a successful SAML login but the identity provider has no corresponding authentication event for that user. This mismatch does not prove an attack on its own, but it is a strong indicator that something is wrong with the trust relationship. For ADFS environments specifically, security audit logs (Event IDs 1200, 1201, and 4624 combined with ADFS audit events) can provide the raw material for this correlation in a well-tuned SIEM.

Other signals include unexpected sign-ins for highly privileged accounts that do not align with normal usage patterns, activity originating from unusual locations or devices despite a valid SAML assertion, and—in forensic analysis—subtle inconsistencies in how claims are structured or how timestamps are set in the assertion XML.

MITRE ATT&CK documents this technique as T1606.002 (Forge Web Credentials: SAML Tokens), and organizations building detection logic can use that entry as a starting point for mapping to relevant data sources including Windows Security event logs, IdP audit logs, and cloud application sign-in logs. Cross-correlating identity provider authentication events with service provider access logs across a SIEM is the most reliable path to surfacing the key signal: a valid assertion with no corresponding authentication event.

The deeper challenge is that Golden SAML sits at the boundary between identity and infrastructure. Many security operations centers are not yet structured to monitor identity providers and service providers as a single, integrated system. Without that holistic view, Golden SAML can remain effectively invisible.

Designing for Resilient Federation

If Golden SAML teaches anything, it is that federated identity security is ultimately a problem of key management and operational design, not protocol mechanics. Effective defense requires thinking less about user authentication and more about how identity infrastructure is built, isolated, monitored, and recoverable. The goal is twofold: make it materially harder for an attacker to obtain the signing key in the first place, and ensure that if compromise does occur, its impact can be contained and reversed.

Protecting the SAML Signing Keys

The most important mitigation is to treat identity providers not as ordinary application servers, but as tier-zero security assets—systems whose compromise would undermine the entire enterprise.

At a minimum, this means restricting administrative access to identity infrastructure far more aggressively than typical business applications. Privileged accounts that can manage certificates, keys, or federation settings should be tightly controlled, monitored, and isolated from general-purpose environments. Routine workstation credentials should never be able to reach identity provider systems, and lateral movement paths from less sensitive parts of the network should be minimized.

Equally important is how the signing key itself is stored. Wherever possible, organizations should rely on hardware security modules (HSMs) or similarly hardened key storage mechanisms. A properly configured HSM can prevent direct extraction of private key material even when the underlying server is compromised—forcing all signing operations to be performed inside the HSM rather than exposing the raw key to software processes.

It is important to understand what an HSM does and does not protect against, however. An HSM prevents key extraction, but it does not prevent an attacker who has fully compromised the identity provider host from using the HSM to sign arbitrary assertions at runtime. The HSM ensures the key cannot be copied and used elsewhere; it does not prevent misuse on the compromised host itself. This distinction matters for threat modeling: HSMs raise the bar significantly, but they are not a complete solution in the absence of strong access control and monitoring around the identity infrastructure.

Organizations should also prefer non-exportable signing keys, so that even a compromised system does not trivially yield a portable private key file. This raises the operational cost for an attacker and reduces the likelihood that a single breach turns into universal impersonation.

Reducing Blast Radius

Many organizations use a single SAML signing key for all federated applications. This is convenient but creates a single point of catastrophic failure. A more resilient architecture assigns separate signing keys to different service providers or application groups. If one key is stolen, the attacker can forge assertions only for the applications that trust that key—not for the entire ecosystem.

This approach introduces operational complexity: more certificates to rotate, more federation metadata to manage, and more careful coordination between identity and application teams. But from a security perspective, it transforms a binary risk into a graduated one. In high-risk environments—especially those with privileged access to cloud administration, financial systems, or sensitive data—this tradeoff is often worthwhile.

Recovery After a Signing Key Compromise

If there is credible evidence that a SAML signing key has been exposed, organizations must assume that every service trusting that key may have been accessed illegitimately. Response is not a routine maintenance task—it is an identity incident with enterprise-wide implications.

The first step is certificate rotation: generating a new signing key, publishing a new public certificate, and updating trust relationships with all affected service providers. This process can be disruptive, because every federated application must be reconfigured to trust the new key. However, it is the only reliable way to invalidate forged Golden SAML tokens.

Simultaneously, defenders should review access logs across both identity providers and service providers to identify suspicious activity that may have occurred while the key was compromised. Because Golden SAML can bypass normal authentication signals, this often requires looking for patterns such as administrative actions performed without corresponding identity provider logins, or unusual bursts of access from unexpected locations.

Crucially, organizations should treat this as a systemic identity breach, not merely a server compromise. Resetting user passwords alone is insufficient. Tightening MFA policies does not address the root issue if service providers are still trusting a compromised key.

In practice, recovery often involves a broader reassessment of identity infrastructure security: revisiting access controls, auditing key storage mechanisms, improving monitoring, and in some cases redesigning federation architecture to reduce future risk.

Prevention Over Detection

A recurring theme across all of these mitigations is that prevention and containment matter more than detection. Golden SAML is difficult to spot after the fact because forged assertions are valid by design. Once an attacker controls the signing key, their activity can blend seamlessly into normal system behavior.

For this reason, organizations must invest disproportionately in protecting the trust anchor—the identity provider and its signing keys—rather than relying solely on downstream monitoring. The security of SAML is ultimately the security of the enterprise.

Key Takeaways

SAML itself is not broken. As a protocol, it rests on well-understood and rigorously tested cryptographic primitives, and it has enabled one of the most successful models of enterprise identity ever deployed. That strength, however, is inseparable from its risk: the same mechanism that lets legitimate users move seamlessly across an enterprise can, if its trust anchor is compromised, grant an attacker the same breadth of access just as seamlessly.

Golden SAML does not expose a flaw in SAML’s mathematics; it exposes a fragility in how federated trust is operated in practice. The SolarWinds intrusions demonstrated this at a scale that should have permanently recalibrated how the industry thinks about identity infrastructure. Nation-state adversaries went after signing keys because signing keys are worth more than any individual credential. That calculus has not changed.

When identity becomes the gateway to everything, the private keys that authorize identity assertions become among the most sensitive assets an organization possesses. Protecting those keys—through hardened infrastructure, careful privilege management, hardware-backed storage, monitoring, and thoughtful federation design—is therefore not a niche technical concern but a core security responsibility. Equally important is designing identity architectures that limit blast radius, so that a single failure does not automatically become an enterprise-wide one.

Ultimately, the lesson of Golden SAML is not that federated identity should be avoided, but that it must be treated with the seriousness it deserves. In a world where identity is the perimeter, whoever controls the signing key controls the enterprise. Protect it accordingly.