Risk-Based Authentication Policy Template: How to Match Login Friction to User Risk

Overview

Risk-based authentication, also called adaptive authentication, changes the sign-in experience according to the circumstances of each attempt. A familiar device, expected location, and ordinary account activity may support a low-friction login. A new device, unusual recovery attempt, or sensitive transaction may justify an additional challenge.

The purpose is not to make every login difficult. It is to connect authentication strength to the potential impact of account misuse. A policy should therefore answer four practical questions:

• Which signals are collected, and what do they indicate?
• How are signals combined into a low, medium, or high-risk decision?
• What authentication action follows each decision?
• How will the team measure false positives, missed abuse, and user friction?

Risk scoring is a decision aid, not proof that a person is malicious or legitimate. Signals can be incomplete, shared, stale, or misleading. Keep the policy explainable, limit access to sensitive data, and provide a controlled recovery path for legitimate users who are challenged incorrectly.

For the surrounding controls, review the OAuth 2.0 and OpenID Connect security checklist and the session management security guide. Risk-based authentication works best when it is connected to secure sessions, token handling, logout, and account recovery rather than treated as an isolated login feature.

What to track

Begin with a signal inventory. Record the signal name, the event that produces it, its likely meaning, its retention period, and the action it can trigger. Do not collect a signal merely because it is available; document why it is relevant to account security and how it will be protected.

Core signal categories

• Device and browser change: a first-seen device, a materially changed browser profile, an unusual operating environment, or a device that has recently been removed from a trusted list.
• Network and location context: a new network, a location that differs from recent activity, or an apparent impossible-travel pattern. Treat location as contextual evidence rather than a definitive verdict because users may travel, use corporate networks, or share network addresses.
• Authentication history: repeated failed attempts, rapid attempts across accounts, an unexpected change in authentication method, or a sudden increase in challenge failures.
• Account recovery activity: a recently changed recovery address or phone number, a password reset, multiple recovery requests, or an attempt to use a recovery channel that has not been established.
• Account and transaction behavior: unusual access time, a new payee, an atypical export, a high-impact settings change, or activity that differs substantially from the account's normal pattern.
• Account importance: administrator access, billing authority, access to sensitive records, or permissions that can affect many users should receive stronger baseline protection.

Low, medium, and high-risk decision table

These categories are a starting model, not universal thresholds. Define the evidence that moves an event from one level to another and record whether signals add risk, reduce risk, or simply provide context. A familiar device should not automatically cancel several strong warning signs.

Step-up authentication rules

Write rules in a form that engineers, support staff, and reviewers can understand. For example:

• Require a step-up challenge when a user signs in from a new device and then attempts to change recovery settings.
• Require stronger authentication before an administrator changes permissions, exports sensitive data, or creates a new privileged account.
• Challenge a recovery attempt when the recovery address was recently changed or when several recovery requests occur in a short period.
• Do not treat a successful password alone as sufficient for a high-impact action when the surrounding context is high risk.
• After a failed step-up challenge, pause the sensitive action and offer a documented recovery route rather than cycling through weaker challenges.

Challenge copy should be specific without revealing detection logic. “For your security, confirm this sign-in because this device is new” is more useful than “Suspicious activity detected.” Avoid displaying details that could help an attacker tune future attempts.

Cadence and checkpoints

A risk-based authentication policy needs an operating rhythm. Assign an owner for the policy, a reviewer for security events, and a product or support contact who can assess user impact. Review the following measures at least monthly when the system is active, and perform a fuller policy review each quarter or after a significant change.

• Challenge rate: how often users are asked for step-up authentication, segmented by application area, account type, device context, and risk level.
• Challenge completion: how often users complete the requested method and how often they abandon it or fail repeatedly.
• False-positive reports: support contacts, verified legitimate users, and cases where a challenge blocked a normal task.
• Security outcomes: confirmed account takeover attempts, suspicious recovery activity, unauthorized settings changes, and incidents that passed through the policy.
• Coverage: whether privileged accounts, recovery flows, new devices, APIs, and high-impact actions are actually governed by the policy.
• Authentication method health: enrollment success, availability, fallback use, and failures for each supported method.

Keep a change log containing the date, policy version, reason for the change, affected signals, expected result, approving roles, and rollback plan. Test changes with representative low-, medium-, and high-risk scenarios before broad deployment. Include users with accessibility needs and users who cannot complete a preferred method.

Do not make a policy change solely because one metric moved. Compare the change with product releases, regional traffic, sign-in volume, support reports, authentication-method availability, and known abuse patterns. A challenge-rate increase may reflect an attack, a new device rollout, a browser change, or an overly sensitive rule.

How to interpret changes

Interpret the policy as a feedback loop. A rise in challenges with stable completion and no corresponding security improvement may indicate excessive friction. A fall in challenges alongside more suspicious recovery activity may indicate that a signal is missing, weighted incorrectly, or being bypassed.

Review changes by cohort instead of relying only on an overall average. Compare new and returning users, privileged and standard accounts, regions, device types, authentication methods, and important workflows. This helps distinguish a broad policy problem from a narrow issue in one sign-in path.

Use a simple review sequence:

1. Confirm that the data is complete and that event definitions have not changed.
2. Identify which signal or rule changed, and when the change became active.
3. Compare challenge volume, completion, abandonment, support reports, and security outcomes.
4. Inspect representative cases, including successful challenges, false positives, and missed events.
5. Decide whether to keep, tune, retire, or add a rule, and document the reasoning.

False positives deserve structured review. Capture the user's context, the signals that caused the challenge, the method offered, the result, and the least disruptive correction. Avoid weakening the entire policy to solve a problem that affects one device type or one recovery path. Where a challenge cannot be completed, provide a support process with identity checks appropriate to the account's value. Do not let support bypass a high-risk decision without recording who approved it and why.

For passwordless options and their trade-offs, see the passwordless authentication comparison. If your application uses tokens, the JWT verification guide can help separate token validation from broader login-risk decisions.

When to revisit

Schedule a formal review quarterly, with a lighter monthly check of the core metrics. Revisit the policy sooner when any of the following occurs:

• A confirmed account takeover, recovery abuse, or privileged-account incident occurs.
• Challenge rates, completion rates, abandonment, or support contacts change noticeably.
• The application adds a new device flow, browser experience, authentication method, API, payment flow, or administrative feature.
• Recovery settings, session duration, token behavior, or trusted-device logic changes.
• Users report repeated challenges, inaccessible authentication methods, or unexplained lockouts.
• Browser, device, network, or authentication-method behavior changes enough to affect signal quality.
• A privacy, security, or governance review identifies unnecessary collection, unclear retention, or undocumented access to risk data.

Use this compact approval template at each review:

• Policy version and review date: record the current version and the next planned checkpoint.
• Scope: list applications, user groups, privileged roles, recovery flows, and sensitive actions covered.
• Signals: document each signal, purpose, retention, owner, and known limitations.
• Decision rules: define low-, medium-, and high-risk outcomes and the required step-up method.
• Exceptions: specify accessibility, travel, service-account, support, and outage procedures with approval requirements.
• Results: summarize challenge rate, completion, false positives, security events, and notable cases.
• Decision: approve, tune, test, or retire the policy, with an owner and due date for each action.

Before deployment, walk through ordinary login, new-device login, impossible-travel context, unusual transaction behavior, recovery attempts, privileged access, failed challenges, authentication-service outage, and support recovery. Confirm that each scenario has a clear user message, an appropriate authentication action, an audit record, and a safe fallback. That checklist turns risk-based authentication from a collection of signals into an accountable, reviewable security control.