Passwords alone are weak. Rules about when to ask for more proof are how companies stay safe without making everyone’s day miserable.

The trouble with passwords

A password is a secret that a person remembers and types. It has three well-known problems. People pick passwords that are easy to guess. People reuse the same password on many websites, so one leak opens many doors. And people can be tricked into typing their password into a fake website, which is called phishing. Once an attacker has the password, the app cannot tell the attacker from the real person.

One size does not fit all

The simple cure is to demand extra proof every time, but that creates a new problem. If the company asks for a phone approval to open the cafeteria menu, people will grow tired and look for shortcuts. Security that annoys people gets bypassed. What we want is risk-based thinking: ask for more proof when the app is sensitive or the situation looks unusual, and ask for less when the app is harmless and the situation looks normal.

It is a named set of ordered rules attached to one or more apps. Each rule says what to do when a certain kind of sign-in happens.

In the Okta Admin Console, you find authentication policies under the security area. Each policy is a list of rules. Every rule has two halves. The first half is a set of conditions, which describe a kind of sign-in: for example, “a person in the Finance group, using a laptop that is not managed by the company”. The second half is the action, which says what to do: for example, “allow access only after the person proves themselves with two different factors”, or “deny access”.

Each app is linked to exactly one authentication policy. The same policy can be shared by many apps, which is a handy way to treat all low-risk apps alike and all high-risk apps alike. When someone opens an app, Okta looks at the app’s policy, walks through its rules from top to bottom, and applies the first rule whose conditions fit the situation.

What “Basic” means here

When people say “authentication policy (basic) in Okta”, they usually mean the simple, everyday way of using these policies. A basic setup uses a handful of conditions, such as group, network location and device, and a handful of actions, such as allow with one factor, allow with two factors, or deny. It does not rely on advanced extras such as custom risk models, fine-grained device checks, or complex scripting. You can build a strong, sensible protection layer using only the basics, and you can add advanced pieces later.

Names you may see

Okta has two generations of its admin screens, often called Classic Engine and Identity Engine. In the older Classic screens, the app-level rules are called sign-on policies. In the newer Identity Engine screens, they are called authentication policies. The idea is the same. This guide uses the newer name, and you will see similar settings in either version.

Okta has several kinds of policy, and the names sound alike. Knowing which does what saves hours of confusion.

How they work together

A person first meets the global session policy when they sign in to Okta. That decides how they get onto the dashboard. When they click an app tile, the authentication policy of that app decides whether the dashboard session is strong enough, or whether Okta must ask for more proof. Behind the scenes, the password policy sets the rules for the password, and the enrollment policy makes sure people have set up the methods that the other policies require.

A dozen small words carry most of the meaning here. Learn them once and the rest reads easily.

A policy decision involves the person, Okta’s sign-in service, a collection of signals, and the app that is waiting for the result.

Okta does not build a separate decision machine for every app. Instead, one central sign-in service gathers facts about the sign-in, finds the policy attached to the app, evaluates the rules, and either lets the person through or asks for more. The app never makes this decision itself. It only receives the final signed result, which is why the policy protects even apps that know nothing about security rules.

flowchart LR
    U["Person"] --> B["Web Browser"]
    B --> GS["Global Session Policy"]
    GS --> DB["Okta Dashboard"]
    DB --> TILE["App Tile Click"]
    TILE --> POL["App Authentication Policy"]
    subgraph SIG ["Signals Collected"]
        G["Group Membership"]
        N["Network Zone"]
        D["Device State"]
        R["Risk Level"]
    end
    SIG --> POL
    POL --> RULE{"First matching rule"}
    RULE -->|"Allow"| MFA["Ask for required factors"]
    RULE -->|"Deny"| STOP["Access denied"]
    MFA --> APP["Signed result sent to the app"]
    

The parts, one by one

The global session policy. This is the first checkpoint, when the person signs in to Okta. It decides how people get onto the dashboard and how long that session lives.

The app authentication policy. This is the second checkpoint, specific to each app. It may accept the existing dashboard session, or demand a stronger proof right then.

The signals. Okta gathers facts to compare against the conditions. It knows which groups the person belongs to, from the Universal Directory. It knows the network address of the request. It knows details of the device from what the browser or the Okta Verify app reports. It may also have a risk score from its behavior checks.

