Start with three plain ideas: an application, a sign-on, and a policy.

An application is any program or website that people reach through Okta, such as email, a payroll tool, or a customer database. Signing on means getting into that application. A policy is a set of rules. So an app-specific sign-on policy is the set of rules that decides what must happen when someone tries to open one particular application.

The key word is specific. Okta also has rules for signing in to Okta itself, which apply to everything. An app-specific policy sits on top of that, and speaks only about its own application. It can ask for stronger proof than the general rules, demand a certain kind of device, refuse certain networks, or require the person to prove themselves again if their last proof is too old.

In short, the policy answers three questions for each application. Who may open it? What proof must they give? And how fresh must that proof be?

Three questions this guide answers

Everyday phrases and what they really mean

Identity teams use short phrases that confuse newcomers. When someone says “the app asked for step-up”, they mean a person already signed in was asked for a stronger proof. When they say “reauthentication”, they mean the person must prove themselves again. When they say “assurance”, they mean how sure the system is that the person is real. Knowing these three phrases makes most documentation much easier to read.

Applications differ in risk. A single rule for all of them is either too weak or too heavy.

A company may connect dozens or hundreds of applications to Okta. Some hold public information, such as a cafeteria menu. Others hold payroll, customer records, source code, or the keys to the cloud servers. If every application demanded the same proof, there would be only two choices. Set the rule low, and the sensitive apps are exposed. Set the rule high, and everyone is slowed down for the cafeteria menu.

The sensible answer is to match the rule to the risk. Easy proof for low-risk apps, strong proof for high-risk apps, and special conditions for a few apps with special needs. App-specific policies make this possible without changing how people sign in to Okta in general.

What goes wrong with one rule for all

Why this matters even for small teams

Some teams believe app-level rules are only for large enterprises. In truth, the question begins the day a company has one app that is clearly more sensitive than the rest, such as the accounting system. A small firm with ten people and one finance tool faces the same puzzle on a smaller scale. Writing down which apps need stronger proof costs an afternoon. Untangling a rushed setup after it has spread to hundreds of apps costs months.

A short vocabulary list makes the rest of this guide much easier to follow.

Sign-on policy has its own words. Most describe what is being checked, or how strict the check is. The table below puts each term next to a simple picture.

Policy, rule, condition, action

These four words build the whole structure. A policy contains rules. Each rule has conditions, which are the facts it checks, and actions, which are the things it does. Okta reads the rules in order, finds the first one whose conditions match, and applies its actions. Once you hold this picture in mind, every screen in the console makes sense.

Common misunderstandings

The same idea wears different names in different places. Knowing the map avoids a lot of confusion.

Older Okta material, and organizations still on Okta Classic, speak of the app sign-on policy, which lives on each application’s sign-on settings. Newer material, especially for Okta Identity Engine, speaks of authentication policies. An authentication policy is a reusable set of rules that can be attached to one or many applications. The ideas are very close, and in everyday talk people use the names interchangeably.

Why the newer design helps

A few more words you will hear in meetings

Colleagues may say “assurance level” when they mean how sure the system is that a person is real. They may say “conditional access” when they mean access that depends on conditions such as the device or the place. They may say “phishing-resistant” when they mean a proof that cannot easily be tricked out of a person by a fake site. And they may say “freshness” when they mean how recently a proof was given.

None of these words is hard. Each names a piece of the picture you will see in this guide. When a new term appears, ask which part of the sign-in it belongs to: who, what proof, where, or how recent. Placing the word usually reveals what it means.

Two policies often take part in the same sign-in. Knowing which does what avoids the most common confusion.

The first layer is the global session policy. It governs signing in to Okta and the session that results. It decides who may open a session, what proof is needed to open it, and how long it may last. The second layer is the app-specific policy. It governs access to one application, and says what proof is needed to open that application, even when a session already exists.

How they work together

The stricter of the two demands is what the person experiences. If the session policy already required two proofs, and the app policy needs only one, the person will not see anything extra. If the app policy needs a stronger proof than the session provided, Okta asks for it at the moment the app is opened.

Here is the full picture of how a person, the session, and the app policy fit together.

