AD FS decommissioning: what must be true before shutdown

The hidden risk: AD FS rarely fails loudly

A bad AD FS shutdown does not usually trigger a neat outage page. It shows up as 2 a.m. help desk tickets, stalled SSO for a finance app, and partner federations that keep retrying until they hit lockouts. In one enterprise migration, 14% of sign-ins still depended on AD FS after the team believed they were done, and the first sign was a 38-minute outage for 1,200 users in APAC.

The hard truth is this: AD FS decommissioning is not a server retirement task. It is a proof exercise. Before you turn it off, you need to prove that every authentication path, every trust, every token consumer, and every exception has a replacement or a documented exit.

What has to be true before AD FS decommissioning

1) No production app still depends on WS-Fed, SAML, or claims rules hosted by AD FS

You need an inventory that is better than "we think everything moved." Pull the relying party trusts, export the claims rules, and match them to actual traffic. In practice, that means checking Azure AD sign-in logs, firewall logs, and app configs for endpoints like https://adfs.company.com/adfs/ls/.

A useful rule: if an app still receives tokens from AD FS, it is not ready. One manufacturing firm found a legacy ERP using WS-Federation with a custom claim transform for employee cost center mapping. That one mapping blocked shutdown for six weeks until the ERP vendor delivered a replacement SAML profile.

# Export relying party trusts from AD FS for review
Get-ADFSRelyingPartyTrust | Select-Object Name,Identifier,Enabled,WSFedEndpoint,ProtocolProfile | \
  Export-Csv .\adfs-relying-parties.csv -NoTypeInformation

# Find claims issuance rules that may be business-critical
Get-ADFSRelyingPartyTrust | ForEach-Object {
  [pscustomobject]@{
    Name = $_.Name
    ClaimsRules = ($_.IssuanceTransformRules -replace "\r\n"," | ")
  }
} | Export-Csv .\adfs-claims-rules.csv -NoTypeInformation

2) Every user population has a tested replacement path

For employees, that usually means Microsoft Entra ID with modern auth, Conditional Access, and phishing-resistant MFA. For contractors, partners, and service accounts, the answer may be different. If you still have B2B partners federating through AD FS, you need a migration plan per tenant, not a blanket cutover.

A common benchmark in 2026: organizations that moved 90%+ of interactive sign-ins to Entra ID before decommissioning AD FS reduced authentication-related tickets by 30-45% in the first month after shutdown. The remaining 10% were usually the expensive cases: legacy VPNs, thick clients, and partner portals.

3) Device trust and MFA do not silently rely on AD FS

This is where teams get surprised. Windows Hello for Business, certificate-based auth, device claims, and some MFA adapters may still be chained to AD FS. If your compliance posture depends on device-based access rules, verify the policy engine now, not after cutover.

You should be able to answer these questions with evidence:

• Are all MFA methods enforced in Entra ID or another replacement IdP?
• Are any smartcard, certificate, or third-party MFA adapters registered only in AD FS?
• Are hybrid joined devices validating against AD FS for any sign-in path?

If the answer to any of those is "maybe," the shutdown date is not real.

4) Legacy protocols have been isolated or eliminated

AD FS often survives because one old app still speaks the wrong protocol. In 2026, that usually means a thick client, a custom .NET app, or an appliance that only supports WS-Fed or SAML 1.1. You do not need to modernize every app first, but you do need to isolate the stragglers.

A practical threshold: if more than 5% of authentication volume still goes through legacy protocols, decommissioning AD FS should wait. That 5% often masks a much larger business risk because those users are usually concentrated in revenue, operations, or external access.

Legacy auth decision tree

App -> Supports OIDC? -> Move to Entra ID app registration
    -> Supports SAML 2.0? -> Reconfigure federation and test claims
    -> Supports only WS-Fed/SAML 1.1? -> Keep temporary exception or replace app
    -> Uses custom auth headers? -> Refactor gateway or front door

Build the evidence: inventory, traffic, and exception mapping

Start with three inventories, not one

A single spreadsheet will miss something. You need:

1. Identity inventory: all AD FS relying parties, claims providers, MFA adapters, certificates, and proxy endpoints.
2. Application inventory: every app, owner, protocol, and auth dependency.
3. Traffic inventory: real sign-in and token issuance data for at least 30 days, ideally 90.

In one retail migration, the team believed 22 apps still used AD FS. Traffic logs showed 31. Nine were dormant in CMDB but active in a warehouse subnet, generating only 2-3 logins per day each. Those low-volume apps were the ones that caused the most confusion during cutover.

Use log correlation to prove readiness

Do not trust app owners alone. Correlate AD FS event logs with Entra sign-in logs and reverse proxy logs. Look for:

• Auth requests by source IP
• Relying party identifiers
• Token issuance failures
• Certificate rollover events
• External partner domains

If your AD FS farm still handles more than a few hundred authentications per day, you should be able to quantify where they come from. A healthy migration usually shows a steady decline of 10-20% month over month, not a cliff.

