ADFS CVE-2026-56155: The Federation Privilege-Escalation Flaw That Is a Reason to Retire the Box

Somewhere on your network there may be a Windows server nobody has signed into on purpose in two years. It runs Active Directory Federation Services, it has a public DNS name so remote staff can log in, and it is the single component that decides whether an authentication to Microsoft 365 succeeds. On July 14, CISA added CVE-2026-56155 to its Known Exploited Vulnerabilities catalog, which means that server now carries a flaw attackers are already using in the wild, with a remediation deadline of July 28.

The bug itself sounds unglamorous. Microsoft classifies it as an insufficient granularity of access control issue (CWE-1220) that lets an already-authorized user elevate privileges locally on the AD FS host. On most servers a local privilege-escalation bug is a serious-but-contained problem. On this one it is the on-ramp to forging logins for your entire organization.

Who this is actually for

Here is the relevance verdict before you spend a maintenance window on it. If you still run on-premises AD FS - a federation server, usually paired with a Web Application Proxy in the DMZ, brokering sign-in for Microsoft 365 or other SAML and WS-Fed apps - this is yours, and the clock is short. Apply the July update by the CISA deadline of July 28 and read the detection section below.

If your Microsoft 365 tenant already authenticates in the cloud with Password Hash Sync or certificate-based authentication and you have no AD FS servers left, CVE-2026-56155 is not your problem. Stop worrying about this specific CVE. But confirm you are actually in that group before you move on, because a federation farm that was "migrated" a few years ago and never switched off still answers requests, still holds the signing keys, and still counts. The one-command check in the third section settles it.

What CVE-2026-56155 actually changes

AD FS is a token service. When a user signs in to a federated app, AD FS validates them against on-prem Active Directory and issues a signed SAML token that the app trusts. The signature comes from the token-signing key, and the private half of that key is the most sensitive secret on the box. Anyone who can read it can mint a valid token for any user - including a global administrator - without touching that user's password or triggering their MFA. Security researchers named this technique Golden SAML when CyberArk described it in 2017, and it moved from theory to headline when it was used in the SolarWinds intrusion to pivot from on-prem into cloud tenants.

Reading the signing key is supposed to require the AD FS service account or local administrator on the federation server. That is exactly the boundary CVE-2026-56155 weakens. An access-control granularity flaw means a principal who should only have limited rights on the host can reach operations or objects that were meant to be walled off - the difference between a low-privileged foothold and hands on the key material. Microsoft's own writeup lives in the Security Update Guide; the KEV listing confirms it is being exploited now, not hypothetically. Chain a routine foothold on the AD FS server to this flaw and an attacker walks up the privilege ladder to the one thing that lets them impersonate your whole directory in the cloud.

How large organizations treat this server, and why yours looks different

On the enterprise side, the federation server is treated as a top-tier asset. The token-signing key lives in a hardware security module - Microsoft has supported HSM-backed AD FS keys since Windows Server 2012 R2 - so that even local administrator access does not hand over the private key in cleartext. The farm sits behind a proxy tier, exposes only the endpoints it must, and gets watched. Security teams alert on Golden SAML precursors - access to the distributed key manager, token-signing certificate exports, and cloud sign-ins that claim to be federated with no matching on-prem authentication event. Increasingly the enterprise answer is to leave AD FS behind entirely; Microsoft publishes a formal recommendation to migrate applications off AD FS and rates federation servers as legacy attack surface.

On Red Hound engagements the small-business version of this box tells a different story. Almost nobody chose AD FS recently. A consultant stood up hybrid Microsoft 365 in 2019, federation was the default way to do single sign-on then, and the server has been running untouched ever since. The signing key is in software, not an HSM. There is no dedicated monitoring, the host is often a Windows Server version near or past end of support, and patches land late because nobody wants to reboot the thing everyone logs in through. The blast radius matches the enterprise exactly - forge a token and you are anyone, in every connected app - while the guardrails that make the enterprise version survivable are missing. In plain business terms: this is the login system sitting behind your company email and every application people reach by clicking "sign in with Microsoft," and if it is forged an attacker becomes your staff, and you, everywhere at once, without tripping a password or MFA prompt.