The design has a few clear parts. The person tries to open an application, carrying a session from an earlier sign-in. Okta looks up which policy is attached to that application. It gathers facts about the attempt, such as the person’s groups, the device, the network, and the proofs already given. The policy compares those facts with its rules. The result is access, a request for more proof, or a refusal.

flowchart LR
  subgraph UserSide["User Side"]
    P["Person"]
    B["Browser and device"]
  end
  subgraph OktaZone["Okta"]
    S["Existing session and proofs"]
    F["Facts: group, device, network, risk"]
    AP["App policy and rules"]
    LOG["System Log"]
  end
  APP["Protected application"]
  P --> B
  B -->|"Open the app"| S
  S --> F
  F --> AP
  AP -->|"Allow"| APP
  AP -->|"Ask for more proof"| P
  AP -->|"Deny"| LOG
  AP --> LOG

The components, one by one

Why the middle matters

Every request to open an application passes through the policy. That gives you one place to control how each app is entered, without changing the app itself. A change to a policy takes effect for every sign-in that matches it, which is both powerful and a reason to change it with care.

How Okta chooses a rule decides everything. Learn the evaluation order and half the confusion disappears.

An application policy is made of rules, and each rule has a priority. When a person opens the application, Okta walks through the rules from the top, stopping at the first rule whose conditions all match. That rule’s actions are applied, and no later rule is considered. The last rule, called the catch-all, handles any attempt that no earlier rule matched.

flowchart TD
  S["Person opens the application"] --> R1{"Rule 1 conditions match?"}
  R1 -->|"Yes"| A1["Apply Rule 1 actions"]
  R1 -->|"No"| R2{"Rule 2 conditions match?"}
  R2 -->|"Yes"| A2["Apply Rule 2 actions"]
  R2 -->|"No"| RN{"Further rules checked in order"}
  RN -->|"Match"| AN["Apply that rule"]
  RN -->|"No match"| CA["Catch-all rule applies"]

The order of rules matters

Because the first match wins, the order is part of the meaning. A broad rule placed above a specific one hides the specific rule completely. For example, a rule that says “everyone, any device, one proof” placed at the top will catch every attempt, and a later rule that demands a managed device will never run.

Rules should be short and named

Each rule should have a clear name that says what it does and for whom, such as “Finance app: managed devices only”. A good name makes review and incident work far faster. Keep conditions few, since a rule with many conditions is harder to predict, and any one of them failing means the rule is skipped.

Conditions are the facts a rule checks. The richer the facts, the finer the control.

A rule matches only when all of its conditions are true. Okta offers several kinds of conditions, and the exact list depends on your edition and version. Understanding each kind helps you write rules that are precise instead of blunt.

Common kinds of conditions

Writing conditions that behave

Narrow conditions make a rule easy to reason about. A rule that says “members of the Contractors group, outside the office zone” is clear. A rule with six conditions joined together is harder to predict, and any one of them failing means the rule is skipped. Prefer several simple rules in a sensible order over one rule with a long, delicate list of conditions.

When a rule matches, its actions decide what happens next. Here is what a rule can do.

If conditions are the questions, actions are the answers. A rule’s actions fall into a few groups: whether access is allowed at all, which proofs must be given, how strong those proofs must be, and how often the person must repeat them. Together they define the experience for everyone the rule catches.

The main actions

Allow and deny

The simplest action is allow or deny. A deny rule stops the attempt before any proof is checked. This is useful for networks, devices, or groups that should never reach an application. An allow rule lets the attempt continue, with the proof and freshness requirements that follow. Deny rules usually sit high in the list, so that they are checked before any permissive rule can match.

Allow does not mean easy

An allow rule can still demand strong proof. Think of it as “allowed, after this proof”. The rule that says “managed devices, allow after two kinds of proof, repeated every four hours” is an allow rule. The wording in the console may say “allowed after successful authentication”, which captures the idea well. The proof is the price of entry.

Not every proof is equally strong. A policy chooses the minimum strength for each application.

Proofs come in three broad kinds. Something you know, such as a password. Something you have, such as a phone or a security key. Something you are, such as a fingerprint. A strong policy asks for proofs from different kinds, since breaking one kind does not break the others. Two passwords are still one kind of proof, and add little.

Typical strength levels

Why constraints matter

