It means raising the bar for proof of identity in the middle of a session, when the situation calls for it.

Let us start with the words. Okta is an identity provider, which is a service that proves who people are to many apps at once. Authentication is the act of proving who you are. A factor is one kind of proof, such as a password, a prompt on a phone, or a hardware key. Multi-factor authentication (MFA) means asking for two or more different kinds of proof.

A session is the period of time during which Okta remembers that you already proved who you are, so it does not ask again at every click. Step-up authentication means that, in the middle of a session, a system asks for a stronger proof, a fresher proof, or both, before it allows a particular sensitive thing. The user has already signed in. The system is simply saying, “For this next step, I need you to prove it again, and maybe in a stronger way.”

Strength and freshness

These two words come up in every later chapter, so it helps to be clear about them now. Strength is how hard the proof is to fake. A password alone is weak, a prompt on a phone is stronger, and a hardware security key is stronger still. Freshness, also called recency, is how recently the proof was given. A proof from eight hours ago is stale. A proof from thirty seconds ago is fresh. Step-up can demand either one, or both together.

A short vocabulary will make every later chapter easier to read.

Step-up has its own small language. Learn these terms once, and you will recognize them in Okta screens, documentation, and developer conversations.

The same session cannot be equally trustworthy for every task. That is the problem step-up solves.

Single sign-on is a wonderful convenience. A person proves who they are once, and Okta vouches for them to many apps. But convenience has a hidden cost. The longer a session lasts and the more apps it reaches, the more damage someone can do if they get hold of it. A stolen session, an unlocked laptop left in a cafe, or a hijacked browser can all give an attacker everything that the original sign-in could reach.

Two bad answers

Without step-up, a company usually ends up with one of two poor choices. The first is to make everything strict: every app demands a strong factor at every click. People grow tired, work slows down, and they start looking for shortcuts. The second is to make everything loose: one easy sign-in for the whole day. This is pleasant until the day it is abused.

Step-up offers a third answer. Keep the ordinary path easy and add friction only where the stakes are high. This is a better deal for both security teams and users, and it is why the idea has become a standard part of modern identity design.

Thinking in levels makes step-up much easier to design and explain.

An assurance level is a measure of how sure a system is about who is on the other end. Higher levels need stronger proof. Security standards bodies publish formal level definitions, and Okta has its own named levels that apps and policies can use. For teaching purposes, it helps to picture a simple ladder. The labels below are teaching labels used in this guide, and Okta’s own names appear later.

flowchart LR
  L0["Level 0: Existing session only"] --> L1["Level 1: Password or one factor"]
  L1 --> L2["Level 2: Two factors"]
  L2 --> L3["Level 3: Phishing-resistant factor"]
  L3 --> L4["Level 4: Hardware-protected with user verification"]

A level is about the sign-in, not the person

One idea trips up many beginners. A level describes how a particular sign-in happened, not how trusted the person is. The same employee may reach level 1 on Monday morning with a quick prompt, then reach level 3 on Monday afternoon after touching a security key. The level belongs to the proof, not to the human. This is why one person can be asked to step up again and again, depending on the action.

Several parts work together every time a person is asked to step up.

The picture is simple. A user works in an app. The app, or Okta’s own rules, decides that more proof is needed. The user is sent to Okta, completes the stronger proof, and returns to the app with a signed statement of what just happened. Each part of this has a clear job.

flowchart LR
  U["User and Browser"] --> A["Protected App"]
  A -->|"Request with required level and recency"| O["Okta Sign-In and Policy Engine"]
  O --> P["Authentication Policy and Rules"]
  O --> S["Session and Last Sign-In Time"]
  O --> F["Enrolled Authenticators"]
  O -->|"Token with level and time claims"| A
  O --> L["System Log"]

Notice that the app does not run the stronger check itself. It delegates the check to Okta and reads the result. This keeps the sensitive work, such as handling factors and hardware keys, in one carefully protected place.

Step-up can start from the Okta side or from the app side. Many companies use both.

There are two main starting points. In policy-driven step-up, an Okta administrator writes rules for an app, and Okta applies them whenever someone opens it. The app does not need to be modified. In app-driven step-up, the app itself decides that a certain action is sensitive and asks Okta for a higher level at that moment. This needs a little developer work, but it gives fine control, down to a single button.

The next chapters take each trigger in turn, starting with the one that needs no code at all.

An authentication policy is the rulebook that Okta reads each time someone opens a protected app.

In Okta Identity Engine, each app is attached to exactly one authentication policy. Many apps can share the same policy, which keeps things tidy. Inside a policy sits an ordered list of rules. Okta reads the rules from the top, finds the first rule whose conditions match the sign-in, and applies it. At the bottom sits a catch-all rule that handles everyone who matched nothing above. Older Okta setups use similar ideas under the name sign-on policies, and the screens differ, but the thinking is the same.

What a rule contains

The re-authentication frequency setting is the heart of freshness. It tells Okta to ask for proof again even if the person still has a perfectly good session. For a sensitive app you might choose to ask at every sign-in attempt. For a medium-risk app you might choose to ask after a number of hours. Exact option names change between releases, so check what your Okta version shows.

A simple three-rule policy

Imagine a payroll app. The first rule says that people in the Payroll group, on a managed device, on the office network, need two factors and a fresh proof every few hours. The second rule says that people in the Payroll group anywhere else need a phishing-resistant factor and a fresh proof at every sign-in. The catch-all rule at the bottom denies everyone else. Three short rules express a whole security stance.

A rule can ask for specific kinds of proof, not only a number of factors.

Counting factors is only the start. A thoughtful rule also says which kind of factor will be accepted. In Okta’s rule settings you will find choices that describe the kinds of proof, grouped by the three families of evidence. The knowledge family covers things a person knows, such as a password. The possession family covers things a person has, such as a phone or a hardware key. The inherence family covers things a person is, such as a fingerprint on a device.

Why user verification matters

A phone or a security key proves that a device is present. It does not prove that the rightful owner is holding it. User verification closes that gap by asking for a quick local check, such as a fingerprint, face unlock, or device PIN, before the device answers. If a thief steals an unlocked phone or a key, they still cannot pass the check. This is why user verification is a favorite setting for step-up rules.

An app can ask Okta for a stronger or fresher sign-in at the exact moment it needs one.

OpenID Connect (OIDC) is a sign-in standard built on top of OAuth 2.0. In an OIDC sign-in, the app sends the user to Okta with a request, Okta authenticates the user, and then Okta hands back an ID token, which is a small signed package of facts about the sign-in. The request can carry extra hints that ask for step-up. Two of these hints matter most.

Okta’s named levels

In Okta Identity Engine, an app can request one of several named authentication contexts. The table below lists the ones most often used. Exact values and availability can change, so confirm them against current Okta documentation before building.

sequenceDiagram
  autonumber
  participant U as User
  participant A as Protected App
  participant O as Okta
  U->>A: Open the normal page
  A-->>U: Show the page with an ordinary session
  U->>A: Start a sensitive action
  A->>A: Check how strong and how recent the sign-in was
  A-->>U: Redirect to Okta asking for a higher level and a recent sign-in
  U->>O: Arrive at Okta with an existing session
  O->>O: Compare the session with the requested level
  O-->>U: Ask for the stronger proof
  U->>O: Complete the stronger proof
  O-->>U: Return a code to the app
  U->>A: Deliver the code
  A->>O: Exchange the code for tokens
  O-->>A: ID token with level and time claims
  A->>A: Verify the claims, then allow the action

Reading the flow

The user is already working in the app with an ordinary session. When they click something sensitive, the app checks the strength and age of the sign-in it already knows about. If either is not good enough, it redirects the user to Okta and asks for a higher level, a fresher proof, or both. Okta compares the user’s current session with the request. If the session already satisfies it, Okta can answer immediately with no prompt. If not, Okta asks for the stronger proof, and only then returns a code. The app swaps that code for tokens by speaking directly to Okta, and finally checks the claims in the new token before it allows the action.

