ADFS Security Hardening: Token Signing, Claim Rules, Golden SAML Defence (2026)

If your environment still runs Active Directory Federation Services (ADFS) — and most large enterprises that adopted federation between 2015 and 2020 still do — you are sitting on the single highest-value target in your identity stack. An attacker who extracts the ADFS token-signing certificate can mint SAML tokens for any user, including domain admins, with no further AD interaction and no Kerberos or NTLM tickets to detect. That class of attack is Golden SAML, and it’s exactly what hit SolarWinds-era victims in 2020. This is the practical ADFS security hardening guide for 2026: rotating signing certificates, auditing claim rules, enforcing Extranet Lockout, blocking the mimikatz / ADFSDump extraction path, and the migration path to Microsoft Entra ID for the eventual decommission.

TL;DR — the ADFS hardening priority list

If you only have time for the five highest-impact controls:

1. Rotate the token-signing certificate, then rotate it again 14 days later. Anyone holding an old cert is locked out.
2. Block local logon to ADFS servers for everyone except a tiered admin group. ADFS servers are Tier 0 — treat them like Domain Controllers.
3. Enable Extranet Lockout with AdfsSmartLockoutEnforce mode. Without it, ADFS is a password-spray funnel.
4. Audit every claim rule for transformations that bypass MFA or grant excessive scope. Most environments have unused claim rules accumulated over five years.
5. Forward Event IDs 1200/1201/1202/411/412 to your SIEM. These are the Golden SAML, brute force, and token-replay signals — every ADFS-relevant detection lives in one of those Event IDs.

After those five, the remaining hardening (WS-Trust 1.3 disable, smart account lockout, PowerShell auditing, network segmentation) closes the long tail.

What is ADFS, and why is it still relevant?

Active Directory Federation Services (ADFS) is Microsoft’s on-premises identity federation service. It accepts authentication from Active Directory and issues SAML 2.0 / WS-Federation / OAuth 2.0 tokens that downstream relying parties (Office 365, Salesforce, ServiceNow, custom apps) trust. In a federated topology the relying party doesn’t see AD credentials — it sees signed tokens minted by ADFS.

ADFS was the default Microsoft identity-federation path from 2009 (Server 2008 R2) through about 2018. After that, Microsoft Entra ID (formerly Azure AD) took over as the recommended modern path — but a lot of environments are still running ADFS in 2026 because:

• Long-tail Office 365 migrations that started on ADFS and never finished the cut-over to Entra
• Hybrid identity where ADFS is the bridge to on-prem RP-STS relying parties
• Compliance environments (US Federal, defence contractors) that prefer on-prem identity
• Legacy SaaS apps with custom SAML configurations tied to the ADFS issuer URL

If you have ADFS, two things are true: (a) you should plan to decommission it (Microsoft has signalled this for years and the Entra ID path is materially safer); and (b) until you finish that migration, ADFS must be hardened to the same standard as a Domain Controller.

Why ADFS hardening matters now

Three reasons to put ADFS at the top of your 2026 hardening backlog:

1. Golden SAML is a one-shot domain compromise. An attacker who reads the ADFS token-signing certificate (specifically the private key, stored encrypted on the ADFS server filesystem and in the database) can mint arbitrary SAML tokens. No AD interaction. No Kerberos tickets. No NTLM hashes. They appear at Office 365 (and any other federated RP) as any user they want, including the most privileged. The 2020 SolarWinds incident demonstrated this against multiple US federal agencies and enterprise victims — UNC2452 / APT29 extracted the ADFS signing key and minted tokens for high-value accounts at will.

2. Mimikatz and ADFSDump trivialise the extraction.

• mimikatz.exe "vault::cred /patch" "exit" reads cached credentials from ADFS service accounts
• mimikatz "lsadump::backupkeys" / "lsadump::dpapi" recovers the DPAPI master key used to encrypt the signing cert
• The dedicated ADFSDump.exe (Doug Bienstock, Mandiant) and aadinternals PowerShell module make the extraction a one-liner for anyone with local SYSTEM on the ADFS server

If your ADFS server is reachable from a Tier 1 admin’s workstation, and that workstation is compromised, Golden SAML is one lateral hop away.

