Multi-Factor Authentication

Multi-factor authentication (MFA) requires users to present two or more independent pieces of evidence before the identity provider grants access. Each piece of evidence belongs to a distinct category: something the user knows, something the user possesses, or something the user is. The independence of these categories means that compromising one factor does not automatically compromise another, forcing attackers to defeat multiple distinct security mechanisms to impersonate a legitimate user.

Authentication factor: A category of evidence used to verify identity. The three recognised categories are knowledge factors (passwords, PINs), possession factors (phones, hardware tokens), and inherence factors (biometrics).
Phishing-resistant MFA: Authentication methods that cryptographically bind credentials to specific origins, preventing credential theft even when users interact with convincing fake login pages.
MFA fatigue: Attack technique where adversaries repeatedly trigger push notifications until the target approves one out of frustration or confusion.

Factor categories

The security model of MFA depends on the genuine independence of factor categories. Two passwords provide no additional security over one password because both belong to the knowledge category and share the same vulnerabilities: keyloggers capture both, phishing harvests both, and database breaches expose both. True multi-factor authentication combines categories so that the attack surface for each factor differs fundamentally from the others.

Knowledge factors consist of information the user memorises. Passwords represent the dominant knowledge factor, though PINs, security questions, and passphrases also qualify. Knowledge factors share a fundamental weakness: they can be transmitted perfectly. An attacker who learns a password possesses it as completely as the legitimate user does. Phishing attacks exploit this property by convincing users to type their passwords into attacker-controlled forms. Database breaches expose stored password hashes that attackers crack offline. Keyloggers and shoulder surfing capture passwords during entry. Despite these weaknesses, knowledge factors remain necessary because they require no hardware, work across all devices, and can be changed instantly when compromised.

Possession factors require the user to control a specific physical object or device. The security assertion derives from something unique to that object: a cryptographic key stored in secure hardware, a SIM card receiving SMS messages, or a time-synchronised seed generating one-time codes. Unlike knowledge factors, possession factors cannot be transmitted perfectly. An attacker who intercepts a one-time code possesses only that single code, which expires within seconds. Stealing a possession factor requires either physical theft of the device or compromise of the cryptographic material that makes it unique. The primary weakness of possession factors is availability: users lose phones, forget hardware tokens, and travel to locations without reliable mobile coverage.

Inherence factors authenticate users based on physical or behavioural characteristics. Fingerprint readers, facial recognition systems, and iris scanners measure biological traits assumed to be unique to each individual. Behavioural biometrics analyse patterns in typing rhythm, mouse movement, or gait. Inherence factors resist theft because they cannot be separated from the user’s body. However, they present unique challenges for organisations: biometrics cannot be changed if compromised, they require specialised sensors on every authentication device, and they raise privacy concerns around the collection and storage of biological data. False rejection rates frustrate legitimate users while false acceptance rates create security gaps.

+--------------------------------------------------------------------+
|                       AUTHENTICATION FACTORS                       |
+--------------------------------------------------------------------+
|                                                                    |
|  +------------------+  +------------------+  +------------------+  |
|  |    KNOWLEDGE     |  |   POSSESSION     |  |    INHERENCE     |  |
|  |                  |  |                  |  |                  |  |
|  |  - Password      |  |  - Mobile phone  |  |  - Fingerprint   |  |
|  |  - PIN           |  |  - Hardware key  |  |  - Face          |  |
|  |  - Passphrase    |  |  - Smart card    |  |  - Iris          |  |
|  |  - Secret Q&A    |  |  - SIM card      |  |  - Voice         |  |
|  |                  |  |  - Crypto wallet |  |  - Typing rhythm |  |
|  +--------+---------+  +--------+---------+  +--------+---------+  |
|           |                     |                     |            |
|           v                     v                     v            |
|  +------------------+  +------------------+  +------------------+  |
|  |   Vulnerability  |  |   Vulnerability  |  |   Vulnerability  |  |
|  |                  |  |                  |  |                  |  |
|  |  Transmissible:  |  |  Requires theft  |  |  Cannot change   |  |
|  |  phishing,       |  |  or cloning of   |  |  if compromised; |  |
|  |  keyloggers,     |  |  physical object |  |  requires sensor |  |
|  |  breaches        |  |  or crypto keys  |  |  on every device |  |
|  +------------------+  +------------------+  +------------------+  |
|                                                                    |
+--------------------------------------------------------------------+

Figure 1: Authentication factor categories with distinct vulnerability profiles

