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:

  1. Navigate to Adaptive Risk settings.
  2. Enable Risk Based Escalation.
  3. 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/16

Example

An organization operates only from its corporate offices.

Approved IP ranges:

10.0.0.0/8
192.168.1.0/24

A 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

30

This is the platform recommended value.


Example

Trusted Device

Employee signs in from their regular work laptop.

Result:

Lower Risk

Unknown Device

Employee signs in from a newly purchased laptop.

Result:

Additional Risk Added

Device 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

20

Example

Matching Device Fingerprint

Current sign in closely matches historical device activity.

Result:

Low Additional Risk

Significant Device Change

Current sign in differs significantly from historical patterns.

Result:

Higher Risk Contribution

Geo 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

20

Example

08:00 AM → Lagos, Nigeria

08:30 AM → London, United Kingdom

Because 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

8

Example

A user normally signs in between:

8:00 AM – 6:00 PM

A sign in attempt at:

3:00 AM

may 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

5

Example

10:00 AM → Nigeria

10:05 AM → Germany

Both sessions appear active simultaneously.

Result:

Risk Increased

IP 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

SignalWeight
Device Trust30
Device Fingerprint20
Geo Velocity20
Time of Access8
Concurrent Location5

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 Range

Result:

Blocked Before MFA

Critical 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 Blocked

Escalate Authentication

Allow the user to continue only after additional authentication challenges are completed.

Example

User Sign In
      ↓
Critical Risk Detected
      ↓
Additional MFA Required
      ↓
Access Granted

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

OTP

Application Escalation Factor:

Portrait Verification

Result:

Password
      ↓
OTP
      ↓
Risk Detected
      ↓
Portrait Verification
      ↓
Access Granted

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

Block

Application Setting:

Always Escalate

Result:

Application Policy Takes Precedence

Troubleshooting

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


Did this page help you?