What password rules does SOC 2 require?
If a customer questionnaire or contract asks for your password controls, the direct answer is that the 2017 Trust Services Criteria set no password length, composition or rotation rules. An auditor judges your password design through the access criteria instead, mainly CC6.2 on creating and reviewing access credentials and removing credentials that are no longer valid, and CC6.6 on protecting authentication credentials and requiring additional authentication. The test is whether your policy restricts access and protects credentials in a way you can show with evidence. Points of focus under these criteria are characteristics that can help you design and evaluate controls, not separate requirements, so you do not need to address every one of them.
Because the criteria are silent on numbers, your organization owns the password policy and decides what it says. Auditors commonly use NIST SP 800-63B-4 as the benchmark for what a reasonable policy looks like. It requires at least 15 characters for passwords used as a single factor and at least 8 characters for passwords used only within multi-factor authentication. It prohibits other composition rules and periodic forced changes, requires a change when there is evidence of compromise, and requires checks against a blocklist of commonly used, expected or compromised values. Confirm the current text with the NIST publication directly before you cite it in a policy, since the benchmark is a reference point rather than a SOC 2 requirement.
The policy is only half of the result. Your auditor will look at configuration of your identity provider, the blocklist check, the offboarding records that remove credentials, and the periodic access reviews that confirm credentials remain appropriate. Decide early whether passwords alone protect any system, because NIST states that passwords are not phishing-resistant, and a password used as the single factor for production or administrative access will draw more questions than one paired with a strong second factor. Ask your auditor and any implementation partner to walk through which systems and evidence they expect before you finalize the policy.
Which password policy fits which access path
This table compares three ways to design authentication for a SOC 2 system: passwords as the only factor, passwords inside MFA, and phishing-resistant authenticators for administrative or production access. Read each row as a design option, then check the evidence column against what your auditor will ask to see. The main takeaway is that passwords alone carry the longest minimum length, while MFA and phishing-resistant authenticators address the access paths where a stolen password does the most damage.
| Access path | Design choice and NIST baseline | When it fits | Evidence an assessor expects |
|---|---|---|---|
| Customer-facing application, single factor | Password only, at least 15 characters, checked against a blocklist, no forced periodic change | Rarely appropriate for workforce or privileged access. Confirm whether any customer login in scope uses passwords without a second factor. | Written password standard, configuration showing the length and blocklist settings, and change-on-compromise procedure |
| Workforce login with MFA | Password at least 8 characters inside an MFA flow, checked against a blocklist, no forced periodic change | Standard staff access to internal applications where the second factor is enforced for every session | MFA enforcement settings for each in-scope application, sample login records showing the second factor, and the password standard |
| Remote and VPN access | Password plus MFA, with the MFA factor required at each new session | Staff or contractors reaching in-scope systems from outside the corporate network | Identity provider policy for remote access, list of users with MFA enrolled, and logs of remote sessions |
| Administrative and production access | Phishing-resistant authenticator with a non-exportable private key, the AAL3 pattern in NIST SP 800-63B-4 | Root, cluster admin, database admin and production deployment access where a phished credential could change live systems | Authenticator inventory by user, configuration that blocks other factor types for these roles, and access approvals linked to each session |
| Break-glass and recovery accounts | Stored credential with controlled release, plus a second factor or dual control to use it | Emergency accounts that bypass normal login when identity services fail | Vault or sealed-envelope procedure, usage logs, and a review record after each use |
| Service and machine accounts | Not a human password. Use short-lived credentials or keys managed by a secrets platform, outside the password policy | Automated jobs, pipelines and service-to-service calls | Credential inventory, rotation or expiry settings, and audit logs of credential issuance and use |
| Password change triggers | Force a change on evidence of compromise, not on a calendar schedule | Any account where a breach is suspected, a credential appears in a leak, or a user reports suspicious activity | Incident records showing the trigger, forced-reset logs, and the policy text that rules out routine expiry |
What a SOC 2 password policy should contain
A SOC 2 password policy does not need to copy a fixed rulebook, because the criteria set no length or rotation rules. The cards below cover the parallel elements an auditor will look for when a password control is tested, and each names the evidence that shows the rule is actually running.
Minimum length by factor
Set one minimum for passwords used as a single factor and a separate minimum for passwords used inside multi-factor authentication. NIST SP 800-63B-4 sets 15 characters for single-factor passwords and 8 characters for passwords used only within MFA. Confirm the identity provider enforces these values, not just the policy document. Evidence: a configuration export from the identity provider showing the password length settings for each authentication flow.
Blocklist source and update process
Check new and changed passwords against a list of commonly used, expected or compromised values, as SP 800-63B-4 requires. Name the list source, record who approves changes to it, and set how often it refreshes. Auditors test this by attempting to set a listed password. Evidence: the blocklist source and version, a dated update log, and a test showing a rejected password.
No forced rotation or composition rules
Remove scheduled password expiry and rules that require mixed character classes, because SP 800-63B-4 says verifiers must not impose these. Policy language should say so directly so that a reviewer does not see conflicting rules. Evidence: the identity provider settings showing expiry disabled and no composition rules, plus the policy text that matches them.
Forced reset on compromise
Require a password change when there is evidence that the password or account has been compromised, such as a credential found in a breach corpus or a suspicious sign-in confirmed by the security team. The trigger and the reset should both be logged. Evidence: the detection rule or alert, the ticket that records the decision, and the audit log entry showing the forced change.
Password storage and manager guidance
Specify how passwords are stored by the system (salted, one-way hashing with a current algorithm) and allow users to paste into fields so that approved password managers work. Tell staff which manager is approved for company use. Confirm the hashing configuration with the platform vendor or in your own build. Evidence: the approved manager list, the storage configuration for the identity store, and the staff acknowledgment of the policy.
Lockout and throttling
Limit repeated failed sign-in attempts through throttling or temporary lockout so that guessing attacks are slowed without locking out legitimate users at scale. Set the thresholds in writing and review them with the monitoring team. Evidence: the throttling or lockout configuration export, and sample log entries from failed sign-in events that show the control triggering.
Passwords, MFA and access reviews by role
The compliance lead owns the decision on what the password and authentication policy says, and the organization owns that decision, not the implementation partner or the auditor. The SOC 2 criteria do not set a minimum length or a rotation schedule, so the policy has to state a rule set the organization can defend, usually by reference to NIST SP 800-63B-4. The policy should say which accounts are single-factor, which require MFA, and how privileged and administrative access is treated. It should also describe how access is reviewed on a schedule and who approves exceptions.
- Named rule set: State the minimum length for single-factor passwords and for passwords used inside MFA, following the NIST figures.
- Blocklist and no forced rotation: Require a check against commonly used or compromised values and a forced change only on evidence of compromise.
- MFA scope: List the systems, remote access paths and administrative interfaces that must require a second factor.
- Access review cadence: Set how often reviewers certify user access and who signs off, and keep the records.
- Exception process: Define who can approve a deviation, how long it lasts and how it is reviewed.
Before the audit, confirm the policy matches what the identity system actually enforces, since a mismatch becomes an exception in the report.
The identity engineer turns the policy into configuration in the directory and the login layer, which in a self-hosted estate is often Keycloak or authentik. The engineer must make the enforced settings match the written rules, and must be able to show that the settings were applied and not merely planned. Password policy, lockout behavior, MFA enrollment, session lifetimes and account lifecycle all need to be configured and captured. Where a product cannot enforce a rule, such as a blocklist check, the engineer should document the gap and the compensating control instead of assuming it is covered.
- Password policy configuration: Set minimum length, blocklist checks and the absence of forced rotation in the realm or directory settings, and export the configuration as evidence.
- MFA enforcement: Require a second factor for the groups defined in the policy, and confirm enrollment status with a report.
- Account lifecycle: Disable accounts when people leave, and record the timestamp so leaver evidence can be traced.
- Access review exports: Produce user and role listings on the review date so reviewers certify a fixed snapshot.
- Change history: Keep configuration under version control or audit logging so changes to authentication settings are visible.
Confirm with the product documentation which of these settings the chosen version supports, since capabilities differ between releases.
The auditor tests whether the control operated as described over the examination period, and whether the criteria the organization selected are addressed. For authentication, the auditor will look at the policy, the configuration, and samples of accounts and access reviews. Because the criteria use points of focus rather than fixed rules, the auditor judges whether the design fits the risk the organization documented, and does not check a checklist of password numbers. Passwords and MFA are assessed together, so a strong password rule does not offset missing MFA on remote or administrative access, and the reverse also holds.
- Policy versus configuration: Compare the written rules with exported settings and note any gap as a finding or exception.
- Sampled accounts: Select users and confirm MFA status, role assignment and whether access was appropriate.
- Review completeness: Check that each scheduled access review covered the relevant systems, was signed by a named reviewer and resulted in recorded changes.
- Leaver timing: Compare termination dates with account disablement to test whether credentials were removed in time.
- Documented exceptions: Confirm that any deviation was approved, bounded and reviewed.
Ask the auditor early which samples and evidence formats they expect, so the records exist for the full period.
How the password control gets tested in a SOC 2
The sequence runs from a documented password standard, through configuration in the identity provider, to auditor sampling and exception handling, and each phase leaves a record the auditor can read. The auditor tests the design at a point in time for a Type 1 report and tests operation over a period for a Type 2 report.
Management documents the password standard
Management writes a password policy or authentication standard that names the rules it follows, such as the length and blocklist requirements in NIST SP 800-63B-4 and the decision to pair passwords with MFA. Management owns this document and approves it, and the approval date and version are recorded. The auditor checks that the standard exists, is approved, and matches what the organization says in its system description and customer commitments.
Map the standard to the criteria
The organization links the password standard to the relevant criteria, usually CC6.1 for logical access and CC6.6 for protecting authentication credentials and requiring additional authentication. The control matrix records each control owner, the system where the control runs, and the evidence the auditor will request. The output is a control matrix row that the auditor can trace from criterion to configuration to evidence.
Configure the identity provider to the standard
An engineer sets the password rules in the identity provider, such as Keycloak or authentik, including minimum length, blocklist checking, the absence of forced periodic changes and composition rules, and forced changes after evidence of compromise. Each setting is exported or screenshotted with the date and the change record. The check is complete when a test account confirms that the configured rules reject a blocklisted password and accept a long passphrase.
Confirm MFA enforcement for in-scope access
The team verifies that MFA is required for the accounts and paths the standard covers, such as remote, administrative, and production access, and that the configuration applies to every relevant realm, client, or policy. The evidence is a configuration export or policy listing that shows the MFA requirement. The auditor uses this to test the additional authentication part of CC6.6 alongside the password rules.
Auditor samples accounts and reviews configuration
For a Type 1 report, the CPA firm tests the design of the password controls as of a stated date by reviewing the policy and the configuration at that point. For a Type 2 report, the firm samples accounts and configuration changes across the observation period and checks that the rules were in effect throughout. Management supplies the population listings and change logs, and the auditor selects samples from them. The output is a test result for each sampled item.
Log and assess exceptions
When a sampled account or setting does not meet the standard, such as a legacy account without the blocklist check or a service account exempted without approval, the exception is recorded with its cause, scope, and risk. Management evaluates whether the exception affects the control's operation and whether it needs disclosure in the report. The auditor reviews the exception log and the evaluation as part of the test.
Remediate and retest the password controls
Management corrects the configuration or account, records the remediation with a date and owner, and retains proof that the fix took effect. For a Type 2 report, the auditor tests whether the corrected control operated consistently through the rest of the period. Management should confirm with the CPA firm how remediated exceptions will appear in the final report before the report is issued.
What to check before the auditor arrives
An auditor will test whether your password rules exist, are approved, and are enforced in configuration. The checks below connect a written policy to exported settings, account inventories and MFA coverage, so each claim in your system description has evidence behind it.
Management-approved password policy
Confirm that a written password or authentication policy exists, names an owner, and was approved by management with a recorded date. The policy should state the minimum length for single-factor passwords, the blocklist rule, the no-forced-rotation rule, and the forced-change trigger on evidence of compromise, all drawn from NIST SP 800-63B-4. Check that the approval record is dated before the observation period starts, since auditors compare policy dates against the period they test.
Configuration exports for length and blocklist
Export the live settings from every identity provider, directory and application that accepts passwords, then compare them with the policy line by line. Look for the minimum length for single-factor accounts, the blocklist check at set and change time, and whether any composition rule still runs. A policy that says one thing and a configuration export that says another is a common exception, so capture screenshots or API output with timestamps and the name of the person who ran the export.
Evidence that rotation is not forced
Show that expiry and periodic change are switched off in each system that stores passwords, and that the only forced change is triggered by compromise. Pull the password-age or expiry setting from the directory and the application configuration, and keep a sample of change events that were triggered by a compromise alert rather than a calendar. If an older system still forces rotation, record it as a known gap with a date for removal, because the auditor will test the setting, not the intent.
Inventory of accounts and authenticators
Build a list of every account that authenticates to in-scope systems, including human users, service accounts and shared administrative logins, and record which authenticator each one uses. Note whether the password is a single factor, part of an MFA pair, or stored in a vault. Reconcile this list against the identity provider export, because accounts that exist outside the directory are the ones auditors find during testing and the ones most often left with unmanaged credentials.
MFA enforced for remote and administrative access
Demonstrate that multi-factor authentication is required, not optional, for remote access and for administrative or privileged sessions. Export the enforcement policy from the identity provider and confirm that no group or exception bypasses it. Test the control yourself by attempting a remote login without the second factor, and file the result. This check supports the CC6.6 point of focus on requiring additional authentication, which is where most password-only exceptions surface.
Blocklist and compromise-response records
Show which blocklist source feeds the password check, how often it updates, and how a compromised credential is handled when it appears in a breach feed or a leak. Retain the blocklist configuration and a sample of forced resets tied to a real compromise event. Ask your identity platform vendor to confirm exactly which blocklist it uses and whether it screens passwords at creation, at change and on a recurring basis, because those capabilities differ between products.
Who owns the password control
The organization owns the password control. SOC 2 is an assertion-based examination, so management writes the description of the system and the statements about its controls, and it must give the service auditor written representations. A password policy, the blocklist, the account lockout rules and the decision to rely on MFA for higher-risk access are management decisions, and they must be approved, communicated and enforced by the organization itself. The criteria set no length or rotation rule, so the organization chooses a policy aligned with NIST SP 800-63B-4 and documents why.
- Policy ownership: A named owner approves the password standard, reviews it on a set cycle and records changes.
- Control design: The organization decides which identity provider, directory or SSO service enforces the rules, and where local accounts are allowed.
- Operating evidence: Staff run the controls day to day, including joiner and leaver processing, password resets and exception approvals.
- Management representations: Leaders confirm in writing that the described controls existed and operated during the period.
- Accountability: The organization answers auditor questions and owns any exceptions found during fieldwork.
Check that your policy names an owner, a review date and the systems it covers, and that someone inside the company can explain each rule without referring to a vendor.
An implementation partner such as DeployOpen can help prepare the technical side of the password control. Under a fixed-scope engagement, the partner might configure a self-hosted identity platform so that it enforces the agreed length, blocklist and lockout settings, set up MFA enrollment, and export configuration and log evidence that shows those settings were in place. The partner works inside the client's own infrastructure and hands the client the systems, documentation and evidence. It does not decide the policy for the client, and it does not issue opinions, reports or attestations on whether the control works.
- Configuration work: Setting identity platform policies to match the organization's approved standard.
- Evidence preparation: Producing configuration exports, change records and sample login logs that the organization can give the auditor.
- Documentation: Writing runbooks and descriptions of how the settings are applied and reviewed.
- Testing support: Running security tests that help the organization find weak or reused passwords before the auditor does.
- Written scope: Agreeing in advance which systems, settings and deliverables are included and which are not.
Ask the partner in writing which deliverables it will produce, and confirm that its role ends at preparation and that it will not represent itself as the auditor.
The independent CPA firm is the only party that tests the password control for the SOC 2 report. Under the AICPA attestation framework, the service auditor evaluates whether the controls are suitably designed and, for a Type 2 report, whether they operated effectively across the period. The auditor selects samples, reads the policy, inspects configuration, reviews exceptions and decides what the report says. The firm must be independent of the organization and of any firm that prepared the controls, and it issues the report under its own name.
- Design testing: The auditor checks whether the password standard and the enforcing settings address the criteria tied to access credentials.
- Operating testing: For Type 2, the auditor samples accounts and events across the observation period.
- Independence: The firm may not design or operate the controls it tests, and this boundary limits what the same firm can do for the client.
- Report issuance: Only the CPA firm issues the SOC 2 report and its opinion, including any exceptions.
- Engagement terms: The engagement letter defines the scope, the period and the representations the auditor will require.
Confirm the firm's independence in writing before fieldwork starts, and ask how it will treat any preparation work your partner has done.
The boundary between the three parties decides whether the password control produces a credible report. The organization owns the control and its evidence, the implementation partner prepares settings and documents, and the CPA firm tests and reports. Problems arise when these roles blur, for example when a partner that configured the controls is also asked to certify that they work, or when an organization assumes a tool's default settings satisfy the criteria without a documented decision. Keeping the roles separate protects the report's value for customers and regulators who rely on it.
- Preparation is not attestation: A partner's readiness work does not replace the auditor's testing.
- Documented decisions: The organization records why each password setting was chosen, not just what the default was.
- Clean hand-offs: Evidence should come from the system with timestamps, not from a partner's summary.
- Conflict checks: Ask the CPA firm what non-attest services it may provide and how it handles self-prepared work.
- Vendor reliance: Vendor SOC reports on an identity provider cover that vendor's controls, not yours.
Before signing, write down who signs each deliverable and who may issue any statement about the password control.
Questions buyers ask about SOC 2 passwords
Does SOC 2 require a specific password length?
No. The 2017 Trust Services Criteria do not set a minimum password length or any other password rule. Auditors test whether your policy is designed sensibly and whether controls operate as written, so the rule you choose has to be defensible and consistently applied. Many organizations anchor their policy to NIST SP 800-63B-4, which requires passwords used as a single authentication factor to be at least 15 characters, and at least 8 characters when used only within multi-factor authentication (section 3.1.1.2). Confirm with your auditor which standard they will use as the reference point before you finalize the policy.
Do we still need to force 90-day password rotation for SOC 2?
SOC 2 does not require it, and NIST SP 800-63B-4 advises against it. The guideline says verifiers must not require periodic password changes and must force a change when there is evidence of compromise (section 3.1.1.2). Forced rotation often pushes people toward predictable patterns. A stronger design is a blocklist of commonly used, expected or compromised passwords, a forced reset after a suspected compromise, and access reviews for accounts that no longer need access. If you keep a rotation rule for a customer or internal reason, document why and make sure your policy and system description match what the systems actually enforce.
Can MFA replace strong passwords in a SOC 2 environment?
MFA strengthens authentication but does not remove the need for a sound password policy. NIST SP 800-63B-4 states that passwords are not phishing-resistant, and at authentication assurance level 2 it requires a multi-factor authenticator or two separate factors, with at least one phishing-resistant option offered. Where passwords remain part of the sign-in, the password rules still apply. The practical answer is to keep passwords with length and blocklist checks, require MFA for remote, administrative and production access, and prefer phishing-resistant authenticators for the highest-risk accounts. Map this to CC6.6 in your control matrix so the auditor sees both layers.
How much effort does a password policy change take, and what drives it?
The policy document is the smallest part of the work. Effort depends on how many systems authenticate users directly rather than through a central identity provider, how many accounts and service credentials are involved, whether passwords are stored with modern hashing, and whether you can enforce blocklist checks and length rules in each system. Legacy applications and shared accounts usually take the longest. Costs are mostly staff time for inventory, configuration and communication, plus any identity platform work. Ask any partner for a fixed-scope estimate that lists each system, the enforcement method and the evidence you will hand to the auditor.
Can our internal team handle SOC 2 password controls without outside help?
Often yes, if the team owns identity and has time to maintain the work. The controls are configuration, policy and evidence tasks: setting length and blocklist rules, removing forced rotation, enforcing MFA, reviewing credentials under CC6.2 and keeping records. The hard part is consistency across every system and proving the controls operated over the audit period, which matters most for a Type 2 report. Outside help can be useful for inventorying systems, configuring a self-hosted identity platform, or building evidence collection. Only the independent CPA firm issues the report, so an implementation partner prepares the controls and evidence without replacing the auditor.
What should we ask an auditor or partner before signing?
Ask the auditor which password reference standard they accept, how they will sample evidence for authentication controls, and whether they expect Type 1 or Type 2 coverage for the period you need. Ask a partner for the written scope, which systems and identity sources are included, what configuration changes they will make, what evidence they will deliver, and what you must do yourself. Confirm who owns each control after handover, how exceptions are handled, and whether ongoing support is a separate retainer. Request a fixed-scope written proposal before work begins, since DeployOpen agrees scope, deliverables and timelines in writing and provides quotes from that scope.
How DeployOpen prepares password and identity controls for audit
DeployOpen helps organizations set up the password and identity controls a SOC 2 examination will test, built on the NIST SP 800-63B-4 rules their policy is written against. The organization owns its password policy and controls, DeployOpen prepares the systems and evidence, and only an independent CPA firm issues the SOC 2 report.
How we scope
- Written scope lists the identity systems, directories and applications where password rules are enforced.
- The scope names which password rules apply to single-factor and MFA-backed logins, based on your policy.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Configure password length, blocklist checks and lockout settings in self-hosted identity platforms such as Keycloak or authentik.
- Remove forced periodic rotation and composition rules from identity configuration where your policy no longer requires them.
- Integrate MFA enrollment and recovery flows so that password logins are paired with a second factor where your policy requires it.
How we hand over
- Deliver configuration records and a mapping of each password rule to the policy statement it supports.
- Provide sample evidence exports, such as configuration snapshots and administrator change logs, for the CPA firm to request.
- Document ownership, review cadence and the steps to update password settings, so your team can operate them after handover.
How we support
- Ongoing support and periodic configuration reviews are available as a retainer, scoped in writing.
- Support can cover upgrades to the identity platform and retesting of password and MFA settings after changes.
- Confirm with your CPA firm which evidence it needs for the observation period before a Type 2 examination begins.
Sources and further reading
- AICPA 2017 Trust Services Criteria (revised points of focus, 2022) ↗
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management ↗
- NIST Privacy Framework crosswalk to the AICPA 2017 Trust Services Criteria ↗
- AICPA SOC 2: SOC for Service Organizations, Trust Services Criteria ↗
- AICPA Illustrative Management Representation Letter: SOC 2 Type 2 ↗
