AD FS Zero-Day CVE-2026-56155 July 2026: NC SMB Identity Defense

CVE-2026-56155 AD FS zero-day enables token forgery. CISA KEV federal deadline July 28. NC SMB federation identity emergency playbook. (336) 886-3282.

Cover Image for AD FS Zero-Day CVE-2026-56155 July 2026: NC SMB Identity Defense

TL;DR: Microsoft's July 14, 2026 Patch Tuesday included CVE-2026-56155, a local privilege escalation zero-day in Active Directory Federation Services that Microsoft's own Detection and Response Team (DART) discovered during a live intrusion investigation. AD FS is the on-premises service that issues and signs the authentication tokens trusted by every application that federates to it, including Microsoft 365, Salesforce, ServiceNow, Workday, and hundreds of SaaS platforms. An attacker who gains local administrator privileges on an AD FS host can extract the token-signing certificate private key and forge federation tokens for any user across every connected service, with no further authentication step required. CISA added CVE-2026-56155 to the KEV catalog the same day with a federal remediation deadline of July 28, 2026 under Binding Operational Directive 26-04. The vulnerability is chained in observed attacks with CVE-2026-56164 (the SharePoint zero-day) to convert a single unauthenticated HTTP request into full-tenant identity takeover.

Key takeaway: AD FS is the highest-blast-radius identity component most NC SMBs still run on-premises. A compromised AD FS host is not "one server was hacked." It is "every SaaS your users log into, an attacker can impersonate any user in any of them until you rotate the token-signing certificate and force a global session reset."

Do you still run on-premises AD FS at your NC small business? Contact Preferred Data Corporation for a same-week AD FS emergency-patch, certificate-rotation, and Entra ID migration-plan engagement. BBB A+ rated. On-site within 200 miles of High Point. Call (336) 886-3282.

What Is CVE-2026-56155 and Why Is It a Worst-Case Identity Bug?

CVE-2026-56155 is an elevation-of-privilege vulnerability in Active Directory Federation Services that was exploited in the wild before Microsoft's July 14, 2026 patch shipped. Microsoft credited its own Detection and Response Team (DART) with the discovery, which is a specific signal that the flaw was found inside a real incident-response engagement, not a vulnerability-research disclosure.

Three concrete facts every NC SMB running AD FS should treat as confirmed:

  • CVE-2026-56155 is a local privilege escalation, not a pre-auth RCE. By itself, the flaw does not give an attacker code execution on the AD FS host. It requires an attacker who is already on the host (through a chained exploit, credential theft, or lateral movement) to escalate to administrator.
  • CISA added it to KEV on July 14 alongside the SharePoint zero-day. Federal remediation deadline is July 28, 2026. The parallel listing is a specific signal that CISA and Microsoft observed the two vulnerabilities chained together.
  • The chained impact is token forgery for the entire federated estate. With administrator on an AD FS host, an attacker extracts the token-signing certificate private key. That key lets the attacker mint SAML or WS-Federation tokens for any user in any application that trusts the AD FS federation. Microsoft 365, third-party SaaS, and internal applications are all impacted equally.

The reason AD FS token forgery is a worst-case pattern is that it bypasses every downstream authentication control. MFA is enforced at the identity provider (AD FS), not at each SaaS application; if the identity provider itself is signing forged tokens, the SaaS application has no way to distinguish a forged token from a legitimate one. Conditional access, sign-in risk scoring, and geo-fencing all operate on data the identity provider provides in the token.

Key takeaway: The AD FS attack model is the same attack model that made Golden SAML the signature technique of the 2020 SolarWinds intrusion. CVE-2026-56155 is not a new class of vulnerability; it is a new instance of an old and devastating class.

How Is CVE-2026-56155 Chained with CVE-2026-56164?

Microsoft's DART observed the SharePoint zero-day (CVE-2026-56164) chained with the AD FS zero-day (CVE-2026-56155) in live intrusions. The mechanical steps of the chain are worth understanding because they tell NC SMBs exactly where to hunt.

The four-step chain observed in the wild:

  • Step 1: Initial foothold via CVE-2026-56164. Unauthenticated HTTP request against an internet-reachable SharePoint server drops a first-stage payload. Attacker has code execution as the SharePoint application pool identity.
  • Step 2: Lateral movement to the AD FS host. From the SharePoint host, the attacker uses stolen or cached credentials, WinRM, PSExec-family tooling, or an SMB pivot to reach the AD FS host on the internal network.
  • Step 3: Local privilege escalation via CVE-2026-56155. Once on the AD FS host, the attacker triggers CVE-2026-56155 to escalate from the initial low-privilege access to local administrator or SYSTEM.
  • Step 4: Token-signing certificate extraction and forgery. With SYSTEM on the AD FS host, the attacker extracts the token-signing certificate private key. Every subsequent SAML or WS-Federation token issued (or forged offline using the stolen key) is trusted by every relying party.

