Before learning how risk scoring works, it helps to feel the problem it solves. The problem is a tug-of-war between safety and convenience.

The two simple choices, and why both disappoint

A company that wants to protect its systems has two simple choices. It can ask for strong proof every single time, for every person, in every situation. This is safe, but it is tiring. People sign in dozens of times a day, and constant prompts teach them to tap “approve” without thinking, which is exactly what attackers hope for. Or the company can ask for strong proof rarely, trusting the password most of the time. This is pleasant, but a stolen password then opens the door wide.

Neither extreme is right, because the situations are not equal. Signing in from your own managed laptop in your usual office is very different from signing in from an unknown device in a country you have never visited. A fair system should notice the difference.

What risk-based authentication changes

With a risk-based approach, the strength of the check follows the level of risk. When everything about a sign-in looks familiar, the person may pass with little friction. When something looks unusual, the system raises the bar: it may require a second factor, a stronger factor, or a fresh sign-in. When the signs are alarming, it may refuse the attempt altogether. Security effort is no longer a flat tax on everyone but a targeted response to real warning signs.

The honest promise and the honest limit

Risk scoring does not make sign-in perfectly safe. It is an estimate made from clues, and clues can mislead. A real employee on holiday may look suspicious. A clever attacker using a nearby network and a stolen device may look ordinary. The promise of risk-based authentication is not perfection but better aim: more of the extra effort lands on risky sign-ins and less on safe ones. This guide returns to this point many times, because good designs are built around it.

The word risk is used loosely in everyday talk. For a design to work, we need to say exactly what it is a risk of.

Risk as likelihood and impact

In security, risk combines two ideas: how likely something bad is, and how damaging it would be if it happened. A sign-in that is very likely to be fake but only opens a lunch-menu page carries little risk, because little can go wrong. A sign-in that is only slightly suspicious but opens the payroll system carries much more risk, because the possible damage is large. Good designs consider both halves.

This is why Okta policy has two sides. The signals about the sign-in describe the likelihood that it is not who it claims to be. The application and its sensitivity describe the impact. A rule written for the payroll system can be much stricter than one written for the lunch menu, even when the signals are identical.

What exactly are we afraid of?

Risk at sign-in and risk during the session

Risk is not only checked at the front door. A person can pass every check and then, ten minutes later, something changes: their session suddenly appears from a different country, or their device falls out of compliance. A thoughtful design therefore thinks about risk at two moments. The first is at sign-in, where the decision is whether to let the person in and with what proof. The second is during the session, where the decision is whether to keep trusting the session. Later chapters cover both.

flowchart LR
    L["Likelihood: how suspicious do the clues look?"] --> R["Risk"]
    I["Impact: how damaging if wrong?"] --> R
    R --> D["Decision: how much proof to demand"]
    

Every sign-in leaves a trail of small facts. On their own they say little. Together they paint a picture.

The main families of clues

A signal is a single fact about the sign-in that helps judge risk. Signals fall into a few families. Understanding the families makes it easy to understand any specific feature Okta offers.

Strong and weak clues

Not every clue is equally trustworthy. A strong signal is hard for an attacker to fake: for example, a device that proves it holds a secret key, or a sign-in that arrives through a company-managed secure channel. A weak signal is easy to fake or often wrong: for example, a location guessed from an internet address, which can be hidden by a VPN, or the name of the web browser, which any program can claim to be. Good designs weigh strong signals heavily and treat weak ones as hints, never as proof.

Many clues point in different directions. A score is a way to combine them into one simple summary the system can act on.

The basic recipe

A risk score is a number, or a short label such as low, medium, or high, produced by combining many signals. The basic recipe has three steps. First, each signal contributes some amount of suspicion or reassurance. Second, the contributions are added up, with more important signals counting for more. Third, the total is placed into a band, a range that maps to a risk level, such as “low” for small totals and “high” for large ones. The system then acts according to the band.

A teaching model you can reason with

Okta computes its own risk assessments internally, and the exact weights and methods are not something administrators set point by point. To help you think clearly, the table below shows an illustrative teaching model with made-up numbers. It is not Okta’s algorithm. It simply shows the logic of adding up clues.

flowchart LR
    S1["Signal 1: device"] --> SUM["Add contributions with weights"]
    S2["Signal 2: network"] --> SUM
    S3["Signal 3: location"] --> SUM
    S4["Signal 4: behavior"] --> SUM
    SUM --> B{"Which band?"}
    B -- "Low" --> LOW["Light check"]
    B -- "Medium" --> MED["Step-up proof"]
    B -- "High" --> HI["Deny or strongest proof"]
    

Bands and thresholds

