Adaptive authentication and risk-based MFA
Require the second factor only where risk is highest. With LoginMaster, conditional access is configured per tenant, project and role: more security where it matters, less friction where it doesn't.
What adaptive authentication is
Adaptive authentication is an approach where the second-factor requirement is not always the same, but depends on the context and risk level of the access. With LoginMaster risk is expressed through policies configurable across three dimensions — tenant, project and role: TOTP-based MFA can be disabled, optional or mandatory, so extra verification kicks in where risk is structurally highest (privileged roles, sensitive projects) and stays light elsewhere. It's conditional access applied to identity: more protection where it matters, less friction where it doesn't. Once a user has activated the second factor, no administrator can disable it.
How conditional access works
Risk drives the second-factor requirement, in four moments.
- 1
Define policies by context
Decide where MFA is mandatory: for entire tenants, for individual projects or for specific roles. Context represents risk, and each tenant sets its own thresholds.
- 2
LoginMaster evaluates context at login
On every access, LoginMaster checks the user's role, project and tenant against the active policies and determines whether the second factor is required in that context.
- 3
Step-up only where needed
If the context is higher risk, the user completes the TOTP second factor; in low-risk accesses friction stays minimal. This is the risk-based logic of conditional access.
- 4
Signed, compliant token
The application receives a signed token attesting the authentication level reached, with access logs available for audit and data kept in the customer's EU Tenant.
The dimensions of risk, configurable
LoginMaster's adaptive MFA is modeled on explicit, auditable policies.
By role
Make MFA mandatory for privileged accounts — administrators, approvers, operators — and optional for low-impact roles. Privilege is a risk signal.
By project
Apply strong verification only to projects handling sensitive or critical data, keeping access to low-risk projects fluid.
By tenant
Each tenant configures its own thresholds independently: a customer in a regulated sector can enforce MFA for everyone, another can limit it to sensitive contexts.
Standard TOTP
The second factor is based on TOTP codes, compatible with Google Authenticator and the major authenticator apps. No extra per-user cost.
Not disableable by admins
Once activated by the user, no administrator can turn off the second factor: the account stays protected even if an administrative account is compromised.
Open standards
Conditional access runs on OAuth 2.0, OpenID Connect and SAML 2.0: your app delegates authentication with no mandatory proprietary SDK.
Risk-based authentication: six concrete scenarios
The same user can meet different verification requirements depending on where they are signing in and with which role. Here is how conditional access behaves in the cases that come up most often.
Administrative session on a critical project
An administrator opens the console of a project handling sensitive data. High privilege and a critical project compound: the policy makes MFA mandatory and access always requires TOTP step-up, even when the SSO session is already active.
External consultant or supplier on a single project
An external identity is linked to a single project with a limited role. The perimeter is narrow by construction and MFA stays mandatory for the whole engagement; at the end, revoking the project link cuts access without touching other tenants.
MSPs and system integrators operating across tenants
Whoever manages identity for several organizations meets different thresholds depending on the tenant they are working on: each customer defines its own policies, and per-tenant cryptographic isolation prevents a session from carrying over to a different organization.
Low-impact day-to-day consultation
A read-only user on a non-critical project signs in dozens of times a day. Here the policy leaves MFA optional: friction stays minimal and the second factor does not become a daily operational cost.
Role or project change (mover)
When someone moves to a privileged role or is linked to a more sensitive project, the evaluation changes at the next sign-in: MFA that was optional becomes mandatory, with no manual intervention on the account.
Non-human identities: IoT devices and AI agents
Devices and agents do not use a TOTP second factor: they authenticate with dedicated credentials and per-project keys, and stay confined to the perimeter of the project they are linked to. Risk is governed through scope, not step-up.
Contextual signals: what decides at login, what is correlated afterwards
Many platforms compute an opaque risk score from behavioural signals. LoginMaster separates the two planes: the authentication decision stays deterministic and auditable, while behavioural detection stays in your SIEM, where you have visibility across the whole infrastructure.
Evaluated by policy at login time
- The user's role: privileged or low-impact.
- The project the access is directed at, and its criticality.
- The tenant's policies, defined independently by each organization.
- The state of the user's second factor: disabled, optional or mandatory.
These are explicit dimensions: you can document them during an audit and reproduce their behaviour.
Logged and correlated downstream, in your SIEM
- Geolocation and source IP address of the access.
- Access at an unusual hour compared with the user's habits.
- Device and user agent the session is opened from.
- Impossible travel and repeated failed attempts in sequence.
Every authentication event is available in the access logs and via real-time webhook: correlation rules live in your SIEM integration.
Where adaptive authentication makes the difference
Finance & insurance
Mandatory MFA for transaction operators and approvers, optional for low-risk consultation: compliance and friction under control.
Healthcare
Strong verification for access to sensitive clinical data, while keeping personal data in the organization's EU Tenant.
Public administration
MFA enforced by role on critical procedures, with access logs for audit and GDPR and NIS2 compliance by design.
Energy & manufacturing
Conditional access on critical projects and systems, extended also to IoT device and non-human agent identities.
Frequently asked questions
It's an authentication method where the second-factor requirement varies based on the context and risk of the access, instead of always being identical. Higher-risk accesses require strong verification (step-up), lower-risk ones stay more fluid. With LoginMaster risk is defined by policies on tenant, project and role.
They are two sides of the same approach. Conditional access is the rule that decides, based on context, whether and when extra verification is needed; adaptive MFA is the enforcement of that rule on the second factor. In LoginMaster you configure the conditions per tenant, project and role and TOTP MFA adapts accordingly.
Risk is expressed through configurable context dimensions: the user's role (privileged or not), the project's criticality and the tenant's policies. On these dimensions you define where MFA is disabled, optional or mandatory. It's a risk model based on explicit, auditable policies rather than opaque scores.
Yes. Instead of imposing the second factor on every access indiscriminately, it requires it only in higher-risk contexts. Users operating on low-risk projects and roles encounter fewer steps, while sensitive accesses stay protected. It's the security-usability balance of conditional access.
No. MFA can be made mandatory at the policy level, but once the user has activated their second factor no administrator can turn it off on their behalf. Reset always requires verifying the user's identity. This protects accounts even if an administrative account is compromised.
Not as an input to the authentication decision. The policy that decides whether to require the second factor is based on tenant, project and role: explicit dimensions an auditor can read and verify. Geolocation, IP address, device, unusual hours and impossible travel are still available: every authentication event lands in the access logs and is forwarded in real time via webhook to the customer's SIEM (Splunk, QRadar, Microsoft Sentinel, Elastic and others), where correlation rules and incident response live. The decision at login stays deterministic, while behavioural detection stays where you already have visibility across the whole infrastructure.
Because a risk score computed by the vendor is hard to explain to an auditor and impossible to reproduce. With policies per tenant, project and role the rule is written down, versionable and demonstrable: during a GDPR, NIS2 or ISO 27001 audit you can document exactly under which conditions strong verification is required. The model also does not need to profile user behaviour, consistent with the zero-knowledge architecture in which personal data stays inside the customer's Tenant.
You delegate authentication to LoginMaster via OpenID Connect or SAML 2.0 and configure the MFA policies per tenant, project and role. The step-by-step guide is on the dedicated page about adding 2FA and adaptive MFA to your application.
Bring conditional access to your identity
The LoginMaster team helps you define MFA policies per tenant, project and role and integrate them via OpenID Connect.