Okta Adaptive MFA and risk-based sign-on: is it on, and is anything using it?

What risk-based authentication actually does

When your subscription includes risk-based authentication (part of the Adaptive MFA family), Okta's risk engine evaluates every sign-in — IP reputation, the user's behavioral baseline, sign-in history, and routing signals — and assigns a Low, Medium, or High risk level. The intent is simple and good: a routine sign-in stays frictionless, and a suspicious one gets challenged, stepped up, or denied. It is exactly the kind of adaptive control that stops credential stuffing and account takeover without punishing everyone else.

The default that makes it do nothing

Here is the catch. Policy rules only act on that risk score through the "Risk is" condition, and that condition defaults to Any. Out of the box, a sign-in Okta itself flagged High risk is granted access under exactly the same requirements as a routine one. The engine is scoring every attempt; nothing is listening to the verdict. You can own Adaptive MFA, have the risk engine running, and still be paying the evaluation cost while discarding the result — all because one dropdown was never changed from Any to High. One step-up rule scoped to High risk converts that wasted signal into a real control.

Why this is hard to catch by eye

A feature list will tell you Adaptive MFA is licensed. The Admin Console will show the "Risk is" dropdown in every rule editor. Neither tells you whether a single active policy actually sets it to something other than Any across your Global Session and app sign-on rules. That answer is spread across every rule in every policy, and it changes every time someone edits one. It is precisely the kind of thing a deterministic pass over the live configuration is good at and a human audit tends to miss.

License-aware by design

This is where an assessment has to be careful, and where a static checklist gets it wrong. The "Risk is" condition renders in every org's rule editor whether or not the org is entitled to risk scoring. If your subscription does not include it, setting that condition does nothing, so telling you to configure it would be bad advice. So we detect the entitlement first, read-only: Okta's Behavior Detection API returns access when your subscription evaluates risk and a permission error when it does not, which is a reliable signal for whether risk scoring is actually available to your org. From there the assessment adapts:

If you are licensed and no policy uses risk, we call it out — you are paying for the engine and not acting on it. If you are not licensed, we do not flag a broken control that cannot exist; instead we explain what risk-based authentication would buy you and let you decide whether it is worth the tier. And if a policy already uses risk, we confirm it and check the high-risk path actually steps up to strong authentication rather than quietly allowing access. Same product, different answer per org, every scan.

Why it matters more every quarter

The number of non-human identities and automated agents signing in is climbing fast, and they are exactly the population where a risk signal earns its keep. A stolen credential replayed from an anomalous location, a burst of velocity no human could produce, a new device on a service account — these are the patterns risk scoring is built to catch. If the engine is running and no policy listens, that protection is theoretical. Turning the verdict into a rule is one of the cheapest security upgrades available to an org that has already paid for it.

Owning a control and enforcing it are different things. Atomation tells you which one you have. See it on your own org — the demo is open, no signup:demo.atomation.io.