Adaptive rules for admin accounts
You can customize rules for your adaptive access policy to define appropriate actions based on online behavior: block access, ask for second factors, or let admins skip MFA in trusted contexts.

Blocking rules
Adaptive rules allow you to create blocking rules to deny registration and authentication from specific IP addresses, geographic locations, or in case of certain detected threats.
You can configure restricted geographical locations on a city, state, or country level.

Configuring blocking rules
Once a geo-location or a subnet is blocked, step-up or step-down rules can't be applied to their lower-level locations or subnets, since they are also blocked.
You can provide exceptions to your blocking rule when it would take longer to list all the restricted IP addresses or geo-locations.
Block detected risky behaviors
Adaptive rules also allow you to take on online behaviors that can't be as easily pinpointed as malicious IP addresses.
Depending on your security practices, you can choose to block the following suspicious behaviors:
Anonymous proxy / Tor
This feature detects requests coming from anonymous proxy servers or Tor exit nodes. When enabled as part of a blocking rule, Anonymous proxy / Tor detection allows access to your applications only for those users whose online presence can be traced back.
Bot detection
As part of a blocking rule, bot detection shields your applications from unwanted online traffic. It examines requests coming your way to determine if a bot is trying to access your application by:
- grading the request based on its likelihood of coming from a non-human actor AND
- checking if there’s any known fraudulent activity associated with the IP address
It's up to you to decide how close you want to hold your online traffic up to scrutiny:
- Block only highest risk scores Normal protection that blocks any activity that has the highest chance of coming from a non-human actor. This level of bot detection has a lower probability of blocking legitimate user activity.
- Block high and highest risk scores Advanced protection which is capable of blocking traffic from a lower risk tier. This level of bot detection can cause false positives meaning some legitimate user activity can be blocked.
Step-up rules
Similar to blocking rules, you can choose to step up certain online behaviors depending on your security needs.
You can apply step-up rules in situations where you don't want device recognition to activate and would instead ask for an additional factor from admins to mitigate risks.

Configuring step-up rules
You can apply step-up rules to bypass device recognition in case of specified geographical locations or IP addresses.
Step up detected risky behaviors
You can add extra layers of protection to your applications by stepping up login attempts that appear to be out of the ordinary:
Improbable travel event
An improbable travel event is when someone logs into an account from a location it’s impossible to be at since their last login.
Improbable travel may be a sign of an account takeover. To mitigate the risk of account takeover fraud, you can ask for an additional factor when an improbable travel event is detected.
This way, you allow admins to easily verify a legitimate login without compromising their experience.
Anonymous proxy / Tor
You can choose to step up users who access your applications from behind an anonymous proxy server or Tor exit node.
When enabled as part of a step-up rule, Anonymous proxy / Tor detection will ask for an additional factor of authentication to alleviate account takeover fraud.
Bot detection
As part of a step-up rule, bot detection helps you steer clear of unwanted online traffic while providing admins a way to prove their legitimate access.
Bot detection examines requests coming your way and determines if a bot is trying to engage with your application by:
- grading the request based on its likelihood of coming from a non-human actor AND
- checking if there’s any known fraudulent activity associated with the IP address
It's up to you to decide how close you want to hold your online traffic up to scrutiny:
- Step-up only highest risk scores Normal protection which steps up any activity that has the highest chance of coming from a non-human actor. This level of bot detection has a lower probability of stepping up legitimate user activity.
- Step-up high and highest risk scores Advanced protection which is capable of stepping up traffic from a lower risk tier. This level of bot detection can cause false positives meaning some legitimate user activity can get filtered.
Once step-up is applied to a geo-location or a subnet, step-down rules can't be applied to their lower-level locations or subnets, since step-up already applies.
Step-down rules
You can allow admins to skip an additional factor of authentication when logging in
- from geographical locations or IP addresses you trust
- from trusted devices
- if the user's behavior checks out with their previous online behavior

Configuring step-down rules
In case of a passwordless workflow, admins are asked to provide their password if step-down applies.
At the IP Address or Location sections, you can include locations or IP ranges where you let users skip the MFA step in their flow
Device recognition
Device recognition | Enable device recognition to make the option part of the login workflow. If admins opt in, then they will not be asked for a second factor for the number of days specified or until their device is removed. |
Number of days to remember the device | Provide the number of days admins can activate device recognition until they have to re-confirm their decision. This is 30 days by default. |
Enable remember my device by default | Switch on if you want to have the 'Remember my device' checkbox selected by default for admins. |
Behavior analytics
With behavior analytics, your applications will be able to identify trusted behavior. When trusted behavior is detected, the user will skip their required MFA method. This way you can reduce friction in the login journey in a secure way.
Location | When enabled, behavior analytics collect location information from authentication sessions. Based on the obtained login information, behavior analytics determine if a location can be considered usual. |
Day of time/week | When enabled, behavior analytics monitor the time of authentication to look for consistent patterns. Based on the time of day and the day of the week, behavior analytics determines if logins happen at the admin's usual times. |
If behavior analytics find that admins log in from their usual location or time, they will be stepped down from an otherwise required factor of authentication.
Updated 7 months ago