Golden SAML

Golden SAML is an attack in which an adversary steals an organisation's SAML token-signing certificate and uses it to forge authentication tokens. The forged token is validly signed, so cloud services accept it as a genuine sign-in for any user the attacker chooses, without a password.

Search for this attack and you will be handed a technique identifier, T1484.002, alongside a definition describing a stolen signing key. Open that technique and its own text says it covers forging SAML tokens without compromising the signing certificate.

Both things are true. They describe different halves of the same problem, and telling them apart changes what your detection rules should be watching.

This page covers four things: what is actually forged, which identifier applies to which path, why the standard detection guidance stays quiet during the classic attack, and what to check in your own tenant this week.

Explain It Like I'm 10

Imagine a company where every official letter is only trusted because it carries the company's wax seal. Nobody rereads the letter or calls to confirm it. They just check the seal.

Now suppose someone steals the seal itself. They can write any letter they like, about anyone, and stamp it. The letter is a forgery, but the seal is completely genuine, so everyone downstream treats it as real.

Golden SAML is that, with a cryptographic signing certificate instead of wax.

The two techniques, and which one is golden SAML

The reassuring part first: both identifiers are legitimate, both describe behaviour observed in real intrusions, and if your notes carry both you are almost certainly fine. Nothing below means your documentation has to be thrown away.

The difference is what the attacker had to obtain first.

T1484.002 Trust Modification describes changing the trust relationship itself. Its own description says this "may be used to forge SAML Tokens without the need to compromise the signing certificate to forge new credentials. Instead, an adversary can manipulate domain trusts to add their own signing certificate."

T1606.002 Forge Web Credentials: SAML Tokens describes the forgery itself, and opens: "An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token-signing certificate." That page is also where MITRE cites the 2017 research that named golden SAML.

So the term as it was coined, built on a stolen certificate, sits under T1606.002. The technique the field prints beside it describes what an attacker does when they add a certificate of their own instead.

MITRE separates them itself, in one campaign

This is not an outside reading of the framework. On the SolarWinds Compromise campaign page, MITRE files APT29 under both techniques for the same operation and distinguishes them by four words.

• Under T1484.002, APT29 "changed domain federation trust settings using Azure AD administrative permissions to configure the domain to accept authorization tokens signed by their own SAML signing certificate".
• Under T1606.002, the group "created tokens using compromised SAML signing certificates".

Their own, versus compromised. That is the entire distinction, written by the framework, about one intrusion.

The NSA reached the same split independently. Its December 2020 advisory on abuse of authentication mechanisms described actors compromising on-premises federation components to steal the private key used to sign SAML tokens, and then described a second path: where actors could not obtain an on-premises signing key, they would seek enough privilege in the cloud tenant to add a malicious certificate trust relationship. The second is what you do when the first is out of reach.

One honest boundary. T1606.002 also notes that an adversary with enough permissions "to establish a new federation trust with their own Active Directory Federation Services (AD FS) server" may "generate their own trusted token-signing certificate", so the two overlap at the edges. The question that separates them is whether your existing certificate was compromised.

The framework documented both paths accurately and kept them apart. The flattening happened downstream, in explainers and summaries.

How golden SAML actually works

The mechanism is short, and most explainers cover it adequately, so this section only carries what they leave out.

A SAML token is trusted because of its signature, not because of anything that happens at sign-in time. The cloud service verifies that the token was signed by a certificate it already trusts, and accepts what the token asserts. Nothing in that exchange requires the user to exist at a keyboard.

That is why the consequences are unusually broad. Because the forged token can carry any permissions claims and lifetimes, resetting the user's password does not help, and neither does disabling the account in most configurations. The token was never derived from the password.

MITRE's record of what APT29 actually took is the concrete version: under a separate technique for unsecured credentials, the group "obtained PKI keys, certificate files, and the private encryption key from an Active Directory Federation Services" server. The signing material is the objective, and the AD FS server is where it lives.

The tactic moved, and most sources have not

A smaller correction, and an easy one to check.

T1484.002 is currently version 3.0, last modified 12 May 2026, and its tactics are now Defense Impairment and Privilege Escalation. Defense Impairment is TA0112, a tactic created on 14 April 2026 that now carries 18 techniques. MITRE describes it as covering adversaries who break security mechanisms and tooling "so defenders can't see or trust what's happening".

Much of the material circulating about this attack still lists the technique under Defense Evasion, and some still uses the retired title "Domain Trust Modification". That is a currency problem rather than a mistake by anyone in particular: the revision is four months old, and pages written before it were correct when published.

