Golden SAML

Golden SAML is an attack in which someone who steals the secret key an organization uses to sign its single sign-on tokens uses it to forge new tokens. Cloud services that trust that key accept a forged token as proof that a chosen user signed in, although the organization's identity system never signed that user in.

Explain It Like I'm 10

Think of a school where every hall pass carries the principal's stamp. The teacher at each door does not phone the office. She checks the stamp and lets the kid through. If a kid steals the stamp, they can write any name on a pass, and every door that trusts that stamp lets it through. Golden SAML is the same trick: the stamp is a secret key, the doors are cloud services, and the pass is a sign-in token.

How does a SAML sign-in work, and what does the signing key do?

Many organizations let people sign in once and then reach many services. A service does not check the person itself. It relies on a sign-in token, a small signed statement that the organization's identity provider issues after it has checked who the person is. SAML (Security Assertion Markup Language) is a standard format for that token, which the standard calls an assertion. A typical one says that this user is a named person, with an email address, who was authenticated using a password.

That reliance is called trust, and a set of domains that have established trust is called a federation.

One common setup keeps authentication on the organization's own servers, using software such as Active Directory Federation Services (AD FS), and federates with Microsoft's cloud identity service, Microsoft Entra ID.

Why does a service believe a token?

Trust has to rest on something a service can check, and that something is a digital signature. The federation server signs every token it produces with a private key. The service checks the signature with the matching public key, which it receives in a certificate it is configured to trust. AD FS calls this certificate the token-signing certificate. Before a service reads a token's contents, it validates that signature.

The two parts do different jobs. The private key makes signatures. The public key, which sits in the certificate that services are given, can only check them, so the public certificate alone does not let anyone forge a token. Some sources quoted below use "certificate" as shorthand for the certificate together with its private key; the private key is what an attacker needs.

The private signing key is therefore what the trust rests on. A token passes the check if it was signed with that key, whoever did the signing.

How does Golden SAML work?

Golden SAML is a second-stage attack. The attacker first needs a deep foothold on the system that holds the signing key. CISA's advisory on the SolarWinds campaign describes an adversary compromising the SAML signing certificate with escalated privileges in the victim's network, and Mandiant's guidance says that if an attacker gets top-level access to an AD FS host, the signing key must be considered compromised.

What the key lets the attacker do

With the key, the attacker can forge tokens. MITRE ATT&CK, the public catalogue of attacker techniques, says an adversary may forge SAML tokens "with any permissions claims and lifetimes" if they possess a valid token-signing certificate (with its private key, since only the private key signs). The claims are what the token says about the user, such as which account it names and what that account may do. The attacker chooses them, including those of a highly privileged account.

The attacker then presents the token to services that trust the key. Each service validates the signature, and the check passes, because the token really is signed with the trusted key. A valid signature shows that the signer held the key. It cannot show whose hands held it. So the service treats the token as proof that the named user signed in.

That is also why the forgery leaves a gap. The identity system never signed that user in, so the sign-in that normally comes before a token has no counterpart on the organization's side.

Does Golden SAML get around multi-factor authentication?

It can, where the cloud service believes the token's account of how the user signed in. Multi-factor authentication (MFA) is a sign-in method that requires factors from at least two different categories: something you know, such as a password; something you have, such as a phone or hardware key; or something you are, such as a fingerprint. Two passwords are the same category, so they are not MFA. MITRE records that in the SolarWinds campaign, APT29 used forged SAML tokens "that allowed the actors to impersonate users and bypass MFA".

The mechanism is a claim. A token can say that the user already completed MFA at the identity provider. Microsoft's documentation explains that for a federated domain, MFA may be enforced by the cloud service or by the on-premises federation provider, and that if an administrator has set neither of two related MFA settings, Microsoft Entra ID defaults to accepting MFA that the federated provider performs. Microsoft describes the risk as a bad actor imitating a provider that already performed MFA.

What Microsoft's setting changes

Microsoft's answer is a setting called federatedIdpMfaBehavior. Set to the value rejectMfaByFederatedIdp, Microsoft Entra ID always performs MFA itself and rejects MFA that the federated provider performs. Microsoft says that enforcing Entra MFA every time assures that a bad actor cannot bypass it by imitating that the provider already performed MFA, and highly recommends it unless a third-party MFA provider performs MFA for the federated users. The page scopes the protection to apps governed by an administrator's Conditional Access policy that requires MFA.

The setting is Microsoft's and concerns Entra ID sign-ins; it does not decide what other services do with a forged token. Mandiant notes that a compromised AD FS signing key affects every service that trusts it, not just Microsoft's.

Is a forged token the same as a stolen session?

No. In adversary-in-the-middle phishing, a fake sign-in page relays a person's sign-in and the attacker copies the session cookie, the service's proof of sign-in. MITRE says the tokens in Golden SAML are "new and forged by the adversary, rather than stolen or intercepted from legitimate users". Theft copies a proof of sign-in that a real service issued. Forgery manufactures one that no one issued.

Which MITRE technique is Golden SAML?