The boundaries between bands are called thresholds. Setting a threshold is a choice between two kinds of mistakes. If the threshold for “high” is set too low, many honest sign-ins are treated as dangerous. These are false alarms, also called false positives. If it is set too high, real attacks slip through as ordinary. These are misses, or false negatives. No threshold removes both. Moving it only trades one for the other, which is why tuning is a continuing job, not a one-time setting.

Okta offers several features that gather clues, summarize them, or react to them. Knowing what each one contributes lets you assemble a design from parts you understand.

How the pieces relate

Think of the features as a team. Network zones and ThreatInsight look at where a sign-in comes from. Behavior detection looks at how it compares with the person’s past. Device features look at what machine is being used. The risk level summarizes some of these into a single condition. Risk provider integrations bring in outside opinions. Policy rules then decide what to do, and the System Log tells you what happened.

Putting it together, every risk-aware sign-in follows the same broad path: gather clues, judge, decide, act, and record. Seeing the path makes every later topic easier to place.

The path in six steps

The exact internal workings are Okta’s own, so treat this as a conceptual model. It is accurate enough to design policy and to explain behavior.

flowchart TD
    A["Sign-in attempt"] --> B["Gather signals: network, location, device, behavior, outside risk"]
    B --> C["Assess risk level"]
    C --> D{"First matching policy rule"}
    D -- "Low risk rule" --> E1["Allow with normal proof"]
    D -- "Medium risk rule" --> E2["Step-up: stronger or extra factor"]
    D -- "High risk rule" --> E3["Deny or require strongest proof"]
    E1 --> L["Record in System Log"]
    E2 --> L
    E3 --> L
    L --> T["Review and tune"]
    T -. "feedback" .-> D
    

The loop is the point

Notice the last arrow of the picture: results feed back into tuning. A risk design is not a switch you flip once. It is a loop. You release a policy, watch what it does, learn from the false alarms and the misses, and adjust. The most successful teams treat risk policy as a living thing with an owner, a review schedule, and a record of why each rule exists.

Every sign-in travels over a network and arrives from an internet address. That address is one of the oldest and most useful clues.

The internet address as a clue

An IP address is the number that identifies where internet traffic comes from, a bit like the return address on a letter. By itself it does not say who is typing. But it says a lot about the kind of place the traffic comes from: your own office, a home internet provider, a mobile phone carrier, a large cloud data center, or a service that deliberately hides the real origin.

Network zones

Okta lets you define network zones, which are named collections of network locations. A zone can be a list of your office addresses, the range used by your company VPN, a partner’s addresses, a list of countries, or a category of risky services. Policy rules can then say “if the sign-in comes from the office zone, ask for less; if it comes from the blocked zone, deny”. Zones are reusable, so one carefully built zone can power many rules.

Address reputation and ThreatInsight

Reputation means what is known about an address from past behavior. If an address has been used to try thousands of passwords against many organizations, it has a bad reputation. Okta ThreatInsight draws on sign-in activity across its customers to recognize such addresses. It can be set to only log what it would have done, which is a gentle way to learn, or to log and enforce, where it acts on the threat, for example by blocking the suspicious attempts. Starting in log-only mode and reviewing the results is a wise first step, as the next chapters discuss.

flowchart TD
    IP["Sign-in from an address"] --> Z{"Which zone does it match?"}
    Z -- "Office or VPN" --> F["Familiar: lower risk contribution"]
    Z -- "Partner" --> P["Expected: neutral"]
    Z -- "Anonymizer or proxy" --> A["Hidden origin: higher risk contribution"]
    Z -- "Blocked zone" --> B["Deny or strongest proof"]
    Z -- "Unknown" --> U["Neutral, rely on other signals"]
    

Pitfalls of network clues

• Shared addresses. Thousands of people may share one company or mobile carrier address. A bad actor on the same address can make an honest person look risky.
• Moving addresses. Home internet and mobile phones change addresses often, so “new address” alone is common and weak.
• VPNs and proxies. Many honest people use them for privacy or work. A rule that blocks all of them may punish good behavior.
• Cloud-hosted attackers. Attackers can rent addresses in respectable-looking data centers, or use home-internet addresses of infected computers, both of which are hard to flag.
• Stale lists. Office addresses change. An outdated zone can make your own staff look foreign.

If a person signs in from one city and, twenty minutes later, from a city on another continent, something is wrong. This simple idea is called velocity checking.

Geographic location

From the internet address, services can estimate a rough location: country, region, or city. This is not exact. Accuracy varies, and some addresses map to the location of the provider rather than the person. Still, even a rough location helps. A company with staff in three countries can reasonably treat a sign-in from a fourth, never-seen country as unusual.

