A credential that never changes stays useful to whoever copied it, for as long as the copy exists. D3-CRO Credential Rotation is the MITRE D3FEND countermeasure that limits that window. D3FEND defines it as "a security procedure in which authentication credentials, such as passwords, API keys, or certificates, are regularly changed or replaced to minimize the risk of unauthorized access." It sits in the Harden tactic as a child of Credential Hardening, and is itself the parent of Certificate Rotation and Password Rotation. This card covers what D3-CRO hardens, the ATT&CK techniques D3FEND relates it to, where rotation is implemented, how to prove it works, and where it does not help. It is written for platform, secrets and identity engineers. For running rotation across thousands of credentials, see Credential Rotation at Scale.
Key takeaways
- Rotation regenerates, it does not delete. D3FEND models D3-CRO as regenerating a Credential. The old value must then actually be invalidated, or rotation adds a credential instead of replacing one.
- Two triggers, two purposes. D3FEND names rotation at predetermined intervals and rotation on specific events. Event-driven rotation after exposure is the higher-value case.
- Human passwords are the exception. NIST SP 800-63B-4 says verifiers and CSPs shall not require periodic password changes, and shall force one on evidence of compromise. Scheduled rotation is for machine credentials.
- Outages are the main operational risk. D3FEND's own considerations warn that rotation must be managed carefully to avoid service interruption; dual-credential patterns exist for that reason.
- Measure the age of what is in use. Proof is the age of the oldest active credential and zero use of superseded values, not the existence of a rotation schedule.
D3-CRO at a glance
| Field | D3-CRO Credential Rotation |
|---|---|
| D3FEND ID | D3-CRO (d3f:CredentialRotation) |
| Tactic | Harden |
| Parent technique | Credential Hardening (siblings include Certificate Pinning, Strong Password Policy and Token Binding) |
| Child techniques | D3-CERO Certificate Rotation, D3-PR Password Rotation |
| Digital artefact | Credential (D3FEND relation: regenerates Credential) |
| What it changes | The validity window of a secret: after rotation, copies of the old value stop working |
| D3FEND references | CISA: Eviction Guidance for Networks Affected by the SolarWinds and Active Directory/M365 Compromise; SSH Communications Security: Password and key rotation |
| Typical implementation points | Secrets managers, privileged access tools, certificate lifecycle tooling, cloud IAM, CI/CD pipelines |
| Typical verification data | Secret version history and creation dates, credential last-used data, authentication logs naming the credential or key ID |
| Main limitation | Does nothing for the time between theft and the next rotation, and nothing for tokens derived from the old value |
How it works
D3FEND's entry describes rotation at predetermined intervals or on specific events, done manually for some user passwords but increasingly by automated systems for enterprise passwords, certificates and keys. Its considerations are worth reading as a design brief:
- Availability: rotation must be managed carefully to avoid inadvertent service interruption.
- Incident response: severity of compromise should decide which credentials for which accounts are regenerated.
- Periodic rotation trade-offs: several factors should set frequency, and periodic rotation brings its own risks, including weaker user passwords, poor storage practices and difficulty tracking.
The third point matches NIST SP 800-63B-4, which states: "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised." For people, use compromise-driven change; for service accounts, API keys, database credentials and certificates, scheduled automated rotation is a sound hardening control because no human memorises the value. See D3-PR Password Rotation and D3-CERO Certificate Rotation for the two specialised children.
Rotation patterns
| Pattern | How it works | Best for | Watch for |
|---|---|---|---|
| Single credential, in place | One value is changed; consumers fetch the new value | Simple consumers that read the secret at each connection | A short window where the old value is refused before consumers refresh |
| Alternating (dual) credentials | Two valid credentials; rotation regenerates the one not in use | High-availability services, keys issued in pairs | Both credentials need identical permissions and both must be tracked |
| Overlap with expiry | New value issued, old one kept valid for a grace period, then invalidated | Signing keys, certificates, distributed fleets | Grace periods that quietly become permanent |
| Replace with short-lived credentials | Long-lived secret removed; workloads obtain tokens that expire on their own | Cloud workloads with federation or managed identity | Not always available for third-party APIs |
The last row is often the better answer. Microsoft's Key Vault rotation tutorial itself recommends Microsoft Entra ID authorisation with managed identities over key rotation where the workload allows it. See the Workload Identity Federation Guide.
ATT&CK techniques D3FEND relates to D3-CRO
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CRO. Every row is inferred through the Credential artefact that D3-CRO regenerates, so techniques that create, access or use a Credential or its sub-types are related (D3FEND checked November 2026; IDs checked against ATT&CK v20). D3FEND lists Keychain under an ID ATT&CK has since revoked; its v20 successor is T1555.001. D3FEND shows Steal Web Session Cookie, Steal Application Access Token, Unsecured Credentials and Steal or Forge Authentication Certificates without IDs; they are T1539, T1528, T1552 and T1649. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | What rotation does (NHI Mgmt Group assessment) |
|---|---|---|
| T1552 | Unsecured Credentials | Strong over time: a secret found in a file, repository or log expires with the next rotation |
| T1098.001 | Additional Cloud Credentials | Partial: rotating known credentials does not remove an extra key the attacker added |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Partial: limits how long a slow crack stays useful; strength matters more |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Partial: dumped hashes of rotated service and machine accounts lose value |
| T1555.001 | Keychain | Partial: harvested values age out |
| T1558.001 | Golden Ticket | Specific: only rotation of the krbtgt key, done twice, invalidates forged tickets |
| T1606.001 | Web Cookies (Forge Web Credentials) | Specific: rotating the cookie or token signing secret invalidates forged values |
| T1649 | Steal or Forge Authentication Certificates | Partial: rotation plus revocation of the old certificate; see D3-CERO |
| T1528, T1539 | Steal Application Access Token, Steal Web Session Cookie | Minimal: issued tokens usually survive rotation of the parent credential |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie (Use Alternate Authentication Material) | Minimal for the same reason |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Minimal: local logon tokens are unaffected |
For the techniques in depth, see the MITRE ATT&CK T1552 Unsecured Credentials Guide, the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide and the krbtgt account guide.
Where it is implemented
Most organisations implement D3-CRO through a secrets manager, a privileged access tool or a certificate lifecycle tool. Cloud secrets managers handle scheduling and versions in different ways (platforms are listed alphabetically; facts from each vendor's documentation as of November 2026):
- Amazon Web Services: AWS Secrets Manager rotation strategies are single user, described as the simplest and suitable for most cases, and alternating users, where the first rotation clones the user and later rotations alternate between the two. Versions are labelled AWSCURRENT and AWSPREVIOUS. AWS recommends a retry strategy with exponential backoff and jitter in consumers.
- Google Cloud: Secret Manager rotation schedules use next_rotation_time and an optional rotation_period (minimum one hour) and send a SECRET_ROTATE message to Pub/Sub topics attached to the secret. A subscriber you build creates the new secret version and rolls it out.
- Microsoft Azure: the Key Vault dual-credential rotation tutorial uses the SecretNearExpiry event, published 30 days before a secret's expiry date, to trigger a function that regenerates the alternate key of a key pair and stores it as a new secret version. Rotating a storage shared key also revokes account-level SAS tokens generated from it.
Whatever the tool, rotation only reaches consumers that read the secret from the store. Hard-coded values, copied environment variables and secrets baked into images will not move with it. See the Cloud Secrets Managers Guide.
Implementation steps
- Inventory and classify. List credentials by type (human password, service account, API key, database credential, certificate, signing key), owner and consumers. Exclude human passwords from scheduled rotation.
- Make consumers rotation-ready. Consumers must fetch from the secrets store at runtime and retry on authentication failure. Remove copies of the value from code, images and configuration files first.
- Pick a pattern per type. Use alternating credentials or an overlap window where an outage is unacceptable; move to short-lived credentials where the platform supports federation.
- Set rotation periods by risk, labelled as your own policy. As an example only, many teams start with 30 to 90 days for high-privilege machine credentials and shorter for anything exposed to third parties. Record the reasoning, since no single standard sets the number.
- Pilot and test rollback. Rotate in a non-production environment, then one low-risk production credential, confirming you can restore the previous version if a consumer breaks.
- Automate event-driven rotation. Wire leak detection, staff departure and vendor breach notices to an on-demand rotation that the same automation can run within hours.
- Invalidate the old value. After the overlap period, confirm the superseded credential is disabled or deleted, and revoke sessions and tokens issued from it where the incident calls for it. See D3-CR Credential Revocation.
How to verify it works
- Age check: compare each active credential's creation date with its policy. The oldest active credential per class is the most useful single number.
- Superseded value test: after a rotation, authenticate with the previous value from a controlled host. It must fail once the overlap period ends.
- Usage check: credential last-used data and authentication logs must show consumers on the new version and no use of the previous one.
- Failure review: track rotation jobs that failed or were skipped, since a quiet failure leaves the credential unrotated while the schedule reports success.
| Metric | What it shows | Target direction (example) |
|---|---|---|
| Machine credentials within their rotation policy, as a share of inventory | Real rotation coverage | Rising toward 100% |
| Age of the oldest active credential per class | The worst exposure window | Within policy |
| Failed or skipped rotation jobs per month | Automation health | Each one investigated |
| Outages caused by rotation | Consumer readiness | Falling toward zero |
| Time from exposure notice to event-driven rotation | Incident readiness | Hours |
For a worked method, see How to measure secret age and rotation coverage.
Limits, bypasses and failure patterns
- Exposed secrets left unrotated: in the Internet Archive breach, API keys exposed with a GitLab token were not rotated, and in October 2024 the attacker used an unrotated Zendesk token to send email from the Archive's own account and reach more than 800,000 support tickets. Event-driven rotation is the control that was missing.
- Rotating what you know, not what the attacker added: rotation does not remove extra keys or app secrets created during an intrusion. Pair it with a sweep for new credentials.
- Old values still accepted: overlap windows and dual keys that are never closed turn rotation into accumulation.
- Derived tokens survive: session cookies, refresh tokens and cloud temporary credentials issued before rotation keep working until expiry or revocation.
- Rotation that breaks production: consumers that cache the secret or read it only at start-up fail at rotation time, and the usual reaction is to switch rotation off. See the Secret Rotation Outage Troubleshooting Guide.
- Periodic rotation for people: forcing users to change passwords on a calendar runs against NIST SP 800-63B-4 and tends to produce predictable variants.
Framework mapping
| Framework | Reference | Relationship to D3-CRO (NHI Mgmt Group mapping) |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management | Changing or refreshing authenticators over their lifetime |
| NIST SP 800-53 Rev 5 | SC-12 Cryptographic Key Establishment and Management | Key rotation and replacement |
| NIST CSF 2.0 | PR.AA-01 | Credentials for users, services and hardware are managed |
| NIST SP 800-63B-4 | Password verifier requirements | No periodic change for subscriber passwords; forced change on evidence of compromise |
| MITRE ATT&CK | M1027 Password Policies | Password rules, including for service accounts |
Related countermeasures
- Children: D3-PR Password Rotation and D3-CERO Certificate Rotation.
- Siblings under Credential Hardening: D3-SPP Strong Password Policy, D3-CP Certificate Pinning and D3-TB Token Binding, which addresses the token theft that rotation cannot.
- Eviction: D3-CR Credential Revocation permanently removes a credential rather than replacing it.
For how D3FEND is organised, see the MITRE D3FEND Guide.
Practitioner checklist
- Inventory machine credentials with owner, consumers, type and creation date.
- Keep human passwords off scheduled rotation; force change only on evidence of compromise.
- Remove hard-coded and copied secrets so every consumer reads from the store.
- Choose single, alternating, overlap or short-lived patterns per credential type.
- Write rotation periods into policy with the reasoning, and label them as your own.
- Test rollback before automating production rotation.
- Connect leak detection and breach notices to on-demand rotation.
- Close overlap windows and confirm superseded values fail.
- Report credential age, rotation coverage and failed jobs monthly.
Standards and references
- MITRE D3FEND: Credential Rotation (D3-CRO)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- Amazon Web Services: Secrets Manager rotation strategies
- Google Cloud: Secret Manager rotation schedules
- Microsoft: Key Vault rotation for resources with two sets of credentials
Related NHI Mgmt Group resources: Credential Rotation at Scale · Incomplete rotation breaches · How to measure secret age and rotation coverage · MITRE D3FEND Guide