Some second proofs are weaker than others. A code sent by text message can be intercepted in certain attacks. A code typed from an app can be typed into a fake website. A security key or a device-based biometric resists such tricks, because it checks the real website address or stays bound to one device. A policy can require these stronger kinds for sensitive applications, using a constraint on the possession proof.

Match strength to what is inside

Ask what the worst outcome would be if a stranger entered the app. If the answer is “they read the lunch menu”, a light proof is enough. If the answer is “they move money or read customer secrets”, the proof should be strong. Writing this question beside each application during design makes the decision clear and defensible.

A session can live for hours. Freshness rules make sure the proof behind a sensitive app is recent.

When a person signs in to Okta, they prove themselves once, and the session carries that proof forward. Most apps are happy to rely on it. A sensitive app may not be. It may want to know that the person proved themselves recently, not hours ago when they first sat down. Freshness is the name for how recently a proof was given.

Reauthentication frequency

An application policy can say how often the person must prove themselves again for that app. Common choices include every time the app is opened, once per session, or after a set amount of time since the last proof. The shorter the interval, the closer the app stays to the moment of proof, and the more interruptions people feel.

Step-up in practice

Prompt fatigue

If people see too many prompts, they stop reading them. Attackers sometimes send repeated approval requests, hoping a tired person will accept one. A calm design asks for strong proof clearly, rarely, and at moments that make sense, so that an unexpected prompt stands out.

The same person on two different machines may deserve two different answers.

A device condition lets a rule look at the machine the person is using. At a basic level, Okta can tell whether a device is unknown, registered, or managed by the company. It can also check basic health, such as whether the operating system is recent enough or the disk is encrypted. Rules then use these facts to allow, challenge, or deny.

A simple pattern

Why devices matter at app level

The most sensitive data often lives in a few applications. Restricting those applications to trusted machines protects the data even if a password is stolen. An attacker who steals a password and uses an unknown computer meets a deny rule, and never reaches the data. Meanwhile, the cafeteria app stays open to everyone.

Where an attempt comes from tells you something. Zones let rules use that clue.

A network zone is a named list of IP addresses or locations. Common examples are the office network, the company VPN, a partner’s network, and a list of addresses known to be dangerous. Rules can refer to a zone by name, so they stay readable, and so that updating the address list updates every rule that uses it.

Typical zone designs

Limits of location

Location is a helpful clue but not proof. Attackers can hide behind anonymizing services, or use addresses near the victim. At the same time, honest people travel, work from cafes, and use mobile networks whose addresses change. A rule based only on location may block good people and miss bad ones. Combine location with other conditions, and keep a strong proof as the main protection.

Some rules can react to how suspicious an attempt looks, not only to fixed facts.

Beyond fixed conditions, Okta can look at patterns. Where such features are available in your edition, a rule can respond to an attempt that is scored as risky, or to behavior that is unusual for that person, such as a new device, a new location, or an unlikely travel jump between two places. These signals let policies adapt in the moment.

How adaptive rules help

Strengths and limits

Treat these signals as helpful additions, not as a replacement for good basics. Strong proofs, device rules, and sensible freshness windows still do most of the work. Adaptive rules sharpen the response at the edges.

Different people deserve different rules for the same application. Groups are how you say so.

A rule can be limited to certain groups of people. An application used by everyone may still want a stricter rule for contractors, administrators, or people in a particular country. Groups give you the handle. As long as the groups are accurate, the rules apply to the right people automatically.

Common targeting ideas

A worked example for one application

Group hygiene

Rules are only as good as the groups behind them. If an administrator is missing from the administrators group, they escape the strict rule. If a contractor stays in the staff group after their contract ends, they keep a gentler rule than they should. Keep groups accurate through automation based on trusted data, and review them regularly.

A policy is only useful once an application is attached to it. How you attach policies shapes how easy they are to maintain.

In the newer design, a policy exists on its own, and applications are assigned to it. Each application points to exactly one policy at a time. Many applications can point to the same policy. This means a company can build a small library of well-tested policies, such as “standard business app” and “sensitive app”, and attach the right one to each application.

Why sharing is powerful

When to create a special policy

Most applications fit one of a handful of standard policies. A special policy is justified when an app has truly unique needs, such as an extra network condition for a partner portal. Every special policy is one more thing to maintain, so create them sparingly, and give each a name that explains why it exists.