The authenticators. These are the means by which a person gives proof. Before a rule can ask for a phone approval, the person must have set up the Okta Verify app. That setup is controlled by the enrollment policy.

The System Log. Every decision is recorded, including which rule matched. This is the camera footage the security team replays when something looks wrong.

The app. The app only sees the outcome, in the form of a signed assertion or token, and never learns which factors the person used.

Follow one person through one app click, from the moment they select the tile to the moment the app opens.

sequenceDiagram
    participant U as Person Browser
    participant O as Okta Sign-in Service
    participant P as App Authentication Policy
    participant A as Application
    U->>A: Open the app
    A-->>U: Redirect to Okta
    U->>O: Arrive with the app request
    O->>P: Look up the policy for this app
    P->>P: Compare signals with each rule from the top
    P-->>O: Result is allow with two factors
    O-->>U: Ask for the extra factor
    U->>O: Approve on the phone
    O-->>U: Return signed result for the app
    U->>A: Deliver the result
    A-->>U: Open the app
    

A rule is the building block of every policy. Understanding its two halves is enough to read any policy you meet.

The conditions

Conditions narrow down when a rule applies. A rule only applies when all of its conditions are true at the same time. If a condition is left on its “any” setting, it does not narrow anything. The common ones in a basic setup are listed below.

The actions

The action is the outcome when a rule matches. In a basic setup there are two big families.

• Allow access, with requirements. The person gets in after meeting stated requirements. A common requirement is the number of factors, such as “any one factor” or “any two factors”. Stricter requirements may name specific kinds, such as a hardware key.
• Deny access. The person is stopped. Use this for sign-ins that should never happen, such as access to a payroll app from outside the company’s countries.

Each allow rule also has a setting for how often the person must prove themselves again. Chapter 9 covers that.

A policy says how many and which kinds of proof are needed. This chapter explains the proofs themselves.

The three families of proof

Security experts group factors into three families. A strong sign-in combines factors from different families, so that one stolen item is never enough.

Common authenticators in Okta

Phishing resistance

A factor is phishing-resistant when a fake website cannot trick the person into handing it over. Security keys and passkeys work this way, because they bind the proof to the real website’s address. A code typed into a fake page, on the other hand, is stolen the moment it is typed. For the most sensitive apps, policies that demand phishing-resistant factors are far stronger than policies that only count the number of factors.

Proof is not a one-time stamp. It has an age, and a policy can say how old is too old.

When a person signs in to Okta, a session begins. A session is a short-lived record that says “this person proved themselves recently”. Without sessions, people would have to prove themselves at every single click. Each app rule has a setting called re-authentication frequency, which says how fresh the proof must be before it is accepted for that app.

Typical choices

• Every sign-in attempt. The person must prove themselves again every time they open the app, even when they are already signed in to Okta. Good for very sensitive apps, but tiring for everyday ones.
• After a time period. The proof is accepted for a set length of time, for example a work shift, and is requested again after that.
• While the Okta session is active. No extra prompt appears for the app as long as the dashboard session is alive. Good for low-risk apps.

Two timers, not one

People often confuse two lengths of time. The first is the Okta session length, set in the global session policy, which says how long someone can stay signed in to Okta. The second is the app’s own session, which the app controls after it receives the signed result. The re-authentication setting controls only how often Okta asks for new proof. It does not log the person out of an app that is already open.

Three kinds of context make rules smarter: where the request comes from, what device is used, and how suspicious the sign-in looks.

Network zones

A network zone is a named list of network addresses or locations. You might create a zone called “Head office” with the office’s public addresses, and a zone called “Blocked countries” with places where the company has no staff. A rule can then say “if the request comes from Head office, ask for one factor”, or “if the request comes from Blocked countries, deny”. Zones keep rules readable, because the list of addresses lives in one place and can be updated without touching every rule.

Device state

Okta can tell whether a device is known to the company, and in some setups whether it is managed, which means the company controls its settings, updates and security software. A rule can allow a sensitive app only from managed devices. This is very useful: a stolen password is worthless if the attacker’s laptop is not on the approved list.

