Why password policy is always in scope
Credential-based attacks — phishing, credential stuffing, brute force — account for the majority of confirmed data breaches year after year. Password and authentication policy is the control framework that addresses this class of risk.
Every major compliance framework requires a documented password and authentication policy:
| Framework | Control Reference | Core Requirement |
|---|---|---|
| SOC 2 | CC6.1 / CC6.3 | Logical access controls; authentication mechanisms restrict access to authorised users |
| ISO 27001 | A.8.5 — Secure Authentication | Secure log-on procedures implemented; password management enforced |
| ISO 27001 | A.8.2 — Privileged Access Rights | Privileged access formally managed and restricted |
| PCI DSS v4.0 | Req 8 — Authentication | Unique user IDs; MFA for all CDE access; 12-char passwords from March 2025 |
| NIS2 | Art. 21(2)(j) | MFA or continuous authentication mandatory for essential/important entities |
| HIPAA | §164.312(a)(2)(i) / (d) | Unique user identification; person or entity authentication |
| NIST SP 800-63B | §5 — Memorised Secrets | Minimum 8 chars; breach screening; no mandatory periodic rotation without compromise |
| GDPR / UK GDPR | Art. 32 — TOMs | Appropriate technical measures including authentication controls |
This post covers what your policy must include, common mistakes (especially around NIST guidance), and how to evidence compliance for SOC 2 auditors.
Password length: the single most important control
Length beats complexity. A 16-character passphrase using dictionary words is exponentially harder to crack than an 8-character random string — brute force attack time increases by orders of magnitude with each additional character.
Minimum standards by framework:
- NIST SP 800-63B §5.1.1: Minimum 8 characters for memorised secrets (but NIST recommends 15+ and up to 64 characters supported)
- PCI DSS Req 8.3.6 (effective March 2025): Minimum 12 characters (up from 7 in v3.2.1)
- ISO 27001 / SOC 2: No specific minimum — requires the policy to be documented and proportionate to risk; 12+ characters is the defensible position
- HIPAA: No specific minimum — document and justify; 12+ characters is the defensible baseline
Recommended standard for SaaS in 2026: 12 characters minimum satisfies PCI DSS v4.0, is well above NIST's 8-character floor, and aligns with ISO 27001 and SOC 2 audit expectations. For privileged accounts: 16+ characters minimum.
The NIST guidance most companies misapply
NIST SP 800-63B §5.1.1.2 includes guidance that most companies interpret as "don't require password changes." The nuance matters:
| NIST says | What this means in practice |
|---|---|
| Don't require periodic password changes without compromise trigger | No mandatory 90-day rotation if there's no evidence of compromise — forced rotation encourages predictable patterns (Password1! → Password2!) |
| Do require password change when compromise is suspected or confirmed | Proactive rotation on suspected phishing, credential leak, or staff departure is mandatory |
| Screen against breached passwords | At password creation/change, check against known breach databases (Have I Been Pwned, NIST breach list) |
| Support up to 64-character passwords | Allow passphrases; don't artificially cap length at 20 or 32 characters |
| Don't impose complexity rules if length is sufficient | If minimum is 15+ characters, requiring uppercase+digit+symbol adds minimal security and increases friction |
Practical implication: For most SaaS companies, a policy that says "12+ characters, no mandatory periodic rotation, breach screening at creation, immediate rotation on compromise" is both NIST-aligned and more secure than the legacy "8 characters, 90-day rotation, must include uppercase + number + symbol" approach.
PCI DSS note: PCI DSS Req 8.3.9 still requires password rotation every 90 days if no alternative authentication factor is used. If MFA is enforced for all CDE access, periodic rotation is not required under PCI DSS v4.0.
MFA requirements: what every framework requires
MFA is no longer optional for any compliance-oriented SaaS company. The question is scope and method.
| Framework | MFA Requirement | Notes |
|---|---|---|
| NIS2 Art. 21(2)(j) | MFA or continuous authentication mandatory | Applies to essential/important entities — no exceptions for "small" organisations within scope |
| PCI DSS Req 8.4.2 | MFA for all non-console access into the CDE | Even from inside the network since PCI DSS v4.0 (major change from v3.2.1) |
| PCI DSS Req 8.4.3 | MFA for all remote network access | Any remote access to the cardholder data environment |
| SOC 2 CC6.1/CC6.3 | No explicit MFA mandate — but auditors expect it | "Appropriate" authentication controls; no MFA for admin accounts = gap finding |
| ISO 27001 A.8.5 | "Secure authentication" — MFA implied for privileged access | A.8.2 privileged access requires stronger controls including MFA |
| HIPAA §164.312(d) | Person or entity authentication required — MFA strongly recommended | HIPAA guidance (not rule) recommends MFA for remote access to ePHI |
Minimum viable MFA scope for most SaaS companies:
- All employee/staff accounts (non-negotiable)
- VPN and remote access (non-negotiable)
- Production systems and cloud management consoles
- Admin accounts on any system
- Customer-facing login (highly recommended for data controller obligations)
MFA method security hierarchy
Not all MFA is equal. Here's the security hierarchy, from most to least secure:
| Method | Security Level | Phishing-resistant | Notes |
|---|---|---|---|
| FIDO2/WebAuthn hardware key (YubiKey, Titan) | Very High | ✅ Yes | Best for admin and privileged accounts; requires physical key |
| Passkeys (device-native FIDO2) | Very High | ✅ Yes | Platform passkeys (Face ID/Touch ID backed); best UX for phishing-resistant MFA |
| TOTP authenticator app (Authy, Google Auth, 1Password) | High | ❌ No | TOTP codes can be phished in real-time; acceptable for most use cases |
| Push notification (Duo, Microsoft Auth) | High | ❌ No | Susceptible to MFA fatigue attacks — enable number matching to mitigate |
| SMS OTP | Low — Deprecated | ❌ No | SIM swap and SS7 attacks; only acceptable where nothing else is possible |
| Email OTP | Low — Deprecated | ❌ No | Email account compromise bypasses this factor entirely |
MFA fatigue attacks: Attackers send repeated push MFA requests at 3am until the exhausted victim taps "approve." Mitigate by enabling number matching (user must enter a code displayed on the login screen in the push app — can't approve without seeing the code) and additional context (show IP and location).
Service account controls: the overlooked risk
Service accounts — identities used by applications, CI/CD pipelines, and automation — are often the weakest point in an authentication posture because:
- They accumulate permissions over time without review
- Their credentials are often shared, hardcoded, or never rotated
- They can't enrol in MFA like human users
- They often have elevated permissions for operational convenience
Minimum service account controls:
| Control | Why it matters |
|---|---|
| No shared service accounts — unique identity per service | Shared accounts make attribution impossible and access reviews meaningless |
| Secrets stored in secrets manager (AWS SSM, HashiCorp Vault, 1Password Secrets Automation) | Credentials in code = immediate compromise when repo is public or employee departs |
| Rotate credentials every 90 days (or use short-lived tokens) | Limits blast radius if credential is compromised |
| Least privilege — no admin/root permissions for service accounts | Service account compromise with admin rights = full environment compromise |
| Service account inventory reviewed quarterly | Orphaned service accounts accumulate; deprovisioning is often missed |
The modern alternative to long-lived service account credentials: short-lived tokens via role assumption (AWS IAM Roles, GCP Workload Identity, Azure Managed Identity). The credential doesn't persist long enough to be useful if stolen.
Privileged access management (PAM)
Privileged accounts — root, global admin, production database admin — are the most valuable targets for attackers. Controls:
- Separate privileged accounts from daily accounts: Your engineer's day-to-day account should not have root permissions. A separate account is used only when privileged access is needed — and that account has strong MFA.
- Just-in-time (JIT) access: Rather than permanent admin permissions, request elevated access for a time-limited window (e.g., 1 hour via AWS SSM Session Manager or HashiCorp Vault). This dramatically limits the blast radius of a compromise.
- No permanent root: Cloud management root accounts are locked away, not used daily. Operators use role assumption to assume minimum required permissions.
- Break-glass accounts: Emergency accounts exist in sealed envelopes / hardware vaults. Any access to break-glass credentials triggers immediate security alerts and a post-access review.
What SOC 2 auditors look for
SOC 2 auditors assess authentication controls under CC6.1 (logical access) and CC6.3 (authentication). What they typically sample:
- Evidence that a documented password policy exists and was reviewed in the audit period
- Identity provider (IdP) configuration screenshots showing MFA enforcement — not just policy, but technical enforcement
- A sample of user accounts showing MFA is enrolled (not just enabled but unenforced)
- Evidence of MFA bypass prevention — legacy authentication protocols blocked
- Privileged account inventory and evidence of separate admin accounts
- Service account inventory with credential rotation records
- Access reviews (CC6.2) showing regular review of who has what access
Common finding: MFA is "enabled" but not enforced — users can skip enrollment or use legacy auth bypass paths (IMAP, basic auth). Auditors check technical enforcement, not just policy.
5 common password policy mistakes
| Mistake | Risk | Fix |
|---|---|---|
| 90-day mandatory rotation without MFA enforcement | Users create Password1! → Password2! — provides false security | Enforce MFA; drop mandatory rotation except on compromise |
| MFA enabled but not technically enforced | Users skip enrollment; legacy auth bypasses MFA entirely | Configure conditional access to block legacy auth; enforce MFA enrollment at onboarding |
| Hardcoded credentials in code repositories | Credentials exposed in public or semi-public repos = immediate compromise | Secrets manager for all credentials; git-secrets or similar scanning in CI/CD |
| Shared admin accounts for production access | Attribution impossible; access reviews meaningless; can't investigate post-incident | Unique identity per person; use role assumption for admin access |
| No account lockout or rate limiting | Credential stuffing attacks run unimpeded | Implement lockout after 10 failed attempts; IP-level rate limiting at application layer |
Generate your password and authentication policy: Password & Authentication Policy Generator, Access Control Policy, Information Security Policy, SOC 2 Gap Assessment, ISO 27001 Gap Assessment.
Related reading: Access Control Policy Guide, SOC 2 Gap Analysis, SOC 2 Evidence Collection Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Authentication requirements vary by compliance framework and audit scope. Consult a qualified security professional for implementation guidance tailored to your organisation.