The combination of factors matters more than the specific methods chosen. A fingerprint plus a security question combines inherence with knowledge, providing genuine multi-factor protection. A password plus a different password provides only single-factor protection despite requiring two inputs. This distinction becomes important when evaluating authentication solutions that claim multi-factor support: verify that the factors belong to genuinely distinct categories.

Authentication methods

Within each factor category, multiple implementation methods exist with varying security properties, deployment complexity, and user experience characteristics. The choice of method determines not only security posture but also operational overhead, helpdesk burden, and user acceptance.

Time-based one-time passwords

Time-based one-time password (TOTP) algorithms generate six or eight digit codes that change every 30 seconds. The authenticator application and the server share a secret seed, typically 160 bits encoded as a base32 string. Both parties combine this seed with the current Unix timestamp divided by 30 (the time step), then apply HMAC-SHA1 to produce identical outputs. The authenticator displays the resulting code; the server accepts codes matching the current time step or, to accommodate clock drift, one step before and after.

TOTP requires no network connectivity at authentication time. Once a user enrolls by scanning a QR code containing the seed, their authenticator application generates valid codes indefinitely without contacting any server. This property makes TOTP valuable for field deployments where mobile data is expensive or unavailable. Users can authenticate to systems from locations with no cellular coverage as long as their device clock remains reasonably accurate.

The security boundary of TOTP lies in the shared seed. An attacker who obtains the seed, whether by intercepting the QR code during enrollment, extracting it from a compromised server database, or cloning a device backup, can generate valid codes indefinitely. TOTP codes also remain vulnerable to real-time phishing: an attacker operating a fake login page can relay the code to the real server before it expires. This 30-second window gives attackers sufficient time for automated relay attacks, though it prevents bulk credential harvesting.

Enrollment generates the seed once; users cannot re-display it later. If a user loses their authenticator device without backup codes, recovery requires administrator intervention to reset MFA enrollment. Organisations should generate and securely store 8 to 10 backup codes at enrollment time, each valid for single use.

Push notifications

Push-based authentication sends a notification to a registered mobile application, prompting the user to approve or deny the login attempt. The notification typically displays context about the request: the application being accessed, the geographic location inferred from IP address, and the device or browser making the request. The user reviews this context and taps approve if they initiated the request.

Push authentication improves user experience over TOTP by eliminating manual code entry. Users tap once rather than opening an authenticator, reading a code, and typing six digits before timeout. This convenience increases MFA adoption rates and reduces authentication errors. Push also enables richer context display than a numeric code can convey, helping users identify unexpected access attempts.

The security model of push authentication depends on users actually reviewing notifications before approval. In practice, many users develop automatic approval habits, tapping accept without examining context. Attackers exploit this through MFA fatigue attacks: after obtaining valid credentials through phishing or purchase, the attacker initiates repeated login attempts, generating a stream of push notifications. Eventually the target approves one to stop the notifications, believing the system is malfunctioning, or accidentally taps approve while dismissing other notifications. Documented attacks using this technique have compromised high-value targets at major technology companies.

Mitigations for MFA fatigue include number matching, where the login screen displays a two-digit number the user must enter in the authenticator app rather than simply tapping approve. This confirms the user is viewing both screens and defeats automated approval. Rate limiting that blocks push notifications after three consecutive denials prevents indefinite notification spam. Anomaly detection that flags unusual login patterns can alert security teams to ongoing fatigue attacks.

SMS and voice codes

Short message service (SMS) delivers one-time codes to registered phone numbers. Voice-based authentication speaks codes aloud to landline or mobile numbers. Both methods leverage the global telephone network as a possession factor, requiring control of a specific phone number.

SMS authentication is the weakest widely deployed possession factor. SIM swapping attacks convince mobile carriers to transfer a victim’s phone number to an attacker-controlled SIM card, after which the attacker receives all SMS messages. These attacks require social engineering carrier support staff or exploiting carrier security weaknesses rather than any technical attack on the victim. SS7 protocol vulnerabilities allow sophisticated attackers to intercept SMS messages in transit without controlling the destination SIM. Malware on mobile devices can read incoming SMS messages and forward them to attackers.

Despite these weaknesses, SMS authentication provides substantial improvement over passwords alone. The attacks described require targeted effort against specific individuals; they do not scale to bulk credential harvesting. For organisations whose threat model does not include sophisticated targeted attacks, SMS MFA blocks the vast majority of credential-based intrusions. The ubiquity of SMS, which works on any mobile phone without application installation, makes it the only practical MFA option for some user populations.

