Does SOC 2 require MFA? What auditors expect and what to write if it is not on yet

Updated 25 October 2026

No criterion in SOC 2 names multi-factor authentication. The Trust Services Criteria ask you to restrict logical access with authentication controls, and MFA is the usual way to do it, so an auditor who finds administrative, production or customer-data access protected by a password alone will ask why. None of the three outside guides cited here points to a criterion that names it, and they differ on how hard they push it. What binds you most is your own policy: if it says MFA is on, the auditor tests whether it is on. This guide shows where it is expected, what to write if it is not on every account yet, and the evidence to keep.

Short answer: not named in the criteria, and expected where access is sensitive

A SOC 2 report is written by a CPA firm after it examines your controls against the Trust Services Criteria. Those criteria describe outcomes and leave the means to you. Three guides on this exact question agree on the requirement and differ on the emphasis:

These sources disagree on tone more than on the fact: the headline of one says "mandatory" and its body cites nothing, while Konfirmity says outright that SOC 2 does not explicitly require MFA and SOC2Auditors.org never says it does. Weight them accordingly. SOC2Auditors.org is a directory that earns money from advertising and sponsored placements, Konfirmity sells a compliance platform and Security Scientist links to a compliance tool, so read all three as one side of the question. The practical question is not "is MFA written in the criteria" but "which of our accounts can an attacker reach with a stolen password, and what do we say about that?"

The criteria MFA supports

The generated Authentication and Password Policy maps to CC6.1 and CC6.6. The other two criteria below come up in the outside guides and are covered by other generated policies, so they are listed here with the crosswalk's plain-language summary of each:

• CC6.1 (Logical access security): The company protects its systems and data with identity, authentication, authorization, encryption and network controls that are designed around what needs protecting.
• CC6.2 (User registration and deprovisioning): New users are created only after approval, credentials are issued to the right person, and access is removed promptly when someone leaves or no longer needs it.
• CC6.3 (Role-based access and least privilege): Access is granted by role and limited to what the job requires, privileged access is restricted, and permissions are reviewed and adjusted on a schedule.
• CC6.6 (Protection from external threats): The boundary between the company's systems and the outside world is defended: firewalls, WAF, secure remote access, MFA on external entry points, and hardened endpoints.

SOC2Auditors.org places MFA under CC6.1 and the remote access path under CC6.6 (SOC2Auditors.org), and Konfirmity adds CC6.2 and CC6.3 (Konfirmity). The criteria are written as outcomes, so a mapping like this is an interpretation, not a rule. Your CPA firm decides which of your controls it tests under which criterion.

Where auditors expect it

The sources give the same shape of answer, strongest where the damage from a stolen password is greatest. Konfirmity names privileged accounts, sensitive data stores and remote access, and singles out production databases, administrative interfaces and systems holding customer data (Konfirmity). SOC2Auditors.org says to inventory access that bypasses the main identity provider and notes that named privileged and break-glass admin accounts need a documented reason (SOC2Auditors.org). Put together, a workable scope list for a small SaaS company is:

• Identity provider and single sign-on. If every application hangs off one identity provider, enforcing MFA there covers most of the rest at once.
• Administrative accounts in the cloud console, source control, CI/CD, the production database and the identity provider itself.
• Remote access paths. VPN, bastion or zero-trust access, and any tool that reaches production from outside the office.
• Systems holding customer data, including support tools and analytics that can see it.
• Contractors and shared or break-glass accounts. These are the usual places for an account without MFA to survive a rollout.
• Your own product's login, if customers sign in to it. The generated policy has the product offer MFA to customers.

The generated policy also separates people from systems. Service accounts, API keys and tokens are handled by a different set of statements covering storage, least privilege and rotation, which matches SOC2Auditors.org saying machine identities need machine authentication rather than an MFA prompt.

What the generated policies say when MFA is on, and when it is not yet

The generator asks one question about this: whether MFA is enforced for everyone, answered yes, or "no, MFA is not enforced yet". The answer changes wording in five policies; the four excerpted here are the main ones, and the Human Resources Security Policy's onboarding statement also changes. The excerpts below are not written by hand. They are rendered from the policy templates for the Northwind Cloud Inc sample intake twice, once for each answer, so they change when a template does. The company, cloud and identity provider names are the sample's.

Who must use MFA, and which methods (Authentication and Password Policy, 4.2)

MFA enforced for everyone: Multi-factor authentication is mandatory for every workforce account at Northwind Cloud Inc, without exception for seniority. Administrative accounts in Okta, the identity services of AWS and Vercel and GitHub use phishing-resistant methods such as FIDO2 security keys or passkeys; authenticator applications are acceptable elsewhere. SMS and voice codes are permitted only where no other method is offered and are recorded as an exception.

MFA not enforced yet: Multi-factor authentication is required for every administrative account, for all access to AWS and Vercel, GitHub and customer data, and for every remote access path, using phishing-resistant methods such as FIDO2 security keys or passkeys for administrators. Until it is enforced for every workforce account, the Security Owner owns a dated rollout plan, tracked in the risk register, that extends it to every workforce account, and reports progress to Executive Management quarterly. SMS and voice codes are permitted only where no other method is offered and are recorded as an exception.

MFA as an access control (Access Control Policy, 4.4)

MFA enforced for everyone: Multi-factor authentication is enforced for every workforce account, with phishing-resistant methods for administrative roles, under the Authentication and Password Policy.

MFA not enforced yet: Multi-factor authentication is required for all administrative, production and source code access. Until it is enforced for every workforce account, the Security Owner owns a dated rollout plan, tracked in the risk register, that extends it to every workforce account under the Authentication and Password Policy.

MFA in the top-level policy (Information Security Policy, 4.8)

MFA enforced for everyone: Access follows least privilege and is granted by role under the Access Control Policy. Multi-factor authentication is mandatory for every account that can reach production, source code or customer data.

MFA not enforced yet: Access follows least privilege and is granted by role under the Access Control Policy. Multi-factor authentication is required for administrative, production and source code access, and the Security Owner owns a dated rollout plan, tracked in the risk register, that extends it to every account by a committed completion date.

What personnel must do (Acceptable Use Policy, 4.3)

MFA enforced for everyone: Every account that supports multi-factor authentication has it enabled. Personnel never approve an authentication prompt they did not initiate; an unexpected prompt is reported to security@northwindcloud.example.

MFA not enforced yet: Personnel enroll in multi-factor authentication on every account that supports it as soon as the rollout led by the Security Owner reaches that account, and never defer or disable it. Personnel never approve an authentication prompt they did not initiate; an unexpected prompt is reported to security@northwindcloud.example.

The pattern is the same in all four. With MFA on for everyone, the policy states it flatly. With MFA not on yet, the policy does not claim more than you do: the scope that is already enforced is stated, and a dated rollout plan owned by the Security Owner, tracked in the risk register, covers the rest. The Authentication and Password Policy's monthly coverage check changes in step. The Security Owner exports enrollment status from the identity provider, the cloud and source control, opens a ticket for any account without a method, and suspends accounts still without one after five business days. In the not-yet version, suspension applies to the accounts the plan already covers, and the rest are reported against the plan. The export is retained as evidence.

If MFA is not on every account yet: a rollout that leaves records

Do not describe a state you have not reached. Write the policy to match today, run the rollout, and keep the records as you go. A common order, with the record each step leaves:

Konfirmity describes a similar phased path, from defining scope through a pilot group to policy updates and user communication, and expects logs showing MFA was enforced consistently, with auditors possibly sampling them during a Type II observation period (Konfirmity). Its log fields and timelines are the publisher's suggestions, not a standard. Your policy sets what you retain, so check that what you promise to keep is what your identity provider can actually export.

To see where MFA sits among your other gaps, take the free readiness assessment. It is practice for the questions a customer or CPA firm may ask, not an audit.

Methods: what the policy allows and what the sources say

The generated policy asks for phishing-resistant methods, such as FIDO2 security keys or passkeys, for administrators, and allows authenticator applications elsewhere. SMS and voice codes are permitted only where no other method is offered, and each use is recorded as an exception. On this the sources line up with it: Konfirmity says SMS codes may be used only as a backup and that security questions do not count as MFA because they are knowledge-based (Konfirmity), and Security Scientist recommends hardware keys or authenticator apps over SMS because of SIM swapping (Security Scientist). Neither is a rule in the criteria. The strength of the method you choose belongs in your risk assessment.

The parts people forget: onboarding, recovery and exceptions

A stronger login is only as strong as the way around it. Three procedures in the generated policy cover the bypasses auditors tend to find by asking how things work in practice. Enrollment happens before other access is granted:

Authentication and Password Policy, 5.1: Onboarding enrollment. On the first working day, before any other access is granted, the new hire enrolls in 1Password and registers at least two multi-factor methods in Okta, one of which is a security key or passkey for anyone with an administrative or production role. People Operations records completion and the Security Owner verifies it before approving the standard access bundle.

Recovery of a lost factor is verified through a different channel, and requests by email or chat alone are never actioned:

Authentication and Password Policy, 4.10: Account recovery and multi-factor resets are performed only after identity has been verified through a channel other than the one being recovered, such as a video call with a known colleague or a code sent to a verified personal contact held by People Operations. Requests arriving by email or chat alone are never actioned.

A lost phone is a lost factor, which is why device management and offboarding sit next to this control.

The policy's exceptions section says an exception, for example a legacy application that cannot enforce MFA or a device that cannot support a security key, is approved in writing by the Security Owner, recorded in the exception register with compensating controls and an expiry date no later than twelve months out, and reviewed at each policy review. It also says no exception permits disabling MFA on an administrative account. Konfirmity gives similar examples of compensating controls for legacy systems, such as placing them behind an MFA-protected VPN or an SSO layer with MFA, and says the decision should be discussed with the auditor (Konfirmity). The free policy exception register is built for this. The Audit Kit ($59, one time) includes the register in its governance folder.

What to tell a customer who asks

Security questionnaires usually ask about MFA several ways: for staff, for administrators, for remote access and for customers. Answer each with what is true today, and keep the answers consistent. If MFA is on for administrators and production and the rest is in a dated plan, say exactly that. The questionnaire guide has example honest answers, and the evidence checklist shows how a control like this one turns into records.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.