Set up Authentication Policies (Okta)

Study Notes: Set Up Authentication Policies (Okta)

Authentication Policies control how users authenticate into applications, including which factors are required, what assurance level is needed, whether device posture matters, and when step-up authentication is required. This is one of the most important components in Okta’s Zero Trust framework.


🔐 1. What Are Authentication Policies?

Authentication Policies determine who can access an application and what authentication requirements must be met before access is granted.

Policies can enforce:

  • MFA requirements

  • Minimum assurance levels

  • Device compliance conditions

  • Context and risk rules

  • Step-up authentication

Authentication Policies attach to individual applications or app groups, making them extremely granular.


🧱 2. Structure of an Authentication Policy

Each policy contains rules, and each rule contains:

Conditions

Define which requests the rule applies to:

  • User or group

  • Device posture (managed/unmanaged)

  • Platform (Windows, macOS, iOS, Android)

  • Network zones (trusted, untrusted)

  • Risk levels

  • Known or unknown device

Access Requirements

Define what authentication must occur:

  • Allowed authentication methods

  • Required factor or factor types

  • Minimum assurance level

  • Whether step-up authentication is required

Outcomes

  • Allow access

  • Deny access

  • Require stronger factor (step-up)


🔄 3. How Authentication Policies Work

Authentication Policies are evaluated each time a user attempts to access an app.

Evaluation steps include:

  1. Identify which authentication policy the application is using

  2. Check the ordered list of rules

  3. Apply the first rule whose conditions match

  4. Enforce that rule’s authentication requirements

Rule order matters — Okta applies the first match.


🔐 4. Assurance Levels in Authentication Policies

Authentication strength can be enforced using:

Low Assurance

  • Password only

  • Weak MFA factors

Medium Assurance

  • Requires MFA (e.g., Okta Verify Push, TOTP)

High Assurance

  • Requires phishing-resistant factors like:

    • WebAuthn

    • FIDO2 keys

    • Okta FastPass

    • Smart Cards

High-value apps (HR, Finance, Admin Console) typically require high assurance.


💻 5. Device Conditions

Authentication Policies can evaluate:

  • Whether device is managed

  • Whether Okta Verify is registered

  • Whether device meets compliance posture

  • Operating system

  • Browser

Managed or compliant devices can be required for access.

Unmanaged devices may:

  • Trigger step-up

  • Reduce access scopes

  • Be blocked entirely


🌐 6. Network & Location Conditions

Policies can restrict or allow access based on:

  • IP zones

  • Known networks

  • Corporate locations

  • Geolocation

Example:

  • Allow password-only on corporate network

  • Require MFA or WebAuthn off-network


7. Risk & Behavioral Conditions (Adaptive MFA)

Policies can check:

  • Suspicious IPs

  • Impossible travel

  • Bot-like behavior

  • ThreatInsight signals

  • Partner risk scores (CrowdStrike, Zscaler, etc.)

Risk can be used to:

  • Deny access

  • Trigger additional MFA

  • Increase required assurance level


🔐 8. Step-Up Authentication

Step-up occurs when:

  • A user authenticated at a lower assurance level

  • But the app requires a higher one

Example:

  • User logs in with password + Okta Verify (Medium assurance)

  • App requires WebAuthn (High assurance)
    Okta prompts the user to provide the stronger factor before granting access.


🔧 9. Common Authentication Policy Use Cases

A. Sensitive Applications

Example: Admin Console, Finance, Payroll

  • Require high assurance (WebAuthn / FastPass)

  • Require managed devices

  • Block unknown devices

B. Workforce Apps

Example: Office apps, HR portals

  • Require MFA

  • Allow optional device conditions

C. Contractor Access

  • Require MFA

  • Block high assurance factors like FastPass if not available

  • Restrict by location

D. Zero Trust Access

  • Require strong auth from unmanaged devices

  • Require high assurance when outside trusted networks


🧩 10. Best Practices

  • Always use strong factors for admins (WebAuthn/FIDO2/FastPass)

  • Order rules correctly — first match wins

  • Avoid allowing password-only anywhere except controlled zones

  • Enforce stronger factors for sensitive or high-risk applications

  • Consider creating separate authentication policies for different app categories


11. Key Takeaways

  • Authentication Policies protect applications by enforcing identity verification and device checks.

  • Policies contain ordered rules with conditions and required auth methods.

  • Assurance levels define authentication strength.

  • Device posture and risk signals play a major role in Zero Trust.

  • Step-up authentication ensures users meet required security levels.

  • Policies apply per app or app groups, giving granular control.

Wrap Up

To recap, here are the key takeaways:

  • Authentication policies in Okta, along with Global Session policies, control user access to applications based on assurance levels.

  • These policies ensure specific requirements are satisfied before granting access.

  • Organizations have the flexibility to create per-app policies or share them across multiple apps if the requirements are similar.