🔐 Authentication Policies in Okta
📘 Internal Resources
Introduction: The 3 AM Security Wake‑up Call
Picture this: it's 3 AM. Someone just successfully logged in to your hospital's EHR system using stolen credentials they bought on the dark web. They're in a different country. They have access to 50,000 patient records. And your existing Authentication Policy in Okta said: username, password, done.
That's not a hypothetical. It happens every single week in healthcare. The 2024 Change Healthcare breach started with compromised credentials — no MFA enabled on a critical portal.
Authentication Policies in Okta are your answer. They let you say: one login is not like another. A nurse logging in from a hospital workstation at 8 AM is different from someone logging in from a new country at 3 AM. This guide walks you through 4 distinct policies with rules that treat them differently.
Policy Structure: Policy → Rules → Priority
Before we build, let's understand the architecture. In Okta, an Authentication Policy is a container. Inside that container you have Rules. Rules are evaluated from top to bottom, first match wins.
Each rule has an IF part and a THEN part. IF describes the conditions: What network is the user on? What device are they using? What group are they in? What behaviors are detected? THEN describes the action: Allow with one factor. Require MFA. Deny access.
You then assign a policy to one or more applications. So your EHR app gets a strict policy. Your internal wiki might get a relaxed policy.
Think of it like hospital security zones. Medication storage needs biometric access. The cafeteria just needs a badge tap. Same building, different security rules based on what's at risk.
Lab: Create a New Policy
Navigate to Security → Authentication Policies in the Okta Admin Console. You'll see a Default Policy. We're going to create a brand new one. Click 'Add a Policy' in the top right.
Give it a name. I'll call it 'HealthInsight Clinical App Policy'. Add a description: 'High assurance policy for clinical applications with PHI access'. Click Save.
You'll be taken to the policy's Rules page. There's already a catch‑all rule here: 'Catch‑all Rule' that says: 'Access is denied'. That's actually good — we're going to add specific rules above this, and anything that doesn't match a rule gets denied. Least privilege by default.
1. Corporate Network – Phishing Resistant
Rule: Corporate Network - Phishing Resistant
- IF: User's IP is in Corporate HQ network zone.
- AND Authenticator constraints: Any 1 factor type from: Phishing resistant (Okta Verify FastPass or WebAuthn).
- THEN: Access is Allowed. Re‑authentication frequency: Every session.
This rule provides a smooth experience for on‑prem users with strong, phish‑resistant MFA. No constant re‑prompts.
2. Anomalous Behavior – High Assurance
Rule: Anomalous Behavior - High Assurance Required
- IF: User's behaviors include New Device or New City.
- AND Authenticator constraints: Any 1 factor type from: Phishing resistant.
- THEN: Access is Allowed. Re‑authentication frequency: Every 1 hour.
This rule fires when Okta detects a login from a new device or location. It forces the strongest MFA and re‑authenticates every hour. This rule must be above the Corporate Network rule.
3. Off‑Network Unmanaged Device – Deny
Rule: Off‑Network Unmanaged Device - Deny
- IF: User's IP is NOT in Corporate HQ zone AND Device is NOT managed by Okta.
- THEN: Access is Denied. Custom message: "Access to this application requires a managed device. Please contact IT support at extension 4357."
This is a hard stop. If you're not on our network AND your device isn't managed, you cannot access clinical apps — no MFA fallback. For PHI access in healthcare, this is the right call.
4. Catch‑all Deny (Default)
Rule: Catch‑all Rule (Default)
- IF: (no conditions – matches everything that didn't match above)
- THEN: Access is Denied.
This ensures that any access attempt that doesn't satisfy any of the preceding rules is denied by default. Maintains least privilege.
Final rule order (top to bottom):
- Anomalous Behavior – High Assurance (priority 1)
- Corporate Network – Phishing Resistant (priority 2)
- Off‑Network Unmanaged Device – Deny (priority 3)
- Catch‑all Deny (priority 4)
Lab: Assign Policy to an Application
Now we need to assign this policy to our clinical application. Go to Applications → Applications. Find your EHR app (or any SAML/OIDC app). Click on it, then go to the Sign On tab.
Scroll down to 'User authentication'. It shows the currently assigned policy — probably the Default Policy. Click the dropdown and select our 'HealthInsight Clinical App Policy'. Click Save.
Now this app is governed by our new policy. Users trying to access this app will go through our rules in order. The Default Policy still covers all other apps that we haven't assigned a specific policy to.
Lab: Test the Policy
Let's test this with two simulated users:
- User A (corporate network): On‑prem with Okta Verify FastPass. They sign in — Okta detects the corporate IP, matches Rule 2, prompts for phishing‑resistant MFA, and grants access with no re‑prompts. Smooth.
- User B (off‑network unmanaged): Home network with personal laptop. They enter credentials — Okta evaluates: not in corporate zone, device not managed. Rule 3 matches — Denied with the custom message.
- Simulate anomaly: Clear cookies for User A and try again. Okta sees a new device — Rule 1 (anomaly) fires, requires phishing‑resistant MFA and sets a 1‑hour re‑auth. The user experiences slightly more friction, signaling that something unusual was detected.
This demonstrates how Authentication Policies in Okta provide contextual, risk‑based authentication.
Wrap‑up: Zero Trust in Action
Today we built a three‑rule policy (plus a catch‑all) that protects clinical applications with layered security. Anomalous behavior gets the highest friction. Corporate network with a managed device gets smooth phishing‑resistant auth. Off‑network unmanaged devices get blocked completely.
The key insight is that authentication should be contextual. The same person gets different treatment based on where they are, what device they're using, and what behaviors Okta has seen. That's modern Zero Trust authentication.
In the next episode, we zoom out to the Global Session Policy — which controls how long the Okta session itself lasts, separate from individual app policies. Don't miss it.
📋 10 Frequently Asked Questions
An Authentication Policy in Okta is a container that defines how users authenticate to applications. It contains Rules evaluated from top to bottom — the first match wins. Each Rule has an IF part (conditions like network, device, group, or behavior) and a THEN part (action: allow with one factor, require MFA, or deny access). Policies are assigned to one or more applications, enabling contextual security based on risk.
Okta follows a clear hierarchy: Policy → Rules → Priority.
- Policy – a container (e.g., "Clinical App Policy") that holds multiple Rules.
- Rules – individual logic blocks with Conditions (IF) and Actions (THEN).
- Priority – rules are evaluated from highest priority (top) to lowest (bottom).
Conditions include network zones, device trust, user groups, and behavioral signals like "New Device" or "New City". Actions specify the authentication requirements and session duration.
Every Authentication Policy in Okta consists of five core components:
- Name & Description – identifies the policy's purpose.
- Rules – each with a priority order.
- Conditions (IF) – network zones, IP ranges, device management status, user groups, and behavioral signals.
- Actions (THEN) – access allowed/denied, authenticator constraints, re‑authentication frequency.
- Assignment – which applications the policy governs.
- In the Okta Admin Console, go to
Security → Authentication Policies. - Click "Add a Policy" in the top right.
- Give it a name and description, click Save.
- Add specific Rules above the default "Catch‑all Rule".
- Assign the policy to applications via the Sign On tab.
- Policy = a container that holds multiple Rules. It is assigned to apps.
- Rule = the specific logic inside the container. It defines IF conditions and THEN actions.
Example: A policy named "Clinical App Policy" contains rules for corporate network, anomaly, and denial.
- Add a Rule, name it.
- Under Conditions: User's IP in Corporate Zone.
- Authenticator constraints: Any 1 factor from Phishing resistant.
- THEN: Allowed, re‑auth every session.
This gives on‑prem users a smooth, strong MFA experience.
Triggers on new device or new city. Requires phishing‑resistant MFA and sets 1‑hour re‑authentication. Place this rule at highest priority because anomalies require extra scrutiny.
Add a Rule: User's IP NOT in Corporate Zone AND Device NOT managed → THEN Denied with a custom message. This hard‑stops access from unmanaged devices off the corporate network.
Go to Applications → your app → Sign On tab → User authentication section. Select your custom policy from the dropdown and Save.
Use private browser windows to simulate different users:
- User A (corporate network): smooth phishing‑resistant access.
- User B (off‑network unmanaged): denied with message.
- Anomaly simulation: clear cookies to simulate new device – anomaly rule triggers, requiring stronger MFA and 1‑hour re‑auth.
🧠 Ready to go deeper?
Explore our complete Okta & Azure Identity learning path — from SAML tracer deep dives to Okta Workflows and OAuth 2.0.
Recommended Hardware & Reference Architecture Literature
Tested tools and authoritative documentation to implement the architectures covered in this lab:
