Risk Scoring & Adaptive MFA
Auris computes a risk score between 0 and 100 for every login attempt based on five weighted factors. When the score exceeds configurable thresholds, the system automatically requires additional authentication, escalating from silent logging to MFA step-up to outright blocking. This adaptive approach provides strong security for high-risk events without adding friction to normal logins.
Access via Console → Settings → Security → Risk Assessment, or from the Advanced OAuth section in the sidebar.
Risk Factors
The risk score is the weighted sum of five independent factors. Each factor produces a normalized score (0-100) that is multiplied by its configured weight and summed with the others.
| Factor | Default Weight | Description |
|---|---|---|
| IP Reputation | 20% | Checks the login IP against known bad-IP lists, VPN/proxy databases, and datacenter IP ranges. A login from a clean residential IP scores low; a login from a known Tor exit node or datacenter IP scores high. |
| Device Trust | 25% | Evaluates whether the device fingerprint (browser, OS, screen resolution, timezone) has been seen before for this user. A recognized device scores 0; a completely new device scores high. First-time logins always score high on this factor. |
| Geo Anomaly | 20% | Measures the geographic distance and time gap between the current login and the user’s previous login. If the two locations are physically unreachable in the elapsed time (impossible travel), this factor scores maximum. |
| Behavioral | 15% | Analyzes login time patterns and frequency. A login at 3 AM from a user who always logs in during business hours, or an unusually high login frequency, increases this score. |
| Action Sensitivity | 20% | Rates the sensitivity of the requested action. A standard login scores low. A password change or token exchange scores medium. An impersonation token exchange scores maximum. |
Configuring Weights
Open Risk Assessment settings
Navigate to Console → Settings → Security → Risk Assessment.
Adjust factor weights
Each factor has a slider control. Drag the slider to increase or decrease the weight of that factor. The total across all five factors must equal 100%.
If you move one slider, the others adjust proportionally to maintain the 100% total, unless you lock a factor by clicking the lock icon next to its slider.
Save
Click Save to apply the new weight configuration. Changes take effect immediately for all subsequent logins.
If your users frequently travel or use VPNs, consider reducing the Geo Anomaly weight and increasing Device Trust instead. If most of your users are employees with predictable schedules, increasing the Behavioral weight provides strong anomaly detection.
Risk Thresholds
Thresholds determine what action Auris takes based on the computed risk score. Four levels are defined, each with a score range and corresponding behavior.
| Level | Default Score Range | Action |
|---|---|---|
| Low | 0 - 30 | Allow the login. No additional authentication is required. The login proceeds normally. |
| Medium | 31 - 60 | Suggest MFA. The user is prompted with an optional MFA challenge but can skip it. A notification is sent to the user about the login. |
| High | 61 - 80 | Require MFA step-up. The user must complete an additional MFA factor even if MFA is not normally required for their account. The login is blocked until MFA is completed. |
| Critical | 81 - 100 | Block the login entirely. The user sees a generic error. An admin notification is triggered. The event is flagged for manual review in the audit log. |
Adjusting Thresholds
On the Risk Assessment settings page, each threshold boundary is represented by a draggable marker on a horizontal score bar. Drag the markers to adjust where each level begins:
- Move the Low/Medium boundary left to be more aggressive (more logins trigger Medium actions)
- Move the High/Critical boundary right to be more lenient (fewer logins are blocked)
A recommended starting configuration for most tenants is the default (0-30 / 31-60 / 61-80 / 81-100). Adjust based on your threat model after reviewing the Risk Assessment Dashboard for a few weeks.
Setting the Critical threshold too low (for example, below 60) will cause many legitimate logins to be blocked, especially for users who travel or use multiple devices. Start with the defaults and adjust downward only if you observe undetected threats.
Custom Risk Rules
Beyond the five built-in factors, you can create custom rules that add points to the risk score when specific conditions are met. Custom rule scores are added on top of the factor-weighted base score, and the final score is capped at 100.
Creating a Rule
Open the Risk Rules tab
On the Risk Assessment settings page, click the Custom Rules tab.
Click Add Rule
Click Add Rule to open the rule editor.
Define the condition
| Field | Description |
|---|---|
| Field | The property to evaluate. Options: ip, country, device_type, login_hour, user_role, email_domain, connection_type |
| Operator | Comparison operator. Options: equals, not_equals, contains, not_contains, in, not_in, greater_than, less_than |
| Value | The value to compare against. For in / not_in, provide a comma-separated list. |
Set the score impact
Enter the number of points to add to the risk score when this rule matches. Values can range from 1 to 50.
Save the rule
Click Save. The rule is active immediately and is evaluated for all subsequent logins.
Example Rules
| Rule | Condition | Score Added | Purpose |
|---|---|---|---|
| Block TOR exits | ip in tor-exit-list | +40 | Strongly penalize Tor exit node traffic |
| Off-hours login | login_hour not_in 8,9,10,11,12,13,14,15,16,17,18 | +15 | Add moderate risk for logins outside business hours |
| External contractors | user_role equals contractor | +10 | Slightly elevate risk for contractor accounts |
| Sensitive domain | email_domain equals admin.internal.com | +20 | Increase scrutiny for admin domain accounts |
Rule Evaluation Order
Custom rules are evaluated in the order shown in the rules list. All matching rules are applied — their scores are cumulative. You can drag rules to reorder them, though order only affects readability since all matching rules fire regardless of position.
Step-Up Authentication
When the risk score triggers a High threshold, Auris initiates a step-up authentication flow. This means the user must prove their identity at a higher assurance level than what they initially provided.
ACR (Authentication Context Class Reference)
Auris tracks the assurance level of each authentication session using standard ACR values:
| ACR Level | Meaning | Methods |
|---|---|---|
aal1 | Single-factor authentication | Password only, magic link, social login |
aal2 | Multi-factor authentication | Password + TOTP, password + SMS OTP, password + WebAuthn |
aal3 | Hardware-bound multi-factor | Password + hardware security key (WebAuthn with attestation) |
AMR (Authentication Methods Reference)
The AMR claim in the JWT records which specific methods were used during authentication:
| AMR Value | Method |
|---|---|
pwd | Password |
otp | TOTP or SMS OTP code |
hwk | Hardware key (WebAuthn) |
sms | SMS verification |
mca | Magic link (email-based) |
fed | Federated login (social or SSO) |
Step-Up Flow
When a risk score exceeds the High threshold:
- Auris checks the current session’s ACR level
- If the session is
aal1, the user is redirected to an MFA challenge (TOTP, SMS, or WebAuthn depending on what the user has enrolled) - If the session is already
aal2, the user is prompted for a hardware key if enrolled, or the login proceeds with a warning logged - The JWT is re-issued with updated
acrandamrclaims reflecting the step-up - Applications can check the
acrclaim to enforce minimum assurance levels for sensitive operations
Step-up authentication works even for users who do not have MFA normally enabled on their account. When triggered by a high risk score, the user is guided through enrolling an MFA method on the spot if they have none configured. This is a one-time enrollment that persists for future logins.
Risk Assessment Dashboard
The Risk Assessment settings page includes an overview dashboard showing aggregated risk data across your tenant.
Risk Score Distribution
A histogram showing the distribution of risk scores across all logins in the selected time period (24 hours, 7 days, 30 days). This helps you understand your baseline — if most logins score between 0-20, a score of 45 is noteworthy.
Step-Up Triggers Over Time
A time-series chart showing how many logins triggered step-up MFA, broken down by risk level (Medium suggested, High required). Use this to spot trends — a sudden increase in step-up triggers may indicate an ongoing attack.
Blocked Logins
A count of logins blocked by the Critical threshold, with details on the most common blocking reasons (IP reputation, impossible travel, etc.).
Top Risk Contributors
A table showing which risk factors most frequently contribute to elevated scores. This helps you tune weights — if Device Trust is triggering on 80% of elevated scores, your users may legitimately use many devices, and you should consider reducing its weight.
Permissions
| Permission | Description |
|---|---|
view:risk_assessments | View risk scores, dashboard charts, and assessment history |
manage:risk_rules | Create, edit, and delete custom risk rules and adjust factor weights and thresholds |
manage:advanced_oauth | Full access to all advanced OAuth2 and risk scoring settings |
Related Guides
- Multi-Factor Authentication — Configure MFA methods available to your users
- Adaptive MFA Concepts — How risk-based MFA works at a conceptual level
- Security Settings — IP rules, brute-force protection, suspicious login detection
- Advanced OAuth2 Settings — Device Flow, CIBA, DPoP, and Token Exchange configuration
- Suspicious Login Detection — How Auris detects anomalous logins