Hardware security keys

Hardware security keys are physical devices containing cryptographic keys that never leave the secure element. The FIDO2 standard, comprising WebAuthn for browser interaction and CTAP for device communication, defines how these keys authenticate users to websites and applications without transmitting secrets.

During registration, the security key generates a public-private key pair unique to that website. The private key remains permanently in the key’s secure element; the public key is sent to the server. During authentication, the server sends a challenge (random bytes), and the security key signs this challenge with the private key. The server verifies the signature using the stored public key. At no point does any secret travel over the network.

The origin binding of FIDO2 provides phishing resistance. Before signing any challenge, the security key verifies that the requesting origin matches the origin recorded at registration. A security key registered with login.example.org will refuse to sign challenges from login.examp1e.org regardless of how convincing the phishing page appears to the user. This cryptographic binding defeats phishing attacks entirely rather than merely making them harder.

Hardware keys require physical presence during authentication, typically indicated by touching a button on the key. This confirms that a human is present and prevents remote malware from using the key without user knowledge. USB-A, USB-C, NFC, and Lightning connections support different device ecosystems. Leading manufacturers include Yubico (YubiKey), Google (Titan), and Feitian.

The primary limitation of hardware keys is deployment logistics. Each key costs £20 to £50. Users need backup keys in case of loss, effectively doubling deployment cost. Key distribution to remote staff requires secure shipping. Users working across multiple devices need keys compatible with each connection type, or multiple keys.

+--------------------------------------------------------------------+
|                     FIDO2 AUTHENTICATION FLOW                      |
+--------------------------------------------------------------------+

  User                Browser              Server              Security Key
    |                    |                    |                      |
    |---(1) Login------->|                    |                      |
    |    attempt         |                    |                      |
    |                    |                    |                      |
    |                    |---(2) Request----->|                      |
    |                    |    credential      |                      |
    |                    |                    |                      |
    |                    |<--(3) Challenge----|                      |
    |                    |    + credential IDs|                      |
    |                    |    + origin        |                      |
    |                    |                    |                      |
    |                    |---(4) Verify-------|--------------------->|
    |                    |    origin match    |                      |
    |                    |                    |                      |
    |<----------------(5) Touch prompt------------------------------ |
    |                    |                    |                      |
    |------------------(6) User touches----------------------------->|
    |                    |                    |                      |
    |                    |<---(7) Signed------|----------------------|
    |                    |    assertion       |                      |
    |                    |                    |                      |
    |                    |---(8) Assertion--->|                      |
    |                    |                    |                      |
    |                    |                    |---(9) Verify-------->|
    |                    |                    |    signature with    |
    |                    |                    |    stored public key |
    |                    |                    |                      |
    |                    |<-(10) Authenticated|                      |
    |                    |                    |                      |
    |<-(11) Access-------|                    |                      |
    |    granted         |                    |                      |
    |                    |                    |                      |

Figure 2: FIDO2 authentication flow showing origin verification and challenge-response

Passkeys

Passkeys extend FIDO2 credentials with cloud synchronisation, addressing the backup and recovery challenges of hardware-bound keys. When a user creates a passkey on one device, the credential synchronises through the platform vendor’s cloud (Apple iCloud Keychain, Google Password Manager, or Microsoft account) to all the user’s devices running that platform. Loss of a single device no longer results in account lockout because the passkey exists on other devices and in encrypted cloud backup.

Passkeys retain the phishing resistance of FIDO2 because they use the same origin-bound cryptographic authentication. The private key remains protected within platform secure enclaves (Apple Secure Enclave, Android Titan M, Windows TPM) and synchronises only in encrypted form. Local authentication via device biometrics or PIN authorises passkey use, adding an inherence or knowledge factor to the possession factor of the synchronised credential.

The tradeoff for synchronisation convenience is expanded attack surface. An attacker who compromises a user’s cloud account gains access to synchronised passkeys. Platform vendors implement additional protections, including requiring recent device authentication before passkey synchronisation and excluding passkeys from account recovery flows, but the attack surface differs from hardware keys where the private key exists only in tamper-resistant silicon.

For organisations, passkey deployment reduces support burden compared to hardware keys. Users self-enroll using devices they already own. Lost device recovery occurs through platform account recovery rather than IT intervention. Cross-platform support remains limited as of 2024, with passkeys not yet synchronising between Apple and Google ecosystems, though work on standardised cross-platform transfer continues.

