Risk policy mode

Adaptive rules come in two modes. Basic Rules are the core adaptive access controls with built-in signals, described in Adaptive rules. Risk policy mode replaces those per-policy rule configurations with risk policies, so your authentication decisions can draw on third party integrations and more complex logic.

An adaptive access policy in Risk policy mode behaves externally like any other: the same outcomes (block, step up, or continue without MFA), the same user-facing screens, and no new end-user surfaces. What changes is how the decision is made, and how much of it you can see afterward in the event log.

Choose the rule mode

1. Log in to the Admin Console.
2. From the left-hand menu, select Policies, and then Adaptive access.
3. Open your policy and select the Adaptive rules tab.
4. Under Rule mode, select Basic Rules or Risk policy.

Risk policy mode presents two sections, each independently optional. Cheap pre-identification IP screening and richer post-identification evaluation are different jobs with different available data, so each section selects its own policy.

IP-based protection

Quick checks stop unwanted traffic before any risk policy evaluation (and before any third party queries or their cost). This section keeps the IP-based blocking options from Basic Rules, each individually optional:

• Block sign-ins from listed IP addresses
• Block sign-ins from listed locations
• Block anonymous proxies and Tor
• Bot detection, with the choice of blocking only the highest risk tier or the high and highest tiers

These checks are evaluated first. If one matches, the session is blocked before any risk policy runs. They're intentionally low-cost, so they can absorb bot-attack query volumes that risk policy evaluation (with its third party queries) can't.

Additionally, you can select a risk policy that evaluates before the customer is identified:

1. Under Risk policy (optional), select a policy. Only policies whose needs can be satisfied pre-identification are offered; a policy that requires identified-customer data can't run here.
2. Map each of the policy's results to Block or Allow. Allow proceeds to the rest of the flow.
3. Select Block or Allow for On evaluation error. This setting is mandatory: evaluations never fail open by default.

Authentication

After the customer is identified, a second, typically different risk policy can evaluate with the full context of who is signing in.

1. Under Risk policy (optional), select a policy.
2. Map each of the policy's results to Step up, Step down, or Block.
3. Select the action for On evaluation error from the same set.

Step down means the customer continues without MFA, which matches today's behavior when a policy includes MFA but no step-up rule fires.

Where the built-in techniques went

In Risk policy mode, the per-policy configurations for improbable travel, behavior analytics, known device detection, breached password detection, and the other non-IP techniques don't appear in the adaptive access policy. These capabilities are built-in risk signal sources, consumed inside the risk policies you select. There is one evaluation model, not two running side by side, so there is never a question of which system's decision wins.

What to expect in operation

• Account event content and block-related messaging reflect the richer evaluation detail: the result, the score, each signal's level and values, and the rule that matched.
• Third party signal queries add latency to the affected phase. The latency is bounded by the slowest signal (signals run in parallel), mitigated by session caching, and attributable per integration via query metrics.

✅

After switching a policy to Risk policy mode, run a test sign-in and check the account event: it records which policy evaluated, the result, and every contributing signal, so you can confirm the mappings behave as intended.