# Authentication & Password

**Organization:** {{COMPANY_LEGAL_NAME}}
**Document owner:** {{POLICY_OWNER_ROLE}}
**Approved by:** {{APPROVER_NAME}}, {{APPROVER_TITLE}}
**Version:** {{VERSION}} · **Effective:** {{EFFECTIVE_DATE}} · **Next review:** {{REVIEW_DATE}}
**Classification:** Internal

---

## 1. Purpose

This policy gives {{COMPANY_LEGAL_NAME}} strong, workable authentication that stands up to brute-force and credential-stuffing attacks, protecting access to {{CRITICAL_SYSTEMS}} and {{DATA_TYPES}} across {{GEO_SCOPE}}.

## 2. Scope

This policy covers every human and service account that reaches our applications, {{DEVICE_TYPES}}, and infrastructure. It applies to the {{LOCATION}} workforce, and only managed {{DEVICE_TYPES}} may administer identity systems or production authentication settings in {{CRITICAL_SYSTEMS}}.

## 3. Policy statements

### 3.1 Password requirements
Passwords are at least eight characters or a passphrase, and common breached strings are blocked. We do not force periodic rotation unless we suspect compromise. Each system gets a unique password, kept in an approved password manager, and work passwords are never reused on personal accounts.

### 3.2 Multi-factor authentication
We require multi-factor authentication for administrator accounts, remote access, and any system holding confidential or restricted {{DATA_TYPES}} or running in {{CRITICAL_SYSTEMS}}. Authenticator apps or hardware tokens are preferred, with SMS only as a fallback, and we apply step-up prompts for sensitive actions where a system supports them.

### 3.3 Credential storage and transmission
User passwords are hashed with a strong, salted algorithm such as bcrypt or Argon2. Logins travel only over TLS, and plaintext logins to {{CRITICAL_SYSTEMS}} are blocked. Secrets are never committed to source control; application secrets live in an approved vault or key management service with audit logs retained as {{GEO_SCOPE}} requires.

### 3.4 Account lockout and recovery
Accounts lock after repeated failed attempts in a short window and unlock after a cooldown or an administrator reset. We verify identity before any password reset and issue time-limited reset links. Inactive accounts are disabled and stale sessions to {{CRITICAL_SYSTEMS}} are cleared.

### 3.5 Service accounts and keys
Service accounts cannot log in interactively; they use least-privilege scopes and short-lived credentials. We rotate their credentials at least annually and on suspected compromise, store them only in a vault or key management service, and review their programmatic access to {{CRITICAL_SYSTEMS}} for anomalies.

### 3.6 Measurement and continual improvement
Automated scans confirm multi-factor authentication is enabled on every target system, and periodic password audits confirm the length rules hold. For teams over {{EMPLOYEE_COUNT}} people we widen quarterly sampling across {{CRITICAL_SYSTEMS}} tiers, and we adopt stronger, passwordless methods as they mature in line with {{INDUSTRY}} practice.

## 4. Roles and responsibilities

| Role | Responsibility |
|---|---|
| Executive sponsor | Accountable for the program; approves this policy |
| {{POLICY_OWNER_ROLE}} | Maintains this policy and its procedures |
| Managers | Enforce the policy within their teams |
| All personnel | Comply; report issues promptly |

## 5. Compliance and exceptions

Weak or reused passwords, plaintext secrets, or disabled multi-factor authentication trigger an immediate reset or suspension and user retraining. Systems that cannot support multi-factor authentication require documented risk acceptance by {{APPROVER_TITLE}}, compensating controls, and an expiry date.

## 6. Review

This policy is reviewed at least annually and when significant change occurs.

---

*Aligned to CIS Critical Security Controls. {{COMPANY_LEGAL_NAME}} is not affiliated with or endorsed by the relevant standards body; full standard text is copyrighted and is not reproduced here.*