Risk level

Okta watches signals such as an impossible trip, a brand-new device, or a pattern that differs from the person’s normal behavior. It turns these signals into a risk level, such as low, medium or high. A rule can respond: low risk uses the normal proof, medium adds a factor, high denies. This is a way to be gentle on routine sign-ins and firm on odd ones. Availability and detail of these features depend on your Okta plan.

Here is a complete walk from an empty screen to a policy that protects an app. Labels may differ slightly between Okta versions.

flowchart TD
    A["List the apps and group them by sensitivity"] --> B["Make sure people have enrolled the needed factors"]
    B --> C["Create network zones if needed"]
    C --> D["Create a new authentication policy"]
    D --> E["Add rules from most to least strict"]
    E --> F["Check the catch-all rule"]
    F --> G["Link the policy to the app"]
    G --> H["Test with real test users"]
    H --> I["Review the System Log and adjust"]
    

Most companies get good protection from just three policies, matched to the three piles of apps.

flowchart TD
    S["Sign-in to a sensitive app"] --> R1{"From a blocked country?"}
    R1 -->|"Yes"| X1["Deny"]
    R1 -->|"No"| R2{"In the allowed group on a managed device?"}
    R2 -->|"Yes"| Y1["Allow after two factors"]
    R2 -->|"No"| X2["Deny by catch-all rule"]
    

How the example reads

The first question removes the clearly unacceptable sign-ins. The second question allows only the right people on the right devices, and only after two factors. Everybody else falls to the catch-all and is denied. The structure is short, readable and easy to explain to an auditor, which is a major strength of the basic approach.

A worked example: rolling the three policies out

Imagine a company called Northwind Supplies with 300 employees and 45 apps. The security lead sits down on Monday and sorts the apps into the three piles. Twelve apps fall into everyday, twenty-eight into business, and five into sensitive. On Tuesday she checks enrollment and finds that 90 percent of people have already set up the Okta Verify phone app, while the remaining 10 percent have not. She uses the enrollment policy to require the setup at the next sign-in, and asks managers to remind their teams.

On Wednesday she creates the three policies and links the twelve everyday apps first, because a mistake there would cause the least harm. She watches the System Log for two days and sees that nearly all sign-ins match the expected rule. Next week she links the business apps, and a week after that the five sensitive apps, but only after a small pilot group of ten finance staff has tested the payroll policy. At each stage she keeps one administrator session open, and she announces the change in advance, so people know that an extra prompt is expected and not a sign of trouble.

Within a month the company has consistent protection on every app, the help desk has handled only a few tickets, and the quarterly review shows which rule matched most often. The lesson is that a careful, staged plan beats a clever, complicated one.

Reading a policy aloud

A good test of a policy is to read it aloud as plain sentences. “If the sign-in comes from a blocked country, deny. If the person is in the payroll group and the device is managed, allow after two factors, asked again every four hours. Otherwise, deny.” If the sentences sound sensible to a non-technical manager, the policy is probably clear enough to maintain. If the sentences sound confusing or contradictory, simplify the rules before saving them.

A good policy is not written once and forgotten. It has a life of design, testing, rollout, review and retirement.

What happens to one sign-in’s data

For each sign-in, Okta collects signals, evaluates the rules, applies the action, and writes a log entry. The log entry holds the person, the app, the matching rule, the factors used and the result. These entries feed your security reports and your audits, and they are the best evidence when someone asks “why was this person allowed in?”.

When people change

Because many rules depend on groups, a policy follows people automatically as they move. When a person joins the finance group, the next sign-in to a payroll app is evaluated under the finance rules. When they leave the group, the strict rule stops matching. This is why groups must be kept accurate: the policy is only as correct as the groups behind it.

An authentication policy is itself a security control, so it deserves protection and careful design.

Protect the people who can change policies

Anyone who can edit a policy can weaken it. Give edit rights to as few administrators as possible, require strong factors for those administrators, and review changes in the System Log. A policy change should be treated like a change to the lock on the vault door.

Beware of fatigue attacks

