SAML, the Security Assertion Markup Language, is the older of the two protocols that make enterprise single sign-on work. When you log into a corporate app through SSO, your browser is bounced to an identity provider (IdP): Active Directory Federation Services, Okta, Entra ID, or similar. You authenticate there, and the IdP hands your browser a signed XML document called an assertion. The assertion says who you are, which groups you belong to, when it was issued, and how long it is valid. Your browser passes it to the application, the service provider, which checks the signature against the IdP's public certificate and, if it validates, logs you in.
The signature is the whole trust model. The service provider does not re-check your password. It does not phone the IdP back. It trusts the assertion because it is signed by a key it already trusts. That design is what makes SSO convenient, and it is exactly the pivot Golden SAML abuses.
Steal the Signing Key, Become Anyone
The name is a deliberate echo of Golden Ticket, the Kerberos attack where compromising a domain's master secret lets an attacker forge tickets for any account. Golden SAML, named by researchers at CyberArk in 2017, is the federation-layer version. Instead of the Kerberos krbtgt hash, the prize is the private key of the IdP's token-signing certificate.
With that key in hand, an attacker does not need to log in, and does not need a password, an MFA token, or a live connection to the IdP. They generate a SAML assertion from scratch, fill in whatever username and group memberships they want, sign it with the stolen key, and present it to any service provider that trusts that IdP. The signature validates, because it is a real signature from the real key. The service provider has no way to tell a forged-but-signed assertion from a legitimate one.
Multi-factor authentication happens when a user proves their identity to the identity provider. Golden SAML forges the assertion the IdP produces afterward, so it starts after the point where MFA would have run. The attacker is not logging in. They are impersonating the record that says a login already happened.
The SolarWinds Connection
Golden SAML moved from research curiosity to headline technique during the SolarWinds intrusion disclosed in December 2020. The attackers had deep access to victim networks through the compromised Orion software update. In several environments, investigators found they had reached the ADFS servers and stolen the token-signing key. From there they forged SAML tokens to authenticate to cloud services, including Microsoft 365, as chosen users, including highly privileged ones. Because the tokens were validly signed, the access looked like normal federated login in the logs.
This is what made that part of the breach so hard to detect and so hard to evict. Resetting user passwords does nothing, because no password was used. Requiring MFA does nothing, because the assertion is forged past that step. Until the signing certificate is rotated and the old key invalidated everywhere, the attacker can keep minting valid logins. The technique also generalizes beyond forging brand-new tokens: attackers with the key have modified attributes on tokens and abused related trust in cloud identity platforms, which is why the broader family is often discussed together.
Why This Class of Attack Keeps Working
Golden SAML sits in a structural blind spot. It is not a vulnerability in SAML that a patch can fix. The protocol is doing exactly what it was designed to do: trust a valid signature. The failure is that a single high-value secret grants total impersonation, and the systems that consume assertions have no independent way to sanity-check them.
A forged assertion signed with the real key is indistinguishable from a legitimate one. The defense cannot live in the verifier. It has to live in protecting the key and in detecting the theft.
There is a broader lesson about centralized trust here. XML signature handling has its own long history of parsing bugs, XML signature wrapping attacks that trick a verifier into checking one element while trusting another, so implementation flaws can sometimes forge assertions without even stealing the key. But the clean version of the attack needs no bug at all, only the key.
What Actually Reduces the Risk
| Defense | What it does |
|---|---|
| Keys in an HSM | Store the token-signing key in a hardware security module so it can sign but cannot be exported. Raises the cost of the primary attack from copying a file to compromising hardware. |
| Guard the IdP host as tier zero | The federation server is as sensitive as a domain controller. Treat administrative access to it accordingly; most Golden SAML incidents start with the attacker already owning that box. |
| Rotate signing certificates | Regular, and immediate on any suspicion of compromise. A stolen key stays useful until it is invalidated, so short-lived keys shrink the window. |
| Monitor assertions and sign-ins | Watch for tokens with unusual lifetimes, logins with no matching IdP authentication event, and sign-in properties that do not match a real interactive login. |
| Shorten token lifetimes | Long-lived assertions give forged tokens more room. Tighter lifetimes force more frequent legitimate reissuance, narrowing the value of a single forgery. |
Notice what none of these do: none of them let the service provider detect a forged token in the moment. That limitation is intrinsic to how federated trust works. The whole strategy is to protect the signing key so it is never stolen, and to detect the theft fast if it is.
Golden SAML is a useful thing to understand even outside an enterprise SSO team, because it illustrates a pattern that recurs across security: a system that concentrates trust in one key inherits the full blast radius of that key's compromise. The same reasoning is why the DNSSEC root key gets a filmed ceremony, why JWT verification has to be done with the same care, and why hardware security modules exist at all. If you work with SSO, the adjacent reading is our post on OAuth phishing, which attacks the same federated-identity layer from the user's side rather than the key's.