Case Study: Improving Identity Security by Decommissioning AD FS and Moving to Modern Cloud Authentication
At a glance
- Client type: Two large New Zealand enterprises
- Problem: Critical authentication dependency on legacy AD FS for Microsoft 365 and applications
- Action: Migrated authentication to Microsoft Entra ID, moved applications to Entra ID SSO, enabled MFA, and designed Conditional Access
- Outcome: AD FS dependency removed or significantly reduced, with improved identity security and lower federation risk
Overview
Two large New Zealand enterprises were still relying on Active Directory Federation Services, commonly known as AD FS, for Microsoft 365 and application authentication.
AD FS had originally been implemented because many enterprises needed federation to adopt Microsoft 365 and Azure Active Directory at the time. However, identity platforms have moved on. Microsoft Entra ID now provides modern cloud authentication, Conditional Access, MFA, application SSO, and stronger identity security controls without requiring organisations to maintain complex federation infrastructure.
For both organisations, AD FS had become difficult to operate, difficult to secure, and difficult to decommission. Internal teams had attempted to remove it several times over multiple years, but the work repeatedly stalled because of complexity, uncertainty, legacy application dependencies, and limited internal experience with federation services.
CloudQbit helped decommission AD FS, migrate Microsoft 365 authentication to modern cloud authentication, move federated applications to Microsoft Entra ID SSO, enable MFA, and design Conditional Access policies.
The result was a significant identity security uplift, reduced infrastructure complexity, and a modern authentication model aligned with Microsoft Entra best practice. Microsoft provides guidance and tooling for migrating from federation to cloud authentication and for moving AD FS applications to Microsoft Entra ID.
The Challenge
The organisations were large enterprises with mature but complex identity environments.
AD FS had been in place for years and was used for Microsoft 365 sign-in and multiple federated applications. Over time, the platform became a difficult dependency.
The challenge was not simply technical. It was also operational.
Internal teams understood that AD FS should eventually be removed, but decommissioning it had repeatedly been placed into the “too hard” category. Projects were started, paused, closed, and restarted because the risk of breaking authentication was high.
The organisations needed to answer several critical questions:
| Question | Why it mattered |
|---|---|
| Which applications still depend on AD FS? | Unknown dependencies can break authentication |
| Can Microsoft 365 authentication be moved safely? | User sign-in continuity is business critical |
| Which applications can move to Entra ID SSO? | Application migration must be planned and validated |
| How will MFA be enforced? | Modern security controls need to replace legacy assumptions |
| What Conditional Access policies are required? | Cloud authentication must be protected by strong policy |
| How can AD FS be removed without disruption? | Decommissioning must be staged, tested, and reversible |
The goal was to modernise identity without interrupting the business.
Why AD FS Had Become a Risk
AD FS is not inherently bad. It served an important purpose for many enterprises adopting Microsoft 365 and federated identity.
However, in many environments, AD FS has become legacy identity infrastructure that is expensive and risky to maintain.
It usually requires:
- Federation servers
- Web Application Proxy or equivalent publishing components
- Certificates
- Firewall rules
- Monitoring
- Patch management
- High availability design
- Disaster recovery planning
- Specialist operational knowledge
If not operated carefully, AD FS can become a critical authentication dependency with a large support burden.
Modern Microsoft Entra ID authentication reduces that dependency by moving the authentication control plane into the cloud and enabling capabilities such as Conditional Access, MFA, risk-based controls, and modern application SSO. Microsoft also has specific Entra recommendations that identify AD FS application migration opportunities.
The key issue was that the organisations still had a legacy federation model where a modern cloud identity model was now more appropriate.
Investigation Approach
CloudQbit approached the work as a controlled identity modernisation project, not a simple infrastructure removal.
The first step was discovery.
The review focused on:
| Area | Review focus |
|---|---|
| Microsoft 365 federation | How the tenant authenticated users |
| AD FS relying party trusts | Which applications depended on AD FS |
| Sign-in patterns | Which applications were actively used |
| Claims rules | What custom logic needed to be replicated or redesigned |
| Certificates | Federation and token-signing dependencies |
| MFA model | Existing MFA coverage and gaps |
| Conditional Access | Required policies for secure cloud authentication |
| Rollback planning | How to reduce risk during cutover |
This helped create a clear migration path rather than attempting a risky “big bang” decommission.
Microsoft’s AD FS application migration guidance supports a staged approach: discover applications, evaluate migration feasibility, configure Entra applications, test, and then move authentication.
Root Cause
The root cause was legacy identity dependency combined with limited internal capability to safely remove it.
AD FS had become embedded in the environment over many years. Application dependencies were not always fully documented, and teams were understandably cautious about changing authentication systems.
The main issues were:
| Issue | Impact |
|---|---|
| Legacy federation dependency | Microsoft 365 and applications relied on AD FS |
| Limited application visibility | Teams were not always sure what still used AD FS |
| Operational complexity | AD FS required specialist support, certificates, patching, and monitoring |
| Security limitations | Modern Conditional Access and cloud-native controls were harder to use consistently |
| Project uncertainty | Previous decommission attempts stalled due to perceived risk |
| Business-critical sign-in dependency | Any mistake could affect user access to key systems |
The organisations needed production experience, not theory.
Solution Approach
CloudQbit helped design and execute a phased migration away from AD FS.
The work included:
| Area | Action |
|---|---|
| Discovery | Identified AD FS dependencies and active federated applications |
| Microsoft 365 migration | Moved Office 365 authentication from federation to modern cloud authentication |
| Application migration | Migrated AD FS applications to Microsoft Entra ID SSO where appropriate |
| MFA enablement | Enabled or improved MFA coverage for user authentication |
| Conditional Access | Designed policies to protect cloud authentication flows |
| Claims review | Reviewed and translated required claims into modern Entra ID application configuration |
| Testing | Validated sign-in flows before production cutover |
| Cutover planning | Planned staged changes with rollback considerations |
| Decommissioning | Removed AD FS dependencies once authentication was successfully migrated |
| Knowledge transfer | Educated internal teams on the new model and operational responsibilities |
The result was not just removal of servers. It was a shift to a cleaner and more secure identity operating model.
Business and Security Outcome
The AD FS decommissioning delivered a significant improvement in security posture and operational simplicity.
The outcome included:
| Area | Outcome |
|---|---|
| Legacy reduction | AD FS dependency removed or significantly reduced |
| Microsoft 365 authentication | Migrated from federation to modern cloud authentication |
| Application SSO | Federated applications migrated to Microsoft Entra ID SSO |
| MFA | Stronger MFA coverage introduced |
| Conditional Access | Modern access policies designed and applied |
| Operational simplicity | Reduced need to maintain federation infrastructure |
| Security posture | Improved alignment with modern Microsoft identity practices |
| Delivery confidence | Projects that had stalled for years were completed |
| Internal capability | Teams gained better understanding of the modern identity model |
The biggest value was that the organisations moved away from a fragile legacy dependency and into a cloud-native identity control plane.
Benefits of Moving Away from AD FS
For many organisations, removing AD FS can provide both security and operational benefits.
| Benefit | Why it matters |
|---|---|
| Reduced infrastructure | Fewer federation servers, proxies, certificates, and firewall dependencies |
| Better cloud security controls | Conditional Access, MFA, and identity protection become central to authentication |
| Simpler operations | Less specialist AD FS support required |
| Lower outage risk | Authentication no longer depends on on-premises federation availability |
| Improved application SSO | Applications can be integrated directly with Microsoft Entra ID |
| Better visibility | Cloud sign-in logs and Entra reporting provide clearer identity telemetry |
| Easier security governance | Policies can be managed consistently in Entra ID |
| Modernisation path | Helps prepare for stronger cloud-first identity architecture |
Microsoft Entra ID supports modern application authentication through SAML, OpenID Connect, OAuth-based integrations, and gallery or custom enterprise applications. Microsoft’s guidance also describes moving SaaS applications federated with AD FS to Microsoft Entra ID.
The Mindset Shift
The old mindset was:
The improved mindset was:
| Old mindset | Better mindset |
|---|---|
| “AD FS is business critical, so leave it alone.” | “Business-critical identity needs modernisation and controlled migration.” |
| “Nobody fully understands what depends on AD FS.” | “Discovery and sign-in analysis can reduce uncertainty.” |
| “Decommissioning is too hard.” | “A staged migration makes it manageable.” |
| “Federation is required for Microsoft 365.” | “Modern cloud authentication can replace federation in many environments.” |
| “MFA is an add-on.” | “MFA and Conditional Access should be core identity controls.” |
| “Legacy apps block progress.” | “Applications can often be migrated, modernised, or isolated with the right approach.” |
This mindset helped the organisations complete work that had been deferred for years.
Why This Matters
Many enterprises still have AD FS because it was implemented during earlier Microsoft 365 adoption projects.
In some cases, teams are reluctant to remove it because they are unsure which applications depend on it or because they fear sign-in disruption. That concern is understandable. Authentication is critical.
But leaving AD FS in place indefinitely can create its own risks and costs.
A mature AD FS modernisation review should ask:
- Is Microsoft 365 still federated with AD FS?
- Which relying party trusts are still active?
- Which applications have sign-ins in the last 30, 60, or 90 days?
- Which apps can move to Microsoft Entra ID SSO?
- Which claims rules need to be replicated or redesigned?
- Is MFA enforced consistently?
- Are Conditional Access policies designed and tested?
- What is the rollback plan for authentication cutover?
- Can AD FS be decommissioned safely?
- Does the internal team have the experience to complete the migration?
These questions help turn a difficult legacy dependency into a structured modernisation project.
CloudQbit Capability Developed
CloudQbit has real production experience helping large New Zealand enterprises decommission AD FS and migrate to modern Microsoft identity services.
This includes:
- AD FS discovery and dependency mapping
- Microsoft 365 federation to cloud authentication migration
- AD FS relying party application assessment
- Migration of applications to Microsoft Entra ID SSO
- MFA enablement
- Conditional Access design
- Claims and application configuration review
- Cutover and rollback planning
- Decommissioning support
- Team education and documentation
This capability is valuable because many organisations know AD FS should be removed, but do not have the internal confidence or practical experience to complete the work safely.
Conclusion
This case study demonstrates how legacy federation can be safely modernised when the work is approached with the right structure and experience.
Two large New Zealand enterprises had relied on AD FS for Microsoft 365 and application authentication for years. Internal teams had attempted decommissioning before, but the work repeatedly stalled due to complexity, dependency uncertainty, and business risk.
CloudQbit helped migrate Microsoft 365 authentication to modern cloud authentication, move federated applications to Microsoft Entra ID SSO, enable MFA, design Conditional Access policies, and remove AD FS dependencies.
The result was a significant security and operational improvement.
The lesson is simple:
This is the type of practical security and identity improvement CloudQbit focuses on: reducing legacy risk, improving authentication security, and helping organisations move to modern Microsoft identity with confidence.