Multi-factor authentication was a huge step forward, but treating every sign-in the same way creates new problems.

What MFA means

MFA stands for Multi-Factor Authentication. It means proving who you are with more than one kind of evidence. The kinds of evidence are usually grouped into three families: something you know (a password), something you have (a phone or a security key), and something you are (a fingerprint or face). A password alone can be stolen, guessed, or leaked in a data breach. When a second kind of proof is added, a thief who only has the password is stopped at the door.

The problem with always asking

If MFA is switched on the old-fashioned way, the system asks for the second factor every time, for every person, in every situation. An employee sitting at a company laptop inside the office, on a trusted network, gets the same prompt as a stranger logging in from another continent. People get tired of this. Tired people approve prompts without looking, and attackers know it. This is the idea behind prompt bombing, also called MFA fatigue, where an attacker floods a victim with approval requests hoping the victim taps Approve just to make them stop.

The opposite problem: asking too little

Some teams respond to the annoyance by relaxing the rules everywhere. That is also dangerous. If MFA is only needed once a month, a stolen session or a stolen laptop can give an attacker a long window of free access. The goal is not more prompts or fewer prompts. The goal is the right number of prompts at the right moment.

Before diving in, let us define the words you will keep meeting in Okta documentation and in conversations with security teams.

Adaptive access in Okta is not one switch. It is a small set of cooperating pieces, each with its own job.

Why several policies instead of one

New learners often ask why Okta has so many different policy types. The reason is that a sign-in has several separate moments: opening a session with Okta itself, enrolling a new authenticator, and opening a specific application. Each moment needs different questions answered, so each has its own policy type. Keeping them separate also means you can change one without breaking the others.

Where adaptive decisions really happen

The adaptive magic mostly lives in the authentication policy, because that is where you attach conditions to each application. Each authentication policy is a list of rules. Every rule says: if the sign-in matches these conditions, then require this level of proof. Okta reads the rules in order and uses the first one that matches. A final catch-all rule exists at the bottom, so every sign-in always lands somewhere.

Context is the heart of the idea. Let us look at each kind of clue, what it tells you, and where it can mislead.

User and group

The simplest context is who is signing in. You can attach different rules to different groups, such as administrators, contractors, or finance staff. An administrator can change the whole company’s settings, so it is normal to ask more of them than of someone who only reads the cafeteria menu. Groups also let you roll out changes gradually to a pilot team first.

Network and location

Okta can evaluate where the request comes from using network zones. An IP zone lists specific addresses or ranges, such as your offices and your VPN exits. A dynamic zone can be based on countries, regions, or types of networks such as anonymising proxies and Tor exit nodes. Using a zone, you can say that sign-ins from inside the office are lower risk, and sign-ins through an anonymous proxy are blocked or challenged hard.

Device

Device context asks whether the laptop or phone is known and healthy. Okta can tell if a device is registered with Okta Verify, whether it is managed by your device management tool, and which platform it runs. A managed, encrypted, up-to-date company laptop is far more trustworthy than an unknown browser on a shared computer.

Behavior

Okta can compare the current sign-in with the user’s recent past. Out of the box, behaviors include a new device, a new IP address, a new city, a new country or state, and an impossible travel pattern known as velocity. For example, if a user signed in from Delhi an hour ago and now appears in another continent, no flight can explain it, so something is wrong.

Risk

Okta can combine many signals, including threat intelligence about known bad IP addresses, into a risk level of low, medium, or high. Rules can then say: if risk is high, require the strongest proof or deny. ThreatInsight, which looks at patterns of malicious activity across Okta’s customers, feeds into this picture and can stop suspicious traffic before it even reaches your users.

Application and time

The application itself is context too. A payroll system deserves a stricter rule than a company newsletter. The time of day can matter in some designs as well, although it is used less often because remote work makes working hours less predictable.

Let us follow a single sign-in from the moment the user types a username to the moment the application opens.

The journey in plain steps

