After an incident, the legitimate user, service or workload still needs to work, and the credential it gets back must be one the attacker has never seen. MITRE D3FEND names this countermeasure Reissue Credential (D3-RIC) and defines it as "Issue a new credential to a user which supersedes their old credential." It sits under the Restore tactic as a child of Restore Access (D3-RA), alongside Restore User Account Access (D3-RUAA) and Restore Network Access (D3-RNA). Its job is different from the Evict techniques that come before it: Credential Revocation (D3-CR) takes the attacker's access away, and D3-RIC gives the rightful owner working access back. This card covers how to reissue safely for people and non-human identities, which ATT&CK techniques D3FEND relates to it, and how to prove that only the new credential works. It is written for incident responders, identity teams and platform engineers.
Key takeaways
- Supersede, do not add. D3FEND's definition is a new credential that supersedes the old one. A reissue that leaves the old password, key or token valid alongside the new one restores nothing; it doubles the exposure.
- Reissue after eviction, not instead of it. Revoke sessions and tokens, remove attacker persistence and confirm containment first. Reissuing while the attacker still controls the host or mailbox hands them the new credential too.
- Deliver through a trusted channel. The new credential must reach its owner by a route the attacker does not control: an identity-verified help desk process, an enrolled authenticator, or a secrets manager the workload already trusts.
- Machine credentials are the hard part. Service accounts, access keys and client secrets are embedded in many systems. Reissue them with a dual-credential overlap, then disable the old one, as cloud providers document.
- Prove the old credential is dead. Verification means a failed attempt with the old credential and last-used data showing no further use, not only that the new one works.
D3-RIC at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-RIC (d3f:ReissueCredential) |
| Tactic | Restore |
| Parent technique | Restore Access (D3-RA) |
| Siblings | Restore User Account Access (D3-RUAA, parent of Unlock Account D3-ULA), Restore Network Access (D3-RNA) |
| Digital artefact | Credential (D3FEND relation: restores Credential) |
| D3FEND reference | CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks |
| Applies to | Passwords, authenticators, API and access keys, client secrets, certificates, Kerberos keys, tokens |
| Main limitation | A new credential is only as safe as the host, channel and owner that receive it |
How it works and how it differs
D3FEND gives no further description; its only reference is CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, which cover identifying, remediating and recovering from incidents. Three related D3FEND techniques act on credentials and are often confused:
| Technique | Tactic | Purpose | Typical trigger |
|---|---|---|---|
| Credential Rotation (D3-CRO), under Credential Hardening | Harden | Replace credentials routinely to limit the useful life of any leak | Schedule or policy |
| Credential Revocation (D3-CR), under Credential Eviction | Evict | Invalidate a credential the attacker may hold | Suspected or confirmed compromise |
| Reissue Credential (D3-RIC) | Restore | Give the legitimate owner a new credential that supersedes the old one | After eviction, to return the owner to service |
In practice revocation and reissue often run in one change, but the order matters and the verification differs. For the eviction side see D3-CR Credential Revocation; for routine replacement see D3-CRO Credential Rotation. The account-level restore steps are in D3-RUAA Restore User Account Access, and the Restore Access implementation guide gives the family overview.
ATT&CK techniques D3FEND relates to D3-RIC
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-RIC. Every row is inferred because D3-RIC restores Credential, and these ATT&CK techniques act on Credential or one of its sub-artefacts such as Password, Access Token or Session Cookie (D3FEND 1.6.0, checked November 2026). D3FEND labels these relations inferred and experimental. It still lists Keychain under a revoked ID; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | Why reissue matters after it |
|---|---|---|---|
| T1552 | Unsecured Credentials | Same artefact: accesses Credential | Credentials found in files or scripts must be replaced, and the new ones stored properly |
| T1606 | Forge Web Credentials | Same artefact: forges Credential | Forging depends on signing material; reissue the signing key, not only user passwords |
| T1098.001 | Additional Cloud Credentials | Same artefact: creates Credential | Attacker-added keys must be removed and the owner's real credentials reissued |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Sub-artefact: Encrypted Credential | Dumped hashes stay crackable or replayable until each affected password is reissued |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Sub-artefact: Password | A guessed or cracked password must be superseded with one meeting current policy |
| T1558.001 | Golden Ticket | Sub-artefact: Kerberos Ticket Granting Ticket | Requires reissuing the krbtgt account key, not user passwords |
| T1528, T1539 | Steal Application Access Token, Steal Web Session Cookie | Sub-artefact: Access Token, Session Cookie | Revoke the token, then issue a fresh session after re-authentication |
| T1606.001 | Web Cookies | Sub-artefact: Session Cookie | Reissue the cookie signing secret where forged cookies are possible |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie | Sub-artefact: Access Token, Session Cookie | Replayed tokens stop working only when superseded and invalidated |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Sub-artefact: Access Token | Reissue credentials of accounts whose tokens were used on compromised hosts |
The Golden Ticket row is a reminder that the credential to reissue is sometimes not the user's. See the krbtgt account guide for the two-reset procedure, and the MITRE ATT&CK T1606 Forge Web Credentials Guide for signing keys.
Where it is implemented
| Credential type | Reissue mechanism | Supersede step | Documented detail |
|---|---|---|---|
| Hybrid Active Directory user | Administrator password reset, then user sets a new password after identity verification | Old password and hash stop working at reset | Microsoft's revoke-access guidance for hybrid accounts resets the password twice to mitigate pass-the-hash risk, especially where replication is delayed |
| Cloud directory user | Password reset or new authenticator registration | Revoke refresh tokens and sessions | Microsoft Entra: Revoke-MgUserSignInSession revokes refresh tokens; existing access tokens stay valid until expiry, one hour by default, unless the app supports Continuous Access Evaluation |
| Cloud access keys | Create a second key, move workloads, deactivate the old key, then delete it | Deactivate, confirm, delete | AWS IAM: check GetAccessKeyLastUsed before deactivating; reactivate to roll back; the secret is retrievable only at creation |
| Application client secrets and certificates | Add a new secret or certificate to the app registration, deploy, remove the old | Remove old secret | Platform-specific; follow the provider's credential management documentation |
| Kerberos service keys | Reset the service or krbtgt account password | Tickets signed with the old key fail once the old key is out of the history | See the krbtgt account guide |
| Secrets in a vault | Generate a new version; consumers fetch it | Disable or destroy the old version | Works only if consumers read from the vault instead of holding copies |
Where identity fits
In most cloud incidents the credentials that matter are non-human: access keys, service principal secrets, CI tokens and integration tokens. They have no person to call the help desk, and they are often copied into several systems. Reissue for them depends on knowing every consumer, which is why an inventory with last-used data comes before the incident. The Cloudflare Thanksgiving Breach 2023 shows the cost of skipping it: after the Okta support system breach, four exposed credentials, including a service token and service account credentials, were not rotated because they were believed unused, and an attacker used them weeks later. See Credential Rotation at Scale and Incomplete rotation breaches.
Implementation steps
- Confirm containment. Reissue only after the attacker's access paths, persistence and sessions are removed. Otherwise the new credential is exposed on arrival.
- Scope every affected credential. List human and non-human credentials used on, stored on or reachable from compromised systems, including signing keys and credentials believed to be idle. Credential Compromise Scope Analysis is the analytic step; see D3-CCSA Credential Compromise Scope Analysis.
- Order by blast radius. Reissue identity provider and directory keys (krbtgt, federation signing keys), administrative accounts and cloud keys first, then service accounts, then standard users.
- Verify the owner, then deliver securely. For people, verify identity through an approved process before issuing a temporary credential that must be changed at first use, or re-register a phishing-resistant authenticator. For workloads, write the new credential to the secrets manager or deployment pipeline, never to chat or email.
- Supersede the old credential. Disable, revoke or delete it. For machine credentials, keep an overlap only long enough to move consumers, then deactivate before deleting, as AWS documents.
- Keep a rollback path. For a machine credential that breaks a dependency, reactivate the old one briefly only if it is not known to be compromised; if it is, fix the consumer instead.
- Record and monitor. Log who reissued what, when and through which channel, and add the old credential identifiers to detection rules.
How to verify it works
- Old credential test: attempt an authentication with the superseded credential from a controlled test system. It must fail.
- Last-used check: for cloud keys and service accounts, confirm last-used timestamps for the old credential stop at the reissue time and the new credential shows normal use.
- Session check: confirm sessions and refresh tokens issued before the reissue are revoked, and allow for access-token lifetimes when judging residual access.
- Consumer check: every system that used the old machine credential is confirmed working with the new one, with no fallback copies left in configuration files.
- Detection on old identifiers: any later use of an old key ID or password hash raises a high-priority alert.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| In-scope credentials reissued and old versions disabled | 100% before incident closure | Incomplete reissue is a known breach pattern |
| Superseded credentials with any use after reissue | Zero | Proves the old credential is dead |
| Time from containment to reissue of tier-zero credentials | Tracked per incident; hours, not days | Highest-impact credentials first |
| Reissues delivered through an approved channel | 100% | Protects the new credential in transit |
| Non-human credentials with a known consumer list | Rising quarter on quarter | Determines how fast machine credentials can be reissued |
Limits, bypasses and failure patterns
- Reissuing before eviction: the attacker still on the host or in the mailbox captures the new credential.
- Skipping "unused" credentials: credentials believed idle are reissued last or never, as in the Cloudflare case above.
- Old credential left active: a new key is created but the old one is never deactivated, so the attacker keeps working.
- Weak delivery: temporary passwords sent by email or chat, or help desk resets without identity verification, give a social engineer the new credential.
- User password reset for a signing-key problem: forged tickets or tokens keep working because the signing material, not the user's password, was compromised.
- Long-lived tokens ignored: a password reset does not end existing sessions everywhere; Microsoft notes that access tokens stay valid until expiry.
Framework mapping
The mapping below is NHI Mgmt Group's view of where the control sits; D3FEND itself maps only to its digital artefact and inferred ATT&CK relations.
| Framework | Reference | Relevance |
|---|---|---|
| MITRE D3FEND | D3-RA Restore Access, D3-RIC | Parent and technique |
| NIST SP 800-63B-4 | Section 3.1.1.2 | Verifiers shall force a password change when there is evidence the authenticator has been compromised |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, IR-4 Incident Handling | Changing authenticators after compromise as part of incident handling |
| NIST CSF 2.0 | RC.RP-01, PR.AA-01 | Recovery plan executed; identities and credentials managed |
| MITRE ATT&CK mitigations | M1027 Password Policies, M1018 User Account Management | Policies the reissued credential must meet |
Practitioner checklist
- Confirm eviction and containment before reissuing any credential.
- Scope every credential exposed on compromised systems, including idle and signing credentials.
- Reissue tier-zero keys and administrative credentials first.
- Verify the owner's identity before issuing a credential to a person.
- Deliver machine credentials only through the secrets manager or deployment pipeline.
- Disable or delete the superseded credential and confirm it fails.
- Check last-used data to prove the old credential is no longer used.
- Alert on any later use of superseded credential identifiers.
- Keep consumer lists for non-human credentials before the next incident.
Standards and references
- MITRE D3FEND: Reissue Credential (D3-RIC)
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- AWS: Update IAM user access keys
- MITRE ATT&CK: T1558.001 Golden Ticket
Related NHI Mgmt Group resources: Enterprise Credential Reset Runbook Template · Workload Identity Compromise Response Playbook · Identity Incident Response Playbook · MITRE D3FEND Guide