23% of Part II — the final and most policy-heavy use case.
5 tasks · this deck covers task 2 of 5
↑ Security Enforcement OverviewTask 1 turned an authenticator on. This task is about controlling who gets asked to enroll in it, when, and how much runway they get before enrollment becomes mandatory.
Authenticator enrollment policies manage "how and when your end users enroll authenticators." Each authenticator can be designated Required, Optional, or Disabled for enrollment.
These policies are rule-based — scoping enrollment by conditions like which app a user is accessing, or their geographic location.
Enrollment policies are separate from sign-on policies, but they interact: "Okta may prompt users to enroll more authenticators if the global session policy, app sign-in policy, or password policy require them."
In other words, a sign-on policy can demand a factor the user hasn't enrolled yet — and that's what triggers the enrollment prompt, even outside the enrollment policy's own rules.
Once either grace period expires, the option to proceed without enrolling disappears entirely.
Watch for these in your own sandbox run:
→ Confusing enrollment policy (who enrolls, when) with sign-on policy (what's required at login) — they're separate, interacting systems.
→ Not realizing skip-count grace periods are an Early Access feature, not available by default.
Sources: help.okta.com — about-mfa-enrollment-policies.htm
Next: Task 3 →