Security Policies
Domain 2: Security Policies
This domain tests Okta's policy engine: password, MFA enrollment, global session, authentication (app sign-on), profile enrollment, IdP routing, and authorization-server access policies. Questions often ask which policy fires, in what order, and which factor satisfies a requirement.
Core rules
- Policies are containers of rules. Rules have conditions (groups, network zones, device platform/trust, IP) and are evaluated in priority order; the first matching rule applies. Put specific exceptions above broad rules.
- Password policy governs length, complexity, history, lockout, and recovery. It does not decide which MFA factor is required.
- MFA enrollment policy decides which authenticators users must enroll; authentication policy decides when MFA is challenged for an app. A user can be enrolled but not challenged, or challenged for an unenrolled factor and fail.
- Global session policy controls Okta sign-in and session lifetime; app authentication policy controls app-level access and can set its own session duration.
- Phishing-resistant factors include FIDO2/WebAuthn, smart card, and Okta FastPass. SMS, voice, email, and Okta Verify push are weaker; do not treat push as phishing-resistant.
Worked example
Contractors must use Okta Verify and be blocked outside the corporate network zone. Create an authentication policy for the app with rule 1: group Contractors, condition network zone 'Outside', action Deny. Rule 2: group Contractors, action Allow with Okta Verify. Rule 3: Everyone, Allow with password. Because rules are first-match, the deny rule must be above the allow rule. If rule 3 were first, contractors would bypass MFA. Verify with policy simulation and the System Log event policy.evaluate_sign_on.
Traps
Do not put a broad Allow above a specific Deny. Do not confuse enrollment with challenge. Do not assume a global session policy enforces per-app MFA. Do not rely on SMS for high-assurance access.