48-Hour AD FS Identity Health Check for CVE-2026-56155

CISA added CVE-2026-56155, an Active Directory Federation Services zero-day, to its Known Exploited Vulnerabilities catalog on July 14. If your organization runs AD FS for federated authentication, you need to patch immediately and then verify that your identity infrastructure hasn’t already been tampered with. Patching closes the door. It does not tell you whether someone already walked through it.

This post is a 48-hour identity health check for SMBs that still rely on AD FS. It covers the steps your team or IT provider should complete this week, not just applying the update, but validating the trust chain that AD FS depends on.

Why AD FS Is a High-Value Target

AD FS handles authentication for everything your organization federates: Microsoft 365, line-of-business applications, VPN portals, partner integrations. When an attacker compromises a federation server, they don’t just get access to one application. They gain the ability to mint authentication tokens that are trusted across your entire environment.

This is fundamentally different from compromising a single user account. A compromised AD FS server can generate valid tokens for any user, including administrators, without triggering MFA prompts or conditional access policies. The tokens look legitimate because they are signed by your organization’s own signing certificate. Your cloud services, your identity provider, and your security tools all trust them.

That’s why patching isn’t the end of the response. If an attacker exploited CVE-2026-56155 before your organization applied the update, they may have established persistence mechanisms that survive the patch.

The 48-Hour Health Check

Work through these steps in order. If you find something unexpected at any stage, stop and engage your security provider or incident response team before continuing.

Hour 1-4: Patch and Verify the Patch

Apply the Microsoft security update for CVE-2026-56155 from the Microsoft Security Response Center. Confirm the update installed successfully on every AD FS server in your farm, including secondary nodes.

After patching, verify the AD FS service starts cleanly and federation is functioning. Check Event Viewer for AD FS event IDs 299 (successful token issuance), 1000 (failed issuance), and 364 (certificate issues). If the service won’t start or produces certificate-related errors after patching, you may have a signing certificate issue that needs immediate attention.

Hour 4-12: Audit DKM Container Permissions

AD FS stores its token-signing and token-decryption certificates in the Distributed Key Management (DKM) container in Active Directory. This container holds the private keys that sign every authentication token your federation server issues. If an attacker has modified the access control list on this container, they may have extracted or replaced those keys.

Find your DKM container’s distinguished name first:

(Get-AdfsProperties).DkmContainerDn

Then check the container permissions in Active Directory Users and Computers:

1. Open ADUC with Advanced Features enabled (View > Advanced Features)
2. Navigate to the DKM container using the distinguished name from the command above (it will be a GUID-named container, typically under CN=ADFS,CN=Microsoft,CN=Program Data,DC=yourdomain,DC=com)
3. Right-click the container and check the Security tab
4. The only accounts with access should be the AD FS service account and Domain Admins

If you see any account with permissions on this container that shouldn’t be there, particularly recently added entries, treat this as a confirmed compromise indicator. That account may have been used to extract token-signing keys.

Hour 12-24: Validate Signing Certificates

Open the AD FS Management console and navigate to Service > Certificates. You should see two certificates: Token-signing and Token-decryption.

Verify these three things:

• The certificates match what you expect. If your organization tracks certificate thumbprints (you should), compare the current thumbprints against your records. An unexpected certificate means someone rotated it outside your normal process.
• The certificate dates make sense. AD FS auto-renews certificates by default (controlled by the AutoCertificateRollover property). If a certificate was created recently and you didn’t initiate a rollover, investigate.
• Only one primary signing certificate is active. If you see multiple primary signing certificates, determine why. Attackers who extract signing keys sometimes add a secondary certificate to maintain access even if the primary is rotated.

Run Get-AdfsCertificate -CertificateType Token-Signing in PowerShell to see all signing certificates, including secondary ones that the GUI may not prominently display.

Hour 24-36: Review Token Lifetime and Claims Rules

Attackers who gain access to AD FS configuration sometimes modify token lifetime policies to extend session duration, or add custom claims rules that grant elevated access to specific accounts.

Check your global SSO lifetime and per-trust overrides:

Get-AdfsProperties | Select-Object SsoLifetime
Get-AdfsRelyingPartyTrust | Select-Object Name, TokenLifetime | Format-Table -AutoSize

A TokenLifetime of 0 on a relying party trust is normal — it means “inherit the global default.” Focus on trusts with non-zero values that set explicitly long lifetimes (hours or days) and verify those were intentional configuration changes. Also check SsoLifetime at the global level; an attacker who extends the SSO window increases how long a forged token stays valid across all relying parties. Extended token lifetimes are occasionally legitimate for specific applications, but they should be documented and approved.

Review your claims rules for anything unexpected:

Get-AdfsRelyingPartyTrust | ForEach-Object {
    Write-Output "=== $($_.Name) ==="
    $_.IssuanceTransformRules
}

Look for rules that assign administrative roles, bypass MFA claims, or hardcode specific user identifiers. Legitimate claims rules map Active Directory attributes to application claims. Rules that inject static values or override group memberships are red flags.

Hour 36-48: Check Federation Logs and Plan Forward

Prerequisite: verify that AD FS auditing is enabled. If auditing wasn’t turned on before the exposure window, you have no retrospective visibility into what happened — no log review will help. Enable it now with Set-AdfsProperties -AuditLevel Verbose and configure the corresponding Windows audit policy to capture AD FS events. If auditing was off during the entire exposure window, engage your security provider for an alternative forensic assessment rather than assuming the environment is clean.

If audit logs are available, review the period between July 14 (when the CVE was added to KEV) and when you applied the patch. Focus on:

• Event ID 299: Successful token issuance. Look for unusual volumes, authentication from unexpected IP ranges, or token requests for high-privilege accounts during off-hours.
• Event ID 1000: Failed token issuance. Spikes in failed issuance attempts may indicate exploitation attempts or unauthorized access testing.
• Event ID 364: Certificate-related events. Any certificate operations during this window deserve investigation, particularly unexpected certificate validation failures or rollover events.

Consider Whether AD FS Still Makes Sense

This is the harder conversation. AD FS was built for a world where authentication happened on-premises. Microsoft has been steering organizations toward Entra ID (formerly Azure AD) for federated authentication for years, and security is a major reason why.

Cloud-managed identity eliminates the on-premises federation server as an attack surface entirely. There’s no DKM container to protect, no signing certificate to extract, no on-prem server to patch under time pressure. Conditional access policies, continuous access evaluation, and token protection features are natively available without running additional infrastructure.

For organizations that still need AD FS because of applications that require SAML claims or WS-Federation and can’t use OIDC, the question is whether those applications can be migrated. Microsoft’s AD FS to Entra ID migration tools can identify which relying party trusts are compatible with cloud authentication and which require additional work.

If you have 5 relying party trusts and 3 of them can move to Entra ID, moving those 3 reduces your attack surface by 60% even if the remaining 2 keep AD FS running. Partial migration still counts.

Don’t Wait to Start

CVE-2026-56155 is a reminder that federation servers are infrastructure-level targets with infrastructure-level consequences. The 48-hour health check above is the minimum. If your organization runs AD FS and you haven’t had a comprehensive identity security review in the past year, the current threat environment makes that overdue.

For Dallas-Fort Worth businesses that need help running through this health check or evaluating migration to cloud-native identity, our team has done this work across healthcare, financial services, and defense contractor environments where identity security is non-negotiable.