When a user begins to sign in, Okta first identifies who they claim to be. Then it gathers the context: the IP address, the device information, the browser, and any signals from behavior detection and risk scoring. Next it finds the authentication policy assigned to the application the user wants. It walks through that policy’s rules from top to bottom. The first rule whose conditions match wins. That rule states which authenticators are acceptable, how many factors are needed, and how often the user must prove themselves again. Okta then challenges the user accordingly, and if the challenge is passed, it creates or extends a session and lets the user in.

flowchart TD
    A[User starts sign-in] --> B[Okta gathers context]
    B --> C{Matching rule found?}
    C -->|Rule 1 - Trusted device and zone| D[Light challenge or none]
    C -->|Rule 2 - New device or location| E[Two factors required]
    C -->|Rule 3 - High risk| F[Deny or strongest proof]
    C -->|Catch-all| G[Default secure challenge]
    D --> H[Session created]
    E --> H
    G --> H
    F --> I[Access blocked and logged]
        

Not all proof is equally strong. An adaptive policy only works well if you understand the ladder of strength.

The ladder of strength

At the bottom of the ladder sit passwords and SMS codes. Passwords can be phished or leaked. Text messages can be intercepted through SIM swapping, where an attacker tricks a mobile carrier into moving your number to their phone. In the middle sit push notifications and one-time codes from an app such as Okta Verify. These are much better, but a tired user can still approve a push they should not. At the top sit phishing-resistant methods such as FIDO2 security keys and passkeys, and Okta FastPass, which binds the sign-in to the real website address and to the device so a fake website cannot collect usable proof.

Constraints that shape the challenge

When you write a rule, you do not only choose a list of authenticators. You also describe constraints. You can require the user to prove possession of something, such as a device or key, or require user verification, which means a fingerprint, face, or PIN confirming that the right person, not just anyone holding the device, is present. You can require that the authenticator be phishing-resistant, and you can require that the key be stored in secure hardware on the device. Each added constraint raises the assurance and narrows the set of methods accepted.

Number challenge

One of the most useful defences against prompt bombing is the number challenge. Instead of a simple Approve button, the sign-in screen shows a short number, and the user must pick the same number on their phone. A person who is not actually sitting at the screen cannot know the right number, so a random approval from a flooded phone no longer works.

A trusted person on an untrusted device is still a risk. Device context closes that gap.

Why the device matters

Imagine a trusted employee signing in from a laptop that has not been updated for two years, has no disk encryption, and is shared with family. The password is right and the second factor is right, yet the machine itself may be infected with spyware. Checking the person without checking the machine leaves a hole. This is why modern access control treats the device as a first-class signal.

Registered versus managed

Two terms are often confused. A registered device is one that has Okta Verify installed and has been enrolled with Okta, so Okta can recognise it. A managed device is one that is also controlled by a device management tool, so your company can enforce settings and remove data if it is lost. Managed is the stronger statement. Okta can integrate with device management platforms so that a policy can say the device must be managed before access to a sensitive application is granted.

Device assurance policies

A device assurance policy lists what a healthy device looks like for each operating system. Typical items include a minimum operating system version, a screen lock being enabled, disk encryption being turned on, and a requirement that the device be secured in hardware where possible. Once defined, such a policy can be referenced from the rules of an authentication policy. If the device falls short, the rule can deny access or send the user to fix the problem first.

This is the part of Okta that notices when something feels different, even if every password and code is correct.

Learning what normal looks like

Behavior detection works by remembering. Okta keeps a record of where each user has recently signed in from, which devices they used, and which networks they came through. When a new sign-in arrives, Okta compares it with that history. If the city, the country, the device, or the IP address has never been seen before, Okta can flag it. You decide how far back the memory goes, so you can say that a location counts as familiar if it was seen within the last few weeks.

Risk scoring

Behavior is only one input. Okta can also weigh the reputation of the IP address, whether the request comes through an anonymising service, and other signals, and then produce a risk level. This is useful because it lets you write short, readable rules. Instead of listing a dozen conditions, you can say that high risk means deny, and medium risk means ask for stronger proof. The detail of how the score is built stays inside the platform.

ThreatInsight