The chain is dangerous because the SharePoint half is unauthenticated and internet-reachable, and the AD FS half converts a modest foothold into a full federation compromise. NC SMBs that run both on-premises SharePoint and on-premises AD FS are the exact target profile for this chain. NC SMBs that run only cloud SharePoint (Microsoft 365) and cloud identity (Entra ID) are not exposed to this specific chain; the equivalent risk in that environment is admin consent phishing and unmanaged OAuth applications, which is a separate playbook.

What Is the NC SMB Emergency Response for AD FS?

The AD FS response is a compressed three-track program on the CISA July 28, 2026 deadline. Every SMB with on-premises AD FS should be executing all three tracks in parallel, starting no later than July 21, 2026.

Track 1: Patch (0-48 hours).

  • Apply the July 14, 2026 Windows security updates on every AD FS host. Primary and secondary; do not defer for change control.
  • Restart AD FS services after patching. Verify service startup logs are clean and the AD FS federation metadata still resolves correctly.
  • Confirm patch installed successfully across the WID or SQL AD FS configuration by checking build numbers on all farm hosts.

Track 2: Compromise hunt on the AD FS host (24-72 hours).

  • Review Windows Event Log 4624 and 4672 for the last 90 days. Look for administrator logons to the AD FS host from unexpected source IPs, accounts, or times. Any hit is a high-confidence signal.
  • Review AD FS admin event log for token-signing certificate export events, relying-party-trust modifications, or claims-rule changes that were not initiated by your team.
  • Cross-reference against SharePoint compromise-hunt findings if you also run on-premises SharePoint. A SharePoint compromise-hunt hit combined with any anomalous AD FS admin activity is a treat-as-compromised signal.

Track 3: Rotate the token-signing certificate (48 hours-7 days).

  • Generate a new token-signing certificate and add it as the secondary. Microsoft documented the rotation procedure for AD FS; the process supports a rollover window where old and new certificates are both trusted.
  • Update every relying party trust with the new certificate. Microsoft 365, third-party SaaS, and internal applications. Many federations support automatic metadata refresh; others require manual certificate upload.
  • Promote the new certificate to primary and retire the old. After the rollover window (typically 5-14 days), the old certificate is removed. Any token signed with the old key becomes invalid.
  • Force a global session reset. All users must re-authenticate. This is the step that invalidates any forged token that predates the certificate rotation.

For a typical NC SMB with a two-host AD FS farm and 15-40 relying party trusts, the three-track program is a 30-60 hour engagement compressed into two weeks. The certificate rotation touches every SaaS federation and requires coordination with SaaS administrators or the SaaS vendors themselves; that is the longest single task in the program.

Should NC SMBs Decommission On-Premises AD FS?

Yes, for most NC SMBs, the correct medium-term posture is to migrate off on-premises AD FS to a cloud identity provider (Microsoft Entra ID with cloud authentication, Okta, or a comparable modern identity platform). The July 14, 2026 chain is a specific catalyst for a broader posture question that has been building since 2023.

Three concrete reasons AD FS is a strategic liability for most NC SMBs:

  • AD FS is an on-premises server with an internet-facing role. The attack surface pattern (edge-exposed, high-blast-radius, credential-adjacent) is the exact pattern that has driven the 2024-2026 wave of federation compromises.
  • Microsoft has been publicly deprecating AD FS in favor of Entra ID for years. New identity innovations (passwordless, phishing-resistant MFA, sign-in risk scoring, Continuous Access Evaluation) are Entra ID features. AD FS receives security patches, not feature investment.
  • Cyber insurers increasingly ask about the federation posture. "Do you run on-premises AD FS?" appears on 2026 questionnaires from multiple carriers, and a "yes" is not a disqualifier but is a follow-up-question signal.

For an NC SMB that runs AD FS today, a realistic migration timeline is 4-9 months for a well-planned move to Entra ID cloud authentication with password hash sync, Entra Connect Sync for directory objects, and staged application migration. The immediate July 14 emergency patch is not a substitute for the migration; the migration is the durable resolution.

How Does July 2026 AD FS Risk Compare to Prior Federation Compromises?

The AD FS token-forgery attack model is not new. It is the same model as Golden SAML, which was central to the SolarWinds intrusion in 2020, and it has recurred with variations across the 2020-2026 window.

Comparison: Major federation-compromise incidents 2020-2026.

IncidentYearFederation platformAttack modelBlast radius
SolarWinds Golden SAML2020AD FSToken-signing key theft, token forgeryEvery AD FS-federated cloud tenant of victim orgs
Storm-0558 Azure token forgery2023Entra ID (MSA key)Stolen consumer signing key used against enterpriseCross-tenant Microsoft 365 access
Midnight Blizzard Entra abuse2024Entra IDOAuth consent + MFA bypassMicrosoft 365 mailboxes
CVE-2026-56155 AD FS zero-day2026AD FSLPE + token forgery via chained accessEvery AD FS-federated app in victim orgs

