Adaptive Risk Authentication
Adaptive Risk Authentication allows Fixiam to evaluate sign in activity in real time and apply additional security controls when suspicious behaviour is detected.
Unlike traditional MFA, which challenges every user equally, Adaptive Risk Authentication evaluates contextual risk signals such as device trust, IP address, location, sign in patterns, and other indicators before deciding whether additional verification is required.
This helps organizations improve security without unnecessarily impacting user experience.
How Adaptive Risk Authentication Works
When a user attempts to sign in, Fixiam evaluates configured risk signals.
Each enabled signal contributes to an overall risk score.
Based on the resulting risk level, Fixiam can:
- Allow the sign in
- Request additional authentication
- Block the sign in attempt
Authentication Flow
User Sign In Attempt
↓
Risk Signals Evaluated
↓
Risk Score Calculated
↓
┌─────────────────────┐
│ Low Risk │ → Allow Sign In
└─────────────────────┘
┌─────────────────────┐
│ Elevated Risk │ → Require Additional MFA
└─────────────────────┘
┌─────────────────────┐
│ Critical Risk │ → Block or Escalate
└─────────────────────┘Accessing Adaptive Risk Settings
Navigate to:
Settings → User Management Settings → Adaptive Risk
>
Enabling Adaptive Risk
Adaptive Risk Authentication is disabled by default.
To enable it:
- Navigate to Adaptive Risk settings.
- Enable Risk Based Escalation.
- Save your changes.
Once enabled, Fixiam begins evaluating configured risk signals during authentication.
Understanding Risk Signals
Risk signals are indicators that help Fixiam determine whether a sign in attempt appears normal or suspicious.
Each signal can contribute to the overall risk score.
IP Allowlist
The IP Allowlist defines trusted network locations from which users are permitted to sign in.
Only configured IP addresses or CIDR ranges are considered approved.
Navigate to:
Settings → User Management Settings → Access Policy
>
Adding Allowed IP Addresses
Examples:
192.168.1.10
10.0.0.0/8
172.16.0.0/16Example
An organization operates only from its corporate offices.
Approved IP ranges:
10.0.0.0/8
192.168.1.0/24A sign in from an unapproved public network may be considered higher risk.
Device Trust
Device Trust identifies whether a user is signing in from a previously trusted device.
Trusted devices typically contribute less risk than unfamiliar devices.
Device Trust is a foundational security signal used throughout the Adaptive Risk engine.
Recommended Weight
30This is the platform recommended value.
Example
Trusted Device
Employee signs in from their regular work laptop.
Result:
Lower RiskUnknown Device
Employee signs in from a newly purchased laptop.
Result:
Additional Risk AddedDevice Fingerprint Score
Device Fingerprint compares characteristics of the current device against previously recorded device information.
Examples include:
- Browser characteristics
- Device attributes
- Operating environment
Large differences may indicate an unfamiliar or potentially spoofed device.
Recommended Weight
20Example
Matching Device Fingerprint
Current sign in closely matches historical device activity.
Result:
Low Additional RiskSignificant Device Change
Current sign in differs significantly from historical patterns.
Result:
Higher Risk ContributionGeo Velocity
Geo Velocity identifies impossible travel scenarios.
It evaluates whether a user could realistically travel between sign in locations within the observed time window.
Recommended Weight
20Example
08:00 AM → Lagos, Nigeria
08:30 AM → London, United KingdomBecause physical travel between these locations is impossible within that timeframe, the sign in is flagged as suspicious.
Time of Access
Time of Access evaluates whether a sign in occurs during the user's normal login patterns.
Recommended Weight
8Example
A user normally signs in between:
8:00 AM – 6:00 PMA sign in attempt at:
3:00 AMmay increase the overall risk score.
Concurrent Location
Concurrent Location detects overlapping sign ins from different countries within a short period.
This may indicate:
- Credential sharing
- Account compromise
- Session theft
Recommended Weight
5Example
10:00 AM → Nigeria
10:05 AM → GermanyBoth sessions appear active simultaneously.
Result:
Risk IncreasedIP Reputation
IP Reputation evaluates whether a sign in originates from potentially risky infrastructure.
Examples include:
- VPN services
- Datacenter networks
- Known threat sources
Coming Soon
This feature requires external threat intelligence provider integration.
Credential Breach Detection
Credential Breach Detection evaluates whether user credentials have appeared in known breach datasets.
Coming Soon
This feature requires external breach intelligence provider integration.
Understanding Risk Weights
Each risk signal contributes a weighted value toward the overall risk evaluation.
Higher weights indicate that a signal has greater influence during risk assessment.
Example Configuration
| Signal | Weight |
|---|---|
| Device Trust | 30 |
| Device Fingerprint | 20 |
| Geo Velocity | 20 |
| Time of Access | 8 |
| Concurrent Location | 5 |
In this example:
- Device Trust contributes more heavily than Time of Access.
- Geo Velocity has a stronger impact than Concurrent Location.
Recommendation
Use platform recommended weights unless directed by your security team.
Pre Screen Block Signals
Pre Screen Blocks evaluate sign in attempts before authentication proceeds.
If a configured signal is triggered, Fixiam can immediately stop the sign in process before MFA begins.
Available Signals
Outside IP Allowlist
Blocks sign ins originating from IP addresses outside approved ranges.
Device Fingerprint Spoofed
Blocks sign ins when the device fingerprint appears manipulated or spoofed.
Example
User attempts to sign in from:
Unknown Country
Unknown Device
Outside Approved IP RangeResult:
Blocked Before MFACritical Risk Actions
When overall risk reaches the Critical Risk threshold, administrators can define how Fixiam should respond.
Block Sign In
Immediately deny access.
The user cannot proceed further.
Example
User Sign In
↓
Critical Risk Detected
↓
Access BlockedEscalate Authentication
Allow the user to continue only after additional authentication challenges are completed.
Example
User Sign In
↓
Critical Risk Detected
↓
Additional MFA Required
↓
Access GrantedAdaptive Risk for Applications
Adaptive Risk can also be configured at the application level.
Navigate to:
Applications → Login Flow
>
Enabling Application Risk Escalation
Applications can require additional authentication when elevated risk is detected.
Examples include:
- OTP
- Fingerprint
- Portrait Verification
Example
Organization MFA:
OTPApplication Escalation Factor:
Portrait VerificationResult:
Password
↓
OTP
↓
Risk Detected
↓
Portrait Verification
↓
Access GrantedCritical Risk Actions for Applications
Applications can define their own behaviour when Critical Risk is detected.
Inherit Organization Default
The application follows the organization's configured response.
Always Block
The application immediately blocks access.
Always Escalate
The application always requests additional verification.
Precedence Rules
Application settings override organization settings where configured.
Example
Organization Setting:
BlockApplication Setting:
Always EscalateResult:
Application Policy Takes PrecedenceTroubleshooting
Adaptive Risk Is Enabled But No Additional MFA Appears
Verify:
- Risk Based Escalation is enabled.
- Relevant risk signals are enabled.
- Escalation factors are configured.
- Risk thresholds are being reached.
Users Are Being Blocked Unexpectedly
Review:
- Pre Screen Block Signals
- IP Allowlist configuration
- Critical Risk Action settings
Trusted Devices Are Not Reducing Risk
Verify:
- Trusted Devices feature is enabled.
- Device has not expired.
- Device limit has not been exceeded.
Best Practices
- Start with platform recommended weights.
- Use IP Allowlists for corporate environments.
- Enable Device Trust for all users.
- Enable Geo Velocity detection.
- Use escalation before blocking whenever possible.
- Regularly review authentication logs and risk events.
- Test policies before deploying organization wide.
Related Topics
- Password Authentication
- Multi Factor Authentication (MFA)
- Trusted Devices
- Access Policies
Updated about 2 months ago