Velocity: impossible travel

Velocity, in this context, means how fast a person appears to have travelled between two sign-ins. If the distance between the two places could not be covered in the time between them, even by plane, then at least one of the sign-ins is not from the real person. Okta’s behavior detection includes a velocity-style check that looks for travel faster than is realistic, which is often described as impossible travel.

sequenceDiagram
    participant U as Person
    participant O as Okta
    U->>O: Sign-in 1 from City A at 10:00
    O->>O: Record location and time
    U->>O: Sign-in 2 from City B at 10:20
    O->>O: Distance divided by time is too fast
    O-->>U: Treat as higher risk and ask for stronger proof
    

Why location clues mislead

Fair handling of travelers

Business travel is normal, so a good design plans for it. Instead of blocking new countries outright, many companies use location as a reason to ask for a stronger factor and not as a reason to refuse access. If a traveler can complete a strong, phishing-resistant check, the trip proceeds with a small delay, while an attacker who has only a password is stopped. Blocking is reserved for places where you have no legitimate business at all.

The strongest clue is often not what a sign-in looks like in general, but how it compares with this particular person’s past. Okta calls this behavior detection.

Building a baseline

A baseline is a picture of what is normal for someone. As a person signs in over days and weeks, Okta records which devices they use, which addresses and places they appear from, and which patterns they follow. After a period of learning, deviations from this baseline can be noticed. The same sign-in that is perfectly ordinary for one person can be unusual for another, which is exactly what a fair risk judgment needs.

The behaviors Okta can look for

How rules use behaviors

In Okta, behaviors are defined as named detections, and policy rules can use them as conditions: “if the behavior new device is detected, require a second factor”. You can often choose how sensitive the detection is, such as how long a device must be unseen before it counts as new. Combining several behaviors in one rule, such as “new device and new location”, makes the rule more precise because it demands two clues at once.

flowchart LR
    H["History: devices, places, patterns"] --> BL["Baseline for this person"]
    NEW["New sign-in"] --> CMP{"Compare with baseline"}
    BL --> CMP
    CMP -- "Matches" --> N["Normal: no extra signal"]
    CMP -- "Differs a little" --> M["Mild signal"]
    CMP -- "Differs a lot or in several ways" --> S["Strong signal"]
    

The new-person problem

A baseline needs history. A brand-new employee has none, so everything about their first sign-ins looks “new”. If your rule treats “new device” as risky, every new hire is challenged at first. That is not a bug, but you should expect it and design for it: new hires may need an enrollment step where they set up a strong factor in a trusted setting, such as the office or a supervised video call, so that their baseline starts from a trustworthy place.

Where a sign-in comes from matters, but so does what it comes on. The health and identity of the device are some of the most reliable clues available.

Known, managed, and healthy

A device can be described in three useful ways. It can be known, meaning it has been seen before or registered. It can be managed, meaning the company controls it through a device management system. And it can be healthy, meaning it meets requirements such as an up-to-date operating system, disk encryption, and a screen lock. A device that is known, managed, and healthy deserves more trust than an unknown one, and a rule can reflect that by asking for less from such devices.

Device assurance

Okta’s device assurance policies describe what a healthy device looks like, per operating system. Authentication policy rules can then require that a device meet that description. This turns a fuzzy question, “is this computer okay?”, into a clear rule: “only devices meeting this description may open the finance system”.

Device-bound proof

Some sign-in methods tie the proof to the device itself. Okta Verify supports a passwordless method, known as Okta FastPass, that relies on a secret key stored on the device. Because the secret never leaves the device and the proof is bound to the real website, such methods are difficult for an attacker to imitate from another machine, and they resist fake login pages. In risk terms, a successful device-bound sign-in is a strong, positive signal: it lowers the likelihood that the sign-in is fraudulent.

Context beyond the device

Other context also matters. Is the person using a browser or a native app? Are they signing in to a regular application or an administrator console? Are they using a company-approved path or a direct link? Each gives a hint. As always, context should be combined, never used alone.

Your own signals are only part of the picture. Other tools in your company, and other companies, know things Okta does not. Bringing their opinions in makes the picture richer.

What threat intelligence is

Threat intelligence is knowledge about attackers: which addresses are attacking, which kinds of devices are infected, which tricks are currently popular. Security companies and large platforms collect it. Okta ThreatInsight is an example built into Okta, using its view across many customer organizations.

Risk providers and shared signals

