Multi-Factor Authentication

Overview#

The Multi-Factor Authentication module adds a second layer of verification beyond the password, spanning authenticator apps, hardware security keys, biometrics, and SMS codes. Risk-based logic means that users authenticating from familiar devices and locations face minimal friction, while unfamiliar or high-risk contexts require stronger verification.

For organisations handling classified information, patient records, or financial data, the FIDO2 hardware key and biometric options provide phishing-resistant authentication aligned with the higher NIST SP 800-63B assurance levels.

Key Features#

• Authenticator App Support (TOTP): Industry-standard time-based one-time passwords compatible with all major authenticator apps including Google Authenticator, Microsoft Authenticator, Authy, 1Password, Duo Mobile, and any RFC 6238-compliant application. QR code enrolment completes setup in under a minute.

• SMS and Voice Authentication: Mobile-based verification via SMS text messages and voice calls with wide international coverage. Multi-language support with automatic carrier detection and failover between providers for reliable delivery.

• Biometric Authentication: Fingerprint, facial recognition, and voice recognition support across iOS (Face ID, Touch ID), Android (BiometricPrompt), Windows (Windows Hello), and web browsers (WebAuthn/FIDO2). Biometric data never leaves the user's device.

• Hardware Security Keys (FIDO2): Phishing-resistant authentication with physical security keys including YubiKey, Google Titan, and other FIDO2-compliant devices. Supports passwordless authentication with resident credentials and passkeys, meeting the highest assurance level requirements.

• Backup Codes and Recovery: Emergency single-use backup codes with multiple recovery options including recovery email, recovery phone, trusted contacts, and administrator-assisted recovery, so users can regain access even after losing every enrolled device.

• Risk-Based Authentication: Intelligent analysis of device trust, location, behavioural patterns, and network reputation determines when MFA is needed. Trusted devices and networks receive reduced friction; unfamiliar contexts trigger stronger verification automatically.

• Step-Up Authentication: Sensitive operations such as changing security settings, accessing classified data, or performing administrative actions require additional verification regardless of the initial login risk score. Weakening protection is itself a step-up operation: disabling MFA or removing a passkey demands a verified fresh password proof, and the check fails closed, so a rejected or failed proof always aborts the change.

• Hardened Challenge Tokens: The temporary token issued mid-login, while a user still owes a second factor, is structurally distinct from a real session credential. It carries a dedicated token type recognisable before payload inspection, and every session validation path explicitly rejects any pending-MFA marker. These two independent defences ensure that an attacker who obtains a pending-MFA token gains no access; only the dedicated MFA verification endpoints accept it.

• Consistent Enforcement Across Web and Mobile: Accounts required to use a passkey, typically administrators and other high-risk roles, cannot satisfy multi-factor login with a one-time code on the native mobile flow. Mobile verification routes through the same canonical factor-policy check as the web and fails closed when a passkey is mandated, before any code is evaluated, even if the challenge context omits the requirement marker. Mobile password login advertises only the factors an account is actually allowed to use.

• Independent Offline-Unlock Key Rotation: The mobile offline-unlock feature supports a dedicated signing secret that can be rotated on its own schedule, independently of the platform's session-signing material, so mobile offline access can be re-keyed without touching session infrastructure.

• Self-Service MFA Management: Users enrol and manage their own MFA devices, generate backup codes, and configure recovery methods through an intuitive self-service portal, reducing helpdesk burden without reducing security. Authenticator enrolment secrets stay hidden by default: they are revealed only on explicit user action and cleared when the enrolment dialog closes. These protections apply uniformly across every application that embeds the shared security screen, with accessible, multilingual labels throughout.

Supported Authentication Methods#

Use Cases#

• Law enforcement agencies and intelligence organisations requiring phishing-resistant FIDO2 hardware keys for access to classified investigation systems.
• Government departments meeting NIST 800-63B AAL2 and AAL3 requirements for authenticator assurance levels.
• Financial institutions satisfying PCI DSS MFA requirements across cardholder data environments with minimal staff friction.
• Healthcare providers balancing HIPAA access control requirements with the speed clinical staff need during patient care.
• Critical infrastructure operators deploying hardware key authentication for operational technology access where credential theft would have physical consequences.

Open Standards#

• FIDO2 / W3C Web Authentication (WebAuthn Level 3): Hardware security keys, platform authenticators, and passkeys are registered and verified using the full WebAuthn registration and authentication ceremony, including attestation and assertion handling.
• NIST SP 800-63B (Digital Identity Guidelines): Risk-based authentication thresholds and method requirements are aligned to Authenticator Assurance Levels AAL1, AAL2, and AAL3 as defined in this guideline.
• RFC 6238 (TOTP): Authenticator-app one-time passwords are generated and validated using the Time-Based One-Time Password algorithm; any RFC 6238-compliant application can be enrolled.
• RFC 4226 (HOTP): The HMAC-based one-time password algorithm that underpins TOTP is implemented as defined in this specification, including the counter and truncation logic.
• RFC 8176 (Authentication Method Reference Values): Tokens issued after MFA carry standardised authentication method reference (amr) claim values, such as otp and hwk, to communicate the authentication methods used to downstream services.
• RFC 7519 (JSON Web Token): Access tokens and step-up tokens are issued as JSON Web Tokens signed with RS256, carrying claims that record the authentication methods used and whether step-up verification has taken place, for downstream authorisation decisions.
• OpenID Connect Core 1.0 / OAuth 2.0 (RFC 6749): External SSO and OIDC callback provisioning integrates with identity providers using these protocols, enabling federated MFA enforcement across partner organisations.

Getting Started#

1. Enable MFA Policies: Configure which authentication methods are available and which are required for your organisation.
2. User Enrolment: Launch self-service enrolment for users to set up their preferred MFA methods.
3. Configure Risk Thresholds: Set risk score boundaries to determine when additional authentication is required.
4. Monitor Adoption: Track MFA enrolment and usage through the authentication analytics dashboard.

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16