---
status: template
playbook-section: 40
title: "Password & Authentication Policy"
last-reviewed: "[FILL IN: YYYY-MM-DD]"
---

# Password & Authentication Policy

> **Template status** — fill every `[FILL IN: …]` marker before use.

> **Not code-enforced** — MFA enforcement, minimum password complexity, and account lockout are **explicitly deferred** in [ADR-025 § Deferred items](../../decisions/adr-025-eu-compliance-baseline.md) because they require identity-infrastructure choices (TOTP/WebAuthn/passkeys), a threat-model-specific policy, and an OTP delivery vendor that are consumer-supplied. This template documents the policy; the consumer implements the technical controls once those choices are made.

---

## 1. Purpose & Scope

This policy defines the minimum authentication standards for all accounts — human and service — that access systems operated by `[FILL IN: organisation name]`, including `[FILL IN: describe systems — e.g., the application, Payload CMS, cloud infrastructure consoles, CI/CD pipelines]`.

**Owner:** `[FILL IN: role — e.g., Head of Engineering / CISO]`

---

## 2. Password Requirements

### 2.1 User accounts

| Requirement             | Minimum standard                            | Organisation value             |
| ----------------------- | ------------------------------------------- | ------------------------------ |
| Minimum length          | 12 characters                               | `[FILL IN:]`                   |
| Character complexity    | No single-class requirement; length > rules | `[FILL IN: any additions]`     |
| Breach / pwned-password | Must be checked on creation / change        | `[FILL IN: tool / service]`    |
| Maximum age             | Not enforced unless breach detected         | `[FILL IN: or "not enforced"]` |
| Reuse restriction       | `[FILL IN: e.g., last 10 passwords]`        | `[FILL IN:]`                   |

> Reference: NIST SP 800-63B §5.1.1 — length beats complexity rules; mandatory rotation is discouraged.

### 2.2 Service accounts & API secrets

- All service secrets are stored in `[FILL IN: secret manager — e.g., AWS Secrets Manager / HashiCorp Vault]`.
- Secrets are rotated `[FILL IN: frequency — e.g., every 90 days or on suspected compromise]`.
- Long-lived credentials are prohibited for `[FILL IN: list systems — e.g., production database, CI/CD pipelines]`.

---

## 3. Multi-Factor Authentication (MFA)

> **Deferred per ADR-025.** The specific MFA method (TOTP, WebAuthn, SMS) and the enforcement perimeter are consumer decisions. Until those choices are made, document the target state here.

| Account type                   | Required MFA method          | Enforcement date / trigger |
| ------------------------------ | ---------------------------- | -------------------------- |
| Admin / privileged users       | `[FILL IN: e.g., WebAuthn]`  | `[FILL IN: YYYY-MM-DD]`    |
| All users (application)        | `[FILL IN: e.g., TOTP]`      | `[FILL IN:]`               |
| Service accounts               | N/A — use short-lived tokens | —                          |
| Infrastructure / cloud console | `[FILL IN:]`                 | `[FILL IN:]`               |

---

## 4. Account Lockout & Brute-Force Protection

> **Deferred per ADR-025.** Lockout thresholds are deferred until the authentication threat model is established. The application ships rate-limit budgets (see `rateLimit` in each feature manifest and ADR-025 § Epic C) but does not hard-lock accounts.

| Parameter                      | Target value                                    | Status                       |
| ------------------------------ | ----------------------------------------------- | ---------------------------- |
| Failed attempts before lockout | `[FILL IN: e.g., 10]`                           | `[FILL IN: deferred / live]` |
| Lockout duration               | `[FILL IN: e.g., 15 minutes]`                   | `[FILL IN:]`                 |
| Admin unlock procedure         | `[FILL IN: e.g., helpdesk ticket + MFA reset]`  | `[FILL IN:]`                 |
| Notification on lockout        | `[FILL IN: e.g., email to user + Sentry alert]` | `[FILL IN:]`                 |

---

## 5. Privileged Access

- Privileged (admin) access requires `[FILL IN: approval workflow — e.g., pair-approval in #infra-access]`.
- Privileged sessions are limited to `[FILL IN: duration — e.g., 4-hour session tokens]`.
- All privileged actions are captured by the audit channel (see [`docs/guides/audit-and-compliance.md`](../../guides/audit-and-compliance.md)).

---

## 6. Review Cycle

This policy is reviewed `[FILL IN: frequency — e.g., annually or after any authentication-related incident]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`.