Every policy has a safety net. Understanding it is essential, because it quietly decides the outcome for anyone not matched elsewhere.

Inside every policy, the last rule is a catch-all, which handles any attempt that no earlier rule matched. The catch-all cannot be removed, because the system must always have an answer. Okta also provides some ready-made policies, which you may attach to applications as a starting point. These are helpful, but they are general, and should be read before being trusted.

Why the catch-all matters

The catch-all rule is the answer to the question “what happens if none of my specific rules fit?” If the catch-all is generous, a person who slips through your specific rules gets easy access. If it is strict, the same person is stopped or challenged. Many real incidents come from a generous catch-all that nobody ever looked at.

A healthy overall shape

The simplest way to design app policies is to sort applications into tiers and give each tier a standard rule set.

Most companies find that their applications fall into a few natural groups. Instead of inventing a new rule for each application, define three or four tiers, and attach every application to a tier. This keeps the design understandable and makes reviews quick.

How to classify an application

Okta’s own doors

Okta itself has doors that deserve special attention. The Okta dashboard, where people see their apps, and the administration console, where settings are changed, are themselves applications with their own policies. The administration console should sit in the highest tier, because anyone who enters it can change the rules for everything else. Review these built-in policies, and confirm what your edition applies to them by default.

Follow one attempt to open an application, and see where each setting takes effect.

Putting the pieces together, opening an application is a short conversation between the person, the browser, Okta, and the application. The two policies take part in the middle. The steps below show the typical order, though details vary with your configuration.

sequenceDiagram
  autonumber
  participant U as User
  participant B as Browser
  participant A as Application
  participant O as Okta
  participant P as App policy
  U->>B: Open the application
  B->>A: Request access
  A->>O: Redirect to Okta to sign in
  O->>O: Check the session policy and existing session
  O->>P: Evaluate the application rules
  P-->>O: Allow after required proofs and freshness
  O->>U: Ask for step-up if the proof is not enough
  U->>O: Provide the proof
  O->>A: Confirm identity to the application
  A-->>U: Access granted

Step by step

Applications connect to Okta in different ways. The way they connect shapes what a policy can and cannot do.

Most modern applications trust Okta through a standard protocol. Two of the best known are SAML and OpenID Connect. In both, the application sends the person to Okta, Okta checks who they are and applies the policy, and then Okta sends back a signed statement saying “this person is verified”. The application accepts that statement and opens.

Why this works for policy

Because the application relies on Okta’s decision, Okta’s policy controls the door. If the policy denies access, Okta never sends the signed statement, and the application never opens. This is why app-specific policies are such a strong control for applications that connect through standard protocols.

Apps that do not fit neatly

The app’s own session

Many applications keep their own session once Okta has confirmed identity. That private session has its own clock. If a person’s Okta session ends, they may keep working in an application for a while. If you need an application to end quickly, you may need to set its own timeouts, or use any sign-out signals the application supports.

App policies are one of your most important security controls. Here is how they can fail, and how to keep them strong.

The application policy sits at the door of each application. A mistake in it can quietly open that door. A well-designed policy, in contrast, makes a stolen password or session much less useful, and keeps the most sensitive data out of reach of unknown machines.

The main risks

Protective habits

The best policy on paper fails if people dislike living with it. Plan the human side as carefully as the technical one.

People accept security when it is quick, clear, and sensible. They resist it when it interrupts their work for no visible reason. An app policy changes how often people are asked for proof, and when they are blocked, so every change is felt by real people at real desks.

What a good experience looks like

The power of a good message

When access is refused, the message is the only help the person gets at that moment. “Access denied” teaches nothing and creates a ticket. “This application needs a company-managed device. Please use your work laptop, or contact the help desk to request one” lets people fix the problem themselves and keeps support calm.

Changing a policy changes people’s day. A careful rollout keeps surprises small.

Application policies touch many teams. The identity team owns Okta. Application owners know what their tools hold. Security reviews the risks. The help desk answers calls. Without a plan that names each team, the project stalls in the gaps between them.

A rollout plan in simple stages

Start gently when raising the bar