Your company probably runs other security tools: an endpoint protection tool on laptops, a mobile device management system, a tool that watches network traffic, a platform that detects suspicious behavior in cloud accounts. Each may notice danger that Okta cannot see. Okta supports ways for such tools to send their risk judgments into Okta, through risk provider integrations and through standard approaches for sharing security signals between systems. Once received, those judgments can be used by policy, for instance “if the endpoint tool says this laptop is infected, deny sign-in”.

flowchart LR
    EDR["Endpoint protection tool"] --> OK["Okta risk assessment"]
    MDM["Device management system"] --> OK
    NDR["Network monitoring tool"] --> OK
    TI["Threat intelligence feeds"] --> OK
    OK --> POL["Policy rules"]
    POL --> ACT["Allow, step up, deny, end sessions"]
    

The other direction

The flow can also go outward. When Okta sees something alarming, such as a confirmed account takeover, other systems should hear about it quickly: logs can be streamed to a central monitoring platform, alerts raised, and in modern setups, signals sent so that connected applications can end sessions or reduce access. A risk design works best when information moves in both directions, instead of each tool keeping its knowledge to itself.

A risk level means nothing until a rule acts on it. This chapter shows how to translate low, medium, and high risk into concrete decisions.

The shape of a risk-aware policy

A typical authentication policy for a sensitive application is a short list of rules, ordered from most specific and most dangerous to most general. The most dangerous situations come first, so they are caught before a broad “allow” rule can accept them. A common shape looks like this.

The menu of actions

Always provide a way forward

A well-designed policy leaves an honest person a path to continue. If a traveler is stepped up, they should be able to complete a strong factor. If a device is unhealthy, the message should say how to fix it. If a denial happens, the person should be told whom to contact. A system that only says “no” creates anger and workarounds, while one that explains and offers a route builds cooperation.

flowchart TD
    A["Sign-in to sensitive app"] --> R1{"Blocked zone or high risk?"}
    R1 -- "Yes" --> D["Deny and log"]
    R1 -- "No" --> R2{"Medium risk or several new signals?"}
    R2 -- "Yes" --> S["Require phishing-resistant factor"]
    R2 -- "No" --> R3{"Managed, healthy device?"}
    R3 -- "No" --> M["Require MFA, short session"]
    R3 -- "Yes" --> OK["Allow with standard proof"]
    

Step-up is the most common response to medium risk. It means asking for more proof, but only when the situation justifies it.

What step-up means

A person who has already signed in with a password and a basic second factor may be asked to prove themselves again, or in a stronger way, when they try something riskier or when their situation looks unusual. This extra proof is called step-up authentication. The name captures the idea: the person steps up to a higher level of assurance before being allowed further.

Not all factors are equal

A factor is a kind of proof. Factors differ in how hard they are for an attacker to steal, trick, or imitate. Understanding the ladder helps you choose the right step.

Matching the step to the risk

The logic is simple: the higher the risk, the higher up the ladder you ask the person to climb. For mild unusualness, a push approval with number matching may be enough. For stronger unusualness, or for very sensitive applications, require a phishing-resistant method. This keeps everyday life light and puts the heavy proof where it counts.

flowchart TD
    R["Risk level and app sensitivity"] --> Q{"How high?"}
    Q -- "Low" --> A["Existing session or simple second factor"]
    Q -- "Medium" --> B["Push with number matching or code"]
    Q -- "High" --> C["Phishing-resistant factor"]
    Q -- "Critical" --> D["Deny, or strongest factor plus approval"]
    

Re-authentication timing

Step-up also involves when to ask. Rules can require fresh proof after a set period, for example every few hours for a sensitive application, or every sign-in for the most critical one. Short intervals protect against stolen sessions but add friction. Pick the interval to match the sensitivity of the application, not a single number for everything.

The same risk level should lead to different actions in different applications. Sorting your applications by how much damage they could cause is the other half of a good design.

Tier your applications

Not all applications are equally important. A company canteen menu, an expense tool, a customer database, and a production cloud console are very different. Group applications into tiers by the damage a misuse could cause, and attach a matching authentication policy to each tier. A small number of tiers, perhaps three or four, is easier to manage than a custom policy for every application.

The matrix: risk level against application tier

Why a matrix beats a one-size rule

Without a matrix, teams tend to drift to one of two bad extremes: a single strict rule that frustrates everyone, or a single loose rule that under-protects the crown jewels. The matrix gives each cell a deliberate answer, makes discussions concrete, and gives reviewers something to check. It also reveals gaps, for example an application that has no tier at all.

Passing the front door check is not the end of the story. Sessions last for hours, and the situation can change while they run.

Why a one-time check is not enough

