🔐 Authentication Policies in Okta

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

2. Anomalous Behavior – High Assurance

3. Off‑Network Unmanaged Device – Deny

4. Catch‑all Deny (Default)

Final rule order (top to bottom):

1. Anomalous Behavior – High Assurance (priority 1)
2. Corporate Network – Phishing Resistant (priority 2)
3. Off‑Network Unmanaged Device – Deny (priority 3)
4. 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

---