Policies are only useful if they do what you meant. Order decides whether they do.

Suppose you write two policies. The first says, “Everyone in Finance must use a strong proof of identity.” The second says, “Everyone in the company may sign in with a simple proof.” If both match a Finance employee, which one does Okta use? If you are not sure, then you do not control your own security. The answer depends entirely on which policy sits higher in the list.

Small order mistakes, large consequences

A single misplaced policy can quietly weaken security. A broad “everyone” policy placed above a strict “executives only” policy means the executives never see the strict one, because Okta stops at the first match. The strict policy still exists. It still looks correct on the screen. It simply never runs for the people it was written for. This is one of the most common and least noticed mistakes in real Okta organizations.

The opposite mistake

Order mistakes can also lock people out. A strict rule placed above a friendly one can demand a method of proof that a group of users has not set up. Those people then cannot sign in at all, and the help desk fills with calls. When a whole department is locked out on a Monday morning, the cause is often a policy that was added in the wrong position.

What you will gain from this guide

By the end, you will be able to look at a person, an app, and a situation, and say with confidence which policy and rule will apply. You will know how to arrange policies so the most specific ones come first. You will know why default policies exist, how catch-all rules protect you, and how to test changes before they reach real users.

A small set of words appears again and again in this topic. Learn them once and the rest reads easily.

Policy

A policy is a named collection of instructions about one area of Okta. There are policies about passwords, about how people sign in, about which methods of proof they may set up, and more. A policy by itself is like a folder. The real instructions sit inside it as rules.

Rule

A rule is one instruction inside a policy. Each rule has conditions, which say when the rule applies, and an action, which says what to do. For example: “If the person is outside the office network, then require a second proof.” A policy usually holds several rules, arranged in order.

Condition

A condition is a test. It asks a question about the situation, such as “Is the person in the Finance group?” or “Is the sign-in coming from a known network?” A rule applies only when all of its conditions are true.

Priority

Priority is the position of a policy or rule in its list. The one at the top has the highest priority and is checked first. Moving a policy up the list makes it more important. Priority is how you tell Okta which instruction should win when more than one could apply.

First match wins

This phrase is the heart of the whole guide. Okta walks down the list, finds the first item whose conditions fit, applies it, and stops. Items below it are not checked at all, even if they would also fit.

Default policy and catch-all rule

A default policy is the safety net at the bottom of a list of policies. It applies to everyone who did not match anything above it. A catch-all rule is the safety net at the bottom of a list of rules inside a policy. It applies to any situation that no earlier rule described. Both exist so that no sign-in is ever left without an answer.

Group

A group is a named collection of people, such as “Finance” or “Contractors.” Groups are the most common way to decide which policy applies to whom.

Okta has several kinds of policies. Each answers its own question, and each has its own ordering list.

It helps to think of Okta policies as a family with several members. They share common habits, such as priority and rules, but they have different jobs. The most important idea to remember is that Okta keeps a separate ordered list for each kind of policy. A password policy never competes with a sign-in policy, because they live in different lists and answer different questions.

Separate lists, separate winners

For one sign-in, several of these policies may take part. The global session policy picks one winner. The app’s authentication policy picks another. The password policy may be consulted for rules about the password. Each type has exactly one winning policy for the person at that moment, and each winning policy has exactly one winning rule. Together, those winners shape the journey.

