The following reconfiguration has been identified as part of the preparation for the upgrade to Okta Identity Engine (OIE). Note that additional Okta features may require reconfiguration or be disabled to complete the upgrade. The warning is generated when a Multi-Factor Authentication (MFA) Enrollment Policy rule is configured with the User is accessing condition set to Okta only or A specific application.
Whether the warning indicates an actual change in end-user behavior depends on three things: the population the rule applies to (admins, employees, or customers/CIAM), the flow those users take when enrolling an authenticator (Service Provider initiated, Okta Dashboard initiated, self-service registration, or admin-created), and whether the rule is paired with a Network Zone condition. Most rules using this condition are paired with other guardrails and will see no functional change after the upgrade; review the Solution to confirm.
- Okta Identity Engine Upgrade
- Multi-Factor Authentication Enrollment Policies
- Service Provider (SP) initiated authenticator enrollment
- Validator Key: MFA_ENROLL_POLICY_APP_CONDITION
In Okta Classic, the User is accessing condition was applied permissively. A user who landed on an authenticator-enrollment prompt by way of a Service Provider (SP) initiated flow — that is, by going directly to an application — would match a rule scoped to Okta only or to A specific application even when the application they were actually accessing was different. In effect, the rule applied broadly during enrollment regardless of how the user arrived.
In Okta Identity Engine, the same condition is evaluated strictly. The rule fires only when the user is accessing the exact application(s) named in the rule. A user who triggers authenticator enrollment via an SP-initiated flow to any other application will not match the rule, and any allow/deny behavior the customer relied on in Classic will not be applied to that user in OIE.
Example of a Triggering Configuration:
Step 1: Locate the rules that triggered the warning
-
In the Admin Console, go to Security > Multifactor.
-
Select the Factor Enrollment tab.
-
For each policy, select the policy name to view its rules.
-
Identify each rule whose User is accessing condition is set to Okta only or A specific application. These are the rules raising the warning.
Step 2: Decide whether the rule needs to change
Before editing, consider who the rule applies to and how those users enroll. The right resolution depends on the answers.
- Who does the rule apply to? Administrators, employees, or external/CIAM users. Each population typically enrolls through different flows.
- How do those users enroll authenticators?
- SP-initiated (the user goes directly to an application and is prompted to enroll): this flow is affected by the strict OIE evaluation.
- Okta Dashboard initiated (the user signs in to Okta first and enrolls from the dashboard): the rule continues to apply as expected.
- Self-Service Registration (SSR): typically not impacted, because the SSR flow itself walks users through enrolling the authenticators it is configured to require. Verify that the SSR configuration actually enrolls every authenticator the user will later need to satisfy sign-on policies; any gap leaves the user dependent on an enrollment prompt at first sign-in.
- Admin-created or API-created: impact depends on what was enrolled at creation. If the admin or the API provisions the user with every required authenticator, there is no enrollment prompt to miss and no impact. If the user is created without the authenticators they will need, and their first encounter with Okta is an SP-initiated access to an application, the rule scoped to Okta only or to A specific application will not fire under OIE's strict evaluation. The user will not be guided through enrollment and may be blocked from completing sign-in.
- Is the rule paired with a Network Zone condition? Many "Okta only" or "A specific application" rules exist to enforce on-prem-only enrollment for admins or sensitive populations. When a Network Zone is also present, the zone control typically remains the binding restriction after upgrade.
Step 3: Apply the appropriate change
- If you want to preserve the Classic behavior of having the rule apply during SP-initiated enrollment as well as Dashboard logins: edit the rule and change User is accessing to Any application, then click Update Rule.
- If the rule was always intended for Dashboard-initiated enrollment only (for example, an admin-only rule paired with a Network Zone), no configuration change is required. The rule will continue to govern Dashboard enrollment exactly as it did in Classic. Be aware that users enrolling via SP-initiated flows will not match this rule and will fall through to the next rule in the policy.
- Repeat for every MFA Enrollment policy and every rule that uses this condition.
NOTE: The validator warning will persist as long as any rule is configured for Okta only or A specific application, even when the configuration is intentional and correct for OIE.
Example of a "non-impacted" Configuration:
