Skip to main content
Not every sign-in deserves the same treatment. A sign-in from a familiar, managed device to a low-stakes app is very different from access to a sensitive application. Adaptive access lets your authentication policies respond to that difference - asking for more when the situation warrants it and staying out of the way when it does not.
Adaptive access is something an authentication policy expresses. This page explains the levers you can adapt on; the policy page explains how to combine them into a decision.

What you can adapt on

Today, the strongest lever for adaptive access is device trust - the conditions a policy places on the device a person signs in from. You apply it selectively by attaching stronger policies to your more sensitive applications:

Device trust

Require a known, healthy, managed device for sensitive apps, while allowing routine apps from any device.

Application tiers

Use risk levels to classify how sensitive each app is, and attach stronger device-trust policies to your top tier.
By tiering your applications and attaching stronger policies to the sensitive ones, you get access that adapts to context without slowing everyone down.

Risk levels

Iru also lets you define risk levels - named classifications you create to fit how your team already talks about risk. Risk levels give you a consistent vocabulary to organize applications and policies around their sensitivity. Today you can assign a risk level to an application role to mark more sensitive access.
Risk levels are a classification you define. Automatically scoring each sign-in and feeding that score into policy decisions is an area Iru is expanding; see Iru release stages for how capabilities mature. Plan today around device trust, which is enforced now; a passkey or Iru Access is already required for every sign-in regardless.

A practical approach

Tier your applications

Decide which applications are most sensitive. Define risk levels that capture those tiers so the rest of your team shares the same language.

Start from the built-in baseline

Every sign-in already requires a passkey or Iru Access, so all access starts from a strong, phishing-resistant baseline - there is nothing to configure for that.

Tighten the sensitive tier

For your most sensitive apps, add a device trust requirement so only known, healthy devices get in.

Review outcomes

Watch how sign-ins are decided in the activity log and adjust so legitimate people are not slowed down unnecessarily.

Where to go next

Authentication policies

Where device trust and your application tiers come together into one decision.

Device trust

Require a known, healthy device for sensitive access.

Authenticators

The phishing-resistant proof every sign-in uses.

Activity log

Review how sign-ins are being decided over time.