The practical consequence is worth stating for anyone maintaining ATT&CK-mapped content: after the May 2026 revision, re-check the tactic, not just the technique ID. Techniques have moved between tactics, and a mapping table that was accurate last year may now file this attack under a tactic that no longer applies to it.

Why your detection rule stayed quiet

This is where the distinction stops being about naming.

T1484.002's detection strategy, DET0458, covers trust relationship modifications. Its two analytics look for exactly that:

• AN1259 watches Active Directory domain trust settings changed through `netdom`, `nltest` or PowerShell, and modifications to object attributes such as `trustDirection`, `trustType` and `trustAttributes`.
• AN1260 watches for a federated identity provider being added, or a tenant domain moving from Managed to Federated, through events like `Set domain authentication`, `Add federated identity provider` and `Update-MsolFederatedDomain`.

Compare that against the classic attack. An adversary holding your organisation's own token-signing certificate signs tokens with the certificate your tenant already trusts. No trust is added. No domain is converted. No federation configuration changes at all. Those two analytics have nothing to fire on, because the events they describe never occur. That comparison is a reading of the two technique pages against each other rather than a claim MITRE makes, and it takes about two clicks to check.

The analytics that fit sit under T1606.002, in detection strategy DET0148. Five of them, and the first is the idea the whole page turns on:

• AN0418 correlates valid-signature tokens with absent Kerberos authentication events. The signature is good, but the authentication that should have produced it never happened.
• AN0419 looks for cross-cloud or cross-account authentication without matching STS events.
• AN0420 looks for federated application access without normal Kerberos activity.
• AN0421 looks for SaaS logins succeeding without MFA, or with inconsistent token claims.
• AN0422 looks for token replay across Microsoft 365 applications, or privileged mailbox access without an interactive login.

None of which makes the trust-modification analytics useless. They are precisely right for the other path, and that path is current: CISA's advisory on Scattered Spider records those actors adding a federated identity provider to a target's SSO tenant. A mature detection programme wants both. They cover different halves.

The AD FS vulnerability in the news, in proportion

A second thread has run alongside this topic since July 2026, and it is being described inaccurately in a way that mirrors the technique confusion.

CVE-2026-56155 is real and it is serious. CISA added it to the Known Exploited Vulnerabilities catalog on 14 July 2026 with a remediation due date of 28 July 2026, and the product is Active Directory Federation Services.

What it is not is a token forgery flaw. CISA titles it an "Insufficient Granularity of Access Control Vulnerability" and describes it as allowing "an authorized attacker to elevate privileges locally". The NVD record agrees, scoring it CVSS 7.8 with the vector `AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`: a local attack vector, requiring privileges the attacker already holds. Several circulating summaries call it an AD FS token forgery zero-day. Neither authoritative record supports that description.

The accurate connection is narrower, and worth making. The AD FS server is where the token-signing key lives, so a local privilege escalation on that server is relevant to golden SAML as an enabler of the theft, not as the forgery itself.

One detail in CISA's entry stands out. The required action tells agencies to follow vendor mitigations or "discontinue use of the product if mitigations are unavailable", and the reference notes link Microsoft's AD FS decommission guide. The KEV deadline has passed, so the useful action now is confirming the patch is applied.

What to change, and what it costs

Four things, in order of value for effort. The first is not mentioned anywhere on the first page of results for this topic.

Check `federatedIdpMfaBehavior`, and understand its default. Microsoft's federation settings include a security setting governing whether Entra ID trusts a federated identity provider's assertion that MFA has already been performed. It takes three values: `acceptIfMfaDoneByFederatedIdp`, `enforceMfaByFederatedIdp`, and `rejectMfaByFederatedIdp`, the last of which means Entra ID "always performs MFA and rejects MFA that federated identity provider performs". Microsoft's own documentation states the purpose plainly: enforcing MFA every time "assures that a bad actor can't bypass Microsoft Entra multifactor authentication by imitating that identity provider already performed MFA".

And if neither this setting nor the older `SupportsMfa` property has ever been configured, Entra ID defaults to `acceptIfMfaDoneByFederatedIdp`. A forged token asserts precisely that MFA was already done. This is also the honest scope on the common claim that golden SAML skips MFA entirely: with the reject setting in place, Entra performs its own MFA regardless of what the token asserts. You can read your current value with `Get-MgDomainFederationConfiguration`.

