MFA Compliance for IT Teams: SOC 2, ISO 27001, and Beyond

Multi-factor authentication is no longer optional in most compliance frameworks. SOC 2, ISO 27001, PCI DSS, HIPAA, and NIST guidelines all include requirements around MFA — and increasingly, they require more than just having MFA enabled. They require documented controls, audit trails, and formal access management.

This guide covers what the major compliance frameworks expect from MFA, what "compliant MFA management" looks like in practice, and how to close the gaps that most organizations have.

Why MFA Compliance Has Gotten More Demanding

Five years ago, "we use MFA" was sufficient for most auditors. Today, it isn't.

The shift reflects real-world attack patterns. Credential stuffing, phishing, and SIM-swapping attacks have made it clear that MFA deployment without governance is a weak control. Auditors now look not just at whether MFA is enabled, but at:

• Whether all users with privileged access use MFA
• How MFA secrets are stored and protected
• Whether access to MFA codes is logged
• How access is revoked when personnel change
• Whether backup and recovery procedures exist

SOC 2 and MFA

SOC 2 (Trust Services Criteria) addresses MFA primarily under CC6.1 (Logical and Physical Access Controls):

"The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events."

In practice, SOC 2 auditors look for:

• MFA required for all privileged access — admin accounts, cloud consoles, and critical services must use MFA
• MFA for remote access — VPN and remote desktop access should require MFA
• Evidence of MFA policy — a documented policy stating who must use MFA and on which systems
• Access reviews — periodic reviews of who has access to what, including MFA-protected accounts
• Offboarding procedures — documented process for revoking MFA access when users leave

The gap most organizations have: they can demonstrate MFA is in use, but they can't demonstrate proper management. No audit logs of MFA access. No documentation of who can access which codes. No formal revocation process.

ISO 27001 and MFA

ISO 27001:2022 addresses authentication through Control 8.5 (Secure Authentication) and Control 5.18 (Access Rights):

Control 8.5 requires that authentication systems:

• Prevent unauthorized access
• Not reveal credentials after failed authentication
• Support strong passwords and MFA where appropriate
• Log authentication events

Control 5.18 requires documented procedures for:

• Granting access rights
• Changing access rights
• Revoking access rights (including on personnel change)

For MFA compliance under ISO 27001, organizations need:

• A documented MFA policy
• Evidence that MFA is enforced for appropriate systems
• Access provisioning and deprovisioning procedures
• Logs of authentication events

PCI DSS and MFA

PCI DSS v4.0 (effective 2025) significantly strengthened MFA requirements. Requirement 8.4 now mandates:

• MFA for all access into the cardholder data environment (CDE)
• MFA for all remote network access
• MFA for all administrative access to system components in the CDE

Critically, PCI DSS 4.0 requires that MFA systems:

• Are not susceptible to replay attacks
• Cannot be bypassed by any individual (including administrators)
• Generate audit logs of all authentication events

This last point is significant: PCI DSS now explicitly requires authentication audit logs. Organizations that manage OTP codes informally — without logging who generated which codes — are non-compliant.

NIST SP 800-63B and MFA

NIST 800-63B (Digital Identity Guidelines) classifies authenticators into Authenticator Assurance Levels (AAL):

• AAL1: password only
• AAL2: password + MFA (TOTP qualifies here)
• AAL3: hardware cryptographic device (YubiKey or similar)

Federal systems and contractors increasingly need to meet AAL2 or AAL3. For private organizations, NIST guidelines are influential even without regulatory mandate.

NIST 800-63B also addresses authenticator lifecycle management — how secrets are stored, protected, and revoked — which directly applies to how organizations manage OTP codes.

What "Compliant MFA Management" Looks Like

Bringing together the requirements above, compliant MFA management for an IT team includes:

1. Documented MFA policy

A written policy stating:

• Which systems and accounts require MFA
• Which users must use MFA (all privileged users at minimum)
• How MFA secrets are stored and protected
• Who is responsible for MFA management

2. Centralized code storage

OTP secrets must be stored securely — not on personal devices, not in plaintext. Encrypted storage with access control is required. A dedicated team MFA vault satisfies this requirement.

3. Access control per code

Access to specific OTP codes should be controlled based on role and business need. An employee should only be able to generate OTPs for accounts they're authorized to access.

4. Audit logging

Every MFA-related event should be logged:

• Code access (who generated a code, when)
• Code management (who added, modified, or deleted a code)
• User access changes (who was granted or revoked access)

These logs should be retained for a period defined by your compliance requirements (commonly 1 year for SOC 2, 3 years for PCI DSS).

5. Formal offboarding procedures

A documented, auditable process for revoking MFA access when personnel leave. The process should result in immediate revocation and a log entry.

6. Periodic access reviews

Regular (typically quarterly or annual) reviews of who has access to which MFA codes, confirming that access remains appropriate.

Closing the Compliance Gap

Most organizations have MFA deployed but lack the governance layer that compliance frameworks require. The gap typically includes:

• No audit logs of who accessed which OTP codes
• No access control at the individual code level
• No documented offboarding procedure for MFA access
• Codes on personal devices with no organizational control

A team MFA vault like Gatera addresses these gaps directly:

• Every access event is logged with timestamp and user identity
• Access is controlled per code with role-based permissions
• Offboarding is a single action that immediately revokes all access
• Codes are stored encrypted in an organizational system, not on personal phones

This turns MFA from a check-box into a demonstrable, auditable control.

Preparing for an Audit

When preparing for a SOC 2, ISO 27001, or PCI DSS audit, auditors will typically ask for:

1. Your MFA policy document
2. Evidence that MFA is enforced on in-scope systems (screenshots, configuration exports)
3. A sample of authentication event logs
4. Evidence of access reviews (typically a spreadsheet or report showing who has access to what)
5. An example of offboarding — documentation showing MFA access was revoked for a recent departure

Being able to pull these from a structured vault system is significantly easier than reconstructing them from informal records.

Conclusion

Compliance frameworks are moving beyond "just enable MFA" toward requiring documented management, audit trails, and formal access controls. Organizations that manage OTP codes informally — through personal phones and ad-hoc sharing — are increasingly exposed in audits.

The solution is to implement MFA management infrastructure that natively produces the audit evidence compliance frameworks require.

Try Gatera → — the team MFA vault with built-in audit logging for compliance-conscious IT teams.