Method comparison

The following table compares authentication methods across dimensions relevant to deployment decisions. Security rating reflects resistance to common attack techniques; operational complexity reflects ongoing support burden.

Method	Phishing resistance	Offline capable	Device requirement	Recovery complexity	Deployment cost
TOTP	None	Yes	Smartphone or token	Moderate (backup codes)	Low
Push notification	None	No	Smartphone with app	Low (re-register device)	Low
SMS	None	No	Any mobile phone	Low (phone number transfer)	Low
Hardware key (FIDO2)	Full	Yes	Dedicated hardware	High (backup key required)	High
Passkey	Full	Yes	Platform-enrolled device	Low (cloud recovery)	Low

Security ratings require context. TOTP and push provide strong protection against bulk credential attacks, password spraying, and opportunistic account compromise. For organisations whose threat model centres on these attacks, the absence of phishing resistance presents acceptable residual risk. Organisations facing targeted attacks from sophisticated adversaries, including those operating in high-risk contexts with state-level threats, should prioritise phishing-resistant methods for staff with access to sensitive systems.

Deployment patterns

MFA deployment requires balancing security requirements against user experience, operational capacity, and the diversity of authentication scenarios across the organisation. A single MFA policy rarely fits all contexts; effective deployment recognises different risk levels and user populations.

Risk-based authentication

Risk-based authentication adjusts MFA requirements based on context signals. Rather than prompting for MFA on every authentication, the system evaluates risk indicators: Is this a recognised device? Does the IP address match previous logins? Is the login time consistent with user patterns? Does the geographic location indicate impossible travel? Low-risk authentications proceed with the primary factor alone; elevated-risk authentications require additional factors or step-up verification.

The risk engine assigns scores based on configured rules. A login from a recognised corporate device, from an IP address within the office network, during normal working hours, receives a low risk score. The same credentials used from an unrecognised device, from an IP address geolocated to a different country, at 3 AM, receives a high risk score triggering MFA.

Risk-based authentication reduces MFA friction for routine access while maintaining protection for anomalous access. Users working from consistent locations and devices experience fewer MFA prompts, improving productivity and reducing MFA fatigue. The approach requires tuning to organisational patterns; overly sensitive scoring creates excessive prompts while insufficient sensitivity misses genuine threats.

Tiered requirements

Different roles require different MFA strength based on the sensitivity of systems they access. A tiered model matches authentication requirements to risk:

Tier 1 applies to all staff and requires at minimum TOTP or push-based MFA for all cloud applications and VPN access. This tier blocks bulk credential attacks and provides substantial security improvement over passwords alone.

Tier 2 applies to staff accessing financial systems, HR data, or donor information, and requires phishing-resistant MFA (hardware keys or passkeys). These roles present attractive targets for spear phishing; phishing resistance closes that attack vector.

Tier 3 applies to IT administrators, security staff, and anyone with privileged access to infrastructure. This tier requires hardware security keys specifically, with passkeys not permitted due to cloud synchronisation risks. Administrative access to identity systems, cloud infrastructure, and security tools demands the strongest authentication available.

Enrollment workflow

MFA enrollment converts users from single-factor to multi-factor authentication. The enrollment process must be mandatory and time-bounded to prevent indefinite operation with passwords alone, yet provide sufficient support for users encountering difficulties.

A typical enrollment timeline begins with advance communication explaining the change, its purpose, and available support resources. The enrollment window opens with self-service registration: users log in and follow guided setup for their chosen method. Daily reminder emails notify users who have not enrolled. After 14 days, accounts without MFA enabled are blocked from sensitive applications, with access to a self-service enrollment portal maintained. Users unable to self-enroll receive direct IT support.

Enrollment should register backup methods alongside primary methods. Users enrolling with a hardware key should also enroll backup codes. Users enrolling with push notifications should generate TOTP backup codes. This redundancy prevents lockouts when primary methods become unavailable.

Field deployment considerations

Organisations operating in field contexts face unique MFA challenges. Mobile network coverage is inconsistent, making push notifications and SMS unreliable. Internet connectivity for cloud-based verification may be unavailable or prohibitively expensive. Shared devices in field offices complicate device-based authentication.

TOTP emerges as the most field-appropriate method because it requires no network connectivity at authentication time. Once enrolled, users generate valid codes indefinitely from an offline authenticator application. The authenticator application can run on basic smartphones; it need not be the same device used for work.