Consider what can happen after a successful sign-in. An attacker may steal the session, for example through malicious software or a fake page that relays the person’s login in real time. The person’s laptop may become infected. Their device may stop meeting health requirements. A partner tool may flag the account. If risk is only judged at the moment of sign-in, all of these go unnoticed until the session ends.

Reassessing during the session

Continuous risk evaluation means that risk is assessed again while the session continues, using new signals as they arrive. Okta’s newer identity threat protection capabilities aim to do this: they watch for changes in risk during active sessions and can respond, for example by asking for a fresh check, by ending the session, or by telling connected applications to do so. A related capability, Universal Logout, lets Okta ask supported applications to end a person’s sessions across the board when danger appears. Availability depends on your license and on whether each application supports the necessary integration.

sequenceDiagram
    participant P as Person
    participant O as Okta
    participant A as Connected app
    participant S as Security tool
    P->>O: Sign in, risk judged low
    O-->>P: Session starts
    P->>A: Works in app
    S->>O: Alert: device now suspected infected
    O->>O: Raise risk for this session
    O->>A: Ask app to end sessions for this person
    A-->>P: Session ended, sign in again
    

Session length and token lifetimes

Even without advanced tools, simple settings reduce exposure. Shorter session lifetimes limit how long a stolen session is useful. Shorter lifetimes for access tokens, the small digital passes applications use, limit the damage from a stolen token. Re-authentication requirements for sensitive actions, such as changing payment details, add another check at the exact moment when it matters most. These measures cost some convenience, so apply them in proportion to the sensitivity of the application.

Some accounts are worth far more to an attacker than others. Risk policy should reflect that and ask more of them.

Why administrators are special

An administrator account can change settings, create accounts, and reach sensitive data. Taking one over gives an attacker leverage over the whole organization. Attackers know this and target administrators with the most persuasive tricks. Risk policy should therefore treat an administrator’s sign-in more strictly than an ordinary user’s, at every risk level.

A stricter profile

• Always phishing-resistant. Require a device-bound or hardware method for administrator access, not just at medium risk but always.
• Managed devices only. Admin consoles should open only from managed, healthy devices, ideally dedicated machines.
• Tighter locations. Limit administrator sign-ins to known networks or require stronger checks from anywhere else.
• Shorter sessions. Require fresh authentication for administrator work more often.
• Immediate alerts. Notify the security team whenever an administrator signs in from an unusual place or device.
• Separate identities. Use a separate admin account distinct from the everyday account, so that email-based tricks do not reach admin power.

Do not lock yourself out

Strict administrator rules carry a danger of their own: you might block the very people who can fix problems. Keep a tested emergency path, a break-glass account, with strong protection, clear ownership, and alerts on every use. Test it regularly, and make sure at least two trusted people can use it. Plan this before tightening anything.

No risk design is right on the first day. Calibration is the patient work of adjusting it until it fits your people, your places, and your attackers.

What you are tuning

You cannot reweight Okta’s internal assessment point by point, but you control a great deal around it: which behaviors are enabled and how sensitive they are, which zones exist and what they contain, which conditions you combine in each rule, which actions follow each level, and how long sessions last. Calibration means adjusting those controls based on evidence.

The evidence to collect

A tuning loop

Beware of tuning to quiet

A natural temptation is to loosen a rule whenever people complain. Complaints are real and valuable, but a perfectly quiet system might simply be one that checks nothing. Balance the loud signal of complaints with the quiet signal of missed attacks. Where possible, review samples of both challenged and unchallenged sign-ins, and look for attacks that passed without notice.

A risk rule that goes wrong can lock out honest people or leave doors open. Test before you trust.

Learn first, enforce later

The gentlest way to start is to observe before enforcing. Several Okta features can run in a mode that only logs what they would have done. ThreatInsight can be set to log without acting. Policies can be created in an inactive state, or applied to a small test group. Review the logs for a week or two and ask: how many sign-ins would this have affected, and were they honest or hostile? Only then turn on enforcement.

Test with personas

Create pretend users who represent real situations: a regular office worker, a remote worker, a frequent traveler, a new hire with no history, a contractor, an administrator, and a person with a lost factor. Predict, in writing, what should happen to each under the new rule, then try each and compare. Surprises are findings. Include negative cases that should be refused, and boundary cases such as a person in two groups.

Use a test org and staged rollout

Where your agreement allows, rehearse in a separate preview or test org first, so mistakes affect nobody real. Then release to production in rings: your own security team, a group of volunteers, one department, one region, and finally everyone, with a health check and a rollback plan at each step. Use the policy simulation tool in the Admin Console, where available in your org, to see which rule would match a described situation without needing a real sign-in.

