The Golden SAML attack sits in a quiet corner of hybrid Microsoft environments, rarely talked about until it is too late. It leaves no trace in Azure AD sign-in logs, bypasses cloud MFA without ever interacting with the targeted user, and grants persistent access that survives password resets. The reason it works is straightforward: a misconfigured or poorly protected ADFS server acts as an unconditional trust anchor for your entire tenant.
How federated authentication creates the exposure
In a standard federated setup, Azure AD does not validate user identities directly for synchronized accounts. It delegates that responsibility to the on-premise Identity Provider — the ADFS server. When a user authenticates, ADFS produces a SAML assertion signed with its private token-signing certificate. Azure AD checks the signature and, if it passes, grants access. Full stop. No secondary verification, no additional challenge.
This design is intentional and works as expected under normal conditions. The problem emerges when an attacker obtains that private signing certificate. At that point, they can craft any SAML assertion they want: any username, any group membership, any privilege level, including Global Administrator. Azure AD receives a cryptographically valid token and complies without hesitation.
The technical execution of a Golden SAML attack
The attack starts on the ADFS server itself. A threat actor with privileged access to that machine can extract the token-signing certificate through several paths: reading the ADFS configuration database (AdfsConfiguration.mdf), querying the Windows Identity Foundation service, or reaching into Active Directory via the DKM (Distributed Key Manager) API if the keys are stored there. Tools like ADFSDump have made this extraction accessible to a wide range of attackers.
With the certificate and private key in hand, the attacker builds a SAML assertion offline. That assertion contains the expected Azure AD attributes: the target's UPN, their ImmutableID, and the relevant group claims. They sign the XML document with the stolen key, submit it to Azure AD's federation endpoint, and collect a valid access token. The entire sequence happens without touching the target account, without triggering an MFA prompt, and without generating an alert in Azure AD.
Why cloud MFA provides no protection here
This is the part that surprises most security teams when they first encounter this attack. Azure AD's Conditional Access policies and MFA requirements apply to authentication flows that Azure AD itself controls. In a federated SAML flow, Azure AD trusts the assertion produced by ADFS. If that assertion declares the second factor was satisfied, or if Conditional Access is configured to exempt federated sign-ins from certain requirements, MFA is simply irrelevant. The attacker never touches the cloud authentication stack. They arrive with a pre-stamped ticket, and the door opens.
Why ADFS must be treated as a Tier 0 asset
Active Directory tiering exists to protect assets whose compromise leads to total infrastructure takeover. Domain controllers belong in Tier 0. So does the ADFS server, because whoever controls ADFS controls the identity of every federated user in your environment, cloud included.
In practice, ADFS is frequently managed as if it were a standard application server. It runs on shared VMs, mid-level IT administrators have local admin rights on it, and it often lacks the logging depth and network segmentation that domain controllers receive. That gap is precisely what Golden SAML exploits. Consider a realistic scenario: an attacker compromises a non-Tier 0 admin workstation, moves laterally to the ADFS server, extracts the signing certificate, and from that point controls persistent access to the Azure tenant — even after IT resets every password in the directory.
If you want to test how your ADFS architecture holds up against this kind of attack chain in a controlled setting, the identity attack labs available on the CyberAct platform cover these hybrid exploitation scenarios step by step.
Concrete protective measures
Start by enforcing Tier 0 controls on the ADFS server: access limited to dedicated Tier 0 accounts only, full event logging (especially certificate operations and configuration access), and strict network segmentation. If your ADFS server is reachable from general IT admin workstations, the attack surface is already too wide.
On the technical side, enable regular token-signing certificate rotation. A stolen certificate that has already expired cannot be used to forge valid assertions. Azure AD supports automatic rotation when properly configured. Also review your certificate validity periods — the default lifespan is often longer than necessary for high-sensitivity environments.
Enable verbose ADFS audit logging (events in the 500-503 and 1200-1203 ranges). These logs can surface assertions generated for accounts that never authenticated from that machine, or at unusual hours. On the Azure AD side, sign-in logs filtered by federated authentication type can reveal anomalies if alerting rules are in place. Correlation between ADFS-side events and Azure AD sign-in behavior is where the most useful detection signals emerge.
Finally, consider migrating your most sensitive accounts — Global Admins, Security Admins — to Azure AD managed authentication, removing them from the ADFS federation scope entirely. An account that does not use ADFS cannot be impersonated via Golden SAML. It is one of the highest-impact mitigations available for privileged identities.
What SOC teams should monitor
Windows Security events 4768 and 4769 on the ADFS server, paired with the absence of a corresponding on-premise logon or VPN session, represent a weak signal worth correlating. In Azure AD, a successful SAML-federated login for an account with no prior history of federated authentication warrants immediate investigation. Geolocation anomalies and unusual user-agent strings add context. If your SOC has no detection rules covering hybrid identity flows yet, that is a gap worth addressing quickly. A structured assessment of your detection maturity is a practical way to identify exactly these blind spots.
Frequently asked questions
Does Golden SAML only affect Microsoft environments?
No. SAML is an open standard, and any infrastructure that relies on an on-premise IdP to federate cloud access is potentially exposed. Okta, PingFederate, Shibboleth, and other federation platforms can all be targeted with the same logic: steal the signing key, forge the assertion, bypass cloud authentication. The attack is not specific to Microsoft — it is specific to how SAML federation works.
Does resetting the victim's password stop the attack?
No, and that is one of the most dangerous aspects of this technique. Because the attacker forges assertions without using the target's credentials at all, a password reset has zero effect on their access. Only rotating or revoking the ADFS token-signing certificate cuts the attacker's ability to generate valid tokens. This is why rapid detection and incident response planning matter as much as preventive controls.
How can I tell if my environment has already been compromised this way?
The most reliable indicators are federated SAML logins in Azure AD logs for accounts with no corresponding on-premise activity, or access events on the ADFS configuration database outside of scheduled maintenance windows. A targeted threat hunting exercise focusing on these traces — ideally covering several months of historical logs — is the most thorough approach to answering that question.
Does migrating to Azure AD native authentication eliminate the risk entirely?
For migrated accounts, yes. A user whose authentication is managed directly by Azure AD, with no ADFS involvement, cannot be impersonated via Golden SAML because no locally-signed SAML token is accepted for that account. Migrating high-privilege accounts away from federation is one of the most effective risk reduction measures available, and it should be a priority for any account with Global Administrator or Security Administrator roles.