Key takeaways
- A workable password rotation policy covers scope, ownership, deadlines, and an audit trail for every credential.
- NIST SP 800-63B dropped mandatory periodic rotation for human passwords in favor of event-driven rotation on evidence of compromise.
- Long-lived machine credentials like API keys still need 30/60/90-day rotation deadlines paired with a named owner.
- Every Key Vault key and secret should carry an expires attribute, with Near Expiry events routed into your ticketing system.
- Write each requirement as a five-part clause: scope, owner, deadline, exemption, and evidence.
A password rotation policy should separate human passwords from machine credentials, assign an owner and expiry to each secret, and set 30/60/90-day rotation deadlines you can actually audit. This guide gives you copy-ready policy clauses for AWS IAM/root and Azure Key Vault, plus a disambiguation of the FEMA and FIFA "rotation policy" noise that fills the search results.
What should a password rotation policy actually cover in 2026?
The four elements every policy needs
A workable rotation policy covers four things: scope (human passwords vs machine credentials), ownership (which team or person answers for each key), deadlines (expiry and rotation dates per credential class), and an audit trail proving what happened and when. Most shops already have the vault. What's missing is the metadata layer: who owns this key, when does it expire, and what happens next.
Why 'rotate everything every 90 days' is no longer the default
NIST SP 800-63B dropped mandatory periodic rotation for human passwords in favor of rotation on evidence of compromise. Machine credentials still need real deadlines, but blanket 30/60/90-day rules mostly produce stale spreadsheets. Write exemptions into the policy instead: short-lived creds, keys rotated by the provider, and break-glass accounts each need explicit treatment. Track the lifecycle in one place; KeyGuardRail monitors expiry and ownership metadata without holding secret values, and its data handling terms are at Data deletion policy · KeyGuardRail.
How do NIST guidance and modern practice change rotation requirements?
What NIST actually says about periodic rotation
NIST SP 800-63B stopped recommending forced periodic password changes for human accounts. The reasoning: mandatory 60/90-day changes push people toward predictable patterns (Spring2026!, Summer2026!) and incremental variants of the old password, which attackers model easily. NIST instead checks passwords against breach corpora at creation and rotates immediately on evidence of compromise. For your human SSO and console passwords, that means your rotation policy should be event-driven, not calendar-driven.
Where the 30/60/90 day rule still applies
Machine credentials are a different case. Long-lived API keys, access tokens, and service credentials in AWS Secrets Manager or your vault have no human memorizing them, so the NIST usability argument disappears. Practitioners on r/devops still apply strict 30/60/90 day rotation to long-lived creds precisely because humans handle them at creation time and copies end up in Postman collections and local scripts. The key is pairing a deadline with a named owner per credential; an API key expiration policy with owner metadata beats a bare expiry date (API Key Expiration Policy Examples for Small Teams).
What does an AWS password rotation policy need for IAM users and root accounts?
IAM password policy settings to mandate
AWS lets you set account-level password requirements directly in IAM: minimum length, character classes, and max_password_age for expiry. Mandate a 90-day max_password_age, 14-character minimum, and password reuse prevention set to at least 5. Anything human-typed should sit under these settings; anything machine-held should not be a password at all.
Root account clauses
Root should have no routine password use. Copy-ready clause: "The root account password is stored in the organization vault, used only for break-glass tasks logged in the change system, protected by MFA on all root credentials, and rotated within 24 hours of any use or suspected exposure." Root never appears in code, Postman collections, or individual developer vaults.
Access key rotation clauses
Access keys are where AWS rotation policies actually fail, because AWS does not rotate them for you and humans are the transport layer. A workable clause reads: "Every IAM access key has a named owner and a creation date recorded before issuance; keys older than 90 days are flagged, and keys older than 180 days are disabled by the credential owner's manager. Rotation means creating a new key, updating the consumer, then deleting the old key, in that order, never the reverse. Keys used only by automation move to short-lived credentials via IAM roles where the workload supports it." That last line matters: the general rule of thumb practitioners repeat is short-lived creds wherever possible, with a strict 30/60/90 day rotation policy for the rest, and tracking owner, age, and next rotation deadline across IAM, Stripe, and GitHub keys is what KeyGuardRail does with metadata only, without holding secret values.
How does an Azure key rotation policy differ from a password rotation policy?
Azure Key Vault rotation is about keys and secrets with explicit expiry attributes, not human passwords. Every key and secret carries expires and enabled metadata, and Key Vault can fire a Near Expiry Event Grid event before the deadline, so you can trigger rotation without reading the secret value. Password rotation, by contrast, is a human account rule enforced in Entra ID or your IdP. Treat them as two clauses in one policy, not one rule.
Key Vault expiry and rotation mechanics
Set an expires attribute on every key and secret at creation time, then subscribe to Event Grid's Near Expiry event to route a deadline into your ticketing system. Key Vault does not rotate anything for you; the event tells you a deadline is close, and a human or pipeline does the rest. That tracking gap between event and action is where most shops drift, which is why a lifecycle layer that watches expiry metadata without holding the secret value helps (Alternatives to Manual Credential Rotation Tracking).
Copy-ready Azure key rotation policy clause
Every Key Vault key and secret MUST have an
expiresattribute set at creation; secrets without an expiry are treated as incidents. Owners MUST respond toNear Expiryevents within 5 business days by rotating the credential and updating ownership records. Keys used for encryption MUST rotate every 12 months; secrets supporting external SaaS integrations MUST rotate every 90 days. Rotation MUST NOT require reading the prior secret value.
How do you write policy language teams can actually follow?
A policy that says "rotate credentials regularly" gets ignored because it names no owner and no deadline. Write each requirement as a five-part clause instead.
The five-part clause template
Each clause needs: Scope (which credential, named exactly), Owner (a team or person, not "engineering"), Deadline (a rotation interval tied to credential type), Exemption (when the clause does not apply), and Evidence (where you record the rotation happened). AWS's own guidance recommends removing root user access keys entirely, which is a good model for exemption clauses: state what must not exist, not just what must rotate.
Worked example: Stripe API key clause
Scope: All Stripe restricted API keys in the Payments platform account. Owner: Payments platform lead. Deadline: Rotate within 30 days of creation, then every 90 days. Exemption: Keys scoped to read-only webhooks with no PII access may extend to 180 days. Evidence: Rotation logged in the credential register within 24 hours.
Track ownership, deadline, and evidence in one place rather than in the clause document itself; a vault like Doppler or Infisical holds the secret value, but the register holds the metadata. KeyGuardRail covers the metadata layer only, so it cannot enforce rotation for you, but it does flag which clauses are past deadline before an auditor asks. For what automated rotation handling looks like in practice, see Automation access: npm tokens, workflow policies, and an IoT TLS fix · KeyGuardRail.
When should credentials be exempt from rotation?
Not every credential needs a 30/60/90 day rotation policy, and forcing one on the wrong class of credential wastes engineering time while creating new failure modes. Four exemptions are legitimate.
Short-lived credentials and federation
Credentials that expire on their own schedule are already rotating. STS session tokens, OIDC-federated CI roles, and workload identity for Kubernetes all replace long-lived keys with tokens that live minutes to hours. If a credential's max age is under your shortest rotation interval, exempt it and record that reasoning in the policy itself.
The same applies to credentials you have replaced with federation. A GitHub or Stripe key retired in favour of an SSO-issued token does not need a rotation deadline; it needs a decommission date.
Break-glass and incident-driven rotation
Break-glass accounts should stay exempt from routine rotation because unsealing them mid-incident should never depend on a stale password. Compensate with alerting on every use and a post-use review.
Conversely, treat any suspected exposure as a rotation event that overrides the schedule. Incident-driven rotation replaces the calendar, not complements it, and your audit trail should show which path fired.
How do you audit whether the policy is being followed?
Audit checklist
A rotation policy you cannot audit is a document, not a control. Run this check quarterly:
- Inventory coverage. Every credential in Secrets Manager, Vault, or Infisical appears in a single registry, including keys devs parked in Postman collections and CI variables.
- Expiry metadata. Each entry has a rotation deadline matching your 30/60/90 day policy, not just a created date.
- Owner assignment. Every key maps to a team ("Payments platform", "Platform engineering") and a named human who gets paged.
- Evidence of last rotation. A timestamp and an actor, pulled from the vault's audit trail, proving the rotation actually happened.
Vault-native vs lifecycle monitoring: same criteria for all
| Criterion | Vault-native reporting | Lifecycle monitoring layer |
|---|---|---|
| Inventory per vault | Yes, per instance | Aggregates AWS + Stripe + GitHub |
| Expiry deadlines | Partial; Azure Key Vault supports rotation policies and near-expiry Event Grid events (Azure Key Vault docs) | Deadline registry across providers |
| Owner mapping | Rarely built in | Core feature |
| Rotation execution | Yes | Monitoring and reminders only |
Honest limits on us: KeyGuardRail is metadata-only, holds no secret values, and does not rotate anything. If you want execution, HashiCorp Vault or Doppler do that; we tell you what is expiring and who owns it. For a recent snapshot of lifecycle checks across providers, see TLS renewal, npm trust, and AWS password fix · KeyGuardRail.
FEMA rotation, FIFA rotation, job rotation: which 'rotation policy' are you searching for?
Search "rotation policy" and you get four unrelated things. FEMA publishes rotation policies for deployed personnel and incident responders. FIFA's rules govern squad rotation in competitions. Job rotation is an HR staffing practice. And log rotation (logrotate, syslog) is about disk space, not credentials.
If your problem is API keys and IAM users expiring or going unowned, none of those apply. What you want is credential rotation: expiry dates, ownership, and a 30/60/90 day schedule for machine secrets. That distinction matters when you're writing policy, because HR and syslog templates will pull your clauses in the wrong direction. Keep the terms separate in your docs so a search for "rotation policy" doesn't hand your auditors the wrong document.
FAQ
How often should you rotate passwords and API keys?
Human passwords should be event-driven: rotate on evidence of compromise, not on a calendar. Long-lived machine credentials, like API keys and service secrets, still need real deadlines, typically 30, 60, or 90 days depending on exposure. Short-lived tokens and federated credentials are exempt because they expire on their own, and break-glass accounts stay outside routine rotation.
Does AWS force you to rotate IAM user passwords?
No. AWS gives you account-level IAM controls, including a max_password_age setting, but enforcement is your job. A sensible baseline is a 90-day max_password_age, a 14-character minimum, and reuse prevention set to at least 5. Access keys are the bigger gap: AWS never rotates those for you, so owners and deadlines must come from your own policy.
What is the difference between a password rotation policy and a key rotation policy?
Password rotation governs human accounts, enforced through your IdP or IAM password settings, and follows NIST's event-driven model. Key rotation governs machine credentials in vaults, where every key or secret carries expiry metadata and a named owner. Treat them as two separate clauses in one policy; the deadlines, evidence requirements, and exemptions differ for each.
Is forced password rotation still recommended by NIST?
No. NIST SP 800-63B dropped mandatory periodic changes for human passwords because forced 60 or 90-day resets produce predictable variants attackers model easily. The current guidance checks passwords against breach corpora at creation and rotates immediately on evidence of compromise. Calendar-driven rotation still applies to machine credentials, where the usability argument does not hold.
How do I track rotation deadlines across AWS, Stripe, and GitHub without giving up my secret values?
Keep the metadata layer separate from the secrets themselves. A register records owner, creation date, and next deadline per key, while the vault holds the value. KeyGuardRail works this way: metadata only, no secret values, no execution. It flags which credentials are past deadline before an auditor asks; tools like HashiCorp Vault or Doppler handle actual rotation.