A sign-on policy is a set of rules that controls how people are allowed to sign in.

A sign-on policy is a collection of rules inside Okta. Each rule looks at the situation around a sign-in attempt, such as who the person is, which network they are on, and what device they use. Based on what it sees, the rule chooses an action. The action may be to allow access, to deny access, or to ask for an extra proof of identity, such as a code or a phone approval.

The word basic in this guide means we focus on the core, everyday features: policies, rules, conditions, actions, network zones, and session settings. These are enough to build a strong and sensible setup for most organisations. More advanced tuning can come later once these foundations are solid.

What a sign-on policy is not

• It is not the list of people. People and their facts live in Universal Directory. The policy only reads those facts.
• It does not decide what you can do inside an app. It decides whether and how you may get in. Permissions inside apps are a separate job called authorization.
• It is not the same as a password rule. Password rules say how strong a password must be. A sign-on policy says when and how often proof is asked for.

One rule for everyone is either too weak for some people or too annoying for others.

Imagine a company with one simple rule: everybody signs in with a password and nothing more. Staff in the office find it easy. But a stolen password now opens everything, from anywhere in the world. Now imagine the opposite rule: everybody must pass three checks every time. It is safe, but staff become frustrated, and frustrated people look for shortcuts, which often creates new risks.

Different people, different needs

Not all sign-ins carry the same risk. A finance manager opening payroll from a coffee shop in another country is very different from a receptionist opening the visitor list from the office desk. Sign-on policies let you match the strictness to the situation, instead of treating every sign-in the same.

Protecting the sensitive doors

Some people hold powerful access, such as administrators. Some apps hold sensitive data, such as payroll or customer records. Policies let you place extra locks on these doors without burdening everyone else.

Controlling how long sign-in lasts

Without limits, a session could last for weeks. A laptop left open, a borrowed computer, or a stolen browser cookie would keep granting access. Policies set how long a session may last and how long it may sit idle, so old logins eventually expire.

A short dictionary. Each term says what it is, why it exists, and gives a picture to remember it.

One policy guards the door to Okta, and another guards the door to each app.

Okta checks sign-in rules at two levels, and understanding both is the first big step.

Level 1: signing in to Okta itself

When a person first signs in to Okta, a policy decides whether they may start an Okta session, what proof is needed, and how long the session lasts. In the older Okta Classic Engine this is called the Okta sign-on policy. In the newer Okta Identity Engine, it is called the global session policy. It is “global” because it covers the whole Okta session, before any single app is opened.

Level 2: opening a particular app

Once a person has an Okta session, they may open apps from their dashboard. Each app has its own policy deciding whether this person may open it right now and whether more proof is needed first. In the Classic Engine this is called the app sign-on policy. In the Identity Engine, it is called an authentication policy, and one such policy can be shared by several apps.

flowchart LR
    U["User"] --> E["Okta Edge Load Balancer and API Gateway"]
    E --> SI["Sign-in Service"]
    SI --> GP["Okta Sign-On Policy or Global Session Policy"]
    SI --> UD[("Universal Directory")]
    GP --> Z["Network Zones"]
    GP --> R["Risk and Behavior Signals"]
    GP --> MFA["Authenticators and MFA"]
    SI --> SS[("Session Store")]
    U --> APP["Open an App from the Dashboard"]
    APP --> AP["App Sign-On Policy or Authentication Policy"]
    AP --> MFA
    AP --> Z
    SI --> LOG["System Log"]
    AP --> LOG

Why two levels is useful

Having two levels lets you keep everyday sign-in smooth while placing a stronger lock on sensitive apps. A person might sign in to Okta with one proof from the office network. When they click the payroll app, that app’s policy may ask for a stronger proof. This is called step-up authentication.

Policy, assignment, rule, condition, and action. Five pieces, one clear structure.

Every sign-on policy has the same simple structure. Once you can see it, you can read any policy at a glance.

Policies are also ordered

There may be several policies, each assigned to different groups. Okta checks the policies in priority order and uses the first one that applies to the person. Inside that policy, it checks the rules in priority order and uses the first one whose conditions match. So there are two layers of “first match wins”: first for the policy, then for the rule.

The default policy

Every Okta organisation comes with a default policy, assigned to everyone, with a default rule at the bottom. This is the safety net. If no other policy applies to a person, the default policy answers for them. Because it covers everyone who falls through the cracks, its default rule should be reviewed early, and not left on a relaxed setting by accident.

The same simple steps run every time anyone signs in.

When a sign-in attempt arrives, Okta does not guess. It follows a fixed routine, which takes only a fraction of a second.

flowchart TD
    A["Sign-in attempt"] --> B["Find the policy assigned to this user"]
    B --> C["Read rules from top to bottom"]
    C --> D{"Do the rule conditions match?"}
    D -- No --> N["Try the next rule"]
    N --> D
    D -- Yes --> E{"What does the rule action say?"}
    E -- Deny --> X["Block access"]
    E -- Allow --> Y["Let the user in"]
    E -- Prompt --> P["Ask for a factor"]
    P --> Q{"Factor passes?"}
    Q -- Yes --> Y
    Q -- No --> X

The sign-in, step by step

sequenceDiagram
    participant U as User Browser
    participant O as Okta Sign-In
    participant P as Policy Engine
    participant Z as Zones and Risk Signals
    participant A as Authenticator
    U->>O: 1. Request to sign in
    O->>P: 2. Which policy and rule apply
    P->>Z: 3. Check network zone, device and risk
    Z-->>P: 4. Signals returned
    P-->>O: 5. Matching rule says prompt for a factor
    O-->>U: 6. Ask for a second proof
    U->>A: 7. Approve on the authenticator
    A-->>O: 8. Proof confirmed
    O-->>U: 9. Session created and access granted

Notice that the person’s password is only one part of the picture. The policy engine takes in facts about the network, device, and risk, then makes a decision. The password check proves a secret was known. The policy decides whether that is enough for this particular situation.

The facts that decide whether a rule applies.

Conditions are the “if” part of a rule. A rule can combine several conditions, and all of them must be true for the rule to match. The exact list differs by engine and plan, but these are the common ones.

Combining conditions

Because all conditions in a rule must be true together, a rule can be very precise. For example: “People in the Finance group, outside the office network, on a mobile device.” That is a narrow slice of sign-ins, which can be given a stricter action than everyone else.

Allow, deny, or ask for more. Plus the timing settings that go with them.

The three basic actions

How often to ask for the extra proof

When a rule asks for extra proof, there is a second choice: how often. In the Classic Engine, the options are commonly described like this.

• Every sign-in: the person is asked each time they sign in. Safest, but the most interruptions.
• Once per session: asked when a session starts, then not asked again until it ends.
• Per device with a remembered period: after passing the check on a device, Okta remembers it for a chosen time, so the person is not asked again on that same device until the time runs out.

The remembered period is often called the factor lifetime. A short period is safer and a long period is more convenient. A sensible middle path is to remember trusted devices for a modest time, and to ask every time for sensitive apps.

Session settings

A rule can also set how long a sign-in lasts, with three common settings.

• Maximum session lifetime: the longest the session may last, even if the person keeps working.
• Idle time limit: how long the session may sit unused before it expires.
• Persistence across browser restarts: whether the session survives closing and reopening the browser. Allowing this is convenient, but is less safe on shared computers.

A zone is a named list of locations that a rule can refer to by name.

Writing a long list of network addresses inside every rule would be tiring and error-prone. Instead, Okta lets you create a network zone once, give it a clear name like “Head Office,” and then refer to that name in as many rules as you wish. If the office address changes, you fix the zone in one place and every rule is updated.

Types of zones

• IP zones: lists of network addresses or address ranges, such as the ones your office or VPN uses.
• Dynamic zones: zones defined by traits such as countries or regions, and sometimes by the kind of network, for example anonymising proxy services.

Okta organisations also commonly include built-in zones for blocking, such as a list of addresses that are always denied. Check the zone list in your own organisation to see what exists.

Common ways to use zones

A safe, simple path from an empty page to a working policy.

The steps below describe the general approach. Screen names may differ slightly in your organisation, so treat this as a plan rather than a click-by-click manual.

A small, readable policy that fits many organisations as a starting point.

Here is an example of a basic set of rules, listed in the order they are checked. This is a teaching example, not a ready-made answer. Adjust it to your own people, networks, and risk.

Reading it like a story

Rule one stops unwanted places early. Rule two puts the strongest lock on the most powerful people. Rule three treats short-term outsiders carefully. Rules four and five let staff move easily in the office but ask for more elsewhere. Rule six makes sure anyone unexpected is still asked for proof. Notice that the final catch-all is not “allow.” It is “prompt,” so a gap in the plan fails safely.

Same ideas, different labels. A quick translation table.

Okta has gone through a major upgrade of its sign-in system. Older organisations use the Classic Engine, and newer ones use the Identity Engine. Because the labels differ, guides and screens can look confusing. This table helps match the names.

What happens after the rule says yes, and how a session eventually ends.

A sign-on policy does not only decide the moment of sign-in. It also shapes what happens afterwards. Once the rule allows access, Okta creates a session, which means it remembers that this browser has already proved its identity. The session is the reason the second app opens without another prompt.

stateDiagram-v2
    [*] --> SignedOut
    SignedOut --> Evaluating: Sign-in attempt
    Evaluating --> Denied: Rule says deny
    Evaluating --> Challenged: Rule says prompt
    Evaluating --> Active: Rule says allow
    Challenged --> Active: Factor passes
    Challenged --> Denied: Factor fails
    Active --> Idle: No activity
    Idle --> Active: User returns in time
    Idle --> Expired: Idle limit reached
    Active --> Expired: Maximum lifetime reached
    Expired --> SignedOut: Session cleared
    Denied --> SignedOut: Try again

Two clocks run at once

A session has two timers. The idle timer counts time since the last activity. If the person walks away, the timer eventually runs out and the session ends. The maximum lifetime timer counts from the moment the session began, and ends it even if the person has been busy the whole time. Together they make sure no session lives forever.

Two layers of session

Remember that apps keep their own sessions too. Ending an Okta session does not always end every app session straight away. Apps have their own timers, so for very sensitive apps, short app sessions and fresh proof on each visit are good safeguards.

Policies bring flexibility and control, and they ask for care in return.

Thinking in trade-offs

The main trade is security against convenience. Each extra prompt makes sign-in safer and a little more tiring. The art of a good policy is asking for more only when the situation deserves it. A second trade is simplicity against precision. Many tiny rules can describe every situation, but a long list is hard to understand and easy to break. A short list of clear rules, ordered well, is usually safer than a clever list that nobody can read.

What attackers try against sign-in rules, and how a good policy answers.

Defences that matter most

• Require multi-factor authentication broadly, and use the strongest methods for administrators and sensitive apps.
• Make the last rule safe. If nothing matches, ask for proof.
• Deny what has no business reason. Block regions, networks, and anonymisers you never legitimately use.
• Keep sessions short for powerful access. Administrators should have shorter sessions and fresher proof than ordinary staff.
• Use risk and behaviour signals. Raise the required proof when a sign-in looks strange.
• Protect the people who edit policies. Whoever can change a sign-on policy can weaken your whole defence, so give that power to very few people with strong sign-in.
• Review regularly. Zones, groups, and rules drift over time, so check them on a schedule.

You cannot trust a rule you have not tested, and you cannot improve one you cannot see.

Test before you roll out

• Use a small pilot group and test accounts that sit in each of your groups.
• Try sign-ins from inside and outside your zones, and from different device types.
• Where your organisation offers a policy simulation tool, use it to see which rule would match for a given user and situation.
• Confirm that denied cases are really denied and allowed cases are really allowed.

The System Log

Okta records events in the System Log. It includes events about sessions starting, policies being evaluated, extra proofs being asked for, passed, or failed, and policies or rules being changed. Administrators can search these records, and organisations often stream them to external security tools for storage and alerting.

Signals worth watching

Everyday health measures

Beyond security events, useful numbers include how many sign-ins are prompted compared with allowed, how often people fail the extra proof, how long sign-in takes, and how many support requests relate to lockouts. If prompts are too frequent or lockouts are rising, the policy may be too strict for its audience and worth tuning.

Habits that keep a policy clean, and habits that slowly break it.

Patterns worth copying

Anti-patterns to avoid

A short checklist for running sign-on policies well.

Best practices

• Write the plan in plain words first. Build only what you can explain.
• Require multi-factor authentication broadly, and use phishing-resistant methods for administrators and sensitive apps.
• Order rules carefully. Specific first, general last.
• Make the catch-all rule safe. It should ask for proof or deny.
• Use groups and named zones instead of individual names and raw addresses.
• Set sensible session lifetimes. Shorter for powerful access, longer for low-risk roles.
• Test with real scenarios and pilot groups before wide release.
• Keep emergency access. Hold a small number of protected break-glass accounts and keep a second admin session open during changes.
• Review on a schedule. Check zones, groups, and rules every few months, and after any network or organisation change.
• Document and log. Name rules clearly, record why they exist, and watch the System Log.

Common mistakes

Four illustrative situations that show basic policies at work.

The scenarios below are illustrative examples built from common patterns, not accounts of any one named customer.

Quick answers to the questions people ask most.

The whole story of basic sign-on policies in one place.

A sign-on policy is Okta’s rulebook for sign-in. It is made of policies, assigned to groups, containing ordered rules, each with conditions and an action. Okta reads the rules from top to bottom, and the first match decides whether to allow, prompt for proof, or deny. Two levels work together: one guards the Okta session, and one guards each app. With clear zones, sensible session timings, a safe last rule, careful testing, and good logging, a simple policy gives strong protection without making daily work painful.