Home › Guides › Passwords

SOC 2 password requirements

Updated 2026-09-19 · 7 min read · by Deepak Gandhi, who builds SOC2Starter

Why there is no number to look up

People search for SOC 2 password requirements expecting to find a figure — twelve characters, ninety days, one symbol. There isn't one, and the absence is deliberate.

SOC 2 is built on criteria that describe outcomes rather than rules that prescribe settings. The relevant criterion, CC6.1, concerns restricting logical access to authorised users. It does not say how. You decide what “appropriate” means for your company, write it down, and the auditor tests whether reality matches what you wrote.

This has an uncomfortable consequence that catches people out: your policy becomes the standard you are audited against. There is no external minimum to fall short of, but there is also nothing protecting you from a commitment you made and did not keep. A company promising sixteen characters and enforcing eight has a finding. A company promising eight and enforcing eight does not.

What the auditor actually tests

Three things, in this order:

1. Does a documented standard exist? Usually inside your access control policy, approved and dated.
2. Is it technically enforced? Not whether people follow it by habit — whether the system prevents them doing otherwise. This is the step that separates a control from an intention.
3. Can you evidence it? A dated screenshot or export of the actual configuration in your identity provider, showing the settings your policy claims.

That second point is where most findings originate. “Everyone uses strong passwords” is a statement about culture. “Google Workspace enforces a 12-character minimum, and here is the admin console showing it” is a control. If a setting cannot be enforced centrally, an auditor will reasonably ask how you know.

Single sign-on changes the question

If your company runs on Google Workspace, Microsoft 365 or Okta, and most of your tools authenticate through it, then the password standard that matters is the one on that identity provider. Everything behind SSO inherits it.

That is genuinely good news, because it turns a policy you would otherwise enforce by nagging into a single configuration you can screenshot. It also narrows what you have to evidence: one admin console rather than fifteen product settings pages.

What it does not do is cover everything, and the gaps are predictable:

• Your cloud provider's root account, which usually sits outside SSO by design and is the single highest-value credential you own.
• Databases and admin consoles with their own local authentication.
• Tools bought on a credit card by one team and never brought into SSO.
• Anything predating your identity provider that nobody migrated.

List those exceptions explicitly in your policy rather than hoping the auditor does not ask. A named exception with a compensating control — stored in the password manager, MFA enabled locally, access limited to two people — reads as control. An unnamed one reads as an oversight.

A standard that will not trip you up

This is defensible, matches current guidance, and is enforceable in every major identity provider:

• Minimum 12 characters. Length is the property that actually resists modern cracking. Twelve is comfortably enforceable and widely accepted; going to sixteen is fine if you will genuinely hold to it.
• MFA required, everywhere. Far more important than any password rule. Enforced, not merely available — including on cloud root accounts and any admin console reachable from the internet.
• Screened against known-breached passwords. Most identity providers offer this. It prevents the actual attack, which is credential reuse rather than brute force.
• No scheduled expiry. See below.
• Lockout after repeated failures. A modest threshold with a delay.
• A company password manager. Makes the rest realistic instead of theoretical.

Notice what is missing: a complexity formula demanding one uppercase, one digit and one symbol. It is not prohibited, but it is no longer recommended practice, and it pushes people toward predictable substitutions.

Why 90-day rotation is now a liability

Forced password expiry was standard advice for decades and is still written into a great many policy templates. Current guidance from NIST — specifically SP 800-63B, which auditors are broadly familiar with — recommends against routine scheduled rotation, advising that passwords be changed on evidence of compromise instead.

The reasoning is behavioural. People forced to change passwords every quarter make small predictable edits, reuse patterns across systems, and write them down. The rotation buys very little and costs real security.

Two practical consequences:

• Do not copy a template that mandates 90-day rotation unless you intend to enforce it. If your policy says rotation happens and your identity provider is not configured to force it, that is a finding — created entirely by boilerplate nobody read.
• Enterprise questionnaires still ask about rotation. Some buyers have not updated their forms. Answering “we do not force scheduled rotation, in line with NIST SP 800-63B; we require 12+ characters, enforced MFA, and breached-password screening, and we force resets on evidence of compromise” is a strong answer. It is specific, current, and shows you decided rather than defaulted.

Service accounts, keys and the things that are not passwords

The part most policies forget. A SOC 2 auditor looking at access control will ask about credentials that no human ever types.

• API keys and tokens. Who can issue them, where they are stored, and how they are revoked when someone leaves.
• Service accounts. These usually cannot use MFA, which makes their scope and rotation genuinely important — this is the one place where periodic rotation still earns its keep.
• SSH keys. Who holds them and whether they are passphrase-protected.
• Shared credentials. The honest answer for most small companies is that one or two exist. Put them in the password manager with access recorded, and say so.

You do not need a sophisticated secrets programme at ten people. You do need to have thought about it, because “we hadn't considered that” is a worse answer than any imperfect arrangement you can describe.

What to write in the policy

Keep it short and enforceable. A workable access control policy section reads roughly:

“Passwords for all company systems must be at least 12 characters. Multi-factor authentication is required on all systems supporting it, including cloud infrastructure and administrative consoles. Passwords are screened against known-breached credential lists where the platform supports it. Scheduled password expiry is not enforced, in line with NIST SP 800-63B; passwords are reset on evidence or suspicion of compromise. Accounts lock after repeated failed attempts. Company credentials are stored in the approved password manager and never shared outside it.”

Then, crucially, go and configure your identity provider to match, and screenshot it with the date visible. The policy and the screenshot together are the evidence. Either one alone is not.

Resist the temptation to make the policy more impressive than your configuration. Every additional promise is something the auditor will test, and the report records the gap rather than the ambition.

Questions people ask

What are the SOC 2 password requirements?

SOC 2 specifies none. There is no mandated minimum length, complexity formula or rotation period anywhere in the Trust Services Criteria. The requirement is that you define your own password standard, enforce it technically, and evidence that enforcement. Your own policy becomes the standard you are audited against.

What is the minimum password length for SOC 2?

There is no mandated minimum. Twelve characters is a common and defensible choice that is enforceable in every major identity provider and aligns with current guidance. What matters to the auditor is that whatever number you put in your policy is actually enforced in configuration, not that you picked a particular figure.

Does SOC 2 require 90-day password rotation?

No, and current guidance advises against it. NIST SP 800-63B recommends against routine scheduled rotation, since it drives predictable password edits and reuse, and suggests resetting on evidence of compromise instead. Be careful with policy templates that still mandate rotation: if your policy says it happens and your systems do not enforce it, that is a finding created entirely by boilerplate.

Is MFA required for SOC 2?

Not named as a requirement, but in practice it is expected. Auditors reading the logical access criteria will ask how you restrict access to authorised users, and enforced multi-factor authentication is the clearest answer. It matters considerably more than any password length rule, and it must be enforced rather than merely available.

How do you prove password requirements to a SOC 2 auditor?

With two artefacts together: the approved, dated policy stating your standard, and a dated screenshot or export of your identity provider configuration showing that standard actually enforced. A policy alone proves intent; a configuration alone proves no decision was recorded. Auditors ask for both.