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.
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.
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.