ThreatInsight protects the front door before the user even gets to the question of proof. Okta sees an enormous volume of sign-in traffic across its customers, and it can spot IP addresses that are guessing passwords or testing stolen credentials at scale. When ThreatInsight is turned on, such traffic can be logged or blocked before it ever reaches your users’ accounts. It is especially valuable against credential stuffing, where attackers try millions of leaked username and password pairs against many websites.

Knowing the pieces is half the job. The other half is arranging them into rules that are clear, safe, and easy to maintain.

Think in tiers of applications

A common mistake is to build a unique policy for every application. This quickly becomes unmanageable. A better approach is to sort applications into a few tiers by how much damage a break-in could cause, and build one policy per tier. A typical set might be a low tier for general tools, a medium tier for business systems holding customer data, and a high tier for administration consoles, finance, and source code. Each tier has its own ladder of rules.

A sample rule ladder in words

For a medium-tier application, the rules might read like this from top to bottom. First, deny access if the network is an anonymising proxy or the risk level is high. Second, if the device is managed and registered and the location is familiar, allow with one strong factor and a longer re-authentication period. Third, if the device is new or the location is unfamiliar, require two factors including a possession factor with user verification. Fourth, the catch-all: require two factors with a short re-authentication period. Notice how the strictest rule sits at the top, the friendliest rule sits in the middle, and the catch-all is still secure.

Re-authentication frequency

Each rule also says how often the user must prove themselves again. A short interval protects against stolen sessions but annoys people. A long interval is smoother but leaves a bigger window for abuse. Pair the interval with the sensitivity of the application. A payroll approval screen might ask again every few hours, while an internal wiki might ask only once a day or even once per session.

The catch-all rule

The last rule in every policy matches everything the earlier rules did not. Many security gaps come from leaving this rule too relaxed. If the catch-all rule says any single factor is enough, then any sign-in that slips past your clever conditions will get the easiest treatment. Make the catch-all the safe default and let the earlier rules grant exceptions.

Let us see how these ideas play out in everyday situations an organisation actually faces.

sequenceDiagram
    participant U as User
    participant O as Okta
    participant A as Application
    U->>O: Sign-in request
    O->>O: Check device, zone, behavior, risk
    alt Low risk and trusted device
        O->>U: Light challenge
    else New device or location
        O->>U: Stronger challenge with verification
    else High risk
        O-->>U: Access denied
    end
    U->>O: Proof provided
    O->>A: Signed assertion and access
        

A sign-in is a single moment, but a session can last for hours. Risk can change during that time.

The gap after sign-in

Traditional access control checks the user at the door and then trusts them until the session ends. But a lot can happen in a day. A laptop can be infected after lunch. An employee can be fired in the afternoon. An attacker can steal a session cookie from a browser. If the system only checks at the moment of login, all of these events leave a gap where access continues unchecked.

Ways Okta narrows the gap

Okta offers several tools to narrow this gap. Short re-authentication intervals force fresh proof at regular times. Session lifetimes can be limited, so even a stolen session expires quickly. A capability called Universal Logout allows Okta and connected security tools to end a user’s sessions across supported applications at once when something looks wrong. Okta also supports sharing security signals with other products, so that a device management tool or a security platform can say that a device has become risky and trigger a response without waiting for the next login.

A policy you cannot observe is a policy you cannot trust. Visibility turns adaptive access into a living system.

The System Log

Okta records a detailed event for almost everything that happens: successful and failed sign-ins, factor challenges, policy evaluations, risk results, and administrative changes. This is called the System Log. Each event describes who did what, from which device and network, and what Okta decided. When a user complains that they were blocked, the log can show exactly which rule matched and why.

What to watch

A few measurements tell you most of what you need. Watch the rate of denied sign-ins and which rule is producing them. Watch how many challenges are issued per user per day to detect prompt fatigue. Watch spikes in failed attempts from certain networks or countries. Watch how many users are still relying on weaker methods such as SMS, so you can plan their move to stronger ones. And watch how often high-risk events occur and how fast your team responds.

