> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/reference/adaptive-authentication-and-risk-based-access.md).

# Adaptive authentication and risk-based access

Adaptive authentication adjusts how strongly a user must prove who they are, based on how risky the situation looks. A user signing in from their usual laptop on the office network is asked for less than the same user signing in at three in the morning from an unfamiliar country.

This guide covers how SECUREpass assesses risk, how to build the risk profiles that act on it, and the location, device and duress controls that sit alongside them.

## How risk is assessed

SECUREpass evaluates every authentication attempt against several signals at once.

**Behavioural analysis.** Login patterns are analysed continuously — device, location, time of day, and session data — to establish what normal looks like for each user.

**Machine learning.** An Isolation Forest model trains on historical authentication data. It isolates anomalies quickly and flags high-risk behaviour in real time, rather than waiting for a batch job.

**Device fingerprinting.** Recognised devices carry a different risk weight from unrecognised ones.

**Geo-fencing.** Where the request originates from is treated as a first-class signal. See section 5.

**Transaction analysis.** Where the application exposes transaction context, unusual amounts, beneficiaries or timing can raise risk on their own.

## Risk profiles

A risk profile is a set of conditions that maps a context to a required authentication strength. When the conditions match, the profile decides what the user must present.

### Scope

A profile can be created for a **user**, a **group**, or a **role**. Group-based profiles are the usual starting point — stricter conditions for high-risk groups, lighter ones for low-risk groups — with individual user profiles reserved for exceptions.

### Conditions

Profiles are built from static and dynamic parameters:

| Signal      | Examples                                                         |
| ----------- | ---------------------------------------------------------------- |
| Location    | Country, region, city                                            |
| Network     | IP address or range, trusted versus untrusted                    |
| Device      | Device type, operating system, registered or unrecognised        |
| Time        | Time of day, day of week                                         |
| Behaviour   | Login frequency, anomaly score from the ML model                 |
| Transaction | Amount, beneficiary, timing, where the application supplies them |

### Severity mapping

Users and groups are mapped to a policy according to the severity of the risk they present, and authentication modes are mapped to the severity type. A high-severity match demands more; a low-severity match demands less.

This is what makes the system adaptive rather than merely conditional — the same user can land in different severities on different days.

### Attribute weightage

Weightage sets how much each static and dynamic attribute contributes to the overall risk score. It is configured once, by an administrator, and then applies across all profiles.

### Custom attributes

A superadmin can enable or disable individual risk-profile attributes, so the assessment considers only the signals your organisation actually wants to act on. Attributes that are disabled are not offered when a profile is created.

## Conditional access and step-up

Once a profile matches, SECUREpass acts on it in one of two directions.

**Step-up authentication.** For a high-risk application, group or context, additional factors are demanded — a second factor where one would normally do, or a stronger factor such as PKI for a high-value transaction.

**Simplified access.** For low-risk applications or groups, additional steps are bypassed. This is not a weakening of security; it is what makes step-up tolerable to users, because it is not applied everywhere.

Where a session already satisfies part of the requirement, SECUREpass prompts only for what is missing. A user who has already presented one required factor and then hits a rule needing two is asked for the second factor alone, provided the session timeout has not lapsed.

{% hint style="info" %}
Users receive an email notification when their access rights are modified. This is deliberate — it keeps the person affected aware of the change rather than discovering it at the next login.
{% endhint %}

## Trusted networks and device registration

**IP lists.** Administrators can add and remove IP addresses, singly or in bulk, to trusted and untrusted lists. These feed directly into risk profile conditions.

**Device registration limits.** Administrators can cap how many devices a single user may register for login. Capping this limits the blast radius when a credential is compromised, since an attacker cannot simply enrol another device.

## Geofencing

Geofencing associates a geographic boundary with a security action.

### Configuring a geofence

**Location type** — choose the boundary:

* **City**
* **State** or province
* **Country**

**Action** — choose what happens when a user's location falls inside the boundary:

| Action                      | Effect                                                                                 |
| --------------------------- | -------------------------------------------------------------------------------------- |
| Multi-factor authentication | Require an additional factor before granting access                                    |
| Block user                  | Deny access outright                                                                   |
| Notify user                 | Alert the user that their location is restricted or requires additional authentication |

**MFA method** — active only when the action is multi-factor authentication:

* **Knowledge-based authentication** — the user answers personal security questions.
* **Email OTP** — the user receives a one-time password by email.

Select **Create** to save the rule.

{% hint style="info" %}
Geofences can be written to act on being *inside* a boundary or outside it, depending on how you construct the rule. Blocking a list of untrusted countries and requiring MFA for anything outside your operating region are both common patterns.
{% endhint %}

## Duress authentication

Duress authentication lets a user signal, without visible sign, that they are being forced to log in — during a robbery, a coercion attempt, or a hostage situation. The login appears to proceed normally while an alert goes out.

### Duress policy

Two mechanisms are available, and either can be enabled:

* **Use password in reverse.** The user enters their normal password backwards. The system recognises this as a duress signal.
* **Duress PIN.** A separate PIN, registered in advance, entered instead of the regular password.

The duress credential is distinct from the user's ordinary credentials, and is registered before it is ever needed.

### Duress notification

When a duress signal is received, SECUREpass triggers pre-configured actions:

* **Notify email IDs** — a list of addresses to alert. Typically security personnel, managers, or a duty contact.
* **Notify reporting manager** — sends the alert to the user's direct supervisor.

Notifications are silent from the user's point of view. Nothing on screen indicates that duress was signalled.

{% hint style="warning" %}
Duress is only useful if the people on the notification list know what the alert means and what to do when it arrives. Configure the list alongside an agreed response procedure, not on its own.
{% endhint %}

## Bot protection

The **I am not a robot** check distinguishes human users from automated bots on the login page and other forms.

Clicking the checkbox is often enough on its own. Where the system detects suspicious activity — rapid form submissions, unusual mouse movement — it escalates to a challenge-response test such as image identification or distorted text.

The purpose is to blunt automated attacks: fake account creation, spam submission, and credential brute-forcing.

## Example scenarios

| Situation                                        | Rule                               |
| ------------------------------------------------ | ---------------------------------- |
| User signs in from outside the corporate network | Require FIDO2 or push notification |
| Login originates from an untrusted country       | Block                              |
| High-value transaction initiated                 | Step up to PKI                     |
| Unrecognised device, otherwise normal behaviour  | Require email OTP                  |
| Recognised device, office IP, working hours      | Password alone                     |

Adaptive authentication is the difference between a policy that treats every login the same and one that spends its friction where the risk actually is — heavier when the context is unfamiliar, lighter when it is not, and silent when someone needs help.