Password Policy Template: Length, Screening, MFA and Service Account Rules

Many written password policies still demand complexity and 90-day expiry, which both NIST and the NCSC now advise against, so the document that auditors read contradicts the guidance it claims to follow. This template is a fill-in password policy aligned with NIST SP 800-63B-4 (July 2025) and NCSC guidance: length over complexity, screening against breached and common passwords, change on evidence rather than on a calendar, MFA where it matters, and separate rules for privileged and service accounts. It is for policy owners, IAM leads and auditors who need wording they can adopt. The reasoning behind each setting, and how to configure it in Active Directory, Entra ID, AWS and Okta, is in the Password Policy Guide (NIST-aligned); this page does not repeat it.

How to use this template

• Placeholders: replace text in square brackets, such as [Organisation], [IAM team] and [15] characters, with your own terms. Bracketed numbers are suggested values consistent with NIST SP 800-63B-4.
• Must and should: "must" is mandatory; "should" allows a documented alternative.
• Write the policy, then the standard: keep platform settings, such as Password Settings Objects or tenant settings, in a separate [Password Configuration Standard] that cites the statement numbers below.
• Account types: the settings table in 4.1 has one column per account type. Delete columns you do not use rather than weakening a row.
• Machine credentials: section 4.7 sets the minimum for service accounts that still use passwords. Wider rules for API keys, tokens and certificates belong in the NHI Policy Template.

1. Purpose

This policy sets the requirements for creating, using, storing and changing passwords and other memorised secrets used to access [Organisation] systems. It aims to make passwords hard to guess or reuse, to remove rules that push people towards predictable passwords, and to ensure that a password alone is not enough to reach sensitive systems.

2. Scope

This policy applies to:

• All user, administrator, service and shared accounts that authenticate with a password to [Organisation] directories, cloud tenants, applications, network devices and operational technology.
• All systems that verify passwords, including applications built or bought by [Organisation] that hold local accounts.
• All employees, contractors, suppliers and other people given an [Organisation] account.

PINs that unlock a local device authenticator, such as a passkey or Windows Hello, are covered by [Endpoint Security Standard]. Customer accounts on [Organisation] services are covered by [Customer Authentication Standard], which should adopt sections 4.1 to 4.4.

3. Roles and responsibilities

4. Policy statements

4.1 Password settings by account type

Systems that verify passwords must be configured to at least these values. A system that cannot meet a value must be listed in the exceptions register (section 5).

4.2 Creating passwords

1. Account holders must create a password that is unique to the account and not used for any personal or other work account.
2. Account holders should use a passphrase, such as three or more random words, or a password generated by the [approved password manager].
3. Passwords must not contain the account name, [Organisation] name, product names or other terms on the [Organisation] blocklist.
4. Systems must tell the user why a password was rejected and must not require a mix of character types.
5. Systems must not offer password hints visible before sign-in and must not use security questions for password setting or recovery.

4.3 Storing and handling passwords

1. Passwords must not be written down unsecured, sent by email or chat, stored in documents, spreadsheets, browsers on unmanaged devices, source code or tickets.
2. Account holders must store work passwords only in the [approved password manager].
3. Systems must allow password managers and autofill, and should allow paste into password fields.
4. Systems built by [Organisation] must store passwords only as salted hashes using [approved password hashing scheme, e.g. Argon2id, scrypt or PBKDF2] with a salt of at least 32 bits, per [Cryptography Standard].
5. Initial and reset passwords must be random, single use, and must be changed at first sign-in.

4.4 Changing passwords

1. Passwords must not be changed on a fixed schedule.
2. A password must be changed immediately when there is evidence or reasonable suspicion of compromise, including a match against a breached password source, a risky sign-in alert, phishing, malware on the device, or disclosure to another person.
3. [IAM team] should check existing password hashes against breached password data at least [monthly] where the platform supports it, and force a change on any match.
4. Resets must follow identity verification in [Account Recovery Procedure].

The 23andMe breach shows why 4.2.1 and 4.4.3 matter: reused passwords from other breaches opened more than 18,000 accounts.

4.5 Multi-factor authentication

1. MFA must be required for remote access, cloud and SaaS administration, email, and any system holding [Confidential] data or above.
2. Privileged accounts must use phishing-resistant MFA such as FIDO2 security keys, passkeys or certificate-based authentication.
3. SMS and voice codes should be used only where no other method is available, and must not be used for privileged accounts.
4. Where single sign-on is available, applications must use it instead of local passwords, with MFA enforced at the identity provider.

The Change Healthcare breach began with a stolen password on a remote access portal that, according to UnitedHealth's CEO, lacked MFA. See the Phishing-Resistant MFA Guide.

4.6 Privileged and shared accounts

1. Administrators must use a separate privileged account that is not used for email, web browsing or everyday work.
2. Privileged and standard accounts must have different passwords.
3. Shared accounts are prohibited except for [break-glass and vendor-mandated accounts], whose passwords must be held in [PAM solution], checked out with approval and rotated after each use.
4. Local administrator passwords on endpoints and servers must be unique per device and managed by [Windows LAPS or equivalent].
5. Vendor default passwords must be changed before a system or device is connected to the network.

4.7 Service accounts that use passwords

1. New workloads must use a managed or passwordless identity, such as a group managed service account, cloud managed identity or workload identity federation, unless an exception is approved.
2. Remaining password-based service accounts must have a named owner and an entry in the [NHI inventory].
3. Their passwords must be randomly generated to at least [30] characters, held only in [approved vault or PAM solution] and rotated at least every [90 days for privileged, 180 days for others], and immediately when anyone who knew the password leaves.
4. Interactive sign-in by service accounts must be denied (for example through the "Deny log on locally" and "Deny log on through Remote Desktop Services" user rights).
5. Service accounts must not be exempted from MFA or conditional access by broad rules; any exclusion must be scoped to named accounts and source networks.

Scheduled rotation is kept here, unlike for people, because a machine password cannot be "chosen badly" by a user and rotation is automated. See the Service Account Security Guide and the gMSA Guide.

5. Exceptions

Systems or accounts that cannot meet this policy must be recorded in the [exceptions register] with the statement not met, the reason, compensating controls (for example network restriction, MFA in front of the system, or additional monitoring), an owner and an expiry date no later than [12] months. Exceptions for privileged accounts are approved by [policy owner]; others by [IAM team lead]. Legacy systems limited to short passwords, such as the 14-character ceiling of the Active Directory default domain policy setting, must be listed with the planned remediation.

6. Compliance and monitoring

[IAM team] must monitor and report every [quarter]:

• Percentage of in-scope systems whose effective settings match 4.1 (target [100]% for directories and identity providers).
• Number of passwords found in breached password data and the median time to forced change.
• MFA coverage of accounts in scope of 4.5, and phishing-resistant MFA coverage of privileged accounts.
• Number of password-based service accounts, overdue rotations and service accounts with interactive sign-in allowed.
• Password reset volume at the service desk (expected to fall after expiry is removed).
• Detections of password spraying (T1110.003), credential stuffing (T1110.004) and reads of password policy settings (T1201).

Effective settings must be audited from the systems themselves, not from this document. Breaches of this policy may be handled under [disciplinary procedure].

ISO/IEC 27001:2022 users will usually map this policy to Annex A 5.17 Authentication information and 8.5 Secure authentication.

7. Review and approval

• Policy owner: [name, role]
• Approved by: [approving body] on [date]
• Version: [1.0]; next review due [date, no later than 12 months from approval]
• Related documents: [Information Security Policy], [Access Control Policy], [Password Configuration Standard], [Account Recovery Procedure], [NHI Policy], [Privileged Access Standard]

Review early after a password-related incident, a change to NIST or NCSC guidance, or a new identity platform.

Implementation guidance

1. Inventory enforcement points: list every directory, identity provider and application that holds its own password settings; the written policy is only as good as the weakest one.
2. Turn on screening before removing rules: deploy blocklist checking in audit mode for [30] days, review what it would have blocked, then enforce. Removing complexity without screening is the one change that makes things worse.
3. Raise length for new passwords: apply the new minimum at next change rather than forcing a mass reset, which spikes service desk load and invites phishing.
4. Remove expiry last: once screening, MFA and breached password checks are live, stop scheduled expiry. Roll back by restoring the previous policy object if a regulator or contract still requires expiry, and record it as an exception.
5. Close the service account gap: move service accounts to managed identities in waves, starting with privileged ones, and deny interactive sign-in for the rest.
6. Brief people: one message on passphrases, password managers and reporting suspected compromise does more than any complexity rule.

Small organisations with a single cloud identity provider can usually adopt sections 4.1 to 4.5 in one change window. Large organisations with Active Directory should expect fine-grained password policies and a long tail of application exceptions. For attack context see the Password Spraying and Credential Stuffing Defence Guide.

Sources behind this template: NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management · NCSC: Password policy, updating your approach · NIST: SP 800-53 Rev. 5 · NIST: Cybersecurity Framework 2.0 · Microsoft Learn: Group Managed Service Accounts overview

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Password Security Guide · MFA Guide · NHI Policy Template