ADFS to Okta Migration: The Integration Failures That Always Happen and How to Prevent Them
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
ADFS to Okta is one of the most common enterprise identity projects of the past five years. It is also one of the most consistently underscoped. The Okta sales process focuses on the straightforward SAML and OIDC applications that migrate cleanly. The actual migration reveals the applications that were never documented in the integration catalog, the devices that authenticate against ADFS in ways that are not visible in normal usage, and the on-premises applications that relied on ADFS Web Application Proxy in ways that Okta cannot replicate natively.
This guide covers the five failure categories that derail ADFS to Okta migrations, with specific diagnosis steps and configurations for each. The starting point before any of this applies is the pre-migration ADFS inventory.
Pre-migration: audit every relying party trust in ADFS
The ADFS relying party trust list is the source of truth for what needs to migrate. Run this on any ADFS server: Get-AdfsRelyingPartyTrust | Select-Object Name, Identifier, WSFedEndpoint, SAMLEndpoint, IssuanceTransformRules, AccessControlPolicyName | Export-Csv -Path C:\adfs_rpts.csv
The output gives you every application federated to ADFS, its protocol (WS-Federation or SAML 2.0), and its issuance transform rules. The IssuanceTransformRules column is critical: it shows every custom claim the application receives. Applications with complex issuance rules (multiple claim types, claim value transformations, group-to-role mappings) require proportionally more configuration work in Okta.
Classify each relying party trust into three categories: SAML 2.0 applications that Okta can consume directly (straightforward migration), WS-Federation applications that require testing (higher risk), and applications with complex claim transformations that require custom attribute statement configuration in Okta (longest migration time).
Also identify: applications with IP-based access restrictions in ADFS, applications using ADFS's multi-factor authentication adapter, and applications that use ADFS Windows Integrated Authentication (Kerberos).
Failure 1: WS-Federation claims mismatches
WS-Federation applications often depend on specific claim types in the format http://schemas.microsoft.com/ws/2008/06/identity/claims/ or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/. ADFS issuance transform rules produce these claim types from Active Directory attributes. Okta's attribute statements use different naming conventions by default.
The failure manifests as the application accepting the token but then rejecting the user with an authorization error because the group membership or role claim is missing or in an unexpected format.
Fix: in Okta, the application's SAML attribute statements must replicate the exact claim type URIs that ADFS was issuing. Navigate to the Okta application configuration > Sign On > Attributes. For each ADFS issuance rule, create a corresponding Okta attribute statement with the same Name (the claim type URI), same Format (URI), and an Okta expression that maps the equivalent Okta profile attribute or group membership.
For group-to-role claim mappings (ADFS was issuing role claims based on AD group membership), use Okta's group attribute statements to map Okta groups to the expected role values. This requires that the ADFS AD groups have been replicated to Okta either through the Okta AD Agent or manually recreated as Okta groups.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Failure 2: Hybrid Azure AD joined devices lose Primary Refresh Tokens
Hybrid Azure AD joined devices use ADFS to issue Primary Refresh Tokens (PRTs) when they are connected to the corporate network. During the migration window when ADFS is being replaced by Okta, these devices continue attempting to authenticate against the old ADFS endpoint. If ADFS is decommissioned or the federation trust is switched to Okta before device PRT issuance is migrated, devices lose their PRT and users are prompted to re-authenticate on every application launch.
Diagnosis: before cutover, run dsregcmd /status on several hybrid-joined devices. Look at the AzureAdPrt field. If it shows NO during the migration window, the device has lost its PRT and needs to re-authenticate.
Fix: the correct migration sequence for hybrid-joined devices is to convert the domain federation from ADFS to Okta using the Okta domain federation feature BEFORE decommissioning ADFS. Okta's AD Agent handles the PRT issuance flow once federation is pointed to Okta. Run Convert-MgDomainToManaged followed by the Okta federation configuration steps to perform the domain federation transfer. Devices that were hybrid-joined under ADFS will receive new PRTs from the Okta federation endpoint after the next Group Policy refresh cycle.
Failure 3: on-premises applications with no cloud proxy path
ADFS Web Application Proxy (WAP) allowed organizations to publish on-premises applications to external users without a VPN. Applications published through WAP received ADFS-issued tokens, providing pre-authentication at the proxy layer. Okta does not have a native WAP equivalent.
The replacement for WAP-published applications is Okta Access Gateway (OAG), a Linux-based appliance deployed in the on-premises network that integrates with the Okta identity platform. OAG provides pre-authentication, header injection, and reverse proxy capabilities for on-premises web applications.
Applications that used WAP with Kerberos Constrained Delegation (KCD) for backend authentication require additional configuration in OAG. OAG supports KCD through its Identity Engine integration, but the service account used for delegation must be configured in Active Directory with the appropriate delegation settings for each backend application's SPN.
For organizations that cannot deploy OAG, the alternative is to migrate WAP-published applications to Azure App Proxy, which uses the Microsoft Entra ID Application Proxy connector and integrates with the Okta-managed Entra directory. This approach works when the organization is willing to use Entra ID as the token issuer for the proxied application rather than Okta.
The last 10 percent: applications that cannot migrate
Every ADFS to Okta migration has a residual set of applications that cannot migrate to Okta within the project timeline. These fall into two categories.
First: applications with claim requirements that Okta cannot produce. Some legacy applications validate the signing certificate thumbprint of the ADFS token rather than the certificate content, or validate the issuer URI against a hardcoded value that requires a code change to update. These applications need to remain on ADFS or require application-level changes that are out of scope for the identity migration project.
Second: applications that use Windows Integrated Authentication (WIA) for Kerberos-based browser SSO. WIA depends on the browser passing a Kerberos ticket directly to the IIS application, with ADFS serving as the Kerberos realm. Okta does not support WIA. These applications require either a WAP or OAG proxy layer, or conversion to SAML or OIDC at the application level.
For the residual applications, the practical approach is to maintain a minimal ADFS infrastructure specifically for these applications while completing the migration for all other applications to Okta. Document the residual list with a specific migration path for each, and establish a timeline for either retiring the application or completing the SAML conversion. Leaving ADFS running indefinitely for 10 percent of applications is a security debt that requires active management.
The bottom line
ADFS to Okta migration succeeds when the application inventory and claims audit happen before project kickoff rather than during it. The WS-Federation claims mapping, hybrid device PRT migration sequence, and on-premises application proxy gap are predictable for every migration. The failures happen when these categories are discovered during cutover rather than planned for during design. Run Get-AdfsRelyingPartyTrust before you sign the Okta contract.
Frequently asked questions
How long does an ADFS to Okta migration take?
For a mid-market organization with 50 to 150 federated applications, 3 to 6 months is realistic when starting from a complete application inventory. Large enterprises with 300 or more applications typically run 6 to 18 months. The timeline is driven primarily by the number of applications with custom claims transformation requirements and the presence of hybrid Azure AD joined devices. Organizations that have already inventoried their ADFS relying party trusts and classified applications by migration complexity before starting will complete 30 to 40 percent faster than those that discover the inventory during the project.
Can Okta replace ADFS for all use cases, including WS-Federation?
Okta supports WS-Federation as a protocol for SAML identity federation but does not support all ADFS WS-Federation specific behaviors, particularly around complex issuance transform rule chains and Windows Integrated Authentication. Most WS-Federation applications can migrate to Okta with attribute statement configuration that replicates the claim types ADFS issued. Applications that validate token signing details at the cryptographic level rather than the claim level, or that use WIA browser authentication, require additional proxy infrastructure or application-level changes.
What is the recommended cutover sequence for ADFS to Okta?
The recommended sequence is: 1) Complete Okta configuration for all applications and test with a pilot user group, 2) Migrate domain federation from ADFS to Okta using Convert-MgDomainToManaged and the Okta federation configuration, 3) Monitor for 48 hours with both ADFS and Okta active and route specific users to each using Staged Rollout in Entra ID, 4) Complete user migration and decommission ADFS WAP before the ADFS servers. Do not decommission ADFS servers until the residual application list has been resolved or documented with a maintained ADFS path.
What are the most common ADFS to Okta migration failures?
The five most common failures are: (1) custom claims transformation rules in ADFS that map attributes with logic Okta's expression language cannot replicate directly, requiring application-level changes or workarounds; (2) Windows Integrated Authentication dependencies for intranet users who authenticate silently via Kerberos without an interactive login page; (3) on-premises applications that hard-code the ADFS metadata endpoint URL and must be reconfigured to point to Okta's metadata URL; (4) hybrid Azure AD joined devices that have a dependency on ADFS for device authentication; and (5) legacy applications using basic authentication to ADFS that must be updated to support SAML or OIDC.
Can ADFS and Okta run in parallel during a migration?
Yes, and parallel operation is the recommended approach. Okta can federate through ADFS as an upstream identity provider while the migration proceeds application by application. Once an application is configured in Okta directly, traffic for that application routes through Okta while ADFS continues handling unconfigured applications. Entra ID's Staged Rollout feature allows you to route specific users through Okta federation while others remain on ADFS, enabling a per-user or per-group migration wave rather than a single cutover event.
How do I validate that ADFS claim rules are correctly reproduced in Okta before cutover?
Use Okta's SAML tracer browser extension and the application's SAML debugger to capture the assertion Okta sends after authentication and compare it attribute by attribute against a captured ADFS assertion for the same user. Focus on: NameID format and value, group membership claims, custom attributes the application uses for authorization decisions, and any claim transformations (e.g., email to UPN conversion). For applications that rely on group membership claims for role assignment, verify that the Okta groups are correctly mapped and that the claim name and format match exactly what ADFS was sending. A single mismatched claim attribute name causes silent authorization failures that appear as successful logins with no application access.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.