Asking for step-up is only half the job. The app must also check that it really happened.

When Okta returns an ID token, the token contains claims, which are individual facts packaged inside it. Three claims are especially useful for step-up.

Why checking matters

It is easy to assume that if the user came back from Okta, all is well. That assumption is dangerous. A user, or an attacker, may be able to change the request on its way, removing the stronger-level hint. The app must therefore look at the token that comes back and confirm three things: the signature is valid, the level meets what the app needed, and the time is recent enough. If any check fails, the app must refuse the action, no matter how the user arrived.

Be careful with the level you accept

Apps should also decide, ahead of time, which levels they will accept for each action. A payment approval might need phishing-resistant proof from the last five minutes. A profile edit might accept two factors from the last hour. Writing these rules down as a short table, kept next to the code, helps both developers and security reviewers see at a glance what protects what.

Many business apps use SAML, an older standard, and step-up works a little differently there.

SAML stands for Security Assertion Markup Language. It is a widely used standard for single sign-on between a company and its apps. In a SAML sign-in, Okta sends the app a signed message called an assertion, which states who the user is and how they signed in. SAML apps are often handled with policy-driven step-up, because the app side is typically a ready-made product that you cannot change.

What to expect in practice

For most SAML apps, the practical answer is the first option. You attach a stricter policy and accept that the whole app is treated as sensitive. That is perfectly fine for apps like an HR system or a finance tool, where nearly every action deserves care. If you need per-action control inside a SAML product, ask the vendor whether the app supports fine-grained re-authentication, or consider placing a second protected layer in front of the riskiest function.

The accounts with the most power deserve the strictest treatment, and Okta itself applies step-up to them.

The Admin Console is the place where Okta administrators manage users, apps, and security rules. Whoever controls it can change policies, create administrators, and reset other people’s factors. This makes it the single most valuable target in the whole system. Okta therefore protects it with its own rules, and may ask an administrator to prove their identity again before certain sensitive actions, even in the middle of a session. The exact list of protected actions changes over time, so read the current documentation for your org.

What you should do yourself

Beyond Okta’s own protection, you can and should add your own. Attach a strict authentication policy to the Admin Console app, with a rule that requires a phishing-resistant factor, user verification, and a short re-authentication window. This is a strong example of policy-driven step-up, and it is a good place for a first rollout, because the group is small and security-minded.

Sometimes the best reason to step up is not the app but the circumstances.

Okta can look at the context of a sign-in, which means the surrounding facts, and use them in rules. Context-based step-up is called adaptive or risk-based authentication. The idea is simple. On a normal day, from a normal place, on a normal device, keep the experience smooth. On an unusual day, add friction.

flowchart TD
  R["User requests an action"] --> Q1{"Is the action sensitive?"}
  Q1 -- "No" --> OK["Allow with the current session"]
  Q1 -- "Yes" --> Q2{"Is the session strong enough?"}
  Q2 -- "No" --> SU["Step up to a stronger proof"]
  Q2 -- "Yes" --> Q3{"Was the last proof recent enough?"}
  Q3 -- "No" --> RE["Ask for a fresh proof"]
  Q3 -- "Yes" --> Q4{"Does the context look risky?"}
  Q4 -- "Yes" --> SU
  Q4 -- "No" --> OK2["Allow the action"]
  SU --> OK2
  RE --> OK2

Read the diagram from the top. A harmless action sails through. A sensitive action is checked for strength first, then freshness, and finally for any warning signs in the context. At any point a failed check sends the user to the step-up path. Only after all checks pass is the action allowed.

A step-up rule that nobody can satisfy is not security. It is a locked door with no key.

This is the most common reason for a failed step-up rollout. The administrator writes a rule that demands a phishing-resistant factor, and then discovers that most people have never registered one. When those users reach the step-up moment, they find nothing they can use, and they are stuck. The cure is to line up your enrollment policy, which controls what people can register, with your step-up rules, which control what people must present.

Use the soft option while you roll out