flowchart LR
    O["Observe in log-only mode"] --> P["Persona tests in test org"]
    P --> R1["Ring 1: security team"]
    R1 --> R2["Ring 2: volunteers"]
    R2 --> R3["Ring 3: one department"]
    R3 --> R4["Ring 4: everyone"]
    R4 --> M["Monitor and tune"]
    

To design good rules, it helps to know the tricks they must stop. Each attack leaves its own trail of clues.

Credential stuffing

When a website’s passwords leak, attackers try the stolen pairs of usernames and passwords on many other services, betting that people reuse passwords. This is credential stuffing. It is automated and fast. The clues: many attempts from a small set of addresses, many different usernames, a high failure rate, and addresses that appear in threat intelligence. ThreatInsight and rate limiting are aimed squarely at this pattern.

Password spraying

In password spraying, the attacker tries one or two very common passwords against a huge number of accounts, deliberately going slowly so no single account is locked. The clues are spread out: a few failures per account, but across the whole company, often from related addresses. Detecting it needs a view across accounts, not just per-account lockout rules.

MFA fatigue

With a stolen password in hand, the attacker triggers push prompt after push prompt, hoping the real person will approve one out of annoyance or confusion. The clues: many prompts to one person in a short time, prompts at odd hours, and approvals followed by a sign-in from an unfamiliar place. Number matching, rate limits, and alerts on bursts of prompts reduce this risk.

Phishing and adversary-in-the-middle

A fake login page copies the real one. In the simple version it steals the password. In the more advanced adversary-in-the-middle version, the fake page also relays the person’s one-time code to the real site in real time and steals the resulting session. The clues are subtle: a sign-in from an address unlike the person’s, a new device, or a session that suddenly appears elsewhere. The best defense is not a score but a method that cannot be relayed: phishing-resistant factors tied to the true website address.

Session theft

Malware or a malicious browser extension can copy a valid session and use it from another machine. The clues: the same session suddenly appearing from a different place or device, or a sudden jump in risk signals during a session. Continuous risk evaluation and short sessions address this.

Risk scoring is valuable, and it is not magic. Understanding how it can be fooled keeps you from relying on it too much.

How attackers try to look normal

• Residential proxies. Attackers rent home-internet addresses in the victim’s own city, so the location and network look ordinary.
• Stolen devices and sessions. If the attacker has the victim’s actual device or session, many device and behavior signals look perfect.
• Slow and low. Spreading attempts across time and addresses keeps each one below the threshold.
• Mimicking habits. Patient attackers watch a victim and sign in during normal hours from a familiar place.
• Poisoning the baseline. One successful intrusion can teach the system that the attacker’s device is normal.
• Targeting the human. Phone calls to the help desk, pretending to be a locked-out employee, bypass the technical signals completely.

What to do about the limits

flowchart TD
    ATT["Attacker"] --> L1["Layer 1: network and threat intelligence"]
    L1 --> L2["Layer 2: device and behavior signals"]
    L2 --> L3["Layer 3: strong, unrelayable factor"]
    L3 --> L4["Layer 4: continuous risk and short sessions"]
    L4 --> L5["Layer 5: monitoring and response"]
    

An honest summary of what scoring can claim

Risk scoring can make most attacks harder and noisier. It can reduce the number of unnecessary prompts. It can focus your attention. It cannot guarantee that no attacker gets through, and it should never be presented to leaders as a complete answer. Setting honest expectations early protects both the program and the people running it.

Every prompt costs a little patience. A thoughtful design spends that patience carefully, where it buys the most protection.

The friction budget

Think of each person as having a limited friction budget, an amount of interruption they will tolerate before they start looking for ways around the system. Spend it on risky moments, and people accept it. Spend it on routine moments, and they stop paying attention, tap approve automatically, or complain loudly. Risk-based authentication is, in essence, a tool for spending the friction budget wisely.

Make the prompts understandable

• Explain why. A short line such as “We noticed a new device, so we need an extra check” turns confusion into understanding.
• Offer a clear next step. Show exactly what to do, and which options are allowed.
• Avoid dead ends. A person with a lost phone needs a recovery route, not a loop.
• Keep messages calm. Alarming language makes people panic or ignore it.
• Teach the reflex. Tell staff that if they get a prompt they did not start, they should deny it and report it.

Accessibility and inclusion

Not everyone can use every method. Some people cannot use a phone app, have no mobile signal at work, wear gloves in a factory, use assistive technology, or share a computer. A fair design provides several strong methods, and does not assume one kind of device or ability. Test prompts with a wide variety of users, not only the technical team.

Risk scoring looks at people’s behavior and locations. That deserves care, honesty, and respect for rules and for the people affected.

Data minimization