Sending logs to a security platform

Most organisations stream the System Log into a central security monitoring platform. There, identity events can be combined with network and endpoint events to produce richer alerts. For example, a sign-in from a new country followed by unusual downloads from a cloud storage service tells a much clearer story than either event alone. Alerts can also trigger automation, such as opening a ticket or forcing a user to sign in again.

Reviewing policies regularly

Policies age. Offices move, VPN addresses change, new applications appear, and new attack techniques emerge. Schedule a regular review of your zones, rules, and device requirements, and remove exceptions that are no longer needed. Temporary exceptions that never get removed are one of the most common sources of quiet security weakness.

Many adaptive MFA projects fail not because the tools are weak, but because the design has avoidable flaws.

Technology is only half of a successful adaptive MFA programme. The other half is people, communication, and patience.

Why rollout deserves its own plan

Changing how thousands of people sign in is a big change to their daily routine. Even a perfectly designed policy can cause frustration if it arrives without warning. A staged rollout lets you learn from real behavior, fix surprises early, and build trust. It also gives the help desk time to prepare for the questions that will come.

graph LR
    A[Inventory apps and users] --> B[Define zones and device rules]
    B --> C[Enroll strong authenticators]
    C --> D[Pilot group]
    D --> E[Expand in waves]
    E --> F[Retire weak methods]
    F --> G[Review and improve]
    G --> B
        

Adaptive access is powerful but it is not magic. Understanding both sides helps you decide how far to go.

Okta Identity Engine and the Classic Engine

Organisations that have used Okta for many years may still run the Classic Engine, where sign-on rules are written inside a global sign-on policy and applications have their own sign-on rules. The newer Identity Engine separates these into the distinct policy types described in this guide, adds device assurance, and supports more flexible authenticator choices and passwordless journeys. If you are planning a modern adaptive design, the Identity Engine is the natural home for it, and a migration is a good moment to rethink your tiers and rules instead of copying old ones.

Adaptive access and zero trust

Zero trust is the idea that no request should be trusted just because of where it comes from. Every request is evaluated using identity, device, and context, each time. Adaptive MFA is one of the most practical ways to apply that idea to people signing in to applications. It replaces the old picture of a safe inside and a dangerous outside with a continuous, evidence-based decision.

No. It is a way of using Okta’s policies, zones, behavior detection, and risk signals together. Some of the more advanced features are tied to particular licenses, so check what your plan includes.

In safe, familiar situations, yes. In unfamiliar or risky situations they may be prompted more, and with stronger methods. The aim is a better match between risk and effort, not just fewer prompts.

Frequent travellers will trigger location signals. Design the response as a stronger challenge rather than a block, and consider allowing a registered, healthy device to ease the experience while abroad.

It is better than a password alone, but it is among the weakest options because of SIM swapping and interception. Use it only as a fallback and plan to move users to stronger authenticators.

It means the proof is cryptographically tied to the real website and cannot be captured by a fake one. Security keys, passkeys, and Okta FastPass are examples.

Yes. Authentication policies are assigned to applications, so different applications can have different rules. Many applications can also share one policy.

Pilot changes with a small group, keep emergency administrator accounts protected and excluded from risky rules, and review the System Log after each change.

No. You can set different rules for managed, registered, and unknown devices. Managed devices simply allow you to grant smoother access to more sensitive applications.

Partly. Short re-authentication intervals, limited session lifetimes, and Universal Logout help reduce the time a stolen session is useful, but the design should include monitoring and response too.

Start by enrolling users in Okta Verify, sort your applications into tiers, create network zones, and pilot one tiered authentication policy with a small group. Grow from there.

Adaptive MFA and context-based access change the question from whether someone should be challenged to how much proof this specific sign-in deserves. Okta answers that question by combining policies, network zones, device information, behavior detection, and risk signals into ordered rules that always end in a safe default. Done well, people in familiar and healthy situations move quickly, while unusual or dangerous attempts meet strong barriers or are blocked outright. The result is better security and a better user experience at the same time, supported by logs that explain every decision.