> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk and adaptive access

> Make access adapt to context, so it tightens for sensitive apps and risky conditions and stays frictionless when a sign-in looks routine.

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.

<Info>
  Adaptive access is something an
  [authentication policy](/en/identity/authentication/authentication-policies)
  expresses. This page explains the levers you can adapt on; the policy page
  explains how to combine them into a decision.
</Info>

## 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:

<CardGroup cols={2}>
  <Card title="Device trust" icon="laptop" href="/en/identity/authentication/device-trust">
    Require a known, healthy, managed device for sensitive apps, while allowing
    routine apps from any device.
  </Card>

  <Card title="Application tiers" icon="layer-group" href="#risk-levels">
    Use risk levels to classify how sensitive each app is, and attach stronger
    device-trust policies to your top tier.
  </Card>
</CardGroup>

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](/en/identity/applications/roles-and-bundles) to mark more
sensitive access.

<Note>
  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](/en/iru/platform-overview/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.
</Note>

## A practical approach

<Steps>
  <Step title="Tier your applications" icon="layer-group">
    Decide which applications are most sensitive. Define
    [risk levels](#risk-levels) that capture those tiers so the rest of your
    team shares the same language.
  </Step>

  <Step title="Start from the built-in baseline" icon="shield">
    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.
  </Step>

  <Step title="Tighten the sensitive tier" icon="lock">
    For your most sensitive apps, add a
    [device trust](/en/identity/authentication/device-trust) requirement so only
    known, healthy devices get in.
  </Step>

  <Step title="Review outcomes" icon="list-check">
    Watch how sign-ins are decided in the
    [activity log](/en/identity/administration/activity-log) and adjust so
    legitimate people are not slowed down unnecessarily.
  </Step>
</Steps>

## Where to go next

<CardGroup cols={2}>
  <Card title="Authentication policies" icon="shield-halved" href="/en/identity/authentication/authentication-policies">
    Where device trust and your application tiers come together into one decision.
  </Card>

  <Card title="Device trust" icon="laptop" href="/en/identity/authentication/device-trust">
    Require a known, healthy device for sensitive access.
  </Card>

  <Card title="Authenticators" icon="key" href="/en/identity/authentication/authenticators">
    The phishing-resistant proof every sign-in uses.
  </Card>

  <Card title="Activity log" icon="list-check" href="/en/identity/administration/activity-log">
    Review how sign-ins are being decided over time.
  </Card>
</CardGroup>