How do I collect MFA evidence for SOC 2?
What Auditors Check for MFA
The distinction that matters: MFA must be enforced, not just enabled. If MFA is optional and three team members haven't set it up, that's a finding.
Auditors check two things:
- The system is configured to require MFA (configuration evidence)
- All users have MFA active (population evidence)
Where to Collect MFA Evidence
| System | What to Screenshot | Why It Matters |
|---|---|---|
| Google Workspace / Okta | Admin settings showing "Enforce MFA for all users" | Primary identity provider |
| AWS Console | IAM policy requiring MFA for console access | Cloud infrastructure |
| GitHub | Organization settings showing "Require 2FA" | Code repository |
| Application admin panel | MFA settings if your app has admin login | Application access |
| VPN (if used) | VPN configuration requiring MFA | Network access |
Step-by-Step Evidence Collection
1. Configuration Evidence
Screenshot your identity provider's MFA enforcement setting. Show the admin page where MFA is marked as required — not just "recommended" or "available."
2. User Enrollment Evidence
Export or screenshot the user list showing MFA status for each account. Every active user should show MFA as enrolled/active.
3. MFA Method Documentation
Document which MFA methods are accepted (hardware keys, TOTP app, SMS). Note: auditors prefer hardware keys or TOTP apps over SMS, which is vulnerable to SIM swapping.
Common Issues
- MFA available but not enforced: Change the setting from "optional" to "required" before the audit.
- Service accounts without MFA: If you have service accounts or API keys, document these as exceptions with compensating controls (IP restrictions, short-lived tokens).
- New employee gap: Ensure your onboarding process includes MFA setup on day one. Auditors may check onboarding records.
- Personal devices: If employees use personal phones for TOTP, that's fine — auditors care about the factor existing, not the device type.