flowchart LR
    P["One sign-in"] --> L1["Global session policies
one winner"]
    P --> L2["Authentication policies
one winner for the app"]
    P --> L3["Password policies
one winner for the user"]
    P --> L4["Enrollment policies
one winner for the user"]
    L1 --> R["Combined journey
from all the winners"]
    L2 --> R
    L3 --> R
    L4 --> R
    

The diagram shows why Okta can feel layered. There is no single master list. There are several small lists, each choosing one winner, and the journey is built from all the winners together. When you troubleshoot, first work out which list you are looking at.

The word inheritance sounds comforting, but it can mislead. Let us clear it up early.

In everyday speech, inheritance means passing something down. A child inherits eye color. In many computer systems, inheritance means a child object automatically receives settings from a parent. People new to Okta often assume policies work that way: a general policy sets a base, and more specific policies add to it or tweak it. That is not how most Okta policies work.

No blending of policies

Okta does not mix two policies together. If a person matches a strict policy and a relaxed policy, Okta does not take the strict parts of one and the relaxed parts of the other. It picks one policy, the highest on the list that matches, and applies that policy in full. Any settings in the lower policy are simply ignored for that person.

So where does inheritance appear?

The idea does show up in a few looser forms, and it helps to name them so they do not confuse you.

• Default fallback. If no custom policy matches a person, the default policy applies. You could say the person “falls back” to the default.
• Layering across policy types. The session policy, the app policy, and others each contribute a decision to the same sign-in. Their results stack up like layers, but each is chosen separately.
• Shared policies. One policy can be assigned to many apps. Change the policy once, and every app using it changes. This feels like inheritance, but it is really sharing.
• Group membership. A person gets the effects of every group they belong to when conditions test group membership. Membership accumulates, even though policies do not blend.

Why this matters in practice

If you believe in blending, you will write a thin “extra” policy that only adds one stricter requirement, expecting the base rules to still apply underneath. In Okta, that thin policy will win for its audience and replace the base entirely. Every setting you did not repeat inside it is now missing for those people. Each policy must therefore be complete on its own for the audience it covers.

Almost everything in this guide grows out of one simple procedure. Learn it well.

Here is the procedure in plain words. Okta looks at the list of policies of one type, starting at the top. For each policy, it asks, “Does this policy apply to this person in this situation?” If yes, Okta chooses it and stops looking. If no, Okta moves to the next one. When it runs out of custom policies, it reaches the default policy, which always applies.

flowchart TD
    S["Start at the top of the list"] --> Q{"Does this policy
apply to the person?"}
    Q -->|"Yes"| W["Choose this policy
stop checking"]
    Q -->|"No"| N{"Is there another policy
below?"}
    N -->|"Yes"| M["Move to the next policy"]
    M --> Q
    N -->|"No"| D["Use the default policy"]
    

Walking through an example

Imagine a password policy list with three entries, in this order. First, “Executives.” Second, “Contractors.” Third, the default. A contractor who is also a member of the Executives group signs in. Okta checks the first policy: is this person an executive? Yes. Okta chooses it and stops. The Contractors policy is never looked at, even though the person also fits it. If you wanted contractor rules to take priority for contractor executives, you would have to move the Contractors policy above Executives.

Ordering is a design decision

Because the list is read from the top, the order is a design choice, not a detail. The usual wisdom is to put the most specific and most restrictive policies first, and the broadest policies last. Specific policies apply to few people, so they must be checked before a broad policy swallows everyone.

Inactive items are skipped

A policy or rule can be turned off. Inactive items are skipped during evaluation, as if they were not in the list. This is useful for preparing a change, but it can also surprise you: a policy that looks right on screen but is inactive does nothing. Always check the status as well as the position.

Choosing a policy is only the first half. Inside the winning policy, Okta runs the same procedure again on its rules.

After Okta picks the winning policy, it opens that policy and reads its rules from the top. For each rule, it checks the conditions. The first rule whose conditions are all true wins, and its action is applied. Rules below the winner are not checked.

What a rule contains

A rule has three parts. The first is a name and status, such as “Office network, active.” The second is the set of conditions, such as the person’s group, the network zone, the device state, or the level of risk. The third is the action, which varies by policy type. In a sign-in policy, the action might be to allow access with a certain level of proof, to ask for extra proof, or to deny access. In a password policy, the action might set how often a password may be reset.

flowchart TD
    A["Policy chosen"] --> R1{"Rule 1 conditions true?"}
    R1 -->|"Yes"| X1["Apply Rule 1 action"]
    R1 -->|"No"| R2{"Rule 2 conditions true?"}
    R2 -->|"Yes"| X2["Apply Rule 2 action"]
    R2 -->|"No"| R3{"Rule 3 conditions true?"}
    R3 -->|"Yes"| X3["Apply Rule 3 action"]
    R3 -->|"No"| CA["Catch-all rule
applies to anything left"]
    

All conditions must be true

A rule applies only when all of its conditions are true at the same time. If a rule says “Finance group, and on the office network, and on a managed device,” then a Finance person on the office network using a personal phone does not match. The rule is skipped, and Okta moves on. This “and” behavior means adding more conditions makes a rule narrower. A rule with no conditions at all matches everyone.

Order of rules is its own design problem

Just as with policies, rule order matters. A common pattern is to put exceptions first, then general rules, then the catch-all. For example: first a rule that denies access from a blocked risk level, then a rule that grants easy access from the office network, then a rule that asks for stronger proof from anywhere else. If the order is reversed, the easy rule could grab everyone before the blocking rule is read.

Every list has a safety net at the bottom. Understanding it protects you from the most dangerous surprises.

The default policy

For most policy types, Okta provides a default policy that already exists when your organization is created. It sits at the bottom of the list of that type, and it applies to everyone who did not match a policy above it. It generally cannot be deleted, and it stays last in the order. Because it applies to everyone left over, its settings quietly describe the experience of the largest group of people in your organization: everyone who is not special.

Why the default deserves attention

Many teams treat the default policy as a leftover and never look at it. That is a mistake. If you create a custom policy for only a few groups, then every other person falls to the default. A weak default means a weak experience for most of your organization. Since you cannot remove the default, the right move is to review it and set it to something you would be comfortable applying to the majority.

The catch-all rule inside a policy

Inside many policies, especially sign-in policies, there is a last rule often called the catch-all rule. It applies to any situation that none of the earlier rules described. Think of it as the sentence “in all other cases” at the end of a legal document. Without it, there would be gaps: situations where Okta has no instruction. A catch-all closes those gaps.

Choosing a safe catch-all action

The action of the catch-all is a security decision. A catch-all that denies access means any situation you did not think of is blocked, which is safe but may lock out legitimate cases you forgot. A catch-all that allows access with strong proof is a gentler choice. A catch-all that allows access with weak proof is risky, because every unanticipated situation gets easy access. Many teams prefer a safe catch-all and then add explicit rules above it for each situation they want to permit. Check what the starting action is on the policies you create, as the starting action can differ by policy type and engine.

flowchart TD
    A["Person signs in"] --> B{"Matches a custom policy?"}
    B -->|"Yes"| C["Use that policy"]
    B -->|"No"| D["Use the default policy"]
    C --> E{"Matches a rule in it?"}
    D --> E
    E -->|"Yes"| F["Apply that rule"]
    E -->|"No"| G["Apply the catch-all rule"]
    

A short checklist for the default and catch-all

Once a quarter, open each policy list and ask four plain questions. What does the default policy do today, and would I be happy if most people received it? Which people actually land on it, according to the log? What does each catch-all rule do, and was that a conscious choice? Has anything changed in the company, such as a new department or a new kind of contractor, that the safety nets no longer fit? Writing the answers down turns a vague worry into a small, repeatable review.

Policies do not pick people by name. They pick them by what the person belongs to and where the person is.

The most common way to decide who a policy applies to is by group membership. A policy or rule says, “This applies to the Finance group.” Okta checks whether the person is a member of that group at the moment of evaluation. If yes, the condition is true.

People can be in many groups

One person can belong to many groups at once: a department, a location, a project, a contractor group. This is where order matters most. If several of those groups appear in different policies, the policy that appears highest in the list wins. The person does not get a blend of all matching policies. They get the first one.

How people enter groups

People join groups in three main ways. An administrator can add them by hand. Group rules can add them automatically based on their profile, for example “if department is Sales, add to the Sales group.” Or groups can be imported from a directory such as Active Directory. Because group membership can change automatically, the policy a person receives can change too, without anyone touching the policy itself. When a person moves department, their group changes, and with it the policy that applies to them.

Timing of group changes

Group membership changes do not always take effect instantly. Group rules and directory imports run on their own schedule. A person added to a group by a rule may not see the new policy until the rule has run. Also, policies are evaluated at specific moments, as we will see later, so a change may only show up at the next evaluation.

flowchart LR
    HR["Profile change
department moves"] --> GR["Group rule runs"]
    GR --> GM["Group membership updates"]
    GM --> PE["Next policy evaluation"]
    PE --> NP["Different policy may apply"]
    

Designing groups for policies

Good policy design starts with good groups. Create groups that mean something for access, such as “Requires strong proof” or “Contractors,” instead of reusing groups made for email lists. Name them clearly so the reason they exist is obvious. Keep the number of overlapping groups low, so that predicting which policy applies does not require a flowchart for every person.

Before a person reaches any app, Okta decides how they get into Okta itself and how long that entry lasts.

The global session policy, in the Identity Engine, governs the Okta session. A session, you may recall, is the period during which Okta remembers that someone already proved who they are. The global session policy decides things like how the person signs in to Okta, whether a second proof is needed at that stage, and how long the session may last or sit idle before it ends.

How a policy is chosen

The global session policy list works like every other list. Policies are ordered. Each policy is assigned to groups of people. For a given person, Okta walks down the list and picks the first policy whose assigned groups include that person. If none match, the default global session policy applies. Inside the chosen policy, the rules are read in order, and the first rule whose conditions match is applied.

What the rules can look at

Rules in a session policy can test things such as the person’s network location, how the person authenticates, whether the sign-in comes from an external identity provider, and behavior or risk signals when available. The exact set of conditions can differ by engine and license, so check your console. The actions decide the session lifetime and how the person must prove themselves for that session.

Why this policy is special

The session policy comes first in the story of a sign-in. Whatever it decides becomes the background for everything after. A short idle limit here means people are asked to sign in again more often, regardless of what each app requires. It sets the floor of the experience.

In the Identity Engine, each app has its own door rules, and the way those rules are attached to apps works differently from the session policy.

An authentication policy, sometimes called an app sign-in policy, describes what proof a person must give to open a particular app. It is made of rules, just like other policies. But unlike many other policy types, an authentication policy is not chosen by walking down a list of policies and checking groups on the policy itself. Instead, each application is assigned to one authentication policy directly.

One app, one policy

Every app points to exactly one authentication policy. There is no competition between policies here. The question “which policy applies?” is answered by the app’s assignment. The competition happens inside the policy, among its rules. The group tests that decide which people get which treatment sit in the rule conditions.

Sharing policies across apps

One authentication policy can be assigned to many apps. This is a powerful tool. Create a policy called “Sensitive apps” with strict rules, and assign it to your payroll, finance, and HR systems. When you tighten the policy, all of those apps tighten at once. This is the closest thing Okta has to inheritance: many apps sharing one definition. Note the trade-off. A change to a shared policy affects every app using it, so you must check the full list of apps before editing.

How the rules are read

When a person opens the app, Okta reads the rules of the app’s policy from the top. The first rule whose conditions match wins. Typical conditions include the person’s group, their user type, the device state, device assurance level, network zone, and risk. The action decides whether to allow access, how many and what kinds of proof are needed, and how often the person must prove themselves again. The last rule is the catch-all.

flowchart TD
    APP1["Payroll app"] --> POL["Authentication policy
Sensitive apps"]
    APP2["HR system"] --> POL
    APP3["Finance app"] --> POL
    POL --> RU1["Rule 1
High risk, deny"]
    POL --> RU2["Rule 2
Managed device, strong proof"]
    POL --> RU3["Rule 3
Catch-all, deny"]
    

Why this design helps

Because the policy is attached to the app, you can answer the question “what does this app require?” by looking at one place. Because rules carry the group conditions, a single policy can treat different groups differently. You avoid the need for many near-duplicate policies. The cost is that the order of rules inside a policy needs careful thought.

In the older engine, the same idea is arranged in two layers that must both be satisfied.

In the Classic Engine, there is an Okta sign-on policy that applies to the whole organization, and each application has its own sign-on policy rules that apply to that app. The two work as layers. First, the org-level policy governs getting into Okta. Then, when the person opens an app, the app’s own rules may demand more.

Layer one: the Okta sign-on policy

The Okta sign-on policy has an ordered list of policies, each assigned to groups, and each holding ordered rules. Okta picks the first policy matching the person, then the first matching rule in it. That rule decides whether the person needs a second proof to enter Okta, how long the session lasts, and similar matters.

Layer two: the app sign-on policy

Each app has its own sign-on policy, made of rules. These rules are read from the top and the first match wins. A rule can require a second proof for that app, regardless of what the org-level policy asked, or deny access from certain locations. Here the app rules do not replace the org policy. They add a second checkpoint.

How the layers combine

The outcome is that the person must pass the org-level gate and then the app-level gate. If the org gate is strict and the app gate is lenient, the person still faces the strict org gate when first signing in. If the org gate is lenient and the app gate is strict, the person enters Okta easily but faces extra checks when opening the sensitive app.

sequenceDiagram
    participant P as Person
    participant O as Org Sign-On Policy
    participant A as App Sign-On Rules
    participant X as Application
    P->>O: Sign in to Okta
    O->>O: First matching policy, then first matching rule
    O-->>P: Session created with required proof
    P->>A: Open the application
    A->>A: First matching app rule
    A-->>P: Extra proof or allow or deny
    P->>X: Access granted
    

Several policy types decide things about the person, not the app. They follow the group-based, first-match pattern.

Password policies

A password policy sets rules for passwords: minimum length, how complex, how often to change, how many failed tries before a lock, and how resets work. Okta keeps an ordered list of password policies, each assigned to groups. For a given person, Okta picks the first policy in the list that matches one of the person’s groups. If none match, the default password policy applies. A person in two groups with different password policies receives the higher-priority one only, not a combination.

Authenticator enrollment policies

In the Identity Engine, an authenticator enrollment policy decides which methods of proof a person may or must set up. In Classic, a similar idea is called an MFA enrollment policy. Again, there is an ordered list of policies assigned to groups, plus a default. The first match decides, for that person, which authenticators are required, optional, or not allowed.

Profile enrollment policies

A profile enrollment policy describes what details are collected when someone signs up for an account themselves, and whether approval is needed. These policies are attached to apps, so the answer to “which one applies?” depends on the app the person is signing up for.

The interaction between them

These policies do not compete, but they affect each other in practice. An authentication policy may demand a certain authenticator, while the enrollment policy of the same person forbids setting it up. The person is then stuck. The fix is to keep these policy types in agreement. Whenever you tighten what an app requires, check that the people affected are allowed to enroll in the needed method.

flowchart LR
    AP["App policy
requires a security key"] --> CHK{"Does the person's
enrollment policy allow it?"}
    CHK -->|"Yes"| OK["Person enrolls and signs in"]
    CHK -->|"No"| STUCK["Person is stuck
fix enrollment policy"]
    

Conditions are the questions rules ask. Knowing the common ones helps you write rules that match exactly the people you mean.

The set of available conditions depends on the policy type, the engine, and your license, so use this chapter as a guide to the kinds of questions rules can ask, and confirm the exact list in your console.

Who is the person?

The most common condition is group membership, which asks whether the person belongs to a chosen group. Some policies can also test the user type, which is a label that separates kinds of users, such as employees and partners. These conditions narrow a rule to an audience.

Where is the person?

Location conditions use network zones. A network zone is a named set of network addresses, such as the office network or a list of countries. A rule can say, “Only when the sign-in comes from this zone,” or “Only when it does not.” Network location is a useful clue, but never a perfect one, because people travel and attackers use disguises.

What device is the person using?

Device conditions ask whether the device is registered with Okta, managed by the company, or meets a chosen level of health, called device assurance. Platform conditions ask whether the device is a phone, a laptop, or something else. These conditions let you say, “Easy access from a managed laptop, stronger proof from anything else.”

How risky does it look?

Risk and behavior conditions use signals that suggest an unusual sign-in, such as a sudden jump to a faraway country or unusual patterns. Rules can require extra proof, or deny access, when risk is high. The availability of these signals varies by license.

Which kind of sign-in is this?

Some rules look at how the person is authenticating, for example through Okta directly or through an external identity provider. Others look at the app or the type of request. These help separate different kinds of traffic into different rules.

Combining conditions

Conditions within one rule are combined with “and.” A rule matching “Finance, and managed device, and office network” is quite narrow. If you need an “or,” such as “the office network or a trusted partner network,” you can usually place both in one network zone condition, or write two separate rules in order.

Network zones are used as conditions, but they also play a special role as a blocking tool that can act before policies are read.

A network zone is a named set of network locations. Okta lets you define zones by lists of addresses, or by other attributes depending on your features. Zones are reused in many rules, so one definition can serve many policies. Change the zone once, and every rule using it changes with it.

Zones as conditions

In a rule, a zone condition can be positive or negative. A positive test says “when the sign-in comes from this zone.” A negative test says “when it does not.” This lets you separate office traffic from everything else, and apply easier rules to the first and stricter rules to the second.

Blocklist zones

Okta also supports blocklist behavior, in which sign-ins from a listed set of locations are blocked outright. This type of block is generally enforced very early, ahead of the normal policy rules, so a request from a blocked location is stopped even if a policy rule would have allowed it. Check your documentation for exactly how and where your organization applies this, since the details differ by feature and release.

flowchart TD
    R["Sign-in request"] --> B{"From a blocked zone?"}
    B -->|"Yes"| X["Blocked immediately
policies not consulted"]
    B -->|"No"| P["Normal policy evaluation
first match wins"]
    P --> O["Outcome"]
    

Why this ordering is important

If you are surprised that a person is blocked even though a rule says “allow,” look for a blocklist zone. The block is not a rule in the usual list, so you will not find it by reading policies. It sits in front of them. Similarly, adding a location to a blocklist is a very strong action: it overrides your carefully designed allow rules. Use it deliberately.

Keeping zones tidy

Zones go out of date. Offices move, vendors change addresses, and travel patterns shift. Review zones on a schedule, name them clearly, and record who owns each. An old zone that still lists a retired office address could silently trust a network that now belongs to someone else.

Apps that call APIs use tokens, and a separate set of policies decides which tokens may be issued.

An authorization server is the part of Okta that issues tokens, which are signed proofs that let an application call an API on behalf of a person. Okta lets you create custom authorization servers, each with its own access policies. These are a different family from the sign-in policies we have discussed, but they follow a similar logic.

How access policies are chosen

Each authorization server holds an ordered list of access policies. Each policy is assigned to certain client applications, meaning the apps that request tokens. When an app asks for a token, Okta walks down the list and picks the first policy that applies to that client. Inside the policy, Okta walks down the rules, which can test the type of request, the person’s group, and the scopes requested. The first matching rule decides the details, such as the allowed scopes and how long the token lasts.

No match means no token

An important difference from the sign-in policies: there is no automatic default that lets everyone through. If no access policy covers the client, or no rule in the chosen policy matches the request, the request is refused. This is a safe default, but it is also a common reason that an API call suddenly fails. When tokens are refused, check that a policy and a rule actually cover the client and the request.

sequenceDiagram
    participant C as Client App
    participant S as Authorization Server
    participant P as Access Policies
    participant R as Policy Rules
    C->>S: Request a token with chosen scopes
    S->>P: First policy assigned to this client
    P-->>S: Policy found or none
    S->>R: First rule matching the request
    R-->>S: Allowed scopes and lifetime
    S-->>C: Token issued or request refused
    

Keep the two worlds apart in your mind

Sign-in policies decide how a person proves who they are. Access policies decide which tokens an application may receive after that. They have separate lists, separate orders, and separate winners. A person may pass sign-in easily and still find that an app is refused a token because an access policy does not cover it.

Now we put the pieces together and follow one person through every layer of evaluation.

Let us follow a person named Meera, who is a member of both the Finance and Contractors groups. She opens a payroll app from a personal laptop at home. Here is the order in which Okta considers her.

sequenceDiagram
    participant M as Meera
    participant Z as Blocklist Check
    participant G as Global Session Policy
    participant A as App Authentication Policy
    participant E as Enrollment and Password Policies
    participant X as Payroll App
    M->>Z: Request from home network
    Z-->>M: Not blocked
    M->>G: Sign in to Okta
    G->>G: First matching policy then rule
    G-->>M: Session proof required
    M->>A: Open the payroll app
    A->>A: App policy rules read in order
    A-->>M: Strong proof on registered device needed
    M->>E: Check allowed methods
    E-->>M: Method allowed or enroll
    M->>X: Access granted
    

Step by step

First, the request is checked against any blocklist. Meera’s home network is not listed, so she continues. Second, the global session policy list is read from the top. Meera is in two groups, so the first policy that matches either group wins. Say the Contractors policy sits above Finance. Then Meera receives the contractor session rules, whatever the Finance policy would have said. Third, within that policy, the first matching rule applies. Fourth, when she opens the payroll app, the app’s authentication policy is read, and its rules are checked in order against her groups, device, and location. Fifth, if the rule demands a strong proof, Okta checks which methods her enrollment policy allows and whether she has one set up. If all is satisfied, she gets in.

Why this walkthrough is useful

It shows that at least four separate decisions shape Meera’s day, each taken from a separate list. If something goes wrong, you do not search one giant rulebook. You find the step that failed and open that list. The System Log, which we will cover later, shows which policy and rule applied at each step.

Policies are not checked continuously. They are checked at certain moments, and knowing those moments explains many mysteries.

At sign-in

The global session policy is evaluated when a person creates a session by signing in to Okta. The decisions made then, such as the session length, last for the life of that session. A later change to the session policy does not usually rewrite sessions that already exist. The new rules take effect the next time someone signs in.

At app access

App policies are evaluated when a person opens an app. Rules can include a re-authentication frequency, which asks the person to prove themselves again after a set period, even if the session is still alive. This means an app policy can be stricter than the session in time. A sensitive app might ask for a fresh proof every hour, while a casual app might not ask again all day.

At enrollment, password, and token moments

Enrollment and password policies are evaluated when a person sets up a method, changes or resets a password, or is asked to enroll. Authorization server policies are evaluated every time an app requests a token. Each policy type has its own trigger moment.

Why changes seem delayed

When an administrator edits a policy and a user reports no change, it is usually timing. The person’s session is still alive, the person has not yet opened the app, or the group membership has not yet updated. To see a change quickly in testing, use a fresh private browser window and a new sign-in.

Now we zoom out to see the parts that cooperate every time Okta evaluates a policy.

Behind the scenes, the policy engine of Okta is a set of cooperating pieces. You do not need to know how they are coded. You only need a mental model of what each piece does, so you can reason about what goes wrong.

flowchart TB
    REQ["Request
sign-in, app open, token"] --> CTX["Context builder
user, groups, device, network, risk"]
    CTX --> SEL["Policy selector
walks the ordered list"]
    SEL --> RUL["Rule matcher
walks the ordered rules"]
    RUL --> ACT["Action
allow, step up, deny, set limits"]
    STORE["Policy store
policies, rules, priorities"] --> SEL
    STORE --> RUL
    DIR["Directory
users and groups"] --> CTX
    ZONES["Network zones"] --> CTX
    ACT --> LOG["System Log
record of the decision"]
    

The parts, one by one

The diagram shows that the same two-step walk happens everywhere. A request arrives. A context is built. The selector picks a policy. The matcher picks a rule. An action results. The decision is logged. Understanding this pipeline helps you localize a problem: bad context, wrong order, mismatched conditions, or an unexpected action.

The best way to master evaluation order is to practice. Here are three examples, each solved step by step.

Example 1: Two password policies, one person

A company has three password policies in this order. First, “Admins,” assigned to the Administrators group, with a long minimum length. Second, “Contractors,” assigned to the Contractors group, with a shorter lifetime. Third, the default. A person named Dev is in both Administrators and Contractors. Which password policy applies?

Okta starts at the top. Dev is an administrator, so the first policy matches. Okta applies “Admins” and stops. The Contractors policy is not read. Dev does not get the shorter lifetime from the Contractors policy, because policies do not blend. If the company wanted contractor administrators to follow contractor rules, it would have to place “Contractors” above “Admins” and accept that contractor rules would then replace the admin rules for those people.

Example 2: Rules in an app policy

An app policy has these rules in order. Rule 1: if risk is high, deny. Rule 2: if the person is in Finance and on a managed device, allow with one proof. Rule 3: if the person is in Finance, allow with two proofs. Rule 4 is the catch-all: deny. Now consider three people.

• Anil is in Finance, on a managed laptop, with normal risk. Rule 1 does not match, because risk is not high. Rule 2 matches. Anil gets in with one proof.
• Bela is in Finance, on a personal phone, with normal risk. Rule 1 does not match. Rule 2 does not match, because the device is not managed. Rule 3 matches. Bela gets in with two proofs.
• Chen is in Finance, on a managed laptop, but the sign-in looks high risk. Rule 1 matches first. Chen is denied, even though Rules 2 and 3 would have allowed access. The order is why the deny rule works.

Example 3: The rule that never runs

A different app policy has Rule 1: “Everyone, allow with one proof.” Rule 2: “Executives, require a security key.” Rule 3: catch-all, deny. An administrator is puzzled that executives are never asked for a security key. Reading the order explains everything. Rule 1 matches everyone, including executives, so Okta stops there. Rule 2 and the catch-all are unreachable. The fix is to move the executive rule above the broad rule, so the special case is read first.

flowchart TD
    S["Sign-in to the app"] --> R1{"Risk is high?"}
    R1 -->|"Yes"| D1["Deny"]
    R1 -->|"No"| R2{"Finance and managed device?"}
    R2 -->|"Yes"| A1["Allow with one proof"]
    R2 -->|"No"| R3{"Finance?"}
    R3 -->|"Yes"| A2["Allow with two proofs"]
    R3 -->|"No"| CA["Catch-all: deny"]
    

Good policy design is less about clever rules and more about a simple structure that people can read.

Think in tiers

A tier model sorts apps and people into a few clear levels. For example, three app tiers: everyday tools, business-sensitive systems, and critical systems. Each tier gets one authentication policy. Everyday tools might allow easy access from trusted devices. Business-sensitive systems might require a stronger proof. Critical systems might require a strong proof on a managed device with no exceptions. Because many apps share one policy per tier, you manage three policies instead of thirty.

Order from specific to general

Inside every policy, arrange rules from the narrowest and most urgent to the broadest. Typical order: block or deny conditions first, special-case allow rules next, general rules after, and the catch-all last. In the policy lists, place small special-audience policies above the broad ones, with the default at the bottom.

Name things so the order makes sense

Good names make the list readable at a glance. Use a clear pattern, such as the tier, the audience, and the purpose. Number prefixes can help if you want the order to be visible even when the list is exported to a document. Avoid vague names like “New policy 2.”

Keep policies complete

Since policies do not blend, each policy must contain everything its audience needs. When you copy a base policy to create a variant, the variant should include all the base rules plus the differences. A short “delta only” policy is a trap.

Document the intent

Write a short description for each policy and rule: who it is for, why it exists, and who owns it. Descriptions are the only way a future administrator can tell whether an odd-looking rule is a mistake or a deliberate decision.

flowchart TD
    T1["Tier 1 policy
everyday tools"] --> A1["Chat, wiki, calendar"]
    T2["Tier 2 policy
business sensitive"] --> A2["CRM, ticketing, HR portal"]
    T3["Tier 3 policy
critical systems"] --> A3["Payroll, admin consoles, source code"]
    

Policy order is a security control. Mistakes in it become security gaps or lockouts.

The silent gap

The worst failures are the ones nobody sees. A broad allow rule above a strict rule means the strict rule is never reached. The strict rule still appears in the console and gives everyone comfort, but it protects nobody. Regular reviews of the top of every list are the cure.

The catch-all as a last defense

Treat the catch-all rule as a security decision, not a leftover. A deny catch-all means that anything you did not plan for is blocked. This is safe, but it needs explicit allow rules above it for everything legitimate. A permissive catch-all means unplanned situations get through. Choose deliberately and record your reasoning.

Lockout and the break-glass account

A mistake in a policy can lock out everyone, including administrators. Protect against this with break-glass accounts. These are a small number of emergency administrator accounts, protected with very strong methods, excluded from risky policy experiments in a controlled way, monitored for any use, and tested on a schedule. They are the spare key you hide for the day the door jams.

Least privilege and separation of duties

Not everyone with admin rights needs to change sign-in policies. Use administrator roles so only a small trusted group can edit policies and their order. For sensitive changes, require a second person to review before the change goes live. A policy edit is a security change, even when it looks like a mere drag-and-drop.

Attackers and the order of things

Attackers seek the weakest path. If one app uses a lenient policy, attackers will aim for that app. If the default policy is weak, attackers will look for accounts that fall through to it. A consistent minimum across all policies, including the default, narrows the weak spots.

Auditability

Auditors will ask who changed the policy order and when. The System Log and your own change records should be able to answer. Keep a change note for every policy edit: what changed, why, who approved, and what the test result was.

To trust your policies, you must be able to see what they actually did.

The System Log as a witness

Okta’s System Log is a running diary of events. Many entries describe sign-in attempts and policy decisions. For a given event, the log can often show which policy and which rule applied, which methods were used, and what the outcome was. This is the single best tool for answering “why did this person get this result?” because it records Okta’s real decision, not your guess about it.

Reading a decision

When troubleshooting, search the log for the person and the time. Find the event for the sign-in or the app access. Read the details to see the policy and rule that were applied. If that is not the one you expected, you now know exactly where to look: either the person did not match the condition you expected, or something above it matched first.

Simulation tools

Okta offers tools in some versions that let administrators simulate how policies would apply to a chosen person, app, and situation without a real sign-in. These are very useful for checking order and conditions before a change reaches users. Availability and names vary by release and license, so check your console. If a simulation tool is not available to you, a test user in a test group, signing in from a private browser window, is a good substitute.

What to watch over time

Beyond individual cases, keep an eye on patterns. Watch for rising failure rates after a change, for many people hitting the catch-all rule, and for the share of sign-ins handled by the default policy. A growing number of people landing on the default may mean your custom policies no longer match how the company is organized.

flowchart TD
    Q["Question: why this result?"] --> L["Search System Log for person and time"]
    L --> E["Open the decision event"]
    E --> W["Note policy and rule applied"]
    W --> C{"Is it the one you expected?"}
    C -->|"Yes"| F["Rule or action needs a change"]
    C -->|"No"| G["Check conditions, groups, and order above it"]
    

Because order carries so much weight, every policy change deserves a small, repeatable routine.

Use inactive rules to stage changes

One safe technique is to create a new rule as inactive, review the full list, and activate it only when you are ready. Inactive rules are skipped, so the new rule cannot affect anyone until you switch it on. Remember to turn it on, since a forgotten inactive rule does nothing.

Small steps beat big bang

If you plan a major redesign, move in stages. Introduce the new structure for a pilot group, watch the results, and expand. A single big reorder that touches everyone at once is the classic recipe for a Monday-morning crisis.

Okta’s approach is a deliberate design with real strengths and real costs.

First match compared with other models

Other systems use different rules for resolving conflicts. Some choose the most restrictive result among all matches. Some combine permissions from every match. Some give explicit deny rules priority over allow rules. Each approach has strengths. The first-match model trades some safety nets for simplicity and control. You decide the winner, but you must be careful about the order.

A pattern is a solution that keeps working. An anti-pattern is a tempting mistake that keeps hurting people.

Patterns worth copying

Anti-patterns to avoid

If you remember nothing else from this guide, remember the habits in this chapter.

Best practices

• Remember the two questions. Which policy applies, and then which rule inside it applies.
• Order from specific to general. Narrow audiences and deny rules go first.
• Make each policy complete. Nothing is inherited from the policy below.
• Own the default. Review it, and make it safe for the majority.
• Choose catch-alls deliberately. Deny or strong proof is usually the safer choice.
• Keep groups clean. Fewer overlaps mean fewer surprises.
• Test with sample people. Trace at least three through every change.
• Check shared policies before editing. Know every app that will be affected.
• Keep break-glass access. Emergency accounts, tested and monitored.
• Record intent and changes. Descriptions on policies and notes on edits.

Common mistakes

These short stories use made-up companies to show how the ideas appear in everyday work. They are teaching examples, not descriptions of any real organization.

What the scenarios share

Each story was solved by asking the same two questions, using the log to see the real decision, fixing the order or the completeness, and testing with sample people. None needed anything exotic. They needed discipline about order.

When a result surprises you, a calm and ordered approach finds the cause faster than guessing.

Almost every policy puzzle comes down to one of a few causes: the wrong policy won, the wrong rule won, the conditions did not match as expected, the policy is inactive, or the change has not yet taken effect. Work through them in order.

Problem: the rule I wrote is not being applied

Check three things. Is the rule active? Is there a broader rule above it that matches first? Do the person’s actual groups, device, and location satisfy all of the rule’s conditions? Use the System Log to see which rule did apply, then compare it to yours.

Problem: the person gets a policy they should not

List the groups the person belongs to, including any added by group rules or imports. Check the order of policies and see which group matches first. The person may belong to a group nobody remembered.

Problem: everyone is falling to the default

Check whether the groups assigned to your custom policies still contain the people you expect. Group rules may have stopped working, or a directory import may have changed. Also check that the policies themselves are active.

Problem: a person is blocked although a rule says allow

Look for a blocklist zone or another early block, which acts before the normal rules. Also check risk-based rules above the allow rule.

Problem: a change had no effect

Remember timing. The person may have a live session, or tokens may still be valid. Test from a fresh private browser window with a new sign-in, and wait for group changes to finish.

Problem: token requests fail for an app

Find the authorization server used. Check that an access policy is assigned to the client and that a rule matches the grant type, the person, and the scopes requested. No match means no token.

Short answers to the questions people ask most often.

Here is the whole story in a few lines you can carry with you.

Okta does not blend policies. For each policy type, it walks an ordered list, picks the first policy that applies to the person, then walks that policy’s ordered rules and picks the first rule whose conditions all match. Default policies and catch-all rules close every gap. Different policy types keep their own lists and their own winners, and a sign-in is shaped by all of them together. Because position decides the outcome, ordering is a security control. Good design means few overlapping groups, complete policies, specific rules first, a safe catch-all, careful testing, and the System Log to check what really happened.