Risk systems collect information such as approximate location, device details, and sign-in history. Privacy laws in many regions, for example the European Union’s General Data Protection Regulation, expect organizations to collect only what they need, keep it only as long as needed, protect it, and be open about its use. Review which signals you actually rely on, avoid collecting extra detail “just in case”, and set sensible retention limits for logs.

Transparency

Employees and, where relevant, customers should know that sign-ins are assessed for risk, what kinds of information are used, and why. Many organizations describe this in an acceptable-use policy or privacy notice. Transparency builds trust and makes people more cooperative when they are challenged.

Fairness and unintended bias

Signals can affect groups of people unequally without anyone intending it. For example, a rule that distrusts sign-ins from certain countries will burden staff who travel there or who come from there. A rule that distrusts unknown devices may burden contractors or lower-paid staff who use personal equipment. Rules that rely on mobile phone prompts may disadvantage people without suitable phones. Watch for patterns in who gets challenged or blocked, and ask whether the cause is real risk or an accident of design.

A risk design that nobody watches decays. Monitoring is how you notice drift, attacks, and annoyance before they become crises.

The System Log as your evidence

Okta’s System Log records sign-ins, policy decisions, factor prompts, failures, and administrator changes, along with context about the attempt. It is the source for almost everything in this chapter. Because retention is limited and depends on your plan, stream logs to a central monitoring platform if you need long-term history, correlation with other tools, or alerting.

Key measures

flowchart LR
    SL["Okta System Log"] --> ST["Stream to monitoring platform"]
    ST --> DB["Dashboards: challenge rate, pass rate, denials"]
    ST --> AL["Alerts: bursts of failures, prompt floods, admin anomalies"]
    ST --> IN["Investigation and reports"]
    DB --> TU["Tuning decisions"]
    AL --> RE["Response actions"]
    

Alerts worth having

• A sharp rise in failed sign-ins for one application or from one address range.
• A burst of push prompts to one person, or many prompts across the company.
• An administrator signing in from an unusual place or device.
• A successful sign-in immediately after many failures for the same account.
• A change to risk-related policy, zones, or behavior settings by anyone.
• Use of an emergency account.
• A jump in help desk tickets mentioning sign-in prompts.

Review rhythms

Set a rhythm. Look at dashboards weekly. Review a sample of challenged and unchallenged sign-ins monthly. Run a full policy review each quarter, comparing the design with current attack trends and business changes such as new offices, mergers, or new applications. Record decisions in a short log so that the reasons survive staff changes.

Risk decisions depend on information arriving on time. Plan for the days when it does not.

What can go wrong with signals

Signals come from many places: Okta’s own detection, device management tools, partner security products, and your network configuration. Any of them can become unavailable, slow, or wrong. A device management tool might be offline, so Okta cannot tell whether a device is managed. A partner risk feed might stop sending updates. An address list might be out of date. Each failure forces a choice, because the system must still decide what to do.

Fail open or fail closed?

When a signal is missing, the design must decide between two behaviors. Failing closed means treating missing information as risky and asking for more proof or denying access. This is safer, but can cause outages and frustration. Failing open means treating missing information as neutral and continuing. This keeps people working, but may let attackers through while a signal is down. The right choice depends on the application: be stricter for critical systems and more forgiving for low-value ones.

Keep the lifeline

Strict failure behavior only works if you keep a safe emergency path. Maintain tested break-glass accounts, document how to reach them, and rehearse their use. Know where to check Okta’s service status. Prepare user messages in advance so that people hear a clear explanation, rather than rumors, when something is wrong.

flowchart TD
    S["Signal source unavailable"] --> T{"App tier?"}
    T -- "Low" --> O["Fail open, log the gap"]
    T -- "Moderate" --> M["Require standard MFA"]
    T -- "High or critical" --> C["Require strongest factor or deny"]
    O --> A["Alert operations team"]
    M --> A
    C --> A
    

Walking through failures on paper is cheaper than meeting them live. These are the scenarios risk-based designs meet most often.

Scenario 1: a wave of honest people is challenged

After a change, many staff are suddenly asked for extra proof. Causes include a rule that became too sensitive, an office whose internet addresses changed so everyone looks “new”, or a zone that was edited wrongly. Check the System Log for the common factor among the challenged sign-ins, look at recent changes to rules and zones, and correct the cause. Tell staff what happened in plain words.

Scenario 2: an attack passes quietly

An account is taken over and nothing was challenged. Review the sign-in record to find which signals looked normal. The attacker may have used a nearby proxy, a stolen session, or a baseline that learned the attacker’s device. Contain first: end sessions, reset credentials and factors, remove the attacker’s device from the trusted list. Then improve the design, for example by requiring a phishing-resistant method for the affected application tier.