The through-line is that federation systems are high-value targets and attackers repeatedly find paths to the token-signing key. The 2026 CVE-2026-56155 is the specific instance NC SMBs need to remediate; the strategic response is the migration off on-premises AD FS.

Explore Preferred Data's cybersecurity services

How Does Preferred Data Handle AD FS Emergency Response and Migration?

Preferred Data has supported NC SMB AD FS deployments for years and has run multiple emergency-response engagements against the 2024-2026 federation-vulnerability cycle. The July 14, 2026 chain triggered a two-track engagement pattern: emergency patch and hunt in the short term, Entra ID migration plan in the medium term.

PDC's AD FS engagement structure:

  1. Emergency patch and certificate rotation (Weeks 1-2). July 14, 2026 patches applied. Token-signing certificate rotated. Relying-party trusts updated. Global session reset executed.
  2. Compromise-hunt deliverable (Weeks 1-3). 90-day event log review for the AD FS farm, cross-reference against SharePoint findings if applicable, deliverable with clean/suspicious/confirmed finding per host.
  3. Entra ID migration plan (Weeks 3-8). Application inventory of every relying-party trust, Entra ID licensing assessment (Entra ID P1 or P2 recommended), cloud authentication method decision (PHS, PTA, or federated), migration wave planning.
  4. Migration execution (Months 3-9). Wave-by-wave migration of applications from AD FS to Entra ID. AD FS farm decommissioned after the last relying party is migrated.

Cost for a typical NC SMB with a two-host AD FS farm, 15-40 relying party trusts, and 60-150 users: $10,000-$22,000 for the emergency patch, certificate rotation, and hunt; $25,000-$60,000 for the full Entra ID migration project depending on application count and complexity. The migration is a one-time cost that eliminates the AD FS attack surface permanently.

Frequently Asked Questions

Does CVE-2026-56155 affect Microsoft Entra ID?

No. CVE-2026-56155 is specific to on-premises Active Directory Federation Services (AD FS) on Windows Server 2016, 2019, and 2022. Microsoft Entra ID (the cloud identity service formerly known as Azure Active Directory) is not affected. However, NC SMBs that run a hybrid model with AD FS handling authentication for a cloud Entra ID tenant inherit the AD FS risk for those users. Cloud-only Entra ID environments with no federation are outside the CVE-2026-56155 scope.

What is Golden SAML and why does it matter here?

Golden SAML is the offensive technique of stealing a federation identity provider's token-signing certificate private key and using it to forge SAML tokens for any user. It was the signature technique of the 2020 SolarWinds intrusion and remains one of the most damaging identity attacks because forged tokens bypass MFA, conditional access, and downstream authentication controls. CVE-2026-56155 is the specific 2026 vulnerability that provides the escalation path from a low-privilege AD FS foothold to the token-signing key.

How do we rotate the AD FS token-signing certificate?

Microsoft's official procedure uses the Update-AdfsCertificate PowerShell cmdlet to add a secondary token-signing certificate, then promote it to primary after every relying party has trusted the new certificate. The rollover window is configurable; a typical rollover is 5-14 days. Every relying party trust must be updated with the new certificate metadata. For federations with automatic metadata refresh (most modern SaaS), the update is automatic; for manual federations, each SaaS administrator or vendor must upload the new certificate.

If we do not run on-premises SharePoint, are we still exposed to the AD FS chain?

The specific SharePoint-to-AD FS chain requires an internet-reachable on-premises SharePoint server to serve as the initial-access step. NC SMBs that do not run on-premises SharePoint are not exposed to that specific chain. However, CVE-2026-56155 can be exploited by any attacker who reaches the AD FS host through any other means, including phishing that lands on an admin workstation with an SMB path to AD FS, a compromised VPN appliance (see CVE-2026-15409/15410), or an insider threat.

Should we migrate to Entra ID or to Okta?

Both are legitimate options; the right choice depends on your Microsoft 365 dependency and your third-party SaaS mix. NC SMBs already on Microsoft 365 typically find Entra ID the shortest migration path because directory synchronization is already in place. NC SMBs with a broader SaaS mix (Salesforce, Workday, ServiceNow, Google Workspace) sometimes find Okta's application-catalog breadth easier. Both platforms fully eliminate the on-premises AD FS attack surface.

Does our cyber insurance require an AD FS decommission?

Most 2026 cyber policies do not require AD FS decommission, but they increasingly ask about the federation posture on the questionnaire. A "yes, we run on-premises AD FS" answer is not a disqualifier. A "yes, we run on-premises AD FS with the July 2026 patches applied and a documented migration plan to Entra ID" is a materially stronger answer than "yes, we run on-premises AD FS" with no migration plan.

How long is the certificate rollover window?

Microsoft supports rollover windows from days to weeks; the AD FS AutoCertificateRollover feature can automate the promotion. For an emergency rotation in response to a compromise-hunt finding, plan a shorter rollover (5-7 days) with active communication to every relying-party administrator. For a routine annual rotation, a longer rollover (14-21 days) is fine.

Sources

Support