3. ADFS is often the LEAST-hardened machine in the identity stack. Many environments hardened DCs aggressively, deployed LAPS, enabled Credential Guard — and left the ADFS server with default settings, an old token-signing cert that has never been rotated, the WS-Trust 1.3 endpoint exposed to the internet, and no Extranet Lockout. The blast radius is asymmetric: ADFS compromise = federation compromise = every SaaS app trusts forged tokens.

ADFS attack surface

The four major paths to ADFS compromise, and what each enables:

The full hardening plan addresses all four paths in priority order.

How to harden ADFS step-by-step

Each step is unpacked below with the technical detail you’ll need.

Step 1: Token-signing certificate rotation (the highest-priority control)

The token-signing certificate’s private key is what makes Golden SAML possible. If an attacker has read this key (typically via mimikatz extracting the DPAPI master and ADFSDump pulling the cert from the ADFS configuration DB), they can mint arbitrary SAML tokens for any user.

The defence is frequent rotation. Microsoft’s recommendation: rotate annually. Best practice for security-conscious environments: rotate every 90 days. After any suspected compromise: rotate immediately, twice, with a 14-day gap.

# Show the current signing certificate
Get-AdfsCertificate -CertificateType Token-Signing |
  Format-List Thumbprint, NotBefore, NotAfter, IsPrimary, CertificateType

# Generate a new one (becomes secondary; relying parties get it via federation metadata)
Update-AdfsCertificate -CertificateType Token-Signing

# Wait 7–14 days for relying parties to pick up the new cert via metadata
# Then promote the new cert to primary and remove the old
$new = Get-AdfsCertificate -CertificateType Token-Signing |
  Where-Object { -not $_.IsPrimary }
Set-AdfsCertificate -Thumbprint $new.Thumbprint -CertificateType Token-Signing -IsPrimary

# Remove the old certificate
$old = Get-AdfsCertificate -CertificateType Token-Signing |
  Where-Object { -not $_.IsPrimary }
Remove-AdfsCertificate -Thumbprint $old.Thumbprint -CertificateType Token-Signing

For maximum security: generate the token-signing certificate in a Hardware Security Module (HSM). The private key never touches the ADFS filesystem — even local SYSTEM on the ADFS host can’t extract it. Microsoft documents HSM integration for ADFS using nShield and similar; pair with the Microsoft Learn ADFS docs.

Step 2: Tier-0 isolation of ADFS servers

ADFS servers are part of your identity stack — Tier 0 — alongside Domain Controllers. The hardening rule is “no Tier 1/2 admin ever logs on locally to an ADFS server.”

Restrict local logon (GPO at the ADFS OU):

Computer Configuration
 └ Policies
   └ Windows Settings
     └ Security Settings
       └ Local Policies
         └ User Rights Assignment
           ├ Allow log on locally           = ADFS-Admins, Local Administrators
           ├ Deny log on locally            = Domain Users
           ├ Deny log on through RDS        = Domain Users
           └ Allow log on through RDS       = ADFS-Admins

Deploy LAPS on ADFS servers so the local admin password rotates daily and the read permission is scoped to Tier 0 admins only. See the Windows LAPS implementation guide — the same DSRM backup workflow applies to ADFS.

Use a gMSA (Group Managed Service Account) for the ADFS service. Replaces the default NT SERVICE\adfssrv or domain service account. gMSA passwords rotate automatically and there’s no human-knowable password to steal.

# On the ADFS server
New-ADServiceAccount -Name svc-adfs -DNSHostName adfs.corp.local `
  -PrincipalsAllowedToRetrieveManagedPassword "ADFS-Servers"
Install-ADServiceAccount svc-adfs

Then re-configure ADFS to use corp\svc-adfs$ as the service account.

Step 3: Extranet Lockout — closing the password-spray funnel

By default, ADFS’s external endpoints will happily accept thousands of password attempts per minute. Without Extranet Lockout, an attacker can password-spray your entire user base via the ADFS WS-Trust endpoint.

Set-AdfsProperties `
  -ExtranetLockoutEnabled $true `
  -ExtranetLockoutMode AdfsSmartLockoutEnforce `
  -ExtranetLockoutThreshold 5 `
  -ExtranetObservationWindow (New-TimeSpan -Minutes 15) `
  -ExtranetLockoutRequirePDC $false

