Introduction
Multi-factor authentication (MFA) evidence for SOC 2 is the dated record that shows MFA was required, enrolled, and enforced for the people and systems in scope across your audit period, and that every gap had an owner and an approval. Saying "we use MFA" is a claim. A configuration export, an enrollment report, and a short list of approved exceptions are evidence.
Most teams turn MFA on early. Fewer can prove, months later, that it stayed on for every in-scope user, that new hires enrolled before they got access, that a lost phone did not turn into a quiet bypass, and that the cloud console break-glass account was handled on purpose. That is the gap this guide covers.
Here is a labeled hypothetical. A 60-person SaaS company enforces MFA through its identity provider (IdP) for all workforce apps behind single sign-on (SSO). During Type 2 fieldwork, the auditor samples the IdP policy, an enrollment export, and five new hires. The policy and new hires look clean. Then the auditor asks about the cloud provider root account, two contractors added directly to the code hosting platform outside SSO, and a support engineer whose authenticator was reset in March. The company can show the IdP policy, but the other three answers live in chat threads and memory. None of that is a security failure yet. It is an evidence failure, and it turns a simple control into follow-up requests.
In plain language: this page is the playbook for proving MFA in a SOC 2 audit. For the definition of MFA, factor classes, and second-factor methods, see What Is Multi-Factor Authentication?.
What MFA Evidence Means
MFA evidence answers four questions an auditor is likely to ask:
- Where is MFA required? Which systems, user groups, and access paths are covered by an MFA policy.
- Who is enrolled? Whether every in-scope account has a registered second factor, and how new accounts get enrolled.
- Is it actually enforced? Whether the system blocks password-only sign-in, or only encourages MFA.
- What happens at the edges? How exceptions, bypasses, service accounts, break-glass accounts, and authenticator resets are approved and tracked.
| Question | Typical evidence |
|---|---|
| Where is MFA required? | Access control or authentication policy section, IdP conditional access or sign-on policy export, system inventory showing which apps sit behind SSO |
| Who is enrolled? | Enrollment or factor report from the IdP and from any app that authenticates users directly, reconciled to the in-scope user population |
| Is it enforced? | Policy configuration with enforcement settings, sign-in logs showing MFA challenges, settings for direct-login apps |
| What happens at the edges? | Exception register with approvals and expiry dates, reset tickets with identity verification, break-glass account records |
How MFA Connects to SOC 2
SOC 2 reports are built on the AICPA 2017 Trust Services Criteria with revised points of focus (2022). MFA evidence most often supports the logical access criteria:
- CC6.1 addresses logical access security over protected information assets, including how users are identified and authenticated.
- CC6.2 addresses registering and authorizing users before credentials are issued, which is where enrollment at onboarding fits.
- CC6.6 addresses logical access security measures against threats from sources outside the system boundaries. One of its points of focus describes requiring additional authentication information or credentials when accessing the system from outside its boundaries.
Two distinctions matter here. First, points of focus are guidance that helps you and your auditor think about a criterion. They are not a checklist of mandatory controls. Second, SOC 2 does not prescribe a specific MFA method. Your company decides which controls meet its commitments, and your auditor tests the controls you describe. In practice, MFA for remote access, the IdP, email, source control, and cloud administration is a very common control in SOC 2 programs, and customers often ask about it in security questionnaires. See SOC 2 Trust Services Criteria Explained.
For method strength, many teams use outside guidance. NIST SP 800-63B, Authentication and Authenticator Management defines authentication assurance levels and treats authentication through the public telephone network, such as SMS codes, as a restricted option. CISA's Implementing Phishing-Resistant MFA fact sheet describes FIDO/WebAuthn and PKI-based authenticators as phishing-resistant forms of MFA. These are reference points for your own policy decisions, not SOC 2 requirements.
MFA Evidence vs Neighboring Evidence
MFA sits next to several other access controls. Keeping the evidence sets separate makes requests faster to answer.
| Evidence set | What it proves | Where to go deeper |
|---|---|---|
| MFA evidence | Authentication strength: who must present a second factor, and whether they did | This guide |
| Role-based access control evidence | Authorization design: what each role can do | Role-Based Access Control Evidence for SOC 2 |
| User access review evidence | Periodic confirmation that access is still appropriate | How to Run a SOC 2 User Access Review |
| Onboarding and offboarding evidence | Access is granted on approval and removed on departure | Onboarding and Offboarding Evidence for SOC 2 |
| Logging and monitoring evidence | Sign-in activity and alerts are captured and reviewed | Logging and Monitoring Evidence for SOC 2 |
MFA does not replace any of these. A user with MFA and the wrong role still has the wrong access.
Step 1: Define Scope Before You Export Anything
Start with a short MFA standard, usually a section of your access control or information security policy. It should state:
- Which user populations must use MFA: employees, contractors, administrators, and any third parties with workforce access
- Which systems and paths are covered: the IdP, email, source control, cloud consoles, production access, VPN or remote access, and in-scope SaaS apps
- Which methods are allowed, and whether stronger methods are required for privileged roles
- How exceptions are requested, approved, time-limited, and reviewed
- How lost or replaced authenticators are reset, including how identity is verified first
- Who owns the control, named as a control owner
Then list the systems in scope and mark each one as either "MFA enforced at the IdP through SSO" or "MFA enforced in the app itself." Your Asset Inventory Evidence for SOC 2 is the natural source for this list. Apps that allow direct password login alongside SSO need their own row, because an SSO policy does not cover a login path that skips SSO.
Step 2: Capture Enforcement Configuration
Auditors usually want to see how MFA is enforced, not just that it is available. Useful artifacts include:
- An export or dated screenshot of the IdP sign-on or conditional access policy showing that MFA is required for the in-scope groups and apps
- Any policy that exempts users, locations, or devices, with the reason documented
- Settings in apps that authenticate users directly, such as source control, cloud provider consoles, and the domain registrar, showing MFA is required at the organization level where the app supports it
- A record of when each enforcement setting was turned on, from an admin audit log or a change management ticket
For a Type 2 report, a single screenshot from audit week shows the state on one day. It does not show the period. Capture configuration at the start of the period and on a regular schedule, and keep the admin audit log for any change to MFA policies. A change ticket for each policy edit closes the gap between snapshots.
Step 3: Prove Enrollment Coverage
Enforcement settings show the rule. Enrollment reports show the population. Pull a factor or enrollment report from the IdP and from each direct-login app, then reconcile it against the in-scope user list from HR or your directory.
| Field | Why it matters |
|---|---|
| User identifier and status (active, suspended, deprovisioned) | Lets you match the report to the in-scope population |
| User type (employee, contractor, service account, admin) | Shows whether privileged users meet stricter method rules |
| Enrolled factor types | Shows which methods are in use, such as hardware key, authenticator app, or SMS |
| Enrollment date | Supports onboarding sampling |
| Last authentication | Helps spot dormant accounts that never enrolled |
| Report date and system | Proves when and where the export came from |
Record the reconciliation result: number of in-scope users, number enrolled, and the named exceptions. Unenrolled active users should either have an approved exception or a ticket to fix the gap. A report that is exported but never reconciled does not show that anyone checked.
Step 4: Tie Enrollment to Onboarding
Auditors commonly sample new hires during the period. For each sampled person, they may want to see the access request, the account creation, and evidence that MFA was enrolled before or at first access. Two common patterns are:
- Enrollment enforced at first sign-in. The IdP forces MFA registration before the user can reach any app. The policy export plus the enrollment date for the sample covers it.
- Enrollment checked as an onboarding task. A checklist item or ticket step confirms MFA enrollment. Keep the completed task with the date.
Link this to the access request in your onboarding workflow so the full chain is visible. See Onboarding and Offboarding Evidence for SOC 2.
Step 5: Control Exceptions and Bypasses
Every MFA program has edges. Evidence quality depends on whether those edges are deliberate.
- Temporary bypasses. When a user is locked out, some IdPs allow a one-time bypass code or a temporary exemption. Each one should have a ticket, an approver, a reason, and an expiry, and the exemption should be removed afterward.
- Excluded groups or locations. Any group, network, or device excluded from an MFA policy needs a documented reason and an approval. Review the list on a schedule.
- Weaker methods. If your standard requires stronger methods for administrators and an admin is still on SMS, record it as an exception with a plan.
- Apps that cannot enforce MFA. Prefer moving them behind SSO. If that is not possible, document the risk and any compensating control, such as network restriction or extra monitoring, and log the decision in your risk register.
Track open items through exception management. An exception with an approver and an end date is a control working as designed. An undocumented exclusion found by the auditor is a finding waiting to be written.
Step 6: Handle Authenticator Resets as a Security Event
Authenticator resets are a common social engineering target, because whoever controls the reset controls the account. Evidence should show that help desk or IT staff verified identity before resetting a factor. Useful records include:
- A ticket for each reset with requester, verifier, verification method, and timestamp
- The IdP admin log entry for the reset, matching the ticket
- A rule for privileged accounts, such as requiring a second approver or a live video check, if your standard calls for it
Auditors may sample resets from the admin log and ask for the matching tickets. Resets without tickets are hard to defend.
Step 7: Account for Service and Break-Glass Accounts
Not every account can use interactive MFA.
- Service accounts and API credentials usually authenticate with keys or tokens rather than a second factor. Document them separately, restrict what they can do, rotate their credentials, and make sure they cannot be used for interactive sign-in where the platform allows that restriction.
- Break-glass or root accounts exist for emergencies, such as an IdP outage. Protect them with strong MFA, often a hardware key kept under dual control, and keep a record of who holds the factors, when the account was last used, and why. Each use should create a ticket and an alert.
List these accounts in your enrollment reconciliation so they are not mistaken for unenrolled users.
Step 8: Monitor Sign-In Activity
Configuration shows intent. Sign-in logs show operation. Keep IdP sign-in logs for the audit period, or confirm your log retention covers it, and consider alerts for:
- Successful sign-ins that did not satisfy MFA
- Changes to MFA policies or exclusion lists
- Factor resets and new factor registrations on admin accounts
- Repeated push prompts denied by a user, which can signal push fatigue attacks
Route alerts to a reviewed queue and keep the investigation notes. See Logging and Monitoring Evidence for SOC 2 and Incident Response Evidence for SOC 2.
What Auditors Commonly Sample for Type 2
Exact procedures depend on your auditor and the controls you describe. Common requests include:
- The MFA policy or standard in effect during the period
- IdP policy configuration, with evidence that enforcement did not lapse during the period
- An enrollment report reconciled to the in-scope population
- A sample of new hires with enrollment dates
- The exception list with approvals and expiry dates
- A sample of authenticator resets with tickets
- Direct-login app settings for systems outside SSO
- Break-glass account records and any use during the period
The difference between Type 1 and Type 2 matters here. Type 1 looks at design at a point in time. Type 2 tests operation across the audit period. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| Auditor asks how MFA is enforced | IdP policy export plus admin audit log showing no unapproved changes during the period | One screenshot taken in audit week |
| Auditor samples a new hire | Access request, account creation, and enrollment date before first app access | "IT always sets it up" |
| Contractor added directly to source control | Organization-level MFA requirement in the app and contractor listed in the reconciliation | Contractor outside SSO and outside the enrollment report |
| User locked out while traveling | Ticket with identity verification, approver, temporary bypass with expiry, bypass removed | Admin disabled MFA for the user in chat and forgot to re-enable it |
| Cloud root account | Hardware key under dual control, usage log, ticket for each use | Root password and authenticator on one admin's personal phone |
| Admin still using SMS | Exception record with approval, risk note, and migration date | No record, discovered during sampling |
| Legacy app without MFA support | Risk register entry, compensating controls, plan to move behind SSO | App not in the inventory |
Common Mistakes
- Assuming SSO means MFA everywhere, while some apps still allow direct password login
- Screenshots with no date, no system name, or no indication of who captured them
- Enrollment exports never reconciled to the HR or directory population
- Exclusion groups that grow quietly and are never reviewed
- Temporary bypasses with no expiry
- Authenticator resets done over chat with no identity check or ticket
- Break-glass accounts with no record of who holds the factors
- Service accounts counted as unenrolled users, or not counted at all
- Policy says hardware keys for admins, but nobody checks
When you find one, record it and track the fix through Exception Management and Audit Findings Remediation.
Operating Model: Keep MFA Evidence Current
- Name an owner. Assign a control owner for MFA policy, enrollment reconciliation, and exceptions.
- Schedule exports. Capture policy configuration and enrollment reports on a fixed cadence, such as monthly or quarterly, and keep them with dates.
- Reconcile, then sign off. Compare enrollment to the in-scope population and record the result and the reviewer.
- Review exceptions on a calendar. Close expired bypasses and re-approve or remove long-running exclusions.
- Ticket every reset and policy change. Make the admin log and the ticket queue tell the same story.
- Dry-run before fieldwork. Pull the full set of MFA evidence each quarter, not only in audit week.
This cadence also supports continuous compliance, because the evidence builds up during the period instead of being rebuilt at the end.
Linking MFA Evidence to Neighboring Controls
- Access control and least privilege. MFA strengthens authentication. Access control and least privilege decide what users can do once they are in.
- Role design. Stricter method rules usually apply to privileged roles defined in Role-Based Access Control Evidence for SOC 2.
- Access reviews. Reviewers can confirm MFA enrollment while confirming access; see How to Run a SOC 2 User Access Review.
- Zero trust. MFA is a core building block of zero trust programs; see Mapping Zero Trust Controls to SOC 2 Evidence.
- Security awareness. Training on phishing and push fatigue supports MFA; see Security Awareness Training Evidence for SOC 2.
- Vendors. Vendors with workforce access should meet your MFA standard; see Third-Party Due Diligence Evidence for SOC 2.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For MFA, that can mean dated history for exception tickets, authenticator reset tickets, policy change tickets, and scheduled reconciliation tasks, so you can show the work across the period without rebuilding it from chat threads. Your identity provider and your apps remain the systems of record for MFA settings and enrollment. AuditFlo.co does not configure MFA for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
MFA is one of the easiest controls to turn on and one of the easiest to under-evidence. Define where it is required, export enforcement settings and enrollment on a schedule, reconcile enrollment to the people actually in scope, and treat exceptions, resets, service accounts, and break-glass accounts as deliberate, ticketed decisions. If you can answer "where, who, enforced, and edges" with dated records, MFA sampling becomes routine.
If you are building the broader readiness path, start with What Is Multi-Factor Authentication?, What Is Logical Access?, Role-Based Access Control Evidence for SOC 2, SOC 2 Trust Services Criteria Explained, and how to prepare for a SOC 2 audit.
FAQ
Is MFA required for SOC 2?
SOC 2 does not prescribe specific controls or a specific MFA method. The Trust Services Criteria address logical access and authentication, and a CC6.6 point of focus describes requiring additional authentication when accessing the system from outside its boundaries. In practice, MFA for remote access, the identity provider, and administrative access is a very common control, and auditors test the controls your company describes.
Is a screenshot of our MFA policy enough?
It can support a Type 1 report, which looks at design at a point in time. For Type 2, auditors test operation across the period, so dated exports, admin audit logs, and change tickets that show enforcement stayed in place are stronger.
Does SSO prove MFA for every app?
Only for login paths that go through the identity provider with an MFA policy applied. Apps that also allow direct password login, local admin accounts, or API access need their own evidence.
Are SMS codes acceptable?
That is a policy decision for your company and a discussion with your auditor. NIST SP 800-63B treats authentication through the public telephone network as a restricted option, and many programs require stronger methods for privileged access. If you allow SMS, document where and why.
How should we handle service accounts?
Document them separately from human users, restrict their permissions, rotate credentials, prevent interactive sign-in where the platform allows it, and list them in your enrollment reconciliation with the reason they do not use interactive MFA.
What evidence shows an authenticator reset was safe?
A ticket with the requester, the person who verified identity, the verification method, and the time, matched to the reset entry in the identity provider's admin log.
Does AuditFlo.co enforce MFA?
No. Your identity provider and apps enforce MFA. AuditFlo.co helps organize dated evidence such as tickets, tasks, and workflow history from systems you already use, and does not replace your auditor.