Changes to policies in Okta Identity Engine

Changes to policies in Okta Identity Engine

One of the biggest differences administrators will notice when moving from Classic to Identity Engine is the different terminology as well as slightly different behavior of the main policies. When being migrated by Okta the policies will be converted, but it makes sense to have a proper look at them and make some adjustments to achieve the best results both for users and security.

Terminology and administration

Even though they are a bit different in their capabilities and functionality, the main policies are still in Okta Identity Engine, although with new names.

Terminology and administrationTerminology and administration

“(Multi-)Factors” are now “Authenticators” in Okta Identity Engine. Okta has adjusted the terminology slightly, to align better with industry standards. A “factor” now describes a type of authenticator. For example, the authenticator “Password” is of the factor type “Knowledge”, while the authenticator “Okta Verify” is of the factor type “Possession” (+ Knowledge or Biometric, depending on the setup).

If you are using Factor Sequencing in your Classic Engine, as of now you will not be migrated to Identity Engine. Factor Sequencing for Identity Engine is still in development and will come later this year.   

Authentication process

While other changes are mostly just renamed or moved, the biggest differences between Classic and Identity Engine are in the Authentication Policies. Previously they were called “App Sign On Policies” and configurable for every application.

Now they got a more prominent spot in the Admin Console as well as in the authentication structure. While they previously could almost be ignored if no changes had been made although they were always applied, they are now an integral part of the authentication design.

The “Global Session Policy” sets the context of the login attempt and defines a basic rule set for the session that is initiated.

Global Session Policy exampleGlobal Session Policy example

After the "Global Session Policy", before the user gets allowed access, the “Authentication Policy” and their rules define the conditions and factors which are required for allowing the user to pass to each application. *

Typical authentication policyTypical Authentication Policy example

In this example, members of the group "Contractors" are allowed to pass to these applications with a password and one additional factor (Okta Verify or phone). Other users are using the “Catch-all rule.”

*It is good to think of both the “Okta Dashboard” and “Okta Admin Console” each as an application in this context. They too have “app-level” policies, which apply to them.

Application policy rules in detail

Authentication polices allow a complex ruleset to adjust the authentication experience for the users. Each policy allows multiple rules, which are ordered by priority (first hit applies).

The rule can contain the following:

1. IF

This section defines WHEN a rule is applied. 

Section when a rule is applied


This section defines what the rule enforces.

Section what the rule enforces

3. Re-authentication frequency

In the last section of the rule, you can define how often users need to reenter their password or re-authenticate with all factors.

Example Re-Authentication FrequencyExample of re-authentication frequency

Apply authentication policies to apps

Authentication policies can be assigned to multiple applications, making it easier for administrator to separate different security requirements to different applications. Note that some apps require separate policies, like Okta Admin Console or Office 365.

Authentication policies applied to multiple applicationsAuthentication policies applied to multiple applications


Application policies allow Okta administrators to more fine grain their authentication and security policies that what was previously possible with Classic Engine. App-level policies also allow to make use of further enhancements in Identity Engine, like Okta FastPass.