Hardware keys function equally well offline and provide phishing resistance, but the cost of key distribution to remote field locations and the difficulty of replacing lost keys in areas without reliable shipping make them impractical for many field deployments. Reserve hardware keys for field staff handling the most sensitive data, such as protection or safeguarding information.

Shared device scenarios, where multiple users access a single computer in a field office, require careful design. Per-user TOTP works because each user has their own authenticator. Push notifications fail because the device identity is shared. Hardware keys work well because each user carries their own key. Where field offices use shared devices for beneficiary-facing services, those systems should authenticate staff separately from the shared device itself.

For devices crossing borders or operating in hostile environments, see Device Security in Hostile Environments for additional considerations around duress modes and forensic resistance.

+------------------------------------------------------------------+
|                   MFA SUITABILITY BY CONTEXT                     |
+------------------------------------------------------------------+
|                                                                  |
|  OFFICE / RELIABLE CONNECTIVITY                                  |
|  +------------------------------------------------------------+  |
|  |  Recommended: Push notifications or passkeys               |  |
|  |  Alternative: TOTP with authenticator app                  |  |
|  |  High-privilege: Hardware security keys mandatory          |  |
|  +------------------------------------------------------------+  |
|                                                                  |
|  FIELD / INTERMITTENT CONNECTIVITY                               |
|  +------------------------------------------------------------+  |
|  |  Recommended: TOTP (offline capable)                       |  |
|  |  Alternative: Hardware keys (if distribution feasible)     |  |
|  |  Avoid: Push notifications, SMS (connectivity dependent)   |  |
|  +------------------------------------------------------------+  |
|                                                                  |
|  HIGH-RISK / HOSTILE ENVIRONMENT                                 |
|  +------------------------------------------------------------+  |
|  |  Recommended: Hardware keys (FIDO2)                        |  |
|  |  Alternative: TOTP on dedicated device                     |  |
|  |  Avoid: Passkeys (cloud sync risks), biometrics (coercion) |  |
|  +------------------------------------------------------------+  |
|                                                                  |
|  SHARED DEVICES                                                  |
|  +------------------------------------------------------------+  |
|  |  Recommended: Hardware keys (per-user)                     |  |
|  |  Alternative: TOTP on personal devices                     |  |
|  |  Avoid: Push (device-bound), passkeys (device-bound)       |  |
|  +------------------------------------------------------------+  |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: MFA method suitability by operational context

Attack resistance

Understanding how attackers defeat MFA informs defensive choices. The goal is not perfect security but rather raising attack cost above attacker willingness to invest.

Phishing and real-time relay

Traditional phishing captures credentials for later use. Because MFA codes expire rapidly, attackers adapted to real-time relay: the phishing site proxies traffic to the legitimate site, captures the MFA code as the user enters it, and immediately uses it. From the server perspective, the authentication appears legitimate.

Real-time relay attacks require operational infrastructure: a convincing phishing site, a proxy system, and an attacker ready to exploit captured sessions before timeout. This complexity exceeds most bulk credential attackers’ capabilities but remains achievable for targeted attacks against specific individuals.

Only phishing-resistant methods (FIDO2 hardware keys and passkeys) defeat real-time relay. Origin verification occurs in the security key before any response is generated; the attacker’s proxy domain fails verification even if visually indistinguishable from the legitimate site.

MFA fatigue and push abuse

Attackers with valid passwords repeatedly trigger push notifications until the target approves one. This attack succeeds because it exploits human behaviour rather than technical weakness. Users approve requests to stop notification spam, to address perceived system errors, or by accident while managing other notifications.

Defences include number matching (user must enter a displayed number rather than simply approving), rate limiting (block notifications after consecutive denials), and alerting (notify security team of repeated denied attempts). Some organisations implement push notification cooling periods: after five denied attempts in one hour, push is disabled for that account for 24 hours, requiring backup method use.

SIM swapping and SS7 interception

SIM swapping attacks convince mobile carriers to transfer a victim’s phone number to an attacker-controlled SIM. The attacker typically gathers personal information about the target, then contacts the carrier claiming to have lost their phone and requesting transfer to a new SIM. Once successful, the attacker receives all SMS messages including MFA codes.

SS7, the signalling protocol underlying global telephone networks, contains vulnerabilities allowing traffic interception. Attackers with SS7 access can redirect SMS messages without the victim or carrier detecting the interception.

Both attacks require targeted effort and are not scalable to bulk attacks. Organisations facing sophisticated adversaries should avoid SMS MFA entirely. For other organisations, SMS provides meaningful protection despite these theoretical weaknesses.

Authenticator compromise

Malware on mobile devices can read TOTP seeds from authenticator applications lacking secure storage, screen capture codes as they display, or intercept push notifications before users see them. Endpoint security on authentication devices matters even when those devices are personal rather than corporate.

For organisations unable to enforce endpoint security on personal devices, hardware security keys isolate the authentication credential in tamper-resistant hardware that malware cannot access.

Recovery mechanisms

Every MFA deployment must plan for credential loss. Users lose phones, forget hardware keys, and change devices. Without recovery mechanisms, MFA becomes a denial of service against the organisation’s own staff.

Backup codes consist of 8 to 10 single-use codes generated at enrollment. Users store these codes securely, perhaps printed and kept with important documents. Each code authenticates once, then becomes invalid. Backup codes should be sufficiently long (8+ characters) to prevent guessing and should not follow predictable patterns.

Secondary method registration allows users to register multiple MFA methods. A user with both push notification and TOTP can use TOTP when their phone has no connectivity. A user with both a primary and backup hardware key can use the backup when the primary is lost. Secondary methods should be registered at initial enrollment, not during recovery, to prevent attackers from registering their own method during account compromise.

Administrator reset provides last-resort recovery when users have exhausted backup mechanisms. The identity verification process must be robust: in-person verification, video call with manager attestation, or verification questions established at hire. Weak administrator reset processes become the primary attack vector against MFA. An attacker who cannot defeat MFA technically will call the helpdesk claiming to be a locked-out user.

Temporary bypass grants time-limited access without MFA for users in verified recovery situations. Bypass periods should be short (24 to 48 hours maximum) and should log all access for later review. Bypass should require manager approval and should not be self-service.

Implementation considerations

For organisations with limited IT capacity

Begin with TOTP using standard authenticator applications (Aegis Authenticator on Android, Raivo OTP on iOS for open source options; Google Authenticator or Microsoft Authenticator as widely familiar alternatives). Authenticator applications require no server infrastructure beyond MFA-capable identity providers.

Enroll backup codes at the same time as primary TOTP. Store backup procedures in accessible documentation so that whoever handles IT support can assist with recovery.

Avoid SMS as the primary MFA method, but accept it as a backup for users who cannot use authenticator applications. The security improvement over passwords alone outweighs SMS weaknesses for most threat models.

Set conditional access policies in your identity provider to require MFA for all cloud application access. Most identity platforms (Microsoft Entra ID, Google Workspace, Okta, Keycloak) include MFA capability without additional licensing.

Target 14 days for mandatory enrollment. Communicate in advance, provide simple instructions with screenshots, and offer direct support sessions for users who struggle.

For organisations with established IT functions

Implement tiered MFA requirements matching authentication strength to role sensitivity. All staff require at minimum TOTP or push; staff accessing sensitive data require phishing-resistant methods; administrators require hardware keys.

Deploy number matching for push notifications to mitigate MFA fatigue attacks. Configure rate limiting to disable push after three consecutive denials.

Evaluate passkey deployment for general staff as device ecosystem support matures. Passkeys provide phishing resistance with lower operational overhead than hardware key distribution.

Procure hardware security keys for privileged roles. Budget for two keys per user (primary and backup). Establish secure distribution channels for remote staff. Document lost key procedures including temporary bypass and replacement shipping.

Configure risk-based authentication policies to reduce MFA friction for low-risk access patterns. Test policies against actual usage patterns before enabling enforcement to avoid excessive prompting.

For high-risk operating contexts

Mandate hardware security keys for staff handling sensitive programmes, protection data, or communications in surveilled environments. Do not permit passkeys for these roles due to cloud synchronisation risks.

Procure hardware keys from multiple vendors to reduce supply chain risk. Store backup keys in secure locations separate from primary keys.

Consider the coercion implications of biometric authentication. Fingerprint and face recognition can be compelled in ways passwords cannot. For staff who might face device inspection under duress, knowledge factors or hardware keys offer better protection than biometrics.

Establish out-of-band verification procedures for MFA reset requests. In hostile environments, attackers may impersonate staff to helpdesks. Verification should require callbacks to known numbers or in-person confirmation.

Review Secure Communications Under Surveillance for additional guidance on protecting authentication in monitored environments.