-- Example logic for correlating auth activity in a SIEM
SELECT
  source_ip,
  relying_party,
  COUNT(*) AS auth_count,
  MAX(event_time) AS last_seen
FROM auth_events
WHERE provider = 'ADFS'
  AND event_time >= DATEADD(day, -30, GETUTCDATE())
GROUP BY source_ip, relying_party
ORDER BY auth_count DESC;

Document every exception with an owner and an expiry date

If a business unit insists on keeping AD FS for one app, write it down as a time-boxed exception. No owner, no exception. No expiry date, no exception.

A good exception record includes:

• App name and business owner
• Protocol and endpoint
• Why migration is blocked
• Compensating control
• Target removal date

Without that structure, AD FS decommissioning turns into a permanent temporary state.

Replace the control plane, not just the login page

Modern auth is not enough if governance is missing

Moving users to Entra ID is only half the job. You also need the policy layer that AD FS may have been providing indirectly. That includes MFA enforcement, device compliance, session controls, and conditional access for risky sign-ins.

A realistic target architecture in 2026 looks like this:

Users / Devices
   |
   v
Microsoft Entra ID
   |-- Conditional Access
   |-- Phishing-resistant MFA
   |-- Identity Protection
   |-- Access Reviews
   |
   +--> SaaS apps via OIDC/SAML
   +--> On-prem apps via App Proxy / header-based gateway
   +--> Legacy apps via temporary federation bridge

If you remove AD FS without replacing these controls, you may improve availability while weakening policy enforcement. That is not a win.

Test for policy equivalence, not just login success

Your success criteria should include:

• MFA prompts fire for the same risk scenarios
• Named locations still work
• Device compliance still blocks unmanaged endpoints
• Guest access policies still apply
• Break-glass accounts are excluded and monitored

One enterprise cutover passed 10,000 login tests but failed a policy test because contractors from unmanaged devices could still access a sensitive SharePoint site. The issue was not authentication; it was conditional access drift.

Run the final cutover like a controlled failure

Prove rollback before you disable anything

The cleanest AD FS decommissioning plans include a rollback window, even if you never use it. Before shutdown, freeze configuration, export certificates, document DNS records, and keep the federation metadata handy.

A practical sequence:

1. Disable new app onboarding to AD FS.
2. Move remaining apps to a temporary deny-by-default state.
3. Monitor sign-in attempts for 2-4 weeks.
4. Confirm zero production traffic.
5. Remove external endpoints and proxy exposure.
6. Disable the farm in a maintenance window.
7. Keep backups and metadata for 30-90 days.

If you still have active traffic after step 3, do not argue with the data. Find the hidden dependency.

Watch for the last-mile failures

The final 10% of AD FS decommissioning problems usually come from:

• Hard-coded federation URLs in scripts or desktop shortcuts
• Old metadata cached in partner environments
• Mobile apps using embedded browser flows
• Scheduled jobs running under service principals with stale auth settings
• DNS records and certificates that were never cleaned up

A good shutdown runbook includes packet captures, sign-in dashboards, and a named responder from identity, network, and app teams. In one case, a single stale DNS CNAME kept an external vendor hitting the old AD FS endpoint for 11 days after the "shutdown" because their resolver cache was aggressively sticky.

# Example checks before disabling AD FS DNS and endpoints
nslookup adfs.company.com
curl -I https://adfs.company.com/adfs/ls/
Get-ADFSProperties | Select-Object HostName, FederationServiceDisplayName, AutoCertificateRollover

Common Pitfalls

Assuming low traffic means no dependency

Low volume can still mean high criticality. Payroll, trading, and partner portals often authenticate only a few times a day, but failures are expensive. Always map volume to business impact.

Forgetting service accounts and automation

Not every auth flow has a human user. Scheduled exports, integration jobs, and legacy middleware often break after AD FS decommissioning because nobody listed them as apps.

Migrating the app but not the claims logic

If an app needs department, region, or entitlement claims, the migration is incomplete until those claims are reproduced. Missing claims often look like authorization bugs, not login failures.

Leaving certificates and DNS in place

Old certificates, published metadata, and public DNS records keep the blast radius alive. Remove them only after traffic has been zero for a meaningful window and monitoring confirms it.

Cutting over without a named business owner

Identity teams can execute the move, but business owners must sign off on the risk. If nobody owns the exception, the exception will survive forever.

Key Takeaways

• Inventory every relying party, claim rule, MFA adapter, and external trust before planning AD FS decommissioning.
• Use 30-90 days of real traffic data to prove that no production app still depends on AD FS.
• Replace not just authentication, but also device trust, MFA policy, and conditional access behavior.
• Treat every legacy protocol app as an explicit exception with an owner and an expiry date.
• Run cutover like a controlled failure: freeze changes, monitor for hidden traffic, and keep rollback data ready.
• Do not turn off AD FS until sign-in logs, app owners, and business stakeholders all agree the dependency graph is empty.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.