To understand the difference, start with the reason the second engine was built at all.

When Okta first grew popular, signing in was a fairly simple affair. A person typed a username and a password. Maybe they approved a second step, such as a code on their phone. The platform handled this with a fixed series of checks, arranged much like an assembly line. Every sign-in went down the same line, and the line was configured with a handful of rules.

Over time, the world got more complicated. People started using phones, laptops, tablets, and shared devices. Companies wanted to stop relying on passwords, which are easy to steal. Attackers got better at tricking people into approving fake prompts. Security teams wanted to say things like, “Allow this app only from a managed laptop, and only with a strong factor when the person is somewhere unusual.” The assembly line struggled to express such ideas cleanly.

The goal of the newer engine

The Identity Engine was designed around a different idea. Instead of a fixed line of steps, the engine looks at the situation at the moment of sign-in and works out what is needed. It asks, “Who is this? What are they trying to open? What device are they on? How risky does this look?” Then it builds the right path for that person at that moment. This approach is more flexible and makes room for newer techniques, such as passwordless sign-in and checks on the health of a device.

What stays the same

It is worth being clear about what the engines share. Both engines belong to the same Okta platform. Both store users and groups. Both connect to applications through standards like SAML and OpenID Connect. Both support single sign-on, which means signing in once and opening many apps. Both keep a System Log, a running diary of events. The difference lies mainly in how the sign-in journey is built, configured, and extended.

A small set of words appears again and again in this topic. Learn them once and the rest reads easily.

Authentication and authorization

Authentication means proving who you are. Authorization means deciding what you are allowed to do once you are known. A passport check is authentication. A ticket that says “Seat 14A” is authorization. Okta does both, and the engines mostly concern the first: how a person proves who they are.

Session

A session is the period during which Okta remembers that you already proved who you are. It is like a wristband at a festival. You show your ticket once at the gate, receive a wristband, and then walk freely between stages until the wristband expires or is cut off.

Factor and authenticator

A factor is something that helps prove identity, such as a password, a code sent by text message, or an approval on a phone. This is the older Classic word. The Identity Engine uses a newer word, authenticator, which means a method a person uses to prove who they are. The ideas overlap, but the newer word comes with a more organized way of thinking, which we will explore in a later chapter.

Policy and rule

A policy is a set of instructions that decides what happens in a given situation. A rule is one line within a policy, such as “If the person is on the office network, skip the extra step.” Policies are the dials and switches of Okta. How policies are organized is one of the biggest differences between the engines.

Multi-factor authentication

Multi-factor authentication, shortened to MFA, means proving who you are with more than one kind of evidence. For example, something you know, such as a password, and something you have, such as a phone. Using two kinds together makes it much harder for an attacker.

Sign-In Widget

The Sign-In Widget is the ready-made piece of screen that draws the login boxes and prompts in the browser. Both engines use a version of it, but the newer engine uses a newer generation of the widget.

OAuth 2.0 and OpenID Connect

OAuth 2.0 is a widely used standard for letting one system act on behalf of a person with limited permission. OpenID Connect, shortened to OIDC, is built on top of OAuth and adds a standard way to say who the person is. Many modern apps use OIDC to sign people in through Okta.

Knowing the story makes the differences feel logical instead of random.

Okta began as a cloud service that helped companies manage who could use which web applications. In the early years, its sign-in process was built around a classic pattern: a username, a password, and optionally another proof. Policies were arranged in a small number of buckets, and the screens were driven by a straightforward sequence.

As customers grew and security expectations rose, the limits showed. Companies wanted passwordless sign-in. They wanted rules that depended on the device. They wanted self-service sign-up that could ask for extra information step by step. They wanted developers to build custom sign-in experiences without wrestling with a limited interface. Adding all of this on top of the original design became difficult.

So Okta built a new core. The Identity Engine was introduced as a re-thought sign-in brain, and over time Okta added features that only run on it. New Okta organizations are created on the Identity Engine, and Okta has been guiding existing Classic customers toward upgrading. The exact schedule and details of that guidance can change, so always check current Okta announcements for your organization.

Before diving into details, here is one table that holds the whole story in view.

This comparison is a summary of general differences. Specific features and their availability vary, so use it as a guide for what to investigate rather than as a final answer.

How to read the table

The first thing to notice is a theme. Classic is built around fixed steps and the word factor. The Identity Engine is built around situation-aware journeys and the word authenticator. Almost every other row grows out of that single difference. Passwordless fits easily into a flexible journey. Device checks fit easily into a policy that looks at the situation. Step-by-step sign-up fits easily into an engine that builds the next screen as it goes.