Rotate token-signing certificates twice. MITRE's mitigation under T1606.002 says twice, and the count matters: a single rotation typically leaves the previous certificate in place as the secondary, which means a compromised certificate can still sign accepted tokens.

Hunt on the analytics that fit, starting with the absent-Kerberos correlation in AN0418, and enable advanced AD FS auditing so those events exist to correlate.

Treat migration to cloud authentication as the strategic answer, with clear eyes about the project.

What it costs, and where it stops

Migration is real work, and Microsoft's own guidance is candid about it:

• The domain conversion "may take up to 60 minutes", during which users may not be prompted for credentials.
• `onload.js` customisations "can't be duplicated in Microsoft Entra ID".
• The sign-in experience changes, and cannot be customised the same way.
• Rollback means converting managed domains back to federated, which needs planning before you start rather than after.

It also does not close the category. In February 2024, researchers at Semperis disclosed Silver SAML, which forges SAML responses from Entra ID itself when an organisation has imported an externally generated signing certificate rather than using the self-signed certificate Entra provides. It needs no access to AD FS at all. Its scope is narrower, reaching downstream applications rather than Entra ID itself, and Microsoft's response was that the issue did not meet its bar for immediate servicing. The practical control that follows is small and specific: prefer your identity provider's own self-signed signing certificate over an imported one.

And the CVE above does not, by itself, justify an emergency migration. Patch it, then plan the move on its merits.

What this page does not know

No prevalence figure for golden SAML exists in citable form. No government or standards body publishes an incident count, rate or share. That check was run against national cyber-centre material specifically, and it returned governance guidance rather than measurement.

Three further limits:

• The current government workstream is a draft. NIST and CISA published "Protecting Tokens and Assertions from Forgery, Theft, and Misuse" on 22 December 2025 for public comment through 30 January 2026. A final version was not located, so this page describes it as a draft and nothing more.
• MITRE publishes detection analytics, not their catch rates or false-positive profiles. How noisy AN0418 is in a large estate, only that estate can answer.
• The 2017 research that coined the term no longer resolves. Both original posts now redirect to a product page following an acquisition. The attribution survives through MITRE's citation, but the source text is not readable at its original address, so nothing here quotes it. That is a link-rot problem, not a criticism of anyone.

One disclosure. Identity security is one of this site's sponsor categories, and identity vendors produced much of the credible material on this subject. Only primary sources are cited above. The two vendor-originated items are attributed in the sentence where they appear, and one of them, Silver SAML, is used as evidence against this page's own recommendation.

Frequently asked questions

Is golden SAML T1484.002 or T1606.002? T1606.002, if the attacker used your organisation's stolen token-signing certificate. T1484.002 if they added a trust or a certificate of their own. Many real intrusions involve both, which is why MITRE maps APT29's SolarWinds activity to both.

Do I need to redo my existing ATT&CK mappings? Usually not. If your mapping already carries both techniques it is fine. What is worth revisiting is the tactic, since T1484.002 moved to Defense Impairment in the May 2026 revision, and any detection content built only on the trust-modification analytics.

Is CVE-2026-56155 a golden SAML vulnerability? No. It is a local privilege escalation in AD FS, scored CVSS 7.8 with a local attack vector. It matters here because the AD FS server holds the signing key, so it is a route toward the certificate rather than a way to forge tokens.

Does moving off AD FS to Entra ID solve this? It removes the on-premises server that holds the signing key, which is a substantial reduction. It does not eliminate SAML forgery as a class, as Silver SAML showed for tenants using externally generated signing certificates.

Can I detect a forged SAML token at all? Yes, indirectly. You cannot tell a validly signed forgery from a genuine token by inspecting its signature, which is the point of the attack. You detect it by correlation: a token that grants access with no corresponding authentication event behind it.

Where to start

Three checks, none of which requires buying anything.

Read your own federation setting. Run `Get-MgDomainFederationConfiguration` for each federated domain and look at `federatedIdpMfaBehavior`. If it has never been set, you are on the default that trusts the token's MFA claim.

Read the analytics that fit. Open T1606.002 and work through AN0418 to AN0422. If your detection content for this attack was built from T1484.002's analytics, that gap is the work.

Confirm the patch. CVE-2026-56155's KEV due date passed on 28 July 2026.

The difficulty with this attack is not that the token looks convincing. The signature is genuine, which is exactly the problem, and no amount of inspecting it will help. What gives the forgery away is the thing that is missing behind it: an authentication that never happened.