Okta provides a gentler version of some requests, such as the two-factor level marked “if possible.” This asks for the stronger proof when the user has one, and falls back to a lower level when the user does not. Using it during a rollout lets you see who is ready without locking anyone out. When your enrollment numbers look healthy, you can switch to the strict version.

Step-up and session length are close cousins, but they are not the same thing.

When a person signs in to Okta, Okta creates a session. A session has a maximum lifetime and often an idle timeout, which ends it after a period of no activity. Apps then create their own sessions on top. All of these timers are separate, and mixing them up is a common source of confusion.

The key insight is that a step-up proof makes the session stronger for a while, and then it fades. Once the freshness window ends, the next sensitive action will ask again. This is by design. A strong proof from three hours ago should not unlock a payment now.

Choosing the freshness window

Short windows are safer and more annoying. Long windows are friendlier and riskier. A reasonable starting point for the most sensitive actions is a proof from the last few minutes, or even a fresh proof for each action. For medium-risk actions, an hour or two may be fine. Whatever you pick, make it consistent, explain it to users, and review it after you see real behavior in the logs.

Step-up works only when people accept it. A badly designed prompt turns allies into critics.

From the user’s side, step-up is an interruption. They were doing something, and suddenly they are asked to prove themselves again. If the interruption feels random, slow, or confusing, people will complain, work around it, or approve prompts without thinking. If it feels logical, quick, and explained, most people will accept it as a normal part of handling sensitive work.

Principles of a good step-up experience

Prompt fatigue is a real risk

When someone receives repeated approval requests, they eventually tap yes without checking. Attackers know this and sometimes send a flood of requests, hoping that one will be approved by a tired person. This is called prompt fatigue or push bombing. Settings such as number matching, where the user must pick the number shown on the sign-in screen, and user verification on the device both make blind approvals impossible. A good step-up design uses them.

Accessibility and device variety

Not everyone can tap a fingerprint reader, scan a face, or read a small number on a phone screen. Some people use screen readers, some have limited hand movement, and some work on shared kiosks or older laptops. A step-up design that works only for the typical user will quietly shut out others at the very moment they need to finish a task. Offer more than one strong method where your security rules allow it, test prompts with assistive tools, and make sure messages are written in plain language that a screen reader can read in a sensible order.

Device variety matters as well. A hardware key that works on a desktop may need an adapter for a phone. A built-in biometric authenticator is available only on devices that have the hardware and have it set up. Before you demand a particular method, list the devices people really use and check what each one supports. A short survey, or a look at the sign-in logs for operating systems and browsers, often reveals surprises such as a group of shared tablets that cannot do what the new rule demands.

Support and training

The help desk is the safety net for any new rule. Give support staff a one-page guide that explains what step-up is, which apps are in which tier, what the prompts look like, and how to verify a caller before helping with a lost factor. Add a short message at the point of the prompt, with a link to the guide for users. When people can find the answer in a minute, they do not open a ticket, and the rollout feels calm. When they cannot, even a good rule earns a bad reputation.

Exact screens change over time, but the order of work stays the same.

Policy-driven setup

App-driven setup

A story makes the moving parts easy to see in one piece.

Meet Anika, who works in the finance team of a mid-size company. Every morning she signs in to Okta with a prompt on her phone, and she opens the company’s payments app. That sign-in is level 2: two kinds of proof. For small, routine tasks such as viewing invoices, the payments app is happy with that.

At eleven o’clock she prepares a large supplier payment. When she clicks the approve button, the payments app notices that the amount is above a set limit. It checks the token from her morning sign-in. The level is two-factor, but the rule for large payments requires a phishing-resistant proof from the last five minutes. So the app redirects her to Okta with a request for a higher level and a maximum age of five minutes.

Okta sees that Anika has an active session, but that her last proof was too long ago, and was not phishing-resistant. It asks her to use the fingerprint reader on her laptop, which is registered as a built-in biometric authenticator. She taps, and it works in two seconds. Okta sends a token back to the payments app. The app verifies the signature, sees the correct level, sees that the time is only a few seconds old, and allows the payment.