When you tighten a rule for an application many people use, expect pushback. A good method is to start with a warning period in which you only observe, then ask for the stronger proof in a small group, and finally enforce for everyone. Along the way, publish the date and the reason, so nobody is surprised.

You cannot manage what you cannot see. A few steady signals show whether your policies are working.

Monitoring means watching a system’s health so that you hear about trouble before your users do. Logging means keeping a written diary of what happened. For application policy, the diary records which rule applied, what proof was asked, and whether access was allowed or denied. Okta’s System Log is the main place to read it.

Where to look

Metrics worth tracking

Alerts that earn their keep

Set alerts for events that need a human: changes to shared policies, many denials for one account, access to critical applications from unusual places, and administrator access from unexpected devices. Keep the list short, so that every alert still feels important.

Instead of memorizing errors, learn a method: find which rule applied, then ask why.

Almost every application policy problem is a version of “the wrong rule applied” or “the proof asked was not what I expected”. The method for both is similar. Identify the person, the application, the device, and the rule that matched. Then check whether that rule is the one you intended. Always ask what changed recently, since most surprises follow a change.

Walkthrough 1: A person is asked for proof too often

Walkthrough 2: Someone is not asked for the extra proof at all

Walkthrough 3: A person is denied unexpectedly

Walkthrough 4: A strict rule locks out many people at once

When many people fail at the same time, suspect something shared. Look for a recent policy change, a new device requirement, a broken link to the device management system, or a proof method that people have not yet enrolled. Roll back the latest change if you can, and use your emergency path to restore access. A sudden group failure is rarely about the people.

No design is perfect. Here is an honest scorecard for application-specific policies.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

When auditors visit, they ask how you control access to each system. Your application policies are a central part of the answer.

Compliance means following rules set by law, customers, or the company itself. Many frameworks for security and privacy expect strong authentication on sensitive systems, control of privileged access, and evidence that these controls work. Governance is the set of habits and records that let you show that.

Evidence auditors often ask for

Governance habits that help

Privacy in plain words

Policies use information about people, such as their location, device, and behavior. Collect only what the policy truly needs, tell people what is collected and why, and keep records only as long as required. Fewer stored details mean less to protect and less to explain if a regulator asks.

Here are four common situations where well-built application policies earn their place. The companies are fictional teaching examples.

Public facts that give context

Security agencies and standards bodies around the world recommend multi-factor authentication and the protection of privileged access, because stolen credentials remain one of the most common causes of breaches. Okta, founded in 2009, built its business on connecting people to applications securely, and its policy engine is a central part of that work. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

The application-specific sign-on policy is the rulebook for each door behind Okta. It reads the facts of each attempt, finds the first matching rule, and decides whether access is allowed, which proofs are needed, and how fresh they must be. Used well, it protects the most sensitive systems without burdening everyone for the cafeteria menu.

A mental model to carry with you

When any application sign-on question lands on your desk, sort it into one of four buckets. The first bucket is selection: which policy and which rule applied to this attempt? The second bucket is proof: what did the rule demand, how strong, and how fresh? The third bucket is context: what did Okta know about the person, the device, and the network? The fourth bucket is reach: which other layers, such as the session or the app’s own session, sit around this decision?

Most confusing situations turn out to be a mix-up between buckets. An unexpected prompt is usually a selection or proof problem. An unexpected denial is usually a context problem, such as a device that is not managed. A person who stays signed in to an app after Okta ends their session has a reach problem. Naming the bucket first tells you which logs to open and which setting to read.

This model also helps when you explain the design to others. Managers care about proof because it is about risk. Support teams care about selection and context because they explain complaints. Application owners care about reach because it covers their own sessions. A good identity architect speaks to all of them and keeps the plan written down.

A final word on the people behind the sign-ins

Behind every attempt to open an application is a real person trying to get on with their work. Security that ignores this reality gets bypassed, resented, or quietly switched off. Security that respects it, by being clear, fair, and forgiving of honest mistakes, earns trust and keeps working for years.

For application policy, this means three promises. First, make the common path smooth, so that most people barely notice the checks on everyday apps. Second, make the sensitive path firm but kind, so that a refusal always comes with a clear message and a way forward. Third, make the whole design easy to explain, so that a new colleague can read it in an afternoon and understand why each choice was made.