Containment cuts access fast, but giving it back is where many incidents restart: an account is unlocked before its attacker-added MFA method is removed, or a host is reconnected while the stolen credential still works. MITRE D3FEND models this step as Restore Access (D3-RA), defined as restoring an entity's access to resources, in the Restore tactic. Its children cover reissuing credentials, restoring user account access (including unlocking accounts) and restoring network access. This guide covers how to choose, combine and sequence those children, what to check before each one, how to verify the result, and which ATT&CK behaviours D3FEND relates to the family. It is written for incident responders, identity teams and service desk leads; each child has its own page on this site with deployment detail. For D3FEND itself see the MITRE D3FEND Guide.
Key takeaways
- Restore Access is the reverse of eviction. D3FEND evicts credentials, accounts and hosts during containment; D3-RA returns them, and it should only run once the cause is removed.
- Three children, one grandchild. Reissue Credential (D3-RIC), Restore User Account Access (D3-RUAA) with Unlock Account (D3-ULA) beneath it, and Restore Network Access (D3-RNA).
- Reissue before restore. Returning an account or host while an old credential, token or session still works hands access back to the intruder too.
- Verify the person, not just the request. Account restoration is a favourite social engineering target, so identity proofing belongs inside the technique.
- D3FEND's ATT&CK links are inferred. The D3FEND site derives them from the objects D3-RA restores (user accounts, credentials and hosts) and labels them inferred and experimental.
What D3FEND means by Restore Access
In the D3FEND ontology D3-RA is a defensive technique that enables the Restore tactic, with the reference CISA Cybersecurity Incident and Vulnerability Response Playbooks. The parent has no artefact relation of its own: its children "restore" a Credential (D3-RIC), a User Account (D3-RUAA and D3-ULA) and a Host (D3-RNA). Its sibling family is Restore Object (D3-RO), which brings back files, software, configuration, databases and images. In a recovery, objects are restored and verified first, and access is returned last. See the MITRE D3FEND Restore Object Implementation Guide.
The D3FEND website lists Unlock Account alongside the three children on the Restore Access page; in the ontology file it is a subclass of Restore User Account Access. This page follows the ontology hierarchy.
The child techniques
| D3FEND technique | D3FEND definition (summary) | Artefact restored | Typical situation |
|---|---|---|---|
| D3-RIC Reissue Credential | Issue a new credential that supersedes the old one | Credential | Password, key, certificate, token or secret known or suspected to be exposed |
| D3-RUAA Restore User Account Access | Restoring a user account's access to resources | User account | Account disabled during containment, or removed by an attacker |
| D3-ULA Unlock Account (child of D3-RUAA) | Restoring access by unlocking a locked user account | User account | Lockout after failed sign-ins, password spraying or a defensive lock |
| D3-RNA Restore Network Access | Restoring an entity's access to a computer network | Host | Host isolated by EDR, NAC or firewall during the incident |
Choosing and combining the children
Each child answers a different question: is the secret still trusted (D3-RIC), is the account itself trusted (D3-RUAA, D3-ULA), and is the machine trusted (D3-RNA). Most real cases need more than one.
| Situation | Usual combination | Precondition before restoring |
|---|---|---|
| User phished, account disabled | D3-RIC then D3-RUAA | Sessions revoked, attacker MFA methods and mailbox rules removed |
| Lockout from password spraying | D3-ULA, D3-RIC only if a guess may have succeeded | Successful sign-ins from the spraying source ruled out |
| Endpoint isolated after malware | D3-RNA, plus D3-RIC for credentials used on the host | Host rebuilt or cleaned and verified; see Restore Object |
| Service account or API key leaked | D3-RIC for the secret, D3-RUAA if the identity was disabled | Every consumer of the secret identified and ready to take the new value |
| Domain compromise | D3-RIC at scale (including krbtgt), then D3-RUAA, then D3-RNA by tier | Directory restored or cleaned, tier 0 rebuilt first |
| Attacker removed legitimate admins' access | D3-RUAA through break-glass accounts | Attacker-created accounts and roles removed first |
For the domain case see the krbtgt account guide and the Identity Recovery Guide.
Sequencing access restoration
The order below is our recommendation at NHI Mgmt Group; D3FEND does not prescribe a sequence.
- Confirm eradication. The entry point is closed, persistence removed, and restored objects verified. Restoring access earlier simply reopens the door.
- Reissue credentials (D3-RIC). Supersede every credential in the compromise scope, revoke refresh tokens and sessions, and for non-human identities rotate in a way that does not break consumers (dual secrets or staged rollout). See Credential Rotation at Scale.
- Clean the account before restoring it. Remove attacker-added authentication methods, OAuth consents, delegate permissions, forwarding rules and role assignments.
- Verify identity, then restore (D3-RUAA, D3-ULA). Use a proofing method the attacker cannot satisfy with stolen data, such as a manager-verified video call or in-person check for privileged users. See the account recovery and help desk security guide.
- Reconnect hosts by tier (D3-RNA). Tier 0 and management systems first, then servers, then user endpoints, each after its own verification. Keep heightened monitoring on reconnected hosts.
- Watch, then close. Hold a monitoring period on restored identities and hosts before declaring recovery complete.
Rollback: because each child is reversible (disable, lock or isolate again), define in the playbook which signals trigger re-containment of a restored account or host, and who can do it out of hours.
How to verify access was restored safely
- Old credential is dead: a test authentication with the superseded password, key or token fails, and its last-used time stops advancing.
- Account is clean: the authentication methods, delegates, inbox rules, app consents and roles match the pre-incident record or an approved list.
- Owner confirmed: the restore ticket records how identity was proofed and who approved it.
- Host is quiet: after reconnection, no beaconing, no new indicators from the investigation, and endpoint agent health is green.
- Business works: the user or service owner confirms access to what they need, and nothing more.
ATT&CK behaviours D3FEND relates to Restore Access
The D3FEND site lists offensive techniques for D3-RA as inferred and experimental, based on the family restoring user accounts, credentials and hosts. Restoration does not prevent these behaviours: it is the point where you must make sure their effects are gone. The selection below uses ATT&CK v20 IDs.
| ATT&CK technique | Most relevant child | What to check before restoring |
|---|---|---|
| T1078 Valid Accounts, T1078.004 Cloud Accounts | D3-RIC, D3-RUAA | Stolen credentials superseded; no unexplained sign-ins after reissue |
| T1110.003 Password Spraying | D3-ULA | No successful sign-in from the spraying source before unlocking |
| T1558.001 Golden Ticket, T1003.003 NTDS | D3-RIC | krbtgt and other directory secrets reset per the recovery plan |
| T1550.004 Web Session Cookie, T1606.001 Web Cookies | D3-RIC | Sessions and signing keys revoked, not just the password changed |
| T1098.001 Additional Cloud Credentials, T1098.002 Additional Email Delegate Permissions | D3-RUAA | Attacker-added keys, secrets and delegates removed |
| T1136.003 Cloud Account | D3-RUAA | Attacker-created accounts deleted, not restored |
| T1531 Account Access Removal | D3-RUAA, D3-ULA | Legitimate access returned through controlled break-glass paths |
| T1114.002 Remote Email Collection | D3-RNA, D3-RIC | Mail access tokens and app passwords reissued before reconnecting |
See the MITRE ATT&CK T1078 Valid Accounts Guide and MITRE ATT&CK T1531 Account Access Removal pages for those behaviours in depth.
Where identity fits
D3FEND words its children around user accounts, but non-human identities need the same treatment and usually fail it. A service account cannot answer a proofing call, so restoration depends on knowing its owner, every system that uses its secret, and how to reissue without an outage. Keep that record before an incident. Workload identities with federated or short-lived credentials are easier: revoke the trust or the issuing key and new tokens follow. See the Workload Identity Compromise Response Playbook and the Identity Incident Response Playbook.
Detection and measurement
Restore actions themselves are high-value events to log: unlocks, re-enables, MFA resets, credential reissues and network reconnections, each with the approver. Alert on restores without a linked ticket, on many unlocks by one operator, and on a restored identity signing in from the locations seen during the incident. Metrics we suggest (example targets, not standards):
- Reissue completeness: percentage of in-scope credentials superseded before the related accounts and hosts were restored.
- Proofing compliance: percentage of account restorations with a recorded, approved identity verification.
- Re-compromise rate: restored accounts or hosts re-contained within 30 days.
- Time to restore by tier, measured from eradication sign-off.
- Stale credential use: authentication attempts with superseded credentials after reissue (should trend to zero, and each one is a lead).
- NHI readiness: percentage of service accounts and keys with a named owner and a documented reissue procedure.
Framework mapping
| Framework | Reference | Link to D3-RA |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01, RC.RP-05 | Recovery executed; systems and services restored and normal status confirmed |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05 | Identities and credentials managed; access permissions enforced and reviewed |
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management, AC-2 Account Management | Reissuing authenticators; enabling and re-enabling accounts |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling, CP-10 System Recovery and Reconstitution | Access restoration as part of recovery |
| NIST SP 800-61 Rev. 3 | Incident response as a CSF 2.0 Community Profile | Places recovery within incident response |
| MITRE D3FEND | D3-RO Restore Object | Run first; access follows verified objects |
Common failure patterns
- Password reset without session revocation. The new password works, and so do the stolen cookies and refresh tokens.
- Unlocking without asking why it locked. A spraying lockout hides the one account where a guess succeeded.
- Restoring the account with the attacker's MFA method still registered. The intruder signs straight back in.
- Help desk restoration on weak proofing. Callers with personal details from earlier breaches get accounts reset; the MGM Resorts breach shows help desk social engineering used to gain access.
- Partial rotation of non-human secrets. One copy of a key is missed and remains valid. See the incomplete credential rotation guide.
- Reconnecting hosts in bulk. One unverified host rejoins and reinfects the rest.
Practitioner checklist
- Make eradication sign-off a precondition for every D3-RA action in the playbook.
- Reissue credentials and revoke sessions and tokens before restoring accounts or hosts.
- Strip attacker-added MFA methods, delegates, rules, consents and roles before re-enabling an account.
- Require recorded identity proofing for account restoration, stronger for privileged users.
- Keep owner and consumer records for every service account and key so it can be reissued without outage.
- Reconnect hosts by tier, each after verification, with heightened monitoring afterwards.
- Log every restore action with approver and alert on restores without a ticket.
- Track re-compromise rate and stale credential use after each incident.
Standards and references
- MITRE D3FEND: Restore Access
- MITRE D3FEND: Restore Object
- CISA: Cybersecurity Incident and Vulnerability Response Playbooks
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- NIST: SP 800-184 Guide for Cybersecurity Event Recovery
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Account Access Removal
Related NHI Mgmt Group resources: MITRE D3FEND Guide · AWS Backup Security Guide · CIS Control 11 Data Recovery Guide · Recovering IAM and PAM After Ransomware or Domain Compromise · Identity Incident Response Playbook