Find out in one check whether this even touches you

Do not schedule anything until you know the box exists. Run the cloud-side check from any workstation with the Microsoft Graph PowerShell module, and the on-prem check on any server you suspect is or was a federation host.

# Cloud side: is your Microsoft 365 tenant still federated by AD FS?
Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomainFederationConfiguration -DomainId yourdomain.com |
  Select-Object DisplayName, IssuerUri, PassiveSignInUri
# An IssuerUri that names your AD FS host means federation is live.

# On-prem side: run on the suspected server. If the role answers, it is live.
Get-WindowsFeature ADFS-Federation | Where-Object Installed
Get-AdfsProperties | Select-Object HostName, Identifier

If the domain comes back as Managed rather than Federated and the AD FS role is absent, you are on cloud authentication and this CVE is closed for you. If either check lights up, you have a live federation server and the rest of this applies today.

Patch by July 28, then hunt for a token you did not issue

The immediate move is the July security update on every AD FS server in the farm, applied by the KEV deadline. Follow the mitigations in the Microsoft advisory in the same window. Patching closes the door for the next attacker, and it says nothing about one who reached the signing key before you rebooted, so pair the patch with a short hunt. Two signals matter most: access to the token-signing key on-prem, and a cloud sign-in that has no on-prem twin.

# On the AD FS servers: access to the DKM / token-signing key material.
# Security Event 4662 against the DKM container is a forge precursor.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} |
  Where-Object { $_.Message -match 'Token-Signing|DKM|Microsoft.*DKM' } |
  Select-Object TimeCreated, @{n='Actor';e={$_.Properties[1].Value}}

# Cloud side (Entra sign-in logs / Sentinel): list federated successes,
# then reconcile against your AD FS 1200/1202 events. A cloud logon with
# no matching on-prem authentication is the Golden SAML tell.
SigninLogs
| where ResultType == 0 and AuthenticationDetails has "federated"
| where TimeGenerated > ago(7d)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName

Event ID 4662 is noisy, so baseline it: the accounts that legitimately touch the DKM container are few, and a new actor there is worth a phone call. The cloud query only lists federated sign-ins; the finding is in the reconciliation. Because AD FS does not log the token forge itself, the mismatch between what the cloud accepted and what your federation logs recorded is often the only trace you get. If the hunt turns up real evidence of key access, remember that the July patch does not rotate anything: a signing key an attacker already copied stays valid until you roll it. In that case rotate the token-signing certificate twice, back to back, so both the current and previous key are retired, and force a re-federation of trusts, before you consider the incident closed.

Move your logins to the cloud and switch the box off

Patch this by the 28th. Then treat the CVE as the prompt to ask a harder question: do you still need this server at all? For most small businesses running inherited hybrid Microsoft 365, the honest answer is no. Cloud authentication with Password Hash Sync or certificate-based authentication does the same sign-in job, brings Conditional Access and Identity Protection you cannot run on AD FS, and removes an internet-facing server you have to patch, monitor, and defend. The right-sized fix here is subtraction.

The path off the box

• Convert the tenant to cloud authentication (Password Hash Sync is the simplest; certificate-based authentication if your policy forbids syncing password hashes) and run it in parallel for at least a week to confirm sign-in is clean.
• Repoint any SAML or WS-Fed applications still trusting AD FS to Entra ID as their identity provider.
• Only then decommission the farm, following Microsoft's AD FS decommission guide, and remove the public DNS and proxy that exposed it.

A vulnerability on a server you no longer run is a vulnerability you can never be exploited through again. Retiring AD FS closes CVE-2026-56155 and every future flaw in the same product in one move. That is the version of this story worth the maintenance window - not another emergency patch on a box that should already be gone.