Forcing every password to change on a calendar was once standard advice, yet current guidance from NIST and the NCSC says scheduled expiry for human users does more harm than good, while rotation of shared, privileged and machine passwords remains essential. MITRE D3FEND names this countermeasure Password Rotation (D3-PR) and defines it as "a security policy that mandates the periodic change of user account passwords to mitigate the risk of unauthorized access due to compromised credentials." It sits under the Harden tactic as a child of Credential Rotation (D3-CRO), itself under Credential Hardening, and One-time Password (D3-OTP) is listed as its own child. This card covers what D3-PR changes, which ATT&CK techniques D3FEND relates it to, where rotation is implemented, when to rotate and when not to, and how to prove rotation is happening. It is written for identity engineers and auditors who already know the general rules in the Password Policy Guide (NIST-aligned).
Key takeaways
- Rotation limits the life of a stolen password. It does nothing against an attacker who uses a password the same day it is stolen, so it complements, never replaces, MFA, blocklists and monitoring.
- Do not expire human passwords on a schedule. NIST SP 800-63B (Revision 4) says verifiers "SHALL NOT require subscribers to change passwords periodically" but SHALL force a change on evidence of compromise; the NCSC gives the same advice.
- Do rotate what humans do not hold. Local administrator, service account, shared break-glass and device passwords are where scheduled and event-driven rotation pays off, ideally fully automated.
- D3FEND ties it to brute force. Through the Password artefact the ontology links D3-PR to Password Guessing (T1110.001), Password Cracking (T1110.002) and Password Spraying (T1110.003).
- Verify by password age, not by policy text. The evidence that rotation works is the measured age of every in-scope password and the time from a compromise signal to a completed reset.
D3-PR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PR (d3f:PasswordRotation) |
| Tactic | Harden |
| Parent technique | Credential Rotation (D3-CRO), under Credential Hardening (D3-CH) |
| Child technique | One-time Password (D3-OTP) |
| Digital artefact | Password (ontology relation: regenerates Password) |
| What it changes | Replaces a password with a new value on a schedule, after use, or after a compromise signal |
| D3FEND reference | SSH Academy, "Password and Key Rotation" |
| Main limitation | Only shortens the window of use; frequent forced change of human passwords pushes users towards predictable variants |
How it works
D3FEND's description is brief: users may be asked to change passwords on a schedule, and management servers with enterprise account policies can change or reset passwords for accounts. Its considerations section adds the caveat that frequent changes can lead to insecure user behaviour, pointing to the NIST position on resets after known compromise. In practice there are three triggers, and they suit different account types.
- Scheduled rotation: the password is replaced after a fixed age. Appropriate for machine-managed secrets where no human has to remember the value, such as local administrator accounts managed by Windows LAPS.
- Event-driven rotation: the password is replaced after a trigger: evidence of compromise, a leaver who knew a shared password, a breached-password match, or a check-out from a privileged access vault. This is the only rotation NIST SP 800-63B requires for human subscribers.
- Use-limited rotation: the password changes after each use. D3FEND models the extreme case as its child, One-time Password, and privileged access tools apply the same idea by rotating a vaulted password when a session ends.
Where identity fits
The accounts where scheduled rotation still matters most are non-human or shared: Windows and Linux service accounts, local administrator accounts, database and application accounts, network device logins and emergency accounts. Their passwords are often set once and never changed, and they are copied into scripts and configuration files. Operational steps for these are in Rotating a Windows or Linux Service Account Password, and fleet-scale design is in Credential Rotation at Scale. Where a workload can use a managed identity or a short-lived token instead of a password, that removes the rotation problem rather than managing it.
What current guidance says
| Source | Position on periodic change | Required instead or as well |
|---|---|---|
| NIST SP 800-63B Revision 4, section 3.1.1.2 | Verifiers and CSPs SHALL NOT require periodic password changes | SHALL force a change on evidence of compromise; blocklist check on every new password; minimum 15 characters for single-factor passwords |
| NCSC password guidance, "Updating your approach" | Regular password changing harms rather than improves security | Users must change a password when compromise is known or suspected; remove access for leavers, lock inactive accounts, monitor logins, use MFA |
| Microsoft, Maximum password age policy reference | Microsoft's recommended security baseline does not contain the password expiration policy | Organisations without Entra Password Protection, MFA or other modern mitigations of guessing attacks should leave expiry in effect |
| D3FEND D3-PR considerations | Frequent forced change can result in insecure practices | Points to NIST's reset-after-compromise model |
Industry rules can still require expiry in specific cases, so check any sector or payment card obligation that applies to you before removing it, and record the compensating controls. The policy wording itself belongs in the Password Policy Template; the mitigation view is in M1027 Password Policies.
ATT&CK techniques D3FEND relates to D3-PR
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-PR. The rows below are inferred through the shared Password artefact, which D3-PR regenerates and these techniques access (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation | What rotation changes for the attacker |
|---|---|---|---|
| T1110.001 | Password Guessing | Same artefact: accesses Password | A guessed password stops working after the next rotation; little effect on a fast online guess |
| T1110.002 | Password Cracking | Same artefact: accesses Password | Offline cracking of a stolen hash must finish before the password changes; strongest effect for long random machine passwords |
| T1110.003 | Password Spraying | Same artefact: accesses Password | Weak effect: spraying finds whatever common password is current, and forced changes can produce predictable variants |
| T1694.001 | Default Credentials (ATT&CK for ICS) | Same artefact: uses Password | Rotating vendor default passwords on first deployment removes the published value. D3FEND lists this under an earlier ICS ID that ATT&CK v20 has revoked; T1694.001 is the successor. |
The D3FEND website also shows a wider set of "inferred and experimental" relations through the parent Credential artefact, including NTDS (T1003.003), Cached Domain Credentials (T1003.005), /etc/passwd and /etc/shadow (T1003.008), Golden Ticket (T1558.001) and token techniques such as T1134.001 and T1550.001. For password dumping the logic holds: a dumped hash is worth less if the password behind it changes before it is cracked. For token techniques, password rotation alone rarely helps, because issued tokens and sessions can outlive the password change. Defence against the main family is in the MITRE ATT&CK T1110 Brute Force Guide and the Password Spraying and Credential Stuffing Defence Guide.
Where it is implemented
| Implementation class | Example settings | Best fit |
|---|---|---|
| Directory password policy | Windows Group Policy "Maximum password age" under Account Policies\Password Policy (0 to 999 days; 42 days in the default domain policy); Microsoft Entra ID password expiry policy (set per tenant or domain; per-user "never expire" through Microsoft Graph PowerShell) | Event-driven resets for people; scheduled expiry only where a rule requires it |
| Local administrator password management | Windows LAPS: PasswordAgeDays (default 30, range 1 to 365, minimum 7 when backing up to Entra ID), PasswordLength (default 14), PostAuthenticationActions (default 3, reset password and sign out) with PostAuthenticationResetDelay (default 24 hours) | Unique, rotated local admin passwords on every Windows device; see the Local Administrator Password Solution (LAPS) Guide |
| Operating system ageing | Linux shadow ageing via chage: -M maximum days, -m minimum days, -W warning days, -I inactive days, -d 0 to force a change at next login, -l to list | Local Linux accounts that still use passwords |
| Managed service accounts | Active Directory group Managed Service Accounts: the domain controller computes the password from Key Distribution Service keys that change periodically, and Windows manages it instead of an administrator | Windows services and scheduled tasks on Windows Server 2012 and later |
| Privileged access and secrets vaults | Check-out with rotation after check-in, scheduled rotation of vaulted accounts, rotation on demand | Shared admin, database and network device accounts |
Implementation steps
- Classify every password-bearing account. Separate personal human accounts, shared or privileged accounts, service and application accounts, local admin and device accounts. The rotation trigger differs by class.
- Remove scheduled expiry for personal accounts only when compensating controls are live. Confirm MFA, a breached and common password blocklist, and sign-in risk monitoring are in place first, as Microsoft's own policy note requires. Record the decision and any rule that still mandates expiry.
- Define compromise triggers. Breached-password matches, impossible-travel or risky sign-in detections, a user report, a leaver who knew a shared password and an incident scope all force a reset. The Mass Password Reset Playbook covers the large-scale case.
- Automate rotation for non-human and shared accounts. Move local admin passwords to LAPS, services to managed service accounts or a vault, and shared accounts to check-out with rotation after use. Set a maximum age per class (for example 30 days for local admin, an example rather than a standard).
- Update every consumer in the same change. For service accounts, find every host, task, connection string and pipeline that uses the password before rotating it, then rotate in a pilot group and watch for authentication failures.
- Plan rollback. Keep the previous password retrievable for a short, controlled period where the tool supports it, and know how to pause automated rotation for one account without disabling it for all.
How to verify it works
- Password age report: list pwdLastSet for directory accounts, LAPS expiration times for devices, and last rotation in the vault. Every in-scope account should be inside its class maximum.
- Never-expires audit: find accounts flagged to never expire and confirm each is either a managed account or has a documented rotation owner. See How to find AD accounts with password never expires.
- Forced-reset test: trigger a test compromise signal for a pilot account and time how long it takes until the old password fails.
- Old password replay: after a rotation, attempt one sign-in with the previous value from an approved test host and confirm it fails and is logged.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Privileged and service passwords older than their class maximum | Zero |
| Devices with a LAPS-managed local admin password | 100% of Windows endpoints and servers |
| Time from confirmed compromise signal to completed reset | Under 1 hour for privileged accounts |
| Rotation-caused outages per quarter | Falling towards zero |
| Accounts set to never expire without a rotation owner | Zero |
Measuring age and coverage across all secrets, not only passwords, is covered in How to measure secret age and rotation coverage.
Limits, bypasses and failure patterns
- Predictable successors: users forced to change on a schedule append a digit or season, so an attacker with one old password can often guess the next. This is the core reason NIST and the NCSC dropped periodic expiry.
- Rotation without session revocation: changing a password does not always end existing sessions, refresh tokens or Kerberos tickets. Pair a compromise reset with session and token revocation.
- Rotating one copy: the password changes in the directory but an old copy keeps working somewhere else, or a forgotten consumer breaks. The Incomplete rotation breaches page collects incidents where partial rotation left access open.
- Rotation as a substitute for removal: an account that should not exist is rotated for years. Disable unused accounts instead.
- Same password across devices: rotating one shared local admin password everywhere still allows lateral movement with a single stolen value; uniqueness per device matters as much as age.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, IA-5(1) Password-based Authentication | Changing authenticators and the password-specific requirements |
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Account classes, owners and removal of unused accounts |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials for users, services and hardware are managed |
| MITRE ATT&CK | M1027 Password Policies | Mitigation that includes rotation and password rules |
| MITRE D3FEND | D3-CH, D3-CRO, D3-PR, D3-OTP | Ancestors, technique and child |
Related countermeasures
- Credential Rotation (D3-CRO): the parent, covering keys and certificates as well as passwords. See D3-CRO Credential Rotation.
- One-time Password (D3-OTP): the child, where each password is valid for a single authentication. See D3-OTP One-time Password.
- Multi-factor Authentication (D3-MFA): reduces the value of any stolen password. See D3-MFA Multi-factor Authentication.
- Credential Compromise Scope Analysis (D3-CCSA): decides which passwords an incident requires you to rotate. See D3-CCSA Credential Compromise Scope Analysis.
Practitioner checklist
- Classify accounts and set a rotation trigger per class.
- Remove scheduled expiry for personal accounts only after MFA and a blocklist are enforced.
- Force a reset on every confirmed or suspected compromise, and revoke sessions with it.
- Deploy Windows LAPS or an equivalent so every device has a unique, rotated local admin password.
- Move services to managed service accounts or vault-rotated credentials.
- Rotate shared and break-glass passwords after every use and every leaver.
- Report password age per class monthly and chase every account over its maximum.
- Audit never-expires flags and assign an owner to each exception.
Standards and references
- MITRE D3FEND: Password Rotation (D3-PR)
- NIST: SP 800-63B Digital Identity Guidelines, Authentication and Authenticator Management
- NCSC: Password administration for system owners, updating your approach
- Microsoft Learn: Maximum password age
- Microsoft Learn: Windows LAPS policy settings
- Microsoft Learn: Microsoft Entra password policies
- Microsoft Learn: Group Managed Service Accounts overview
- Linux man-pages: chage(1)
Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Credential Rotation at Scale · Local Administrator Password Solution (LAPS) Guide · M1027 Password Policies · MITRE D3FEND Guide