flowchart LR
    subgraph C["Classic Engine"]
        C1["Username and password"] --> C2["Fixed policy check"]
        C2 --> C3["Optional second factor"]
        C3 --> C4["Session created"]
    end
    subgraph O["Identity Engine"]
        O1["Start sign-in"] --> O2["Read the situation
user, app, device, risk"]
        O2 --> O3["Build the path
from policies"]
        O3 --> O4["Ask only what is needed"]
        O4 --> O5["Session created"]
    end
    

The diagram shows two shapes. On the left, Classic travels in a straight line of set steps. On the right, the Identity Engine pauses to read the situation, builds a path from the policies, and then asks only for what that path needs. Both end with a session, but the second one gets there by a smarter route.

Let us open the hood of the older engine and see how its parts fit together.

The Classic Engine is organized around a small set of building blocks that work in a fairly direct order. When a person tries to sign in, the platform checks a few policy areas and then decides whether to ask for more proof. The parts are easy to name and easy to picture.

The main parts

The first part is the user store, where users, their profiles, and their group memberships live. The second is the set of sign-on policies. Classic has policies that govern the Okta session itself and policies that govern each application. The third is the set of factor settings, which decide which methods of proof, such as Okta Verify or SMS codes, are available and when people must enroll in them. The fourth is the authentication interface that the Sign-In Widget and custom applications talk to. The fifth is the session service, which creates and tracks the session after success.

flowchart TB
    U["Person at browser"] --> W["Sign-In Widget
older generation"]
    W --> API["Authentication interface
step by step"]
    API --> POL["Sign-on policies
org level and app level"]
    API --> FAC["Factor settings
enrollment and use"]
    POL --> SESS["Session service"]
    FAC --> SESS
    API --> STORE["User store
profiles and groups"]
    SESS --> APPS["Applications"]
    

How decisions are made

In Classic, the widget talks to the authentication interface one step at a time. First it sends the username and password. If the policy says another proof is needed, the interface answers with a message asking for it, and the widget draws a screen for it. The widget therefore contains a lot of knowledge about which screen follows which answer. That design is simple to understand, but it ties the screens closely to the engine’s fixed steps.

Strengths of the Classic design

Classic has real strengths. It is mature and well understood. Many companies have years of experience, documentation, and custom tools built around it. Its fixed steps are predictable, which makes certain troubleshooting easy. For organizations with stable, simple needs, Classic often just works.

Where it shows its age

The same fixed design makes some modern needs awkward. Passwordless sign-in does not fit cleanly into a flow that begins with a password. Rules that depend on rich device information are limited. Because the widget holds so much of the step logic, building a fully custom sign-in experience is harder than it should be. And because Okta now builds new features on the newer engine, Classic customers do not see the same pace of improvement.

The newer engine rearranges the same job into parts that are more modular and more policy-driven.

The big shift in the Identity Engine is where the knowledge lives. In Classic, the widget knows a lot about the order of steps. In the Identity Engine, the engine itself decides what comes next and tells the client what to show. The client, whether it is the Okta-hosted widget or an application you build, becomes a flexible display that follows the engine’s guidance.

The main parts

The first part is again the user store. The second is the policy layer, which is organized into more specialized policy types: one for the Okta session, one for each application’s sign-in requirements, one for enrolling in authenticators, one for password rules, and one for profile enrollment, which governs sign-up. The third is the authenticator catalog, a clear list of the methods available and how each may be used. The fourth is the interaction engine, which reads the situation, evaluates policies, and works out the next step. The fifth is the session service. The sixth is a set of context signals, such as device, network, and risk information, that policies can use.

flowchart TB
    U["Person at browser or app"] --> CL["Client
Sign-In Widget or custom app"]
    CL  IE["Interaction engine
decides the next step"]
    IE --> POL["Policy layer
session, authentication,
enrollment, password, profile"]
    IE --> AUTH["Authenticator catalog
methods and uses"]
    IE --> CTX["Context signals
device, network, risk"]
    IE --> STORE["User store
profiles and groups"]
    IE --> SESS["Session service"]
    SESS --> APPS["Applications"]
    

The client follows the engine

In the diagram, the arrow between the client and the interaction engine goes both ways. The client tells the engine what the person did, such as entering a username. The engine replies with the state of the journey and what is possible next, such as “ask for a password or offer a phone approval.” The client draws that. This simple change lets the same engine power the hosted widget, mobile apps, and fully custom screens in the same way.

Policies become the control center

Because the engine builds the path from policies at the moment of sign-in, policies carry far more weight. Rather than a few fixed buckets, administrators work with several focused policy types and can write rules that combine who the person is, which app they want, and what the context looks like. This gives much finer control, but it also asks administrators to think more carefully about the design.

Why this is more extensible

Because the engine, not the screen, owns the logic, adding a new authenticator or a new kind of check does not require rewriting every client. The new option simply appears in the engine’s guidance, and clients that follow the guidance can show it. This is the main reason Okta builds new features here.

Follow one person through the older engine from the first click to the finished session.

Suppose a person named Asha wants to open a company app. She clicks a bookmark. The app sees that she is not signed in and sends her to Okta. What happens next shows the Classic design clearly.

sequenceDiagram
    participant A as Asha Browser
    participant W as Sign-In Widget
    participant S as Classic Engine
    participant P as Sign-On Policies
    participant X as Application
    A->>X: Open the app
    X-->>A: Redirect to Okta
    A->>W: Load sign-in page
    W->>S: Send username and password
    S->>P: Check sign-on rules
    P-->>S: Second proof required
    S-->>W: Ask for a factor
    W->>S: Send factor response
    S-->>A: Create session
    A->>X: Return with proof of sign-in
    

Step 1: The redirect

The app does not check passwords itself. It sends Asha to Okta with a small note saying who is asking and where to send her back. This part is the same in both engines because it uses shared standards.

Step 2: The page loads

Okta shows the Sign-In Widget. In Classic, the widget is a fairly smart piece of software that knows the usual order of screens: username and password first, then a factor if needed.

Step 3: Primary proof

Asha types her username and password. The widget sends them to the engine through the authentication interface. The engine checks them against the user store. If the password is wrong, the engine returns an error and the widget shows a message.

Step 4: Policy check

Now the engine looks at the sign-on policies. Is a second proof required for Asha? That depends on rules such as her group, the app she wants, and her network. If the answer is yes, the engine replies “a factor is required,” and tells the widget which factors she has enrolled.

Step 5: Second proof

The widget draws the screen for that factor, for example a prompt to approve on her phone. Asha approves. The widget sends the result back, and the engine verifies it.

Step 6: Session and return

When all required proofs succeed, the engine creates a session and the browser receives a note it can carry back to the app. The app trusts the note, and Asha is in.

What this reveals

The widget plays a large role in Classic. It decides the order of screens and handles many special cases. That is why heavy customization of Classic sign-in often involves editing the widget’s code. It also means the policies mostly answer one question, “Is another proof required?” and have less room for subtle conditions.

Now follow the same person through the newer engine and notice what changes.

Asha again opens the same company app. The first move is the same: the app redirects her to Okta. But the conversation that follows is different.

sequenceDiagram
    participant A as Asha Browser
    participant W as Sign-In Widget
    participant E as Identity Engine
    participant P as Policies
    participant C as Context Signals
    participant X as Application
    A->>X: Open the app
    X-->>A: Redirect to Okta with a request
    A->>W: Load sign-in page
    W->>E: Start an interaction
    E->>C: Read device and network
    E->>P: Evaluate session and app policies
    P-->>E: Needed proof and allowed methods
    E-->>W: Next step options
    W->>E: Asha chooses a method and responds
    E-->>W: Interaction complete
    W->>E: Exchange for tokens
    E-->>A: Session and tokens
    A->>X: Return with tokens
    

Step 1: Start an interaction

The widget does not begin by sending a password. It begins by asking the engine to start an interaction. An interaction is a conversation in which the engine keeps track of where the person is and what is allowed next. In standards language, the newer flow builds on OAuth and OpenID Connect and uses an interaction code to tie the conversation to the final tokens.

Step 2: Read the situation

The engine looks at context. What device is this? Is it known? What network is it on? Which app is being requested? These signals feed into the policies.

Step 3: Evaluate policies

The engine checks the policy for the Okta session and the policy for the specific app. The result is not just “second proof, yes or no.” It is a description of what kinds of proof are acceptable, such as “a possession proof and a user verification proof,” and which authenticators the person has available.

Step 4: Offer the options

The engine sends the next step to the widget, including choices. For Asha, that might be “approve with Okta Verify using fingerprint” or “use a security key.” She picks one. If she has a device-bound option such as Okta FastPass, the engine may be able to complete the sign-in with little or no typing.

Step 5: Finish and exchange

When the policy is satisfied, the interaction completes. The client exchanges the interaction code for tokens, which are signed proofs the app can trust. A session is established, and Asha returns to the app.

What this reveals

In the Identity Engine, the engine owns the journey, and the widget follows it. This is why the same engine can power hosted pages, mobile apps, and custom experiences. It is also why policy design is so important: policies directly shape the path each person sees.

Policies are the steering wheel of Okta. The two engines organize them very differently.

How Classic organizes policies

In Classic, the main sign-in rules live in sign-on policies. There is a policy that governs the Okta session, with rules that say things like “require a second proof from outside the office network” or “sessions end after a set time.” There are also per-application sign-on rules that can add requirements for particular apps. Separate settings control which factors are enabled and who must enroll in them. The pieces work, but sign-in rules, factor choices, and session behavior are spread across several places, and they sometimes overlap in ways that surprise administrators.

How the Identity Engine organizes policies

The Identity Engine splits the job into clearer pieces. A global session policy governs how a person signs in to Okta itself and how long the session lasts. Authentication policies, sometimes called app sign-in policies, govern what each application requires. Authenticator enrollment policies decide who must or may set up which authenticators. Password policies handle password rules. Profile enrollment policies handle sign-up. Each has its own rules, and each answers a specific question.

flowchart TD
    Q["Person tries an app"] --> G["Global session policy
How do they get into Okta"]
    G --> A["Authentication policy for the app
What proof does this app need"]
    A --> E["Authenticator enrollment policy
Which methods can they set up"]
    A --> PW["Password policy
Rules for passwords"]
    E --> R["Outcome
allow, step up, or deny"]
    PW --> R
    

Why the split helps

Separating the questions makes each policy easier to reason about. You can say, “For payroll, require a strong proof tied to a managed device,” in the authentication policy for the payroll app, without touching how people sign in to Okta in general. You can change enrollment rules without rewriting app rules. The result is more precise control with less accidental overlap.

What the extra precision costs

More policy types mean more to learn and more to design. An administrator who knows Classic well may feel lost at first. Teams that move to the Identity Engine often spend time redesigning policies rather than copying them one for one, because a direct copy would miss the new possibilities.

The word change from factor to authenticator marks a deeper change in how proof is organized.

The Classic view: factors

In Classic, a factor is a method for proving identity, such as a password, an SMS code, a voice call, an Okta Verify push, or a security key. Factors are enabled and then chosen for enrollment. They are treated mostly as items on a list, and policies say whether a second one is required.

The Identity Engine view: authenticators

The Identity Engine treats methods as authenticators, each with properties. An authenticator might be a password, an Okta Verify app, a phone, an email, a security key, or a biometric-capable device. Each can be used in certain ways: to sign in, to recover an account, or to confirm a sensitive action. The engine knows what each authenticator can do and what kind of proof it gives.

The three kinds of evidence

A helpful way to think about proof is to group it. Knowledge is something you know, like a password. Possession is something you have, like a phone or a security key. Inherence is something you are, like a fingerprint or a face scan. Strong sign-in often combines at least two kinds. The Identity Engine lets policies speak in these terms. A rule can say “require a possession proof and a user verification proof” instead of naming one specific method.

Why the newer view helps

Because policies can describe the strength of proof instead of listing specific tools, they stay valid as methods change. If a stronger authenticator is added later, the same rule can accept it. It also makes it simpler to move away from weaker methods, such as text-message codes, by simply requiring stronger evidence types for sensitive apps.

A note on weaker methods

Some proofs are weaker than others. Codes sent by text message can be intercepted or redirected. Push approvals can be abused when attackers flood a person with requests, hoping they will tap yes by accident. Stronger options include prompts that make the person match a number on the screen, biometrics on a trusted device, and security keys that only work on the real site. A good design uses these stronger options for the most sensitive apps and tightens the rest over time.

One of the biggest reasons companies move is to reduce or remove passwords.

Passwords are the weakest link in most sign-in systems. People reuse them, forget them, and type them into fake websites. Passwordless sign-in means proving who you are without typing a shared secret, usually by using a device you own and a quick local check such as a fingerprint or face scan.

Why Classic struggles here

Classic was shaped around the idea that a password is the first step and other proofs are extra. A truly passwordless path does not fit neatly into that shape. Some partial approaches exist, but they were not the foundation of the design.

How the Identity Engine supports it

In the Identity Engine, a policy can say that a password is not required for a certain app, as long as the person provides acceptable stronger proofs. The engine can then offer paths that skip the password entirely. One such feature is Okta FastPass, a device-bound method that uses the Okta Verify app on a person’s device to prove both who they are and that they are on a trusted device, often with very little typing.

The idea behind device-bound proof

Device-bound means the proof is tied to a specific device through a secret that never leaves it. Even if an attacker builds a fake sign-in page, they cannot make the real device hand over the secret in a way that works on the fake site. This makes the method resistant to phishing, which is one of the most common attack types.

flowchart LR
    P["Person opens an app"] --> D["Device with Okta Verify"]
    D --> L["Local check
fingerprint, face, or PIN"]
    L --> S["Device signs a proof
secret stays on the device"]
    S --> E["Identity Engine verifies
user, device, and site"]
    E --> OK["Access granted
no password typed"]
    

The diagram shows a short chain. The person opens an app, the device performs a local check, the device signs a proof using a secret that never leaves it, and the engine verifies that the proof matches the user, the device, and the real site. Nothing is typed, and nothing reusable travels across the network.

Realistic expectations

Going passwordless is a journey, not a switch. Some apps and some people cannot use it at first. Devices must be enrolled, people must be trained, and fallback paths must exist for lost or broken devices. A good plan starts with willing groups, strong support, and clear recovery steps.

Modern security asks not only who is signing in, but also what they are signing in from.

A correct password from a clean, managed laptop is a very different situation from the same password on an unknown device with outdated software. Device context means using facts about the device in the sign-in decision.

What Classic can see

Classic can take into account basic context, such as the network zone a person is on, or whether the device is recognized from a previous sign-in. These signals are useful, but they are limited, and the rules around them are fairly coarse.

What the Identity Engine adds

The Identity Engine supports richer device-related checks. One example is device assurance, a policy concept in which an administrator describes the minimum health of a device for access: for example, the operating system must be at or above a certain version, a screen lock must be turned on, or disk encryption must be enabled. The authentication policy for an app can then require that the device meets a chosen assurance level. The exact checks available depend on the platform and on the Okta Verify app on the device, and they are updated over time.

Using assurance in practice

A typical design uses tiers. For everyday apps, any reasonable device may be fine. For apps with sensitive data, the policy requires a registered device that meets a stricter assurance level. For the most critical tools, the policy may require both a strong authenticator and a fully managed device. Because these requirements live in the authentication policy for each app, they can be tuned app by app.

flowchart TD
    A["Sign-in request"] --> B{"Is the device known?"}
    B -->|"No"| C["Offer limited access
or require stronger proof"]
    B -->|"Yes"| D{"Does it meet the
assurance level?"}
    D -->|"No"| E["Ask the person to fix it
update, lock, or encrypt"]
    D -->|"Yes"| F["Allow access
to the requested app"]
    

When customers or partners create their own accounts, the two engines handle sign-up in very different ways.

Self-service registration means letting people create their own account instead of waiting for an administrator. It is common for customer-facing apps and for partner portals. A good sign-up experience collects what you need without scaring people away.

The Classic approach

Classic offers a self-service registration feature that shows a form, creates the user, and can run extra steps through hooks, which are places where your own service can add logic. It works for straightforward cases, but the form is fairly fixed, and extending it for more complex needs often requires custom code and careful use of inline hooks.

The Identity Engine approach: profile enrollment

The Identity Engine introduces profile enrollment policies. These describe what information to collect at sign-up, which attributes are required, and how to handle approval or verification. Because the engine builds the journey, sign-up can be part of the same flow as sign-in, and it can adapt. For example, the engine can ask for an email first, verify it, then gather more details.

Progressive profiling

Progressive profiling means collecting information bit by bit over time, instead of demanding everything at once. A long form at the beginning makes many people leave. With progressive profiling, the first sign-up asks for the minimum, and later sign-ins can ask for a little more, such as a phone number, when it becomes useful. The Identity Engine is designed to support this style, which can improve both completion rates and data quality.

What to watch for

Self-service sign-up is a target for abuse, such as bots creating thousands of fake accounts. Policies should include email verification, and where appropriate other protections against automated sign-ups. Also, think about privacy. Collect only what you truly need, explain why, and respect local rules about personal data.

Recovery is the side door of identity. If it is weak, attackers will use it instead of the front door.

People forget passwords and lose phones. A recovery process lets them regain access. But recovery is also a favorite target for attackers, because if they can trick the recovery process, they can skip the strong sign-in entirely.

Recovery in Classic

In Classic, recovery is configured through password policy settings and recovery options, such as email links or answers to security questions. These work, but they are configured in somewhat separate places, and some older options, such as security questions, are widely considered weak because answers can be guessed or found online.

Recovery in the Identity Engine

In the Identity Engine, recovery ties more closely to authenticators and policies. Each authenticator can be marked as usable for sign-in, for recovery, or for both. Policies can require that a person proves themselves with a suitably strong authenticator before they can reset a password. This makes it easier to align recovery strength with the sensitivity of the account.

sequenceDiagram
    participant U as Person
    participant W as Sign-In Widget
    participant E as Identity Engine
    participant A as Recovery Authenticator
    U->>W: I forgot my password
    W->>E: Start recovery
    E-->>W: Offer allowed recovery methods
    W->>A: Prove identity with a chosen method
    A-->>E: Proof verified
    E-->>W: Allow a new password
    W->>E: Set the new password
    E-->>U: Signed in or asked to sign in again
    

Designing safe recovery

Good recovery follows a few rules. Use strong methods, not guessable questions. Make high-risk accounts, such as administrators, use stronger recovery than ordinary users. Notify the person by a trusted channel whenever recovery happens, so an attacker cannot act silently. And think about the helpdesk: a support agent who can reset anything for anyone who sounds convincing is a weak point. Give the helpdesk a clear identity check procedure.

What people see is shaped by the widget, and the two engines use different generations of it.

The Sign-In Widget is the face of Okta for most users. Its look, wording, and behavior affect trust and ease of use. Both engines let you brand the page with your logo and colors, and both allow deeper customization through code, but the details differ.

Basic branding works in both

Logo, colors, background image, and help links can be set in both engines using the brand and theme settings. If your goal is simply to make the page look like your company, you can do that on either engine. For more on this, see our guide on custom branding for the login page.

Deeper customization differs

Classic pages that were customized with code use the older widget’s structure. When the engine changes, the page structure changes too. Code written for the older widget generally cannot be pasted into the newer one. This catches many teams by surprise during an upgrade. The newer widget exposes different customization points, and pages must be reviewed and often rebuilt.

The widget follows the engine

Because the Identity Engine tells the widget what to show, the newer widget is more of a display layer. It can show new kinds of steps, such as authenticator choice screens, without being rewritten. For administrators, this means new features often appear without any page changes, as long as the page uses the standard widget behavior.

Teams that build their own applications will notice the engine difference most strongly in the interfaces they use.

Applications can use Okta in two main styles. In the redirect style, the app sends people to Okta’s hosted page and receives them back after sign-in. In the embedded style, the app shows its own sign-in screens and talks to Okta behind them, so people never leave the app. Both engines support the redirect style, but the embedded style differs sharply.

Classic embedded sign-in

In Classic, embedded sign-in typically uses the older authentication interface, which exposes the fixed steps directly. An app calls it with a username and password, receives instructions for what to do next, and walks through them. It is simple but tied to Classic’s fixed shape.

Identity Engine embedded sign-in

In the Identity Engine, embedded sign-in builds on the OpenID Connect standard and an interaction-based flow. The app asks to start an interaction, and the engine returns the available next steps. Okta provides software development kits, called SDKs, for several languages and platforms, which wrap this conversation in friendlier building blocks. The app draws its own screens based on the engine’s guidance. Because the engine owns the logic, new authenticators and policies can take effect without the app being rewritten, as long as the app handles the general steps.

What breaks during an upgrade

Apps that use the older step-by-step interface directly may not work the same way on the Identity Engine, because the logic they depend on has moved. Apps that use the redirect style and standard OIDC typically need little or no change. This is why developers should check, early in a project, which apps use which style.

flowchart TD
    A["Application"] --> B{"How does it sign people in?"}
    B -->|"Redirect to Okta page"| C["Usually works as is
test to confirm"]
    B -->|"Embedded, older interface"| D["Needs redesign
move to newer SDK or redirect"]
    B -->|"Uses custom page code"| E["Review the page
against the newer widget"]
    

Okta lets you plug your own logic into the platform. Here is how that extensibility fares across the engines.

Event hooks

An event hook is a way for Okta to tell another service that something happened, like a user being created or a group changing. It is a one-way notification. Event hooks work on both engines, and they are usually the least troublesome part of an upgrade.

Inline hooks

An inline hook is different. It pauses Okta’s process and asks your service for an answer before continuing. For example, a registration inline hook can approve or deny a new sign-up. Because inline hooks sit inside the sign-in or sign-up journey, they are tied to how that journey works. When the journey changes, the hooks must be reviewed to confirm they still fit. Some behaviors map across directly, while others change in format or timing.

Okta Workflows

Okta Workflows, the low-code automation product, works with Okta objects such as users and groups, and is largely independent of which engine runs sign-in. Flows that create groups, assign apps, or send notices generally continue to work. Still, any flow that depends on specific events or fields tied to the sign-in journey should be tested.

Directory and legacy integrations

Many companies connect Okta to directories like Active Directory or LDAP, to older network gear through RADIUS, or to Windows desktop sign-in tools. Each of these integrations relies on specific agents and behaviors, and support can differ between engines or between versions. Check every one of these in advance, with Okta’s current compatibility notes.

Many teams are surprised to find they are not sure. Here are the usual ways to check.

The simplest way to find out is to look at the Admin Console. Okta shows a version label in the console, commonly in the footer area, and the label typically ends with a letter that indicates the engine. A label ending in E usually indicates the Identity Engine, and one ending in C usually indicates Classic. Menu names are another clue. If you see sections for authenticators, authentication policies, and device assurance, you are likely on the Identity Engine. If you see factors and sign-on policies, you are likely on Classic.

Other clues

Organizations created recently are generally on the Identity Engine from the start. Organizations that are several years old may still be on Classic unless they have been upgraded. The sign-in page itself can also hint at the engine, since the two widget generations look and behave a little differently. If you are still unsure, Okta support or your account team can confirm.

Why it matters before anything else

Everything in this guide depends on knowing where you start. Documentation, scripts, and training that match one engine can mislead on the other. Write the answer down, and share it with anyone who administers Okta.

Security is the main reason most companies consider moving. Here is how the engines compare in the areas that matter most.

Phishing resistance

Phishing is when an attacker builds a fake site that looks real and tricks people into entering their credentials. The best defense is a method that cannot be fooled by a fake site, such as a device-bound proof or a security key. The Identity Engine makes these methods first-class and lets policies require them. Classic can support some strong methods, but expressing “require a phishing-resistant method for this app” is harder.

Fatigue attacks on push approvals

Push fatigue is an attack in which someone who already knows a password sends the person many approval prompts in a row, hoping they will eventually tap yes just to make them stop. Defenses include requiring the person to match a number shown on the screen, requiring a fingerprint or face check on the device, and limiting repeated attempts. The Identity Engine offers stronger policy controls for these, but it is worth confirming exactly which options are available in your organization.

Context-aware access

Allowing or blocking sign-ins based on the situation is more powerful when more signals are available. The Identity Engine can combine user, app, device, network, and risk information in a single policy decision. This lets you require extra proof only when the situation looks unusual, which improves both security and convenience.

Least privilege and step-up

Least privilege means giving people only the access they need. Step-up means asking for stronger proof before a more sensitive action, even if the person is already signed in. The Identity Engine’s per-app authentication policies make it natural to give each app its own level of proof, and to ask for more when someone reaches for something sensitive.

Recovery and enrollment

Both the process of setting up authenticators and the process of recovering an account can be abused. The Identity Engine ties these processes to policies in a way that is easier to reason about, but they still need careful design. A strong main door does not help if enrollment or recovery is weak.

When something goes wrong at sign-in, the System Log is your first witness. The two engines tell their stories slightly differently.

The System Log records events in your Okta organization, such as sign-in attempts, policy decisions, and administrative changes. Both engines write to it, and both are searchable. But because the Identity Engine builds the journey step by step from policies, its events tend to describe more of the decisions that were made along the way.

Reading Classic events

In Classic, you often see events for the main stages: a sign-in succeeded or failed, a factor was verified, a policy required more proof. They tell you what happened but may give you less detail on why a particular path was chosen.

Reading Identity Engine events

In the Identity Engine, events can include more information about which policy and rule applied, which authenticator was used, and what the outcome was. This makes questions like “why was this person asked for a second proof?” easier to answer, because the evaluation of policies is more visible.

Common problems after a move

After an upgrade, a few kinds of problems are common. People are asked for different proofs than before. Some are locked out because they had only a method that is no longer allowed. A custom page does not display correctly. An app using an older interface stops signing people in. Each of these leaves traces in the System Log and the app’s own logs.

flowchart TD
    P["Problem reported"] --> L["Search System Log for the person and time"]
    L --> Q{"Which part failed?"}
    Q -->|"Policy asked for more"| A["Read the policy and rule that applied"]
    Q -->|"Authenticator failed"| B["Check enrollment and allowed uses"]
    Q -->|"Page or app error"| C["Check customization and app interface"]
    A --> F["Fix policy or guide the person"]
    B --> F
    C --> F
    

What to monitor on an ongoing basis

Track failed sign-ins and their reasons, the share of people using strong authenticators, the number of people with only weak methods, helpdesk tickets about sign-in, and any spikes after policy changes. During a migration, watch these numbers closely, daily at first.

Every engine choice buys something and costs something. Here are both sides, honestly.

Identity Engine

Classic Engine

The real trade-off

The choice is not between a good engine and a bad one. It is between the comfort of staying put and the benefits of moving. Staying costs nothing today but adds a growing gap between your setup and what the platform offers. Moving costs effort now but gives you better tools and a more supported path.

flowchart LR
    S["Stay on Classic"] --> S1["No project cost now"]
    S --> S2["Growing gap in features"]
    S --> S3["Rising risk over time"]
    M["Move to Identity Engine"] --> M1["Planning and testing effort"]
    M --> M2["Stronger and more flexible sign-in"]
    M --> M3["Aligned with platform direction"]
    

A simple set of questions helps you decide the right pace for your organization.

The question for most organizations is not whether to move, but when and how. Okta has been steering customers toward the Identity Engine, and new features arrive there. Even so, the best timing depends on your situation, and the best pace is one you can execute well.

Questions to ask

flowchart TD
    A["Start"] --> B{"Need passwordless,
device checks, or new sign-up?"}
    B -->|"Yes"| C["Plan the move now"]
    B -->|"No"| D{"Heavy custom code
or legacy gear?"}
    D -->|"Yes"| E["Start inventory and testing early"]
    D -->|"No"| F["Schedule a standard migration"]
    C --> G["Pilot, then roll out in waves"]
    E --> G
    F --> G
    

Notice that every path ends at the same place: a pilot followed by waves. The decision is about how early to begin and how much preparation to expect, not about whether the careful, staged approach is needed.

A good migration is quiet. The people who use Okta barely notice, because the team did the hard thinking in advance.

Okta provides upgrade guidance and, for many organizations, supporting tools, so start by reading the current official upgrade documentation for your situation. The steps below describe the common shape of a safe migration, not a replacement for that guidance.

The technical change is only half the work. The other half is making sure people are ready and the results are verified.

What to test

Build a test list from real life. Can a normal user sign in to each important app? Can a new person enroll in the required authenticators? Can someone recover a forgotten password safely? Does a person on a managed laptop get the easy path, while a person on an unknown device gets extra checks? Do administrators have the stronger proof you expect? Do embedded apps, hooks, and flows still work? Do the legacy gateways still accept sign-ins? Record the results so you can compare to the old behavior.

Who to test with

Use a pilot group of friendly volunteers from different teams, devices, and locations. Include some people with older phones, some who travel, and at least one team that uses the most unusual app. Their feedback shows problems the test list missed.

Telling people

Most upgrade pain comes from surprise. Tell people what will change, when, and what to do. Use short messages with screenshots of the new prompts. Give the helpdesk a script for common questions and a way to escalate. After the change, send a brief follow-up with where to get help.

Rolling out in waves

If your approach allows it, introduce new authenticators and stricter policies in waves rather than all at once. Start with a pilot group, then a larger group, then everyone. Watch the numbers between waves and pause if something looks wrong.

flowchart LR
    T["Test org rehearsal"] --> P["Pilot group"]
    P --> W1["Wave 1
friendly teams"]
    W1 --> W2["Wave 2
most teams"]
    W2 --> W3["Wave 3
sensitive teams"]
    W3 --> R["Review and tighten"]
    

Skills and team readiness

People are part of the migration too. Administrators who know Classic well will need time to learn the new policy types, the authenticator catalog, and the newer widget. Set aside training time, let the team practice in the test organization, and write short internal notes that explain the differences in your own company’s words. Helpdesk staff need to recognize the new prompts, understand the new recovery steps, and know how to verify identity safely. A confident team handles surprises calmly, and a nervous team creates tickets.

Keeping documentation alive

During the project, keep a living record of decisions: why each policy exists, which apps belong to which tier, and which exceptions were granted and by whom. After the move, this record becomes the guide for the next administrator and the evidence for your next audit. Review it whenever policies change, so it never drifts away from reality.

A pattern is a solution that keeps working. An anti-pattern is a tempting mistake that keeps hurting people.

Patterns worth copying

Anti-patterns to avoid

If you remember nothing else from this guide, remember the habits in this chapter.

Best practices

• Know your starting point. Confirm the engine of every Okta organization you run.
• Inventory before you plan. List apps, sign-in styles, custom pages, hooks, flows, agents, and policies.
• Read the official guidance. Use Okta’s current upgrade documentation and readiness checks.
• Design from intent. Start from what each app needs, not from what Classic happened to do.
• Use strength-based rules. Ask for kinds of proof, not just named tools, so policies age well.
• Protect recovery and enrollment. They are part of your sign-in security.
• Test with real people and devices. Include odd cases like older phones and travel.
• Communicate early and plainly. Short guides and a ready helpdesk prevent most pain.
• Improve after the move. Tighten policies and retire weak methods once things are stable.

Common mistakes

These short stories use made-up companies to show how the ideas appear in everyday work. They are teaching examples, not descriptions of any real organization.

What the scenarios share

In every story, the team started with a clear reason, did an inventory, rehearsed, moved in stages, and kept watching afterward. None needed clever tricks. They needed a plan and the patience to follow it.

When something looks wrong after a change, a calm and ordered approach finds the cause faster than guessing.

Most post-upgrade problems fall into a few families. People are asked for different proofs than they expected. Some cannot sign in at all. A custom page is broken. An app using an older interface fails. Or a legacy integration behaves differently. Begin with the simplest explanation and use the System Log to see which policy and rule applied.

Problem: people are asked for unexpected proof

Open the System Log for that person and find the policy and rule that applied. Often a new authentication policy is stricter than the old rule, or a rule ordering means a broad rule matches first. Adjust the rule, or help the person set up the right authenticator.

Problem: a person cannot sign in at all

Check which authenticators the person has enrolled, and compare them to what the policy allows. A common cause is that the person has only a method the new policy no longer accepts. Provide a safe way for them to enroll a stronger method, using an administrator-assisted process with identity checks.

Problem: the sign-in page looks wrong

Check whether the page uses custom code written for the older widget. Switch back to the standard page temporarily to confirm, then rebuild the customization against the newer widget.

Problem: an application stopped signing people in

Find out how the app signs people in. If it uses the older step-by-step interface directly, it needs to move to a redirect-based or newer SDK approach. If it uses standard OIDC and still fails, check the app’s configuration and the token settings.

Problem: legacy gear fails

Confirm that the agent or gateway version is supported on the engine, and that the policies applied to it do not require steps the device cannot perform, such as interactive prompts. Create a rule suited to the device’s abilities.

Short answers to the questions people ask most often.

Here is the whole story in a few lines you can carry with you.

Classic and Identity Engine are two ways Okta runs the sign-in journey. Classic follows fixed steps with factors and a handful of policy areas. The Identity Engine builds the journey from policies and context, speaks in authenticators, and supports passwordless sign-in, device-aware rules, and step-by-step sign-up. Moving between them touches policies, pages, apps, hooks, and legacy integrations, so it is a project, not a switch. The safest path is to know where you are, take an inventory, design from intent, rehearse, pilot, roll out in waves, and keep improving.