Still on Okta Classic Engine? Three features stop working on March 5, 2027, and two of them block the upgrade

Okta is switching off three features on Classic EnginedefinitionOkta's older sign-in engine. You can tell an org runs it when the version in the Admin Console footer ends in C. orgs on March 5, 2027: self-service registration, Desktop SSO through the IWAdefinitionIntegrated Windows Authentication. Okta's IWA agent sits on Windows servers in your domain and uses each person's Kerberos ticket to sign them in, which is why office staff never see a password page. agent, and Mobile Device Trust. If your org still runs Classic and uses any of them, you lose them that day. Check the footer of your Admin Console this week. If the version ends in C, start the Identity Engine upgrade now, while there's still time to test it in Preview first.

Okta's developer blog is blunt about it. Once support ends, Okta turns these capabilities off on Classic Engine, and it stops fixing bugs, security holes or broken flows in them. So this isn't a feature that quietly ages. From March 6, expect the self-service sign-up to stop working for customers, and staff who used to land in their apps without typing a password to be asked for one.

Mobile Device Trust is the one that hurts most if it's missed. Okta describes it as limiting app access to managed devices through Workspace ONE, so policies built on it decide which phones get into sensitive apps. When that check goes, you either lock people out or let unmanaged devices in, depending on how your rules are written. Neither is a good week for the help desk.

Okta sends reminders, with the next ones due November 9, January 11, February 15 and March 1. The trouble is that two of the three features also block the upgrade itself. You can't book the Identity EnginedefinitionOkta's newer sign-in engine, where passwordless sign-in and the new device checks live. If the Admin Console version ends in E, you're already on it. upgrade while IWA routing rules are active, and mobile Device Trust has to be switched off before the upgrade runs. Leave it until February and you'll be doing the hard part under pressure.

For engineers: the upgrade itself is an engine switch you can schedule once every Upgrade Hub action item is done. Apps that use standard SAML or OIDC redirects to the default Okta domain need no code changes, and the Okta-hosted Sign-In Widget keeps working as it is. The risk sits in custom code and in the three retiring features, which each need their own replacement built and tested before production moves.

Self-service registration is the easiest of the three. If you had it switched on in Classic, the upgrade turns on self-service registration in the default enrollment policy and leaves progressive profiling off. What doesn't come across is any read-only or hidden field from your old sign-up form, because the new form only takes read-write attributes. The default redirect option is gone too. Open your old form, list every field and where users went after signing up, and rebuild what's missing.

Desktop SSO is where the real work starts. The IWA agent sat on Windows servers in your domain, checked each user's Kerberos ticket and passed the result to Okta. Agentless Desktop SSOdefinitionAutomatic Windows sign-in where Okta checks the Kerberos ticket itself through an Active Directory service account, so no IWA servers are needed. drops those servers. You create a service account with a Service Principal Name in Active Directory, set up browsers on Windows and Mac, and Okta does the Kerberos check itself. Okta also says it's no longer adding IWA features and gives IWA only limited support and bug fixes, so there's nothing to wait for.

Desktop Device Trust isn't on Okta's March 5 list, but it doesn't carry over to Identity Engine either, and it needs the most care, because the order of steps decides whether people keep access. On desktops you stand up a new certificate authority for Okta Verify, push the new certificates through your MDM, and only then push Okta Verify. Okta's FAQ warns that doing it the other way round cuts users off from apps protected by Device Trust. Classic certificates keep working until each user registers Okta Verify, so don't revoke them early.

You run the upgrade yourself, but you need a super admin to see it. Once your org qualifies, a banner sits on the Admin Dashboard. If it's missing, something on the eligibility list is still open. Work through the Upgrade Hub, which gives a remediation guide for every action item. Scheduling only opens when they're all done.

Okta's rollout guide wants Preview upgraded first, then any sandbox orgs, then production, with at least a week between Preview and production. Each upgrade takes a few minutes and has no downtime, and every admin gets an email when one is booked. Test sign-in, registration, MFA enrollment and password recovery in Preview before you book production.

Don't plan around rollback. Okta will try to put an org back on Classic if a problem can't be fixed in the first seven days after the upgrade, but it calls that a best effort. Changed behaviour that Okta intended doesn't qualify. Most issues found in testing turn out to be configuration, so do the learning in Preview.

One question that comes up on Okta's developer forum is how the Classic Factors API maps to Identity Engine authenticators. The Classic Authn, Factors and Sessions APIs still work after the upgrade, but they don't give you Identity Engine features, and some Sessions API methods aren't supported. Find every custom integration that touches sign-in, account creation, password recovery or sessions, and test each one in Preview. Embedded Sign-In Widgets and SDKs need upgrading to the current Identity Engine versions.

# 1. Engine check: scroll to the Admin Console footer. A version ending in C is Classic, E is Identity Engine
# 2. Find any custom code still calling the Classic registration endpoint, since it has to move
$ grep -rn "api/v1/registration" ./src ./services
# 3. Make a list of anything on the Classic Authn, Factors or Sessions APIs, and test each one in Preview
# 4. Check the Desktop SSO service account has an SPN for your Okta org (run on a domain-joined machine)
$ setspn -L okta-dsso-svc

You're touching desktop sign-in and device checks anyway, so it's a cheap moment to make them stronger. These steps follow directly from the replacements Okta points to.

These are illustrations of common setups, not Cohash client stories. Your own org will likely mix a few of them.

We work through the Upgrade Hub list with your admins, set up agentless Desktop SSO and the Okta Verify certificate rollout, rebuild sign-up forms and test custom integrations in Preview before production moves. See our Okta practice, hire Okta engineers, or start with a readiness assessment.