Controls30 April 2026 6 min read

MFA for SOC 2: Which Accounts Need Multi-Factor Auth?

Learn which accounts require MFA for SOC 2 compliance, how to enforce it in AWS and Okta, and what evidence auditors request.

Key Takeaways

MFA is required for all accounts with access to production systems and sensitive data under CC6.2.
AWS root account MFA is a mandatory baseline — no exceptions.
Enforcing MFA at the IdP (Okta, Google Workspace) is more effective than per-application configuration.
Hardware keys (YubiKey) provide the strongest assurance; TOTP apps (Authy, Google Authenticator) are the standard minimum.
Auditors request an MFA enforcement policy screenshot and a user report showing MFA enrollment status.

In this guide

Why MFA Matters for SOC 2
Which Accounts Must Have MFA
Enforcing MFA in AWS
Enforcing MFA in Okta and Google Workspace
MFA Types and SOC 2 Acceptability
MFA Evidence for Auditors

Why MFA Matters for SOC 2

MFA directly addresses CC6.2, which requires the entity to implement authentication controls prior to allowing access to the system. Password-only authentication is widely considered insufficient for any account with access to production systems or sensitive data — phishing and credential stuffing attacks make single-factor authentication a critical vulnerability.

Auditors evaluating CC6.2 will specifically ask about MFA coverage. It is one of the first things checked in a readiness assessment, and one of the most common findings in companies that are just starting their SOC 2 journey.

Which Accounts Must Have MFA

The absolute minimum for SOC 2 compliance: (1) AWS root account and all IAM users — especially those with console access. (2) All accounts accessing production databases, servers, or S3 buckets containing customer data. (3) Your SSO provider (Okta, Google Workspace, Azure AD) — this covers downstream applications via federation. (4) Code repositories (GitHub, GitLab). (5) Cloud providers (AWS, GCP, Azure). (6) Any admin interface with access to customer data (database admin tools, admin panels).

The broader best practice is MFA for all employee accounts without exception. If your SSO enforces MFA and all applications authenticate through SSO, you achieve universal MFA coverage without per-application configuration.

Enforcing MFA in AWS

For the AWS root account: enable a virtual MFA device or hardware MFA key immediately. The root account should be locked down — no access keys, no regular use, and MFA enforced. Enable AWS Organizations to centralize management and use Service Control Policies to prevent member accounts from disabling MFA requirements.

For IAM users: attach the AWS managed policy "AWSVirtualMFADevice" plus a custom policy that denies all actions except IAM MFA-related actions until MFA is enrolled. The "deny without MFA" pattern uses a condition key: Condition: {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}.

If you use AWS IAM Identity Center (SSO), enable MFA at the Identity Center level and require MFA for all sign-ins. This is the recommended approach for new AWS environments.

Enforcing MFA in Okta and Google Workspace

In Okta: navigate to Security > Multifactor > Factor Enrollment. Set the required enrollment policy to "Required" for all users. Create an authentication policy that requires MFA for all applications or specifically for high-risk applications accessing production data.

In Google Workspace: Admin Console > Security > 2-Step Verification > Allow users to turn on 2-Step Verification, then enforce enrollment within a defined period. For admin accounts, hardware key enforcement is the strongest option.

Disable SMS-based MFA in your policy if possible — SMS OTP is vulnerable to SIM-swapping attacks and some auditors flag it as a weaker form. TOTP apps (Google Authenticator, Authy, 1Password) are the standard minimum. Hardware keys (YubiKey) are the gold standard for privileged accounts.

MFA Types and SOC 2 Acceptability

Hardware security keys (FIDO2/WebAuthn, YubiKey): strongest. Phishing-resistant. Preferred for privileged accounts. TOTP authenticator apps (Google Authenticator, Authy, 1Password): strong. Widely supported. The standard for most employee accounts. Push notifications (Okta Verify, Duo): strong but susceptible to MFA fatigue attacks (users approving requests they didn't initiate). Configure number matching to mitigate. SMS OTP: weak. Vulnerable to SIM-swapping. Avoid for production and admin accounts — acceptable only as a fallback for low-risk scenarios.

Your MFA policy should specify which factor types are allowed for which account categories. Privileged access should require TOTP minimum; hardware keys preferred. Standard employee access can use push or TOTP.

MFA Evidence for Auditors

Auditors typically request: (1) MFA enforcement policy (the written requirement). (2) Screenshot of MFA enforcement configuration in your IdP (Okta, Google Workspace) or AWS IAM. (3) MFA enrollment status report — a list of all users showing MFA enabled/disabled. Any user with MFA disabled is a potential finding. (4) For AWS specifically: screenshot of the IAM Security Status dashboard showing root account MFA enabled, and IAM credential report showing all IAM users have MFA devices attached.

Generate the IAM credential report via AWS CLI: aws iam generate-credential-report && aws iam get-credential-report. This shows MFA device enrollment for all IAM users. Export it as evidence.

Frequently Asked Questions

What if an employee refuses to enroll in MFA?

Your MFA policy should state that MFA is mandatory and non-compliance is a disciplinary matter. Technically enforce it: configure your IdP to block access to work applications until MFA is enrolled. Document the policy and enforcement mechanism as evidence that the control is mandatory, not optional.

Do service accounts and API keys need MFA?

Service accounts and API keys cannot use interactive MFA, but they should use equivalent strong authentication controls: IAM roles with scoped permissions instead of IAM users with long-lived keys, short-lived credentials via IAM roles, and IP-based restrictions where possible. Rotate API keys regularly.

Is it a SOC 2 finding if one employee hasn't enrolled in MFA?

If the auditor samples that user, it could be. More importantly, an un-enrolled account represents a real security gap. Configure your IdP to automatically disable accounts after a grace period if MFA is not enrolled, and run a weekly report to catch any stragglers.

Does MFA need to be enforced for the application itself, or just for SSO?

If the application authenticates through SSO with MFA enforced, that satisfies the requirement — you don't need per-application MFA. If any application allows direct authentication bypassing SSO, that application needs its own MFA. Disable direct authentication in applications that support SSO to avoid this gap.

How do we handle MFA for contractors and third-party vendors with system access?

Contractors with access to production systems should be enrolled in MFA just like full-time employees. Either provision them a guest account in your IdP (Okta, Google Workspace) with MFA enforced, or require them to use a hardware key. Document that MFA is required for all accounts — employee and contractor — in your access control policy.