MITRE files the forging under T1606.002, Forge Web Credentials: SAML Tokens. Golden SAML is often listed beside a different ID, T1484.002, Trust Modification, and the two are not the same thing.

T1484.002 covers changing the trust relationships between domains and tenants. Its own description gives SAML forging as one example: this may be used "to forge SAML Tokens without the need to compromise the signing certificate", because "an adversary can manipulate domain trusts to add their own signing certificate".

Two routes, told apart

So there are two routes to a token a service accepts: use the existing key, or make the service trust a new one. MITRE's SolarWinds campaign page separates them by wording: tokens created "using compromised SAML signing certificates" fall under T1606.002, and configuring the domain to accept tokens "signed by their own SAML signing certificate" falls under T1484.002. Golden SAML is the first route, the one that uses the compromised signing key. The name comes from CyberArk research published in November 2017 and cited by MITRE, and the security vendor Semperis describes the technique as using signing certificates taken from AD FS to forge sign-in responses.

What did the SolarWinds campaign show?

MITRE records the SolarWinds compromise as first seen in August 2019 and last seen in January 2021, and attributes it to APT29. It logs both routes against the campaign. CISA's advisory, last revised on April 15, 2021, describes one of the adversary's methods, the first route: compromising the SAML signing certificate, then creating "unauthorized but valid tokens" and presenting them to services that trust SAML tokens from the environment. CISA says these tokens can then be used to reach resources such as email.

The lesson is about cleanup. CISA says that where SAML abuse is identified, simply mitigating individual issues, systems, servers, or specific user accounts "will likely not lead to the adversary's removal from the network", and that organizations should consider the entire identity trust store as compromised. A forged token rests on the signing key, not on the named user's password, so resetting that password does not change the key that makes the tokens valid.

How can defenders recognize a forged token?

Defenders look for what the forgery does not produce: the sign-in that should have come before the token. Three signals work as a class:

• A valid signature with no matching sign-in: MITRE's detection strategy for forged tokens describes authentication attempts with valid signatures but missing the sign-in events that normally precede them.
• A cloud sign-in that succeeded without MFA, or with claims that do not fit the user: this is another pattern in the same MITRE strategy.
• Odd token lifetimes: CISA's advisory notes that most organizations' SAML tokens last one hour, so long lifetimes "could be unusual", and that a token used at the same moment it was issued is "not indicative of normal user behavior".

These signals depend on logging that records the events being compared. MITRE publishes the analytics, not how often they catch forgery.

The analytics MITRE lists under T1484.002 look for new domain trusts, added identity providers and a domain's sign-in switched to federation. The classic route signs with the existing certificate and changes no trust, so a rule built only on those analytics would not be expected to fire. That is a reading of the two MITRE entries side by side, not a MITRE statement.

Which defenses change the outcome, and where do they stop?

The defenses below work on two points: the key, and what a service believes about a token.

• Keep the key out of reach: MITRE lists restricting permissions and access to the AD FS server, and enabling advanced AD FS auditing. Mandiant advises treating AD FS as top-tier identity infrastructure and moving token-signing certificates to a hardware security module, so that the private key does not exist in software-accessible storage on the host. Mandiant reported in July 2026 from a red team engagement that where automatic certificate rollover was disabled and certificates were rotated by hand, configuration drift could leave an active signing key exposed. For a defender, the point is that how keys are rotated and stored can decide whether the key stays out of reach.
• Rotate the signing certificate twice after a suspected forgery: for containing the impact of a forged token, MITRE advises rotating the certificate twice in rapid succession, which it says will invalidate tokens generated using the previous certificate. Microsoft explains why twice: Entra ID holds on to information about the previous certificate, and without a second certificate it might still be possible for the old one to authenticate users. Rotation may also cause a service outage while trusts update. Removing trust in the compromised key is meant to stop services accepting assertions signed with it, but it does not necessarily end sessions or tokens already issued after a successful sign-in. Microsoft's guide therefore adds a separate step, revoking users' refresh tokens, which it says forces them to sign in again and logs them out of phones, current webmail sessions and other places that use tokens. Recovery also means removing the intruder's access and revoking affected sessions and tokens in each service that supports it; rotating the certificate alone does not complete it.
• Make the cloud service ask for MFA itself: the federatedIdpMfaBehavior setting described above, with the limits given there.
• Move away from federation to cloud sign-in: Microsoft publishes a guide for moving a federated domain to cloud authentication, and Mandiant notes that moving away from AD FS-based federation removes this specific attack path.

The move does not remove the central limitation, which is that a forged token rests on whoever holds the signing key. Entra ID supplies its own signing certificate, but an organization can import one generated elsewhere, and the security vendor Semperis showed in February 2024, under the name Silver SAML, that an attacker who obtains that imported certificate's private key can forge SAML responses the same way. Microsoft replied that the case was assessed as by-design and did not meet its bar for immediate servicing.

In September 2026 NIST and CISA published final guidance on protecting identity tokens and assertions from forgery, theft and misuse, including recommendations on key management, token verification and lifecycle controls.