Capability

Adaptive policy

What it does: Raises the bar when a sign-in or session looks unusual.

WICCIC

In short

Adaptive policy changes what a sign-in requires, depending on the risk. A familiar user on a known device passes with less friction, while an unusual request meets a stronger factor or is denied.124

Book a callHow Okta and Auth0 do it ↓
5
attack types it helps against

What it is, and the attacks it stops

One fixed rule is either too strict for everyday sign-ins or too loose for unusual ones, so either users get annoyed, or attackers go unchallenged.

Adaptive policy evaluates the context of each sign-in, such as network, device or behavior, and applies the requirement that fits.234 NIS2 Article 21(2)(j) lists the use of multi-factor authentication or continuous authentication solutions among the cybersecurity risk-management measures, where appropriate.6

That flexibility helps against situations such as:

1

Sign-ins from unusual locations

A correct password is used from a country or network where the user never works.

2

Leaked passwords tried from a new device

An attacker tries a password from another breach on a device and network the user has never used.

3

Impossible travel

The same account signs in from two distant places within a short time.

4

Sign-ins at unusual times or in unusual patterns

An account that is normally active during office hours suddenly signs in at night and opens many apps.

5

Push fatigue (repeated approval requests)

An attacker with a stolen password triggers prompts until someone taps yes. Adaptive policy can ask for a stronger factor than push when a sign-in looks unusual.

Before and after rollout

Without
With
WithoutEvery sign-in gets the same requirement.
WithThe requirement follows the risk of the sign-in.12
WithoutA sign-in from a new country looks the same as one from the office.
WithConditions such as network zone or behavior can be used in policy rules.37
WithoutUsers are prompted constantly, so they stop paying attention.
WithLower-risk sign-ins can pass with fewer prompts, and stronger factors are kept for riskier ones.1
WithoutCustomer sign-ins are all handled the same way.
WithAuth0 Adaptive MFA can assess risk signals and ask for a second factor when needed. It is available on Auth0 Enterprise plans as an add-on.45

How Okta and Auth0 do it

Okta and Auth0 work in a similar way - they evaluate signals at sign-in and apply the rule that matches.24

1

The user starts a sign-in

A user or customer signs in to an app protected by Okta or Auth0.

2

The context is evaluated

Okta evaluates policy conditions, such as network zone and behavior, as well as risk signals.347

3

A rule matches

In Okta, the first matching rule in the app sign-in policy sets the requirement.2

4

The requirement applies

The outcome can be access, a stronger factor, or denial - depending on how the admin configured the rule.24

WIC
Who it protectsStaff, contractors, admins
App sign-in policiesRules for each app that set the conditions and the factors required.2
Network zonesDefine trusted and untrusted networks that policy rules can use as a condition.7
Behavior detectionCompares a sign-in with the user's usual behavior, and the result can be used in a rule.3
Adaptive MFAOkta Adaptive MFA asks for stronger factors when the risk is higher.1
CIC
Who it protectsYour app's users
Adaptive MFAAuth0 Adaptive MFA can assess the risk of a sign-in and ask for MFA when risk signals appear. It is available on Auth0 Enterprise plans as an add-on.4
Risk signalsAuth0 can evaluate signals such as a new device, impossible travel or an untrusted IP address.4
MFA factorsAuth0 supports several MFA factors that a customer can be asked for.5

How Zelto implements it

Okta and Auth0 provide the conditions and rules - Zelto works out with you which signals your users produce in daily work and which response fits each one. We start from how your users sign in today and tighten the rules in steps, to minimize risk/impact.

Typical rollout

  1. Map normal sign-in patterns

    We list the locations, networks, devices and working hours that are normal for each group.

  2. Define risk levels and responses

    With your security team we agree which signals count as higher risk and what each one requires: nothing extra, a stronger factor or denial.

  3. Pilot with admins and IT

    We start with admins and IT, and review which sign-ins trigger a rule and whether the trigger was justified.

  4. Roll out one group at a time

    Each app and group gets its own policy rule in Okta, and customers get rules in Auth0. Your help desk gets a script for users who are challenged.

  5. Tune and review

    We adjust the rules based on false alarms, and we review exceptions on a schedule.

Pitfalls we plan for

Employees travel or work from home.

−Block every sign-in from outside the office network, so legitimate users are locked out.

+Ask for a stronger factor in unfamiliar locations, and keep denial for the highest-risk conditions.

Rules are added over time by different admins.

−Add a new rule for each complaint until nobody knows which rule applies.

+Keep the rules few and in a clear order, with a named owner, and review the whole policy on a schedule.

A weaker factor is allowed when the strong factor is unavailable.

−Let a sign-in that failed the risk check continue with a weaker factor - attackers then ask for exactly that.

+Keep the same level of requirement for the fallback, or send the user to a recovery process that verifies who they are.

Customers get challenged too often.

−Ask every customer for a second factor at every sign-in, so some stop using the app.

+Challenge on risk signals, and tune the rules with the product team based on what the sign-in data shows.

Want sign-in rules that follow risk instead of one fixed policy?

We review how your staff and customers sign in today and which conditions you could use. Then we tell you what to change first.

Book a call30 minutes, no slides. We look at your sign-in policies today.

Related blog posts

Notes from rollouts

Z Is For Zero Trust: Revalidate Access ContinuouslyRead on the blog →

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Okta Adaptive MFAokta.com product page
  2. 2About app sign-in policiesOkta Help Center
  3. 3About behavior detectionOkta Help Center
  4. 4Adaptive MFAAuth0 Docs
  5. 5Multi-factor authenticationAuth0 Docs
  6. 6Directive (EU) 2022/2555 (NIS2)EUR-Lex
  7. 7Network zonesOkta Help Center