Multi-Factor Authentication (MFA): The Complete Guide for Compliance and Security Teams

What Is Multi-Factor Authentication?

Multi-factor authentication (MFA) is a security mechanism that requires users to verify their identity using two or more independent factors before gaining access to a system, application, or data. By combining multiple authentication factors from different categories, MFA ensures that compromising a single credential (such as a password) is insufficient for an attacker to gain access.

With credential theft and phishing attacks accounting for the majority of breaches, MFA has become a baseline security control required by virtually every compliance framework including ISO 27001, SOC 2, NIS2, and DORA.

Authentication Factor Types

Factor Type	Category	Examples	Strength
Password/PIN	Something you know	Passwords, PINs, security questions	Low (phishable, guessable)
TOTP code	Something you have	Google Authenticator, Authy, Microsoft Authenticator	Medium (phishable via proxy)
SMS code	Something you have	One-time code via SMS	Low-Medium (interceptable)
Push notification	Something you have	Duo Push, Microsoft Authenticator push	Medium (susceptible to fatigue attacks)
Hardware security key	Something you have	YubiKey, Google Titan, Feitian	High (phishing-resistant)
Biometric	Something you are	Fingerprint, face recognition, iris scan	High (bound to individual)
Passkey	Something you have + are	FIDO2 synced credentials with biometric unlock	High (phishing-resistant, passwordless)

MFA Methods Comparison

Method	Phishing Resistant	User Experience	Deployment Complexity	Cost
SMS OTP	No	Medium	Low	Low
TOTP app	No	Medium	Low	Free
Push notification	No	High	Medium	Per-user licensing
Hardware security key	Yes	Medium	Medium	Per-key hardware cost
Platform biometric	Yes	High	Low	Built into devices
Passkey	Yes	Very High	Medium	Free
Smart card + PIN	Yes	Low	High	Per-card + infrastructure

Conditional Access Policies

Condition	Risk Level	MFA Requirement
Known device + known location	Low	No MFA (session token valid)
Known device + new location	Medium	MFA required
New device + any location	High	MFA required + device registration
Privileged action	High	Step-up MFA required
Admin/privileged account	Critical	MFA always required (phishing-resistant preferred)
Impossible travel detected	Critical	MFA required + security review

MFA Implementation Architecture

Component	Function	Examples
Identity provider (IdP)	Centralised authentication and MFA enforcement	Azure AD, Okta, Google Workspace, Auth0
MFA service	Second-factor verification	Duo, RSA SecurID, built-in IdP MFA
SSO integration	Single sign-on with MFA at the IdP	SAML 2.0, OIDC, OAuth 2.0
Directory service	User and group management for MFA policies	Active Directory, LDAP, SCIM
Authenticator apps	Client-side TOTP/push generation	Google Authenticator, Microsoft Authenticator, Authy
FIDO2 server	WebAuthn credential management	Built into modern IdPs

MFA Rollout Strategy

Phase	Actions	Timeline
Phase 1	Enable MFA for all administrator and privileged accounts	Week 1-2
Phase 2	Enable MFA for IT and security teams	Week 3-4
Phase 3	Enable MFA for all employees accessing sensitive systems	Month 2
Phase 4	Enable MFA for all users and external collaborators	Month 3
Phase 5	Migrate to phishing-resistant MFA (FIDO2/passkeys)	Month 4-6
Phase 6	Implement conditional access and adaptive MFA	Month 6-9

Compliance Requirements

Framework Mapping

Requirement	ISO 27001	SOC 2	NIS2	DORA
Multi-factor authentication	A.8.5	CC6.1	Art. 21(2)(j)	Art. 9(4)(c)
Privileged access controls	A.8.2	CC6.3	Art. 21(2)(i)	Art. 9(4)(c)
Access review	A.5.18	CC6.2	Art. 21(2)(i)	Art. 9(2)
Authentication logging	A.8.15	CC7.2	Art. 21(2)(g)	Art. 10(2)
Remote access security	A.8.1	CC6.6	Art. 21(2)(j)	Art. 9(4)(c)
Password policy	A.8.5	CC6.1	Art. 21(2)(j)	Art. 9(4)(b)

Audit Evidence

Evidence Type	Description	Framework
MFA policy	Documented policy requiring MFA for specified user groups	All frameworks
MFA enrollment report	Percentage of users with MFA enabled by method type	All frameworks
Conditional access rules	Configuration of risk-based MFA policies	ISO 27001, SOC 2
Authentication logs	Records showing MFA challenges and results	All frameworks
MFA exception register	Documented exceptions with risk acceptance and review dates	All frameworks
Privileged account audit	Evidence that all privileged accounts have MFA enabled	All frameworks
Recovery procedure documentation	Process for MFA reset and account recovery	ISO 27001, SOC 2

Common Mistakes

Mistake	Risk	Fix
MFA for admins only	Regular user accounts compromised via phishing	Enable MFA for all users, starting with high-risk groups
Relying solely on SMS	SIM swapping and interception attacks	Migrate to TOTP apps, push, or FIDO2 security keys
No MFA for service accounts	Privileged service accounts compromised	Use certificate-based auth or managed identities for service accounts
MFA fatigue vulnerability	Users approve fraudulent push notifications	Implement number matching, limit push attempts, use FIDO2
No MFA bypass procedures	Users locked out with no recovery path	Document and test recovery procedures with identity verification
Excluding legacy applications	Unprotected entry points into the environment	Use reverse proxy or VPN with MFA for legacy apps

How Orbiq Supports MFA Compliance

Orbiq helps you demonstrate authentication security controls:

Evidence collection — Centralise MFA policies, enrollment reports, and authentication logs
Continuous monitoring — Track MFA adoption rates and authentication security posture
Trust Center — Share your authentication security controls via your Trust Center
Compliance mapping — Map MFA controls to ISO 27001, SOC 2, NIS2, and DORA
Audit readiness — Pre-built evidence packages for auditor review