What would have happened to an attacker

Suppose an attacker stole Anika’s browser session at lunchtime. They could view invoices with no extra proof, since the session is valid. But the first time they tried to approve a large payment, the app would send them to Okta and ask for a fingerprint, which they do not have. The attack stops at the exact step where damage would begin. That is the whole point of step-up.

Most companies do better with a small number of tiers than with a different rule for every app.

Imagine a company with about a hundred cloud apps. Writing a custom rule for each would be exhausting and hard to explain. A simpler approach is to sort apps into a few tiers by risk, and to attach one shared policy to each tier. People then learn a simple pattern: normal apps, careful apps, and critical apps.

Why three tiers work well

Three tiers are easy to remember, easy to teach, and easy to audit. New apps can be placed in a tier with a short conversation: “How bad would it be if a stranger used this app for ten minutes?” If the answer is “not very bad,” it goes in standard. If the answer is “we would call a lawyer,” it goes in critical.

Following the data from request to record shows where each check happens.

Every step-up has a short life cycle. It starts with a sensitive action, passes through a decision, collects a stronger proof, and ends with a record. Knowing each stage helps you place checks, logs, and alerts in the right spots.

flowchart TD
  A["Sensitive action requested"] --> B["App or policy asks for a higher level"]
  B --> C["Okta evaluates the policy and the session"]
  C --> D["User completes the stronger proof"]
  D --> E["Okta records the event and updates the session"]
  E --> F["Token returned with level and time claims"]
  F --> G["App verifies the token and acts"]
  G --> H["Logs in the app and in Okta can be matched"]

What is stored and what is not

Okta stores the facts about the sign-in, such as which kind of factor was used and when. It does not store your fingerprint. When a person uses a fingerprint on a laptop or phone, the device checks it locally and then uses a protected key to answer Okta. Okta only sees the signed answer. This is a privacy-friendly design, and it is worth saying so when users ask whether their body data is being collected.

Step-up is a security control, so attackers study it just as carefully as defenders do.

A well-designed step-up closes many doors, but it can also contain gaps. The most important risks come from poor checking, weak fallbacks, and tired users. Each one has a clear remedy.

The weakest link rule

Security chains are as strong as their weakest link. If a critical app demands a hardware key, but the user can also choose a text message for the same app, the real strength is that of the text message. When you design a step-up rule, look at every method the rule allows and ask: if an attacker chose this one, would I still be comfortable? If not, remove it from that rule.

Session theft and why step-up helps

Many modern attacks do not guess passwords at all. Malicious software on a laptop, or a lookalike site that relays the real sign-in page, can capture a live session cookie after the user has finished a perfectly good sign-in. With that cookie, the attacker looks like the user. Step-up changes the value of that stolen cookie. Because the most dangerous actions demand a new proof that the attacker cannot produce, the stolen session can read ordinary data but cannot move money, change administrators, or export the customer list. The attacker is forced to attempt the hard part with no help from the stolen session.

This is also why freshness matters as much as strength. A strong proof from nine hours ago says little about who holds the keyboard now. Short windows on critical actions mean that even a patient attacker, who waits for the right moment, meets a fresh question at the worst time for them.

Privacy and least privilege

Context signals such as location, network, and device state are personal information. Collect only what a rule truly needs, explain it in your acceptable-use policy, and limit who can view the detailed logs. Apply the same least-privilege thinking to people: only the administrators who must edit authentication policies should hold that power, and ideally changes to critical policies should need a second person to review them. Security controls that are themselves tightly controlled earn trust from both auditors and employees.

Protect the policy itself

An attacker who becomes an administrator can simply weaken the rule. Limit who can edit authentication policies, ask for strong proof before they can do so, and watch the log for any change to policies that cover critical apps. A rulebook that anyone can quietly rewrite protects nothing.

Plan for the day a rule locks out the wrong people or a service is unreachable.

Step-up adds one more thing that can go wrong at the exact moment people are doing important work. Planning for failure means you know what happens when the stronger proof is not available, and how to recover quickly without opening a hole.

