Factor Enrollment Policy Set to Do Not Enroll
Last Updated:
Overview
This article explains the impact of having a Factor Enrollment Policy rule set to Do Not Enroll when upgrading from Okta Classic to Okta Identity Engine (OIE).
In Classic, password was never treated as a factor — it was always implied and required. The Do Not Enroll setting only applied to non-password factors (such as Okta Verify, SMS, etc.).
In OIE, password is a full authenticator governed by the Factor Enrollment Policy. When the Classic policy translates to OIE, the Do Not Enroll rule now applies to all authenticators, including password. This can block:
- Account activation — Users created without a password cannot enroll one
- Password recovery — Users attempting to reset or recover their password may be blocked
Applies To
- FACTOR_ENROLLMENT_POLICY_DO_NOT_ENROLL
- Upgrade Eligibility: Customer Consent Required
- Factor Enrollment Policy with a rule set to Do Not Enroll
- Okta Identity Engine (OIE) Upgrade
IS Impacted
- Users created without a password who need to self-activate — the Do Not Enroll rule blocks password enrollment during the activation flow
- Users who need to recover or reset their Okta password — password recovery triggers re-enrollment, which is blocked by this rule
- Customer/consumer (CIAM) accounts created via API or third-party vendor without a password set — these users cannot self-enroll a password post-upgrade
- Any user population assigned to this policy that performs self-service password enrollment or recovery — the rule no longer exempts password in OIE
Is NOT Impacted
- Inbound federation users — no Okta password exists; federation serves as the knowledge factor by default
- Delegated authentication users (primary auth) — no Okta password is used for primary authentication
- Service accounts with admin-created passwords — admin-set passwords are not subject to the enrollment policy; only end-user self-enrollment is blocked
- Users who already have a password set and do not need to recover it — existing passwords continue to work; the policy only blocks new enrollment
- Passwords created by an administrator (via Admin Console or API) — admin-initiated password creation bypasses the enrollment policy entirely
Cause
Why This Happens
In Okta Classic:
- Password is always required and is not considered a "factor"
- The Factor Enrollment Policy's Do Not Enroll rule only governs non-password factors (Okta Verify, SMS, Security Question, etc.)
- Users could always enroll or reset their password regardless of this policy setting
In Okta Identity Engine (OIE):
- Password is treated as an authenticator — it is no longer implied
- Password can be optional, meaning there are no assumed required authenticators
- The Do Not Enroll rule translates to apply to all authenticators in the policy, including password
- Any user subject to this rule who needs to enroll or recover their password will be blocked
Where to Find This Setting
Select the policy name to expand its rules and locate the rule-level Do Not Enroll setting.
- In the Admin Console, go to Security > Multifactor > Factor Enrollment
- Locate the policy in question
- Expand the rules within that policy
- The Do Not Enroll setting is at the rule level (not the policy level)
NOTE: The policy level defines which authenticators are available. The rule level defines the enrollment action (Required, Optional, Do Not Enroll). It is the rule-level Do Not Enroll setting combined with password being included in the authenticator list that causes this issue in OIE.
Solution
Impact Assessment — Am I Actually Affected?
Not every org with this validator will experience user impact. Complete the following steps to determine whether the configuration will cause issues post-upgrade.
Step 1: Identify the Target Population
Who does this policy and rule apply to? Check the group assignment on the policy and any conditions on the rule (such as network zones).
| Population Type | Likely Impact | Why |
|---|---|---|
| Service accounts | No impact | Admins create passwords for these accounts — they do not self-enroll |
| Inbound federation users | No impact | No Okta password exists; federation is the knowledge factor |
| Delegated auth users | Low impact | No Okta password for primary auth, but password recovery flow may be affected |
| Employees (with existing passwords) | Low-Medium impact | Existing passwords still work, but password recovery/reset may be blocked |
| New users (created without password) | High impact | These users cannot activate — they are blocked from setting their initial password |
| Customer/consumer accounts (CIAM) | Evaluate carefully | Depends on onboarding flow and whether users self-enroll passwords |
Step 2: Check for Network Zone Conditions
If the Do Not Enroll rule has a network zone condition (e.g., "Outside corporate network"), evaluate:
- Do users in the target population ever need to activate their account or recover their password while outside the defined zone?
- If the rule only applies off-network, and users only perform activation/recovery on-network (via a different rule), there may be no impact.
Step 3: Check for Redundant Configuration
A common Classic configuration is:
- All non-password authenticators are set to Disabled at the policy level
- The rule is also set to Do Not Enroll (belt-and-suspenders approach)
If this describes the configuration, the Do Not Enroll at the rule level is redundant for non-password factors. However, in OIE it will still block password enrollment. This configuration still requires remediation.
Decision Summary
| Situation | Action Required |
|---|---|
| Policy applies only to service accounts with admin-set passwords | No action needed — safe to proceed |
| Policy applies only to inbound federation users | No action needed — safe to proceed |
| Policy applies to users who will never need to enroll or recover a password in Okta | No action needed — acknowledge and proceed |
| Policy applies to any population that may need to activate, set, or recover a password | Remediation required before upgrade |
| Unsure which users are affected or whether they need password enrollment | Remediation recommended — safer to change the policy than risk blocking users |
Recommended Remediation (Pre-Upgrade)
Perform one of the following options before upgrading:
Option 1: Change the Rule to Allow Enrollment When Required (Recommended)
Change the Do Not Enroll rule so that Factor Enrollment is set to Allowed if required authenticators are missing.
This preserves the intent of limiting unnecessary enrollment while still allowing password enrollment when it is the only way for a user to activate or recover their account.
Edit the enrollment rule and change the action from Do Not Enroll to Allowed if required authenticators are missing to allow password enrollment when it is required.
- Go to Security > Multifactor > Factor Enrollment
- Select the policy containing the Do Not Enroll rule
- Edit the rule
- Change the enrollment action from Do Not Enroll to Allowed if required authenticators are missing
- Save the rule
Option 2: Change to Any Setting Other Than Do Not Enroll
If Option 1 does not align with the configuration requirements, change the rule to either:
- Optional — users may enroll but are not required to
- Required — users must enroll
Option 3: Ensure All Users Have Passwords Before Upgrade
If the policy cannot be changed, ensure every user subject to the policy already has a password set before upgrading:
- Use the Admin Console or API to verify all users in the affected group have a password set
- For any user missing a password, have an admin set one, or move the user to a different policy for activation
Option 4: No Action Required (Federation/Delegated Auth Only)
If all users subject to this policy authenticate exclusively via inbound federation or delegated authentication, no action is required. Federation serves as the knowledge factor, and these users do not have or need an Okta password.
Post-Upgrade Verification
After upgrading to OIE, complete the following verification steps to confirm that account activation, password recovery, and enrollment policies are functioning correctly.
- Test account activation — Create a test user without a password in the affected group and confirm they can successfully activate
- Test password recovery — Trigger a password reset for a test user in the affected group and confirm the recovery flow completes
- Monitor System Log — Watch for
user.account.lockorpolicy.evaluate_sign_onfailures that indicate enrollment blocking
