Theme comparison · multi-factor-authentication
MFA requirements by framework
Compare MFA requirements across SOC 2, ISO 27001, GDPR, and HIPAA, with control mappings, risk expectations, phishing resistance, and SaaS evidence.
Frameworks covered: SOC 2, ISO/IEC 27001, GDPR, HIPAA
Key differences
| Dimension | Approach A | Approach B |
|---|---|---|
| SOC 2 | CC6 logical-access criteria require authentication controls aligned to risk, commitments, and system design. | MFA is not named as universally mandatory, but missing MFA for privileged, remote, or production access commonly creates a difficult control gap. |
| ISO 27001 | A.5.17 covers authentication information and A.8.5 requires secure authentication technologies and procedures based on restrictions. | The SoA and risk treatment explain scope; authentication strength should reflect privilege, exposure, and information classification. |
| GDPR | Article 32 requires appropriate security measures considering risk, cost, state of the art, and processing context. | MFA is a strong accountability measure for systems holding personal data, especially administrative and remote access, but the Regulation is technology-neutral. |
| HIPAA | §164.312(d) requires person or entity authentication, while §164.312(a) governs access controls for ePHI. | The text does not expressly mandate MFA; the risk analysis must support authentication choices for workforce, vendors, remote access, and privileged users. |
| Priority population | All four frameworks strongly support MFA first for cloud administrators, production access, source control, IdP, VPN, finance, and support impersonation. | Customer end-user MFA may depend on product risk and commitments, but privileged staff exceptions need especially rigorous treatment. |
| Factor quality | SMS and OTP provide improvement over passwords but remain vulnerable to phishing, interception, and push fatigue. | FIDO2/WebAuthn passkeys or hardware keys provide stronger phishing resistance and are preferred for high-impact administrative paths. |
| Evidence | IdP policies, enrolled-user exports, conditional-access rules, admin-role lists, auth logs, exception tickets, and periodic reviews prove operation. | Screenshots alone are weak when they omit population, enforcement state, bypass paths, service accounts, or observation-period history. |
Control overlap
A centralized identity provider can create one MFA evidence stream for all four frameworks. Map enforced policies and authentication logs to /controls/soc-2/cc6-1, ISO A.5.17 and A.8.5, GDPR Article 32, and /controls/hipaa/164-312-d. Maintain a reconciled population of workforce users, privileged roles, contractors, break-glass accounts, and interactive service identities; show enrollment and enforcement rather than policy intent alone. Differences lie in rationale and scope: SOC 2 follows system commitments, ISO follows ISMS risk treatment and SoA, GDPR assesses risk to people, and HIPAA follows actual ePHI access. Product-customer MFA and workforce MFA should be evaluated separately.
Sequencing advice
For SaaS, secure the identity provider itself first, then production cloud, source control, CI/CD, password manager, support consoles, finance, and remote administration. Remove legacy protocols and shared accounts before claiming coverage; enroll phishing-resistant factors for administrators and configure two controlled break-glass accounts with monitoring and periodic tests. Expand conditional access to the workforce and high-risk customer actions, then measure exceptions and bypasses from logs. Store monthly enforcement exports for the SOC 2 window, map the design into the ISO SoA, and retain GDPR/HIPAA risk decisions. Give every exception an owner, compensating control, expiry, and migration date.