Scenario 3: a device management feed stops

Okta can no longer confirm that devices are managed. Depending on your failure choices, people may be stepped up or blocked. Restore the feed, and meanwhile decide whether to temporarily relax rules for low tiers while keeping strict rules for critical ones. Document each exception and remove it afterward.

Scenario 4: ThreatInsight or a zone blocks a legitimate partner

A partner’s staff are suddenly refused. Their shared address was flagged or sits in a blocked range. Confirm with the log, add the partner address to a trusted zone with care, and verify that this does not weaken protections more widely. Agree with the partner on a stable list of addresses for the future.

Scenario 5: prompt flood against one person

An attacker with a stolen password triggers repeated push prompts to an employee. Contact the person, confirm they did not approve anything, reset the password and review sign-ins, and tighten prompt limits and number matching. Use the event to remind all staff to deny unexpected prompts and report them.

flowchart TD
    I["Incident noticed"] --> Q1{"Honest users affected?"}
    Q1 -- "Yes" --> F1["Find the common factor, check recent changes, correct rule or zone"]
    Q1 -- "No" --> Q2{"Attack suspected?"}
    Q2 -- "Yes" --> F2["Contain: end sessions, reset credentials and trusted devices"]
    Q2 -- "No" --> F3["Check signal sources and service status"]
    F1 --> V["Verify with test personas and record lessons"]
    F2 --> V
    F3 --> V
    

Patterns are proven shapes for common problems. These ones appear again and again in well-run organizations.

The ladder in practice

The risk ladder pattern is the one most teams start with, so it is worth seeing in full. It defines, ahead of time, what each rung means. This pre-decision makes behavior predictable, simplifies explanations to staff, and gives auditors a clear statement of the control.

flowchart LR
    R0["Rung 0: trusted"] --> A0["Minimal friction"]
    R1["Rung 1: slightly unusual"] --> A1["Second factor with number matching"]
    R2["Rung 2: clearly unusual"] --> A2["Phishing-resistant factor, short session"]
    R3["Rung 3: dangerous"] --> A3["Deny, alert, review"]
    

These are common, tempting mistakes. Spotting them early saves months of trouble.

Risk-based design is powerful, but it is not free. Seeing both sides lets you adopt it with open eyes.

Key trade-offs in detail

If you remember only a few habits from this guide, make them these.

Best practices

Common mistakes

• Assuming a score is a fact. It is an estimate that can be wrong either way.
• Forgetting new hires and travelers. They have little history or unusual locations, and will be challenged first.
• Ignoring service accounts. Rules built for people can break automation silently.
• Editing shared zones carelessly. One edit can change many rules at once.
• Skipping the help desk. They see problems before dashboards do.
• Neglecting privacy. Collecting and keeping more behavior data than needed creates duties and risks.
• Declaring victory. A quiet period does not prove the design is perfect.

Let us design a risk-based policy for a made-up payments company, Northwind Pay, with five thousand employees. All names and numbers are invented for teaching.

Starting point

Northwind staff sign in with a password and a phone prompt. Two accounts were recently taken over after staff approved unexpected prompts. Auditors want stronger control over the payment console. Staff complain about too many prompts in the office. The company has managed laptops for most staff, many travelers, and a contractor workforce on personal devices.

Applications by tier

The design

flowchart TD
    A["Sign-in"] --> B{"Blocked zone or high risk?"}
    B -- "Yes" --> DEN["Deny, alert security"]
    B -- "No" --> C{"App tier 4?"}
    C -- "Yes" --> D{"Managed, healthy device with device-bound proof?"}
    D -- "Yes" --> OK4["Allow, short session"]
    D -- "No" --> DEN4["Deny"]
    C -- "No" --> E{"Medium risk or new device plus new place?"}
    E -- "Yes" --> S["Phishing-resistant factor"]
    E -- "No" --> F{"Managed, healthy device?"}
    F -- "Yes" --> OK["Allow, longer session"]
    F -- "No" --> M["MFA with number matching, shorter session"]
    

The result

After four months, office staff on managed laptops are rarely prompted, which pleases them. Unusual sign-ins meet a strong factor that cannot be relayed from a fake page. The payment console opens only from managed, healthy devices. Prompt-flood attempts trigger alerts within minutes. Auditors receive clear evidence of the control. No single clever feature did this: it was tiering, strong factors, careful observation, staged rollout, and steady tuning.

When someone asks, “Why was I challenged?” or “Why was that attacker not stopped?”, a calm method finds the answer.

Risk-based authentication spends effort where danger is real, and leaves trusted moments smooth.