Fail closed, with a plan

When the stronger proof cannot be obtained, a sensitive action should normally be blocked rather than allowed. Security people call this failing closed. It is the safe default, but it needs a plan so that the business is not stuck. For a critical action, such as an urgent payment, keep a documented manual route, for example approval by two named managers, so that people do not invent unsafe workarounds in a hurry.

A rule you cannot observe is a rule you cannot improve.

Okta keeps a searchable record of events called the System Log. It shows sign-ins, factor use, policy decisions, and administrator changes. Event names and wording vary between releases, so if a name below does not match, search by user, time, and app name. Examples to look for include user.authentication.auth_via_mfa when a person passes a multi-factor check, user.authentication.sso when a person opens an app through single sign-on, and policy.evaluate_sign_on when Okta evaluates a sign-in against a policy. Many events also record which rule applied, which helps you check that your rules behave as intended.

Useful alerts

• A change to any policy or rule attached to a critical app.
• A sharp rise in failed step-up attempts for one account, which may be an attack.
• A user completing step-up from a new country within minutes of a sign-in elsewhere.
• A weak factor appearing in a tier that should accept only strong ones.
• A big drop in step-up success after a rule change.

Send these logs to your security monitoring tool if you have one, using Okta’s log streaming or event hooks. Combine Okta’s view with the app’s own audit log, because each side sees something the other does not. Matching the two by time and user is often the fastest way to explain a surprising event.

Step-up is a balancing act between safety and convenience. Here is an honest look at both sides.

Comparing the approaches

For most companies, the sweet spot is a mix: policy-driven tiers for whole apps, context rules for unusual situations, and app-driven step-up for a short list of especially dangerous actions. Start with the first, add the second when you have good data, and add the third where your developers can invest.

A pattern is a habit that works. An anti-pattern is a habit that looks fine until it hurts.

Patterns that work

Anti-patterns to avoid

These habits separate a smooth rollout from a stressful one.

A short checklist before turning on a stricter rule

• Purpose: Can you state in one sentence why this rule is needed?
• Audience: Do you know which groups and roughly how many people it affects?
• Readiness: Have enough of them enrolled the factors the rule will demand?
• Order: Is the rule in the right place, with specific rules above broad ones?
• Test: Have you signed in as a test user from each affected group?
• Message: Do people know what to expect and where to get help?
• Rollback: Do you know how to undo the change quickly if needed?

Measuring success after launch

A step-up program is working when attackers are stopped and employees barely notice. Pick a few simple measures before you start, and review them monthly for the first quarter. Useful measures include the share of sensitive actions protected by a stronger proof, the percentage of users in critical groups who have enrolled a phishing-resistant factor, the average number of step-up prompts per person each week, and the number of support tickets that mention the new prompts. Compare these numbers with your baseline from before the change.

If protection is rising while tickets stay flat, you are on the right track. If tickets climb, read them for patterns: they usually point to a single confusing message, a missing enrollment, or a window that is too short. Fix the cause, tell people what changed, and keep going. Over time, widen the program carefully, moving more actions into the stronger tiers as users grow comfortable and as the strong factors become part of everyday habit.

Mistakes seen again and again

These stories are illustrative, built from common patterns, to show the ideas at work.

Most step-up problems come from a short list of causes. Check these first.

Testing step-up before and after launch

Treat every step-up rule like a small software release. Before launch, write down the test cases: a user with a strong factor, a user with only a weak factor, a user with no factor, a user on a managed device, a user on an unknown device, and a user whose last proof is just inside or just outside the freshness window. Run each case on each path into the app, including the dashboard tile, the direct link, and any mobile app. Record what you expected and what you saw.

After launch, repeat a short version of the same tests whenever you change a policy, add an app to a tier, or update the app’s own sign-in code. Many teams automate the app-side checks, so a developer change that accidentally stops verifying the token fails a test instead of reaching production. A few minutes of regular testing prevents the quiet failures that are hardest to notice, namely the ones where nothing breaks and protection simply disappears.

A repeatable troubleshooting routine