# Verify
Get-AdfsProperties | Select-Object Extranet*

The AdfsSmartLockoutEnforce mode (vs. AdfsSmartLockoutLogOnly) actually blocks at the ADFS layer — accounts can’t accumulate failed-logon counts against AD. The RequirePDC $false ensures the lockout enforcement works even if the PDC emulator is unreachable.

Step 4: Disabling WS-Trust 1.3

WS-Trust 1.3 (and 2005) are the legacy authentication endpoints that pre-date modern auth. They accept username/password directly and do not enforce MFA — they’re the password-spray and credential-theft surface ADFS exposes. Modern apps don’t need them.

# Inventory which endpoints are currently enabled and proxy-exposed
Get-AdfsEndpoint | Where-Object { $_.Enabled -and $_.Proxy } |
  Select-Object FullUrl, Enabled, Proxy

# Disable the WS-Trust legacy mixed endpoints from the proxy
Set-AdfsEndpoint -TargetAddressPath '/adfs/services/trust/2005/usernamemixed' -Proxy $false
Set-AdfsEndpoint -TargetAddressPath '/adfs/services/trust/13/usernamemixed' -Proxy $false
Set-AdfsEndpoint -TargetAddressPath '/adfs/services/trust/2005/windowstransport' -Enabled $false
Set-AdfsEndpoint -TargetAddressPath '/adfs/services/trust/13/windowstransport' -Enabled $false

# Restart the ADFS service
Restart-Service adfssrv

Before disabling, audit which clients are currently authenticating via WS-Trust. Look in your ADFS audit logs for Event 1200 entries with Activity = TokenIssuanceFromAuthentication and AuthenticationProtocol = WSTrust. Common culprits:

• Older Exchange ActiveSync devices (iOS pre-13, Android pre-9)
• Legacy SaaS integrations (often custom-built or vendor-provided in 2014-2017)
• Internal apps still using WS2007HttpBinding

For each, document the migration path: upgrade the client to modern auth (OAuth 2.0), replace the app, or — if the app can’t be modernised — keep WS-Trust enabled but lock it down with IP restrictions on the WAP.

Step 5: Audit claim rules for hidden bypasses

ADFS relying-party trusts have claim transformation rules that issue, transform, or filter claims as tokens flow through. Over years, these accumulate, and unused or over-permissive rules are common findings in security audits.

# Dump every claim rule for review
Get-AdfsRelyingPartyTrust | ForEach-Object {
  Write-Host "===== $($_.Name) =====" -ForegroundColor Yellow
  Write-Host "Issuance:" -ForegroundColor Cyan
  Write-Host $_.IssuanceTransformRules
  Write-Host "Authorization:" -ForegroundColor Cyan
  Write-Host $_.IssuanceAuthorizationRules
  Write-Host "AdditionalAuth:" -ForegroundColor Cyan
  Write-Host $_.AdditionalAuthenticationRules
}

Red flags to look for in each relying party’s rules:

• Rules that pass through tokenGroupsGlobalAndUniversal — discloses ALL groups, far more than the RP needs
• Rules that issue a literal role claim with a hardcoded Administrator value
• Rules using EXISTS([Type == "..."]) patterns that bypass MultiFactorAuthentication = true requirements
• Relying parties that have not been touched in 24+ months — often shadow IT or shut-down apps

Tighten or remove. Document changes. Test each relying party in a UAT environment before pushing to production.

Step 6: Detection — the Event IDs you need in your SIEM

The full ADFS detection cheat sheet for SIEM ingestion. Forward these from the ADFS server’s Security log and AD FS/Admin log:

Splunk rule example for Golden SAML detection (issuance volume anomaly):

index=adfs source="*/AD FS/Admin*" EventCode=1200
| bucket _time span=1h
| stats count by _time, src_user
| eventstats avg(count) as baseline_avg, stdev(count) as baseline_stdev by src_user
| where count > (baseline_avg + 3 * baseline_stdev)
| eval severity="high", reason="Anomalous ADFS token issuance volume"

Step 7: Defending against mimikatz / ADFSDump extraction

The Golden SAML kill chain has three phases. Disrupt any one and Golden SAML fails:

1. Local SYSTEM on the ADFS server — required for both mimikatz and ADFSDump. Defended by ADFS Tier 0 isolation, LAPS, and modern endpoint hardening (Credential Guard, LSA Protection, ASR rules) per the Windows 11 enterprise hardening guide.
2. DPAPI master key extraction — mimikatz reads the master key from lsadump::dpapi. Mitigations: Credential Guard (which protects LSA), HSM-backed signing cert (no DPAPI involvement), and proper service-account permissions (the cert is encrypted with the service account’s DPAPI master key — if the SA is gMSA, harder to extract).
3. Signing key access in the ADFS config DB — even with the DPAPI master key, the attacker needs read access to the WID/SQL configuration database. The DB lives at C:\Windows\WID\Data\ (Windows Internal Database) or in SQL Server for ADFS farms. Restrict NTFS / SQL permissions to the ADFS service account only.

Detection complement: Any time lsass.exe is read by a non-SYSTEM process, OR mimikatz or ADFSDump keywords appear in PowerShell scriptblock logs from an ADFS server, that’s a high-fidelity alarm.

Migration path to Microsoft Entra ID

ADFS won’t last forever. Microsoft’s current default identity stack is Entra ID; new tenants don’t use ADFS at all. A typical decommission plan:

The Entra ID side has stronger MFA story, native conditional access, continuous access evaluation, and risk-based sign-in — all hard or impossible to build on ADFS. For most environments, the migration pays for itself in reduced operational burden alone.

Common mistakes (and how to avoid them)

Frequently asked questions

Conclusion: rotate the cert this sprint

The single highest-value action you can take this week: rotate the ADFS token-signing certificate. Even if you do nothing else from this guide, that one action invalidates any stolen signing key an attacker might already hold. The full rotation cycle (generate new → wait for relying parties to pick up metadata → promote to primary → remove old) takes 2-3 weeks calendar time but maybe 30 minutes of admin work.

Then layer in:

1. Tier 0 lockdown of ADFS servers (restricted local logon, LAPS, gMSA)
2. Extranet Lockout in smart-enforce mode
3. WS-Trust 1.3 disable after auditing legacy client dependencies
4. SIEM ingestion of Events 1200/1201/1202/411/412 from every ADFS server
5. Quarterly claim-rule audit with documented changes

That’s a complete ADFS hardening posture inside a quarter. Pair with the Windows 11 enterprise hardening guide for the underlying OS controls (Credential Guard, LSA Protection, ASR rules) that make mimikatz extraction substantially harder, and the Windows LAPS implementation guide for the local-admin rotation that keeps the ADFS service account uncompromisable.

Eventual end-state: ADFS decommissioned in favour of Entra ID. Until then, treat ADFS as Tier 0.

Share this guide

LinkedIn:

ADFS is the single highest-value target in any federated identity stack — and most enterprises haven’t rotated their token-signing cert in years. The Golden SAML defence playbook: cert rotation, Tier 0 isolation, Extranet Lockout, WS-Trust 1.3 disable, and the Event IDs your SIEM must ingest. 👇

X / Twitter:

ADFS hardening priority list: (1) rotate the token-signing cert (2) Tier-0 lockdown the server (3) Extranet Lockout in enforce mode (4) disable WS-Trust 1.3 (5) ingest Events 1200/1201/411/412. Anything else after that is incremental. Full guide:

References

• Microsoft Learn: AD FS overview
• Microsoft Learn: Best practices for securing AD FS
• Microsoft: Configure AD FS Extranet Smart Lockout
• Mandiant: Detecting Microsoft 365 and ADFS Attack Tools (Golden SAML) — the foundational Golden SAML detection paper
• ADFSDump (Doug Bienstock, Mandiant)
• MITRE ATT&CK T1606.002 — Forge Web Credentials: SAML Tokens
• Microsoft: Migrate from AD FS to Microsoft Entra ID
• CISA Alert AA21-008A — SolarWinds supply chain compromise — real-world Golden SAML in practice