Okta has announced that from 5 March 2027 Self-Service Registration, Desktop Single Sign-On (IWA) and mobile Device Trust stop working on Classic Engine, which turns the long-optional upgrade to Okta Identity Engine into a deadline for every tenant that still relies on them. The upgrade itself is free and largely self-service, but it changes how policies are evaluated, retires several agents and APIs, and can quietly loosen access if migrated policies are not reviewed. This guide covers the official timeline, the eligibility blockers, how Classic policies map to Identity Engine, how to find Classic API callers, the replacements for Desktop SSO and Device Trust, and how to test the change. It is for Okta administrators, identity architects and the application teams who embed Okta sign-in. Steady-state hardening is covered in the Okta Security Hardening Guide; this page covers the move.
This is an independent guide from NHI Mgmt Group, based on Okta's public documentation as of November 2026. It is not sponsored or reviewed by Okta. Product features change, so confirm settings against Okta's current documentation.
Key takeaways
- 5 March 2027 is the date that matters. Okta's developer blog calls it the hard deadline, after which Okta turns off three Classic capabilities and no longer fixes bugs or vulnerabilities in them.
- Blockers must be cleared first. The self-service upgrade only appears once eligibility tasks are done: IWA routing rules deleted, mobile Device Trust turned off, State Token All Flows disabled, and the Sign-In Widget at 5.11.0 or later on custom hosted pages.
- Migrated policies need a security review. Okta sign-on policies become global session policies, and apps that used the Classic default app policy migrate with a catch-all rule that admits any assigned user with no extra authentication beyond the global session policy.
- Classic APIs keep working only until they do not. The Classic Authentication, Factors and Sessions APIs and pre-Identity Engine SDKs need replacing with redirect flows, the Gen2 widget, the IDX SDK or Direct Authentication APIs.
- The upgrade is a security win if you use it. Okta FastPass, phishing-resistant policy constraints and management attestation become available after the upgrade.
What is changing and why
Classic Engine evaluates sign-in through Okta sign-on policies, app sign-on policies and factor enrolment policies, with authentication driven by the Classic Authentication API. Identity Engine is built around an identifier-first flow: it identifies the user, then decides the next step from policy, device context and available authenticators. Factors become authenticators, policies are reorganised, and new capabilities such as Okta FastPass and phishing-resistant constraints are available only on Identity Engine.
| Classic Engine | Identity Engine | What to check |
|---|---|---|
| Okta sign-on policy | Global session policy | Password requirement and "MFA Required" carry over; review the new "Any factor used to meet the Authentication Policy requirements" option before enabling passwordless |
| App sign-on policy | App sign-in policy (shareable across apps) | Migrated as "<appname> policy"; identical policies merged with a "Merged" prefix; apps on the Classic default policy get a permissive catch-all rule |
| Re-authentication with factor prompt | Password plus another factor, same duration | Confirm the new rule meets your assurance requirement |
| Two separate factors (password and push) | Okta Verify push with biometrics can satisfy two-factor | Decide whether this satisfies your MFA policy wording |
| Self-Service Registration | Profile Enrollment policy | Rebuild registration rules and attribute collection |
| Desktop SSO with IWA agent | Agentless Desktop SSO or Okta FastPass | Retire the IWA agent and routing rules |
| Device Trust (mobile) | Management attestation with Okta Verify | Turn off Classic mobile Device Trust before upgrade (non-Workspace ONE orgs) |
| Okta Mobile app | Not available | Prepare users for its removal |
Official timeline and current status
From Okta's developer blog post of 18 September 2026, checked on 8 November 2026. Okta sends reminders on a fixed schedule; confirm current dates with your account team.
| Date | Event |
|---|---|
| 5 August 2026 | Initial notice to customers |
| 7 September, 7 October, 9 November 2026 | Reminder notices |
| 11 January, 15 February, 1 March 2027 | Reminder notices |
| 5 March 2027 | End of support for Self-Service Registration, Desktop SSO (IWA) and Device Trust (mobile) on Classic Engine; Okta turns these off |
The announcement is scoped to these three capabilities. It is not a date for Classic Engine as a whole, but any tenant using one of them must upgrade or lose the function.
Who and what is affected
- Workforce tenants with Desktop SSO: domain-joined Windows users who sign in silently through the IWA agent.
- Tenants with mobile Device Trust: access rules that rely on device trust signals for mobile apps.
- Customer-facing tenants with Self-Service Registration: sign-up journeys for customers or partners.
- Application teams with embedded sign-in: custom pages, self-hosted widgets older than 5.11.0, Classic SDKs and direct calls to Classic APIs.
- Automation and integrations: event hooks that read the phone number field (its location changes), older AWS CLI tooling to update for Identity Engine, and Terraform configuration that must be resynchronised after upgrade.
Finding affected systems and identities
| Dependency | How to find it | Replacement |
|---|---|---|
| Classic Authentication, Factors and Sessions API calls | Search the Okta System Log for requests to the Classic authn, factors and sessions endpoints, grouped by client and user agent; search application code for those paths and Classic SDK packages | Okta-hosted redirect (OIDC, SAML), Gen2 widget, IDX SDK, or Direct Authentication APIs |
| Custom hosted sign-in page and widget version | Customisations settings; widget version in page source | Widget 5.11.0 or later with deprecated JavaScript methods removed, or Okta-hosted Gen3 |
| IWA agents and routing rules | Directory integrations and identity provider routing rules | Agentless Desktop SSO or FastPass; delete routing rules |
| Mobile Device Trust | Security settings and app sign-on rules referencing trusted devices | Management attestation through Okta Verify |
| Older AWS CLI tooling | System Log entries for the CLI tool | AWS IAM Identity Center before upgrade or the okta-aws-cli app after |
| State Token All Flows (STAF) | Pre-upgrade checklist warning | Disable it or dismiss the warning |
| Event hooks using phone number | Event hook endpoint code | Update to the new field location |
Identity angle: integrations that call Classic APIs usually authenticate with Okta API tokens or service apps. The migration is the moment to replace SSWS tokens tied to a human admin with scoped OAuth service apps and to retire unused tokens. See the How to audit Okta API tokens and service apps.
Migration options
Choosing a deployment model for embedded sign-in
| Path | When to choose it | Security trade-off |
|---|---|---|
| A: Okta-hosted redirect (recommended by Okta) | Web and most mobile apps | Okta owns the UI and supports newer authenticators such as passkeys and FastPass; least code to secure |
| B: Self-hosted Gen2 Sign-In Widget | The sign-in UI must be embedded | You must keep the widget current; Gen3 is Okta-hosted |
| C: Embedded SDK or Auth.js | Fully custom UI | You own the security and maintenance of the flow |
| D: Direct Authentication APIs | Native, CLI, server-side or machine-to-machine without browser redirects | Credential handling needs extra care; avoid for browser apps |
Replacing Desktop SSO
- Agentless Desktop SSO: keeps silent Kerberos-based sign-in for domain-joined devices without the IWA agent servers. Treat the Active Directory service account it uses as a privileged non-human identity with a strong password and AES Kerberos encryption types. See the Kerberos RC4 Deprecation.
- Okta FastPass: a passwordless authenticator in Okta Verify using public key cryptography, with origin checks that resist phishing, on Android, iOS, Linux, macOS and Windows. It works for unmanaged as well as managed devices.
- Decision guidance: agentless Desktop SSO is the smaller change for a Windows estate; FastPass gives phishing resistance and cross-platform coverage, and pairs with phishing-resistant constraints in app sign-in policy rules. Many organisations run both during transition.
Replacing Device Trust and registration
- Device Trust: move to management attestation with Okta Verify, then add device conditions to app sign-in policies for sensitive apps.
- Self-Service Registration: rebuild in a Profile Enrollment policy, adding bot protection and email verification as part of the rebuild.
Phased approach
- Inventory blockers and Classic API callers first, since some remediations (Desktop SSO, embedded apps) need release cycles of their own.
- Remediate blockers in Classic: agentless Desktop SSO, Device Trust off, widget upgrade, STAF off, event hooks updated.
- Rehearse in a preview or free trial org using Okta's upgrade test plan.
- Schedule the self-service upgrade in a maintenance window (only super admins can manage it).
- Review migrated policies immediately after: replace catch-all rules on sensitive apps, consolidate merged policies deliberately.
- Adopt new controls: FastPass, phishing-resistant constraints for admins and high-value apps, device conditions.
Testing and rollback
- Test plan coverage: sign-in, sign-out, account recovery, activation and self-service registration, plus identifier-first behaviour, for each user population and each deployment path.
- Policy diff: export Classic policies before the upgrade (Terraform state or API) and compare them with the migrated global session and app sign-in policies rule by rule.
- API verification: confirm in the System Log that no active calls to Classic Authentication, Factors or Sessions API patterns remain after cutover of each app.
- Rollback: the Okta help pages reviewed for this guide do not describe a tenant rollback, so plan as if the upgrade is one-way. Rehearse in a preview org, and keep application-level rollback (previous widget or SDK release) available only where it is compatible with Identity Engine.
- Admin access: keep a tested break-glass super admin with a phishing-resistant authenticator through the change window.
Monitoring and metrics
- Classic API calls per day, trending to zero before 5 March 2027.
- Apps on a catch-all rule with no additional authentication: target zero for sensitive apps.
- Percentage of workforce users enrolled in FastPass or another phishing-resistant authenticator.
- Sign-in failure rate and help desk tickets per day during the first two weeks after upgrade.
- MFA prompts denied or timed out, watching for push fatigue patterns (ATT&CK T1621).
Risks of doing nothing
- Broken sign-in on 5 March 2027: Desktop SSO, mobile Device Trust and Self-Service Registration are switched off on Classic, so users fall back to prompts or lose access, and registration stops.
- Retired capabilities left in use: Okta states it no longer addresses bugs or security vulnerabilities in the retired capabilities.
- A rushed upgrade: upgrading under deadline pressure without reviewing migrated policies leaves permissive catch-all rules in place on sensitive apps.
- Not turning on Identity Engine security features: phishing-resistant constraints and FastPass are Identity Engine features; turn them on after the upgrade to counter adversary-in-the-middle and push fatigue attacks (T1556.006 and T1621).
Common failure patterns
- Leaving merged and catch-all app sign-in policies untouched after upgrade, so assignment becomes the only access control.
- Upgrading the tenant while embedded apps still call Classic APIs, then finding failures app by app in production.
- Deleting IWA routing rules without deploying agentless Desktop SSO or FastPass, causing a wave of password prompts and help desk resets that social engineers exploit.
- Forgetting automation: Terraform drift, event hooks and CLI tools break silently after the upgrade.
- Enabling the passwordless global session option before every app sign-in policy requires an appropriate authenticator.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-22 Unsupported System Components | Retiring Classic capabilities before end of support |
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2) Multi-factor Authentication | MFA policy after mapping to authenticators |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory | Inventory of Classic API callers and agents |
| NIST CSF 2.0 | PR.AA-03; PR.PS-02 | Authentication; replacing software commensurate with risk |
| MITRE ATT&CK | T1621; T1556.006 | MFA request generation and MFA tampering, mitigated by phishing-resistant authenticators |
Practitioner checklist
- Record 5 March 2027 and an internal target date at least a month earlier in the risk register.
- Work through the pre-upgrade checklist until the self-service upgrade appears for super admins.
- Find every Classic Authentication, Factors and Sessions API caller in the System Log and in code.
- Replace IWA with agentless Desktop SSO or FastPass and harden the Kerberos service account.
- Turn off Classic mobile Device Trust and plan management attestation with Okta Verify.
- Rehearse the upgrade in a preview or trial org using Okta's test plan.
- After upgrade, review every migrated app sign-in policy and remove permissive catch-all rules on sensitive apps.
- Require phishing-resistant authenticators for admins and high-value apps.
- Replace human-bound API tokens used by Classic integrations with scoped service apps.
Standards and references
- Okta Developer: Classic Engine deprecation announcement
- Okta Developer: Replace Classic Engine authentication flows with Okta Identity Engine
- Okta Help: Identity Engine pre-upgrade checklist
- Okta Help: Okta sign-on policies after upgrade
- Okta Help: App sign-on policy migration
- Okta Help: Okta FastPass
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Okta Security Hardening Guide · Okta System Log Detection Guide · Phishing-Resistant MFA Guide · Identity Platform Migration