Does SOC 2 require multi-factor authentication

Remote access is the situation most directly tied to CC6.6, which concerns threats from sources outside the system boundary. Auditors usually start here because a login from outside the corporate network is the path an attacker is most likely to use. They will ask how users reach the system from home, from travel and from unmanaged devices, and whether every route requires a second factor before a session is established. Expect them to test a sample of remote logins and to compare the configured policy against what the identity provider actually enforces.

• VPN, zero-trust gateway and web application logins: Auditors ask for the configuration showing MFA is required for every remote entry point, not only the main one.
• Session establishment: They ask whether MFA is enforced at each new session, and how long a session can persist without a new factor.
• Enrollment and recovery: They ask how factors are registered and how recovery codes or help desk resets are verified.
• Sampled log evidence: They pick logins from the review period and check that a second factor was recorded.
• Exceptions for remote users: They ask for the documented compensating control if any remote path is exempt.

Before the audit, confirm that every remote path your users can reach is listed in the control matrix and that the enforcement setting matches the written policy.

Administrative and privileged accounts can change configurations, read data and disable controls, so auditors treat them as a higher risk than standard user accounts. They will look for MFA on every privileged role, including cloud consoles, directory administration, database administration and infrastructure management tools. A common finding is an administrator account that was created for a single task and never brought under the same enforcement as the rest of the team. Auditors also check that shared or break-glass accounts are either removed or controlled by a documented procedure.

• Privileged role inventory: Auditors ask for a list of roles that grant administrative rights and confirmation that each one requires MFA.
• Break-glass accounts: They ask how emergency accounts are protected, who holds the credentials and how their use is logged and reviewed.
• Separation of admin and daily accounts: They ask whether administrators use separate accounts for privileged work.
• Access reviews: They check that privileged access is reviewed on a schedule and that MFA status appears in the review.
• Phishing-resistant options: They ask whether administrators can use FIDO/WebAuthn, since CISA has urged moving to phishing-resistant methods for high-privilege users.

Confirm the list of privileged roles with your platform team before fieldwork, since the list is the first thing an auditor will sample from.

Production systems and stores of customer data are where an authentication failure has the largest consequence, so auditors often test MFA here separately from general corporate access. They will ask which systems hold customer data, who can reach them directly and whether the paths to those systems require a second factor. The question is not only whether MFA exists but whether the production path is the one people actually use. Auditors commonly find bypass routes, such as a direct database connection or a service account used interactively, and ask how those are controlled.

• Data store access paths: Auditors ask for every route into production databases, storage buckets and admin consoles, and whether each route is covered.
• Interactive use of service accounts: They ask whether any service account is used by people, and if so, how that use is restricted.
• Per-session enforcement: They ask whether production sessions require a fresh factor, and how session recording supports the evidence.
• Change and access logs: They ask for logs linking each production session to a named, authenticated user.
• Scope alignment: They check that the production systems listed in the system description match those covered by MFA enforcement.

Confirm that the production boundary in your system description matches the systems your identity provider protects, because mismatches are a frequent source of questions.

Service accounts, API clients, automated pipelines and machine-to-machine calls generally cannot answer an MFA prompt, so MFA does not fit most of this traffic. Auditors do not expect a human second factor on every API call. They do expect the organization to show how these credentials are protected, scoped and rotated, and why MFA is not applicable to each category. This is where documented exceptions most often appear, and where auditors look hardest at the compensating control. The control usually relies on strong credential protection, short-lived tokens, network restrictions and logging of each use.

• Exception register: Auditors ask for a list of non-interactive identities and the reason MFA cannot apply to each one.
• Compensating controls: They ask what replaces the second factor, such as short-lived tokens, mutual TLS, IP restrictions or workload identity.
• Credential protection: They ask how keys and secrets are stored and who can read them.
• Usage logging: They sample API activity and check that calls are attributable to a specific identity.
• Scope in the system description: They check that the exceptions are stated, so the report does not imply MFA covers machine identities.

When you document an exception, state the compensating control, the owner and the review frequency, and confirm that the system description describes the same boundary.

Your organization owns the MFA control. Management decides which systems, users and access paths must require a second factor, approves the scope of the SOC 2 examination, and is accountable for the description of the system that the report covers. The control is only as reliable as the people who run it day to day, so ownership has to sit with named roles rather than with whoever installed the identity server.

• Scope decisions: Confirm which applications, consoles, VPN gateways and administrative interfaces are inside the system boundary and must enforce MFA.
• Policy and exceptions: Write the authentication policy, define who may approve an MFA exception, and record the compensating control and its expiry date.
• Access reviews: Review enrolled factors and recovery methods on a set schedule, and remove factors belonging to leavers or changed roles.
• Evidence ownership: Keep the configuration exports, enrollment logs and exception approvals that the auditor will request, and make sure someone can produce them on demand.
• Operator training: Train help desk staff on identity verification before factor resets, since a reset path that skips verification can undo the control.

Before engaging anyone, check that a named owner can explain every MFA exception and produce its approval record within a day.

An implementation partner such as DeployOpen can plan, configure and document the open-source identity platform that enforces MFA, inside your own cloud accounts or data centers. Typical work includes setting up Keycloak or authentik, configuring second-factor policies, connecting applications through standard protocols, and writing the runbooks that describe how the system behaves. The partner prepares systems and evidence. It does not own the control and does not issue any attestation.

• Configuration: Set up required-factor policies in Keycloak, such as TOTP or WebAuthn passkeys with recovery codes, or the authenticator validation stage in authentik, and test them against each in-scope application.
• Documentation: Record the chosen factors, enrollment and reset procedures, and configuration keys so an auditor can compare the design with the stated policy.
• Evidence preparation: Set up repeatable exports of realm or flow settings, authentication logs and enrollment records, and test that they still work after upgrades.
• Hardening and testing: Support security testing of login flows, including bypass attempts against factor enforcement, under a written scope.
• Handover: Train your staff to operate the platform so the control does not depend on the partner after the engagement ends.

The work is usually fixed-scope and agreed in writing before it starts. Hiring a partner does not guarantee that the CPA firm will find the control effective, so ask for the written scope and the list of deliverables.

The CPA firm is the independent service auditor. It tests whether the MFA control is designed to meet the relevant criteria, typically under CC6.6, and, for a Type 2 report, whether it operated effectively over the observation period. It issues the report with its opinion. Only the CPA firm can do this, and its work is governed by the AICPA attestation standards that require written representations from management.

• Design testing: The auditor reviews the policy, system description and configuration to decide whether MFA would meet the criterion if it operated as described.
• Operating testing: For a Type 2 examination, the auditor samples enrollments, logins and exceptions across the observation period and checks them against evidence.
• Representations: Management signs a representation letter confirming that the MFA description and exception history are complete and accurate.
• Findings: Any gap, such as an application that skipped MFA, can appear as an exception in the report, which customers will read.
• Independence: The firm may not design or operate the controls it tests, which is why configuration and evidence preparation sit with your team or an outside partner.

Ask the firm which evidence samples it will request and how it will treat exceptions before fieldwork starts.