Okta Policies aren't just another configuration screen — they're the foundation of identity and access management in the Okta ecosystem. This is the first in a short series working through how they're structured and how they actually get evaluated, whether you're new to Okta or you've been running a tenant for years without ever mapping out how the pieces fit together.
The framework: policies, rules, conditions
Okta Policies are the rules and conditions that decide who gets access to applications and APIs, and under what circumstances. The framework breaks into three layers: policies set the overall access guideline, rules add granularity within a policy, and conditions specify exactly when a given rule applies. Pull any policy from the API and you'll see that same shape reflected directly in the data:
curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
"$OKTA_ORG_URL/api/v1/policies?type=ACCESS_POLICY" | jq '.[0]'
The four types that cover almost everything
Global Session Policy. Governs session management across the entire org — how long a session lasts, and the conditions under which it remains valid. This is the first check that runs on every request, and it's what stands between a normal session and the kind of prolonged, loosely-validated access that session hijacking depends on.
MFA Enrollment Policy. Controls how users enroll in multi-factor authentication — which methods are available, and under what conditions enrollment gets required, like when someone's accessing a sensitive application. This is where you decide whether FIDO2 is the default or an opt-in for the security-conscious minority.
Password Policy. Sets password strength requirements and governs recovery flows — resets, self-service unlocks. It's the most traditional layer of the stack, and increasingly the one I'm trying to make matter less by pushing MFA harder instead of tuning complexity rules.
Application Access Policies. The most granular layer — per-application rules that factor in user role, device, location, and risk score. This is where "the finance app requires a managed device and FIDO2" actually gets encoded, as opposed to a blanket rule applied to every application uniformly.
How they actually evaluate together
The Global Session Policy runs first — it's the baseline check on whether the session itself is valid at all. Only after that passes does Okta evaluate the Application Access Policy for the specific resource being requested.
Here's what that looks like end to end: someone tries to access a confidential financial application. First, the GSP checks whether their session is active and within its allowed duration. Then the Application Access Policy for that specific application kicks in — and because it's a sensitive app, it might require an additional authentication factor the GSP alone wouldn't have asked for. A user with a perfectly valid session can still get blocked at the application layer if the app-specific conditions aren't met.
That layering is the actual point: org-wide session hygiene plus per-application risk tolerance, evaluated independently but always in that order. Once that clicks, predicting how a given policy set will actually affect a user's access stops being guesswork.
None of this is meant to be configured once and left alone, either. These policies are highly customizable specifically so they can be tailored to how a given org actually operates, and that only holds true if they get revisited as the org changes — new threats, new user populations, new applications all shift what the right configuration looks like.
This is the foundation. The next piece in the series goes deeper into actually configuring these policies well, not just knowing what they are.