Some attackers already have a stolen password. They trigger repeated approval prompts on the victim’s phone, hoping the tired person taps “approve” just to make the buzzing stop. This is called a fatigue or push-bombing attack. Defenses include number-matching prompts, where the person must type a number shown on the sign-in screen, limits on repeated prompts, and phishing-resistant factors that need no approval taps at all.

Avoid weak fallbacks

A strong rule is useless if there is an easy back door. If a person can skip the phone approval by choosing a text message, or by answering a security question, the attacker will pick the weak path. Review which fallback methods are allowed and remove the ones that are easier to attack than the main method.

Do not trust one signal

Location, device and risk signals can be faked or can be wrong. Use them to adjust the amount of proof, not to replace proof. A request from the office network should still be asked for at least one proper factor.

Keep emergency access safe

Every company needs a way back in if Okta, or a rule, breaks. A small number of emergency administrator accounts, with long random passwords stored in a safe place and every use logged and reviewed, give that way. They must never be used for daily work.

Protect the catch-all

The catch-all rule is where mistakes become holes. If it is set to allow with weak proof, any sign-in that your specific rules did not foresee is accepted. For sensitive apps, set it to deny. For ordinary apps, set it to require at least one solid factor.

When a sign-in is refused or too many people are being prompted, the answers are in the System Log and in a short list of usual causes.

The System Log

Okta records each policy evaluation, including the person, the app, the outcome and the rule that matched. Administrators can filter by person or app to see exactly why a decision was made. The first step in any “why was I blocked?” ticket is to find that log entry and read the matched rule name. This is why clear rule names matter so much.

Common problems and their usual causes

What to watch over time

• Denied sign-ins per rule. A sudden rise on a deny rule can mean an attack, or a rule that is catching real people.
• Prompt counts per person. A person receiving many prompts may be under a fatigue attack.
• Factor mix. Track how many people use weak factors, and push them toward stronger ones.
• Policy changes. Every edit by an administrator should be visible and reviewed.
• Help desk themes. Repeated complaints about one app usually point to one badly tuned rule.

No control is free. Seeing both sides helps you decide how strict to be.

Trade-offs to think about

Teams that run policies well share a few habits. Teams that struggle share a few mistakes.

Patterns that work

Anti-patterns to avoid

Common beginner mistakes

• Putting a broad allow rule above a strict deny rule, so the deny never fires.
• Using one shared policy for apps that really need different strength.
• Forgetting that unmanaged devices and personal phones exist.
• Relying on text messages as the main second factor.
• Writing rule names such as “Rule 3”, which tell nobody anything.
• Never reviewing which apps sit in which tier after the first month.

Questions to ask before adding any new rule

Before you save a new rule, pause and walk through a short checklist. Each question catches a different kind of mistake, and together they take only a couple of minutes.

• Who does this rule affect? Name the group in plain words, and confirm the group really holds only those people.
• What is the worst outcome? If the rule is wrong, will people be locked out, or will attackers be let in? Decide which risk is bigger and design the rule to fail on the safer side.
• Where does it sit in the list? A rule placed above a stricter rule can hide it. A rule placed below a broader one may never fire.
• Can everyone meet the requirement today? Check that every affected person has enrolled the needed factor, and has a working device.
• How will we know it works? Decide which System Log entries you expect to see, and look for them after the change.
• Who owns it, and when will it be reviewed? Every rule should have an owner and a review date, especially exceptions.

Policy evaluation is fast and light. A few other topics decide whether it stays pleasant at scale.

Performance

Evaluating a policy takes only a moment, because Okta compares a short list of conditions. What people actually feel is the time to complete a prompt, such as picking up a phone. Reducing prompts, through sensible re-authentication windows and smooth factors like FastPass, improves the felt speed far more than any server tuning could.

Availability

Because every protected app depends on the sign-in service, plan for the day it is unreachable. Keep emergency administrator access, a written incident plan, and a short list of essential apps that need a backup route. Test the plan once a year, the same way you test a fire drill.

Beyond the basics

Authentication policies show up wherever many people use many apps of different value. These are typical scenarios.

An authentication policy in Okta is the rulebook that decides how strongly a person must prove who they are before an app opens. In its basic form it is a short, ordered list of rules, each with a few conditions and one clear action. Used well, it makes everyday sign-ins easy and makes risky ones hard.