D3-RUAA Restore User Account Access (D3FEND)

Every account disabled, locked or deleted during an incident has to come back, and the restore is where attackers regain access if it is done carelessly. D3-RUAA Restore User Account Access is the MITRE D3FEND countermeasure for that step: D3FEND defines it as "Restoring a user account's access to resources", places it in the Restore tactic under Restore Access (D3-RA), and cites CISA's Cybersecurity Incident and Vulnerability Response Playbooks as its reference. Its one child is D3-ULA Unlock Account. This card covers when an account is safe to restore, how to restore it with fresh credentials and correct permissions, how to verify the result and the mistakes that reopen the door. It is written for identity, help desk and incident response teams. Siblings under Restore Access are D3-RNA Restore Network Access and Reissue Credential (D3-RIC).

Key takeaways

D3-RUAA reverses account containment and account sabotage. It covers accounts the defender disabled or locked, and accounts an attacker locked, deleted or changed (T1531 Account Access Removal).
Restore the account, not the attacker's version of it. Reset credentials, remove attacker-added authenticators and roles, and check mailbox and delegation changes before returning access.
Identity verification is the control point. NIST SP 800-63B-4 requires recovery at AAL2 to use two recovery codes from different methods, a code plus a bound authenticator, or repeated identity proofing, and requires a notification after every recovery.
D3FEND's ATT&CK links are inferred from the User Account artefact. Directly: T1078, T1098, T1136 and T1531, plus ICS technique T0859 Valid Accounts.
Service accounts need a different restore path. A non-human account is restored by reissuing its credential to the owning workload, never by a help desk call.

D3-RUAA at a glance

Field	D3-RUAA Restore User Account Access
D3FEND ID	D3-RUAA
Tactic	Restore
Parent technique	Restore Access (D3-RA)
Child technique	Unlock Account (D3-ULA): restoring access by unlocking a locked User Account
Siblings	Restore Network Access (D3-RNA), Reissue Credential (D3-RIC)
Digital artefact	User Account (D3FEND: the technique "restores" a User Account)
D3FEND reference	CISA: Cybersecurity Incident and Vulnerability Response Playbooks (November 2021)
Reverses	D3-AL Account Locking, account disablement during containment, attacker lockouts and deletions
Main risk	Returning access to an account the attacker still controls through a credential, authenticator or delegation

Two situations, two restore paths

Situation	Typical cause	What has to happen before restore
Defender contained the account	Disabled or locked during response with D3-AL Account Locking or a session kill with D3-ST Session Termination	Eradication of the attacker's access to the account: new password, authenticators reviewed, tokens revoked, changes made by the attacker reversed
Attacker removed access	T1531 Account Access Removal: password changed, account locked, disabled or deleted to slow the response or cause harm	Prove the legitimate owner's identity, then recover the account through an administrator path the attacker cannot use, and treat the account as compromised
Routine lockout	Failed sign-ins tripping a lockout threshold	Check whether the failures were the user or a password spraying attempt before unlocking (see D3-ULA)

CISA's playbook sets the order for the first case: during containment change administrator passwords, rotate keys and revoke privileged access where compromise is suspected; during eradication reset passwords on compromised accounts and confirm all persistent access paths are accounted for; restore only in recovery, with enhanced monitoring. Its checklist also lists implementing multi-factor authentication before systems return to production.

ATT&CK techniques D3FEND relates to D3-RUAA

Relationship type: inferred only. D3FEND relates D3-RUAA to ATT&CK because both act on the User Account artefact, and states that these mappings "are inferred, experimental, and will improve as the knowledge graph grows" (checked November 2026). These are the four techniques whose D3FEND entries name User Account directly; all were checked against ATT&CK v20.

ATT&CK ID	Technique	D3FEND relation	What it means for the restore (NHI Mgmt Group assessment)
T1531	Account Access Removal	Modifies User Account	The direct reversal: D3-RUAA returns access an attacker removed
T1078	Valid Accounts	Uses User Account	Restoring an account with an unchanged credential returns it to the attacker too; reset first
T1098	Account Manipulation	Modifies User Account	Check for added roles, authenticators, credentials and mailbox delegates before restoring
T1136	Create Account	Creates User Account	Do not restore accounts the attacker created; compare against the joiner records

The D3FEND page also lists sub-techniques inherited through account types, including T1078.001 to T1078.004 (default, domain, local and cloud accounts), T1098.002 Additional Email Delegate Permissions, T1098.003 Additional Cloud Roles, T1136.001 to T1136.003, T1548.005 Temporary Elevated Cloud Access and T1087 Account Discovery sub-techniques. The first five are the practical pre-restore checks. See MITRE ATT&CK T1531 Account Access Removal and MITRE ATT&CK T1098 Account Manipulation Guide.

Identity verification before restore

When the user cannot authenticate, restoring the account is account recovery, and the recovery path is itself an attack surface: social engineering of help desks to reset credentials is a known route into organisations. NIST SP 800-63B-4 section 4.2 gives a usable baseline:

Recovery methods: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. Any alternative method has to be based on a documented risk analysis.
AAL2 accounts: recovery requires two recovery codes from different methods, or one recovery code plus authentication with a bound single-factor authenticator, or repeated identity proofing where the account was proofed.
AAL3 accounts proofed at IAL3: a biometric comparison against the sample collected at the original attended proofing.
Notification: account recovery "SHALL" trigger a notification to the subscriber or their designee.

For workforce help desks that means a call-back to a number from the HR record, a manager or second-person approval for privileged accounts, and no reset based on knowledge questions alone. See the Account Recovery and Help Desk Security Guide.

Where it is implemented

Account store	Restore action	What to check first
On-premises directory	Enable or unlock the account, reset the password and require change at next sign-in; restore deleted objects from the directory recycle facility or backup	Group memberships, especially privileged groups; logon scripts and delegated rights on the object
Cloud identity provider	Restore from the soft-deleted state within the provider's retention window, re-enable sign-in, reset credentials and re-register authenticators	Registered MFA methods, app consents, role assignments and conditional access exclusions; confirm what the restore brings back, since memberships and roles may not return
Email and collaboration	Re-enable mailbox access	Inbox rules, forwarding and delegate permissions (T1098.002)
Privileged access tooling	Re-onboard the account and rotate its vaulted credential	Who checked out the credential during the incident window
Service and machine accounts	Reissue the credential to the owning workload and update dependants	Every place the old secret was stored or used

Directory synchronisation can reverse a cloud-side action: a user still present on premises may be restored on the next sync cycle, so restore and disable at the authoritative source. For directory and identity provider recovery at scale see the Identity Recovery Guide.

Where identity fits for non-human accounts

Service accounts, workload identities and API keys are often disabled during containment because they were used for lateral movement. Restoring them is not a help desk task: there is no person to verify. The safe pattern is to issue a new credential to the owning workload, confirm the old one fails, and re-enable the account with the same or narrower permissions than before. Accounts with no clear owner are better left disabled and replaced. See the NHI Offboarding and Decommissioning Guide.

Implementation steps

Write restore criteria into the incident plan. Who approves restoring a contained account, the evidence needed and whether privileged accounts need two approvers.
Review the account before restoring. List authenticators, credentials, roles, group memberships, mailbox rules and delegates changed during the incident window, and reverse attacker changes.
Reset and revoke. New password or credential, all sessions and refresh tokens revoked, and any authenticator the user cannot confirm removed and re-registered.
Verify the person. For attacker-removed access or lost authenticators, use a recovery method that meets the account's assurance level and notify the user after recovery.
Restore with least privilege. Return access in line with the user's current role, not simply the state before the incident; privileged roles can come back later through a time-bound request.
Monitor closely after restore. Put restored accounts on a watch list for unusual sign-ins, new authenticators and permission changes for an agreed period.
Keep rollback ready. Rollback is disabling the account again; make sure responders can do so quickly and that the action revokes sessions.

How to verify the restore

Old credential test: confirm the previous password, tokens and keys fail.
Authenticator check: the registered methods are only those the user confirmed during recovery.
Permission diff: roles and memberships match an approved baseline; nothing added during the incident window remains.
Mailbox check: no forwarding, hidden inbox rules or delegates the user did not set.
Notification check: the user or designee received a recovery notification, as SP 800-63B-4 requires.

Metric (example, not a standard)	What it shows	Direction
Restored accounts with credentials reset and sessions revoked first	Restore discipline	100%
Restored accounts re-contained within 30 days	Restores done before eradication was complete	Falling
Recoveries verified by a method matching the account's assurance level	Strength of the recovery path	100%
Privileged roles returned without a fresh approval	Privilege creep through restore	Zero
Restored service accounts with a new credential and a named owner	Machine identity hygiene	100%

Limits and failure patterns

Restoring before resetting: the account comes back with the credential the attacker holds.
Leaving attacker authenticators: a password reset does not remove an MFA method or app password the attacker registered.
Restoring everything that was disabled: accounts created by the attacker get re-enabled with the legitimate ones.
Help desk social engineering: the attacker requests the restore. Use call-backs and approvals, not caller-supplied details.
Sync reversal: an account disabled in the cloud is re-enabled from on premises, or the reverse.
Full privilege on return: the account gets back every role it held, including ones it should not have had.

Framework mapping

Framework	Reference	Relationship to D3-RUAA
NIST SP 800-53 Rev 5	AC-2 Account Management	Enabling, modifying and reviewing accounts
NIST SP 800-53 Rev 5	IR-4 Incident Handling	Recovery as the step after containment and eradication
NIST SP 800-63B-4	Section 4.2 Account Recovery	Recovery methods, assurance requirements and notification
MITRE ATT&CK mitigations	M1018 User Account Management, M1026 Privileged Account Management, M1032 Multi-factor Authentication	Closest in intent (NHI Mgmt Group mapping, not D3FEND)

D3FEND cites only the CISA playbook for D3-RUAA; the other rows are NHI Mgmt Group's mapping by intent.

Practitioner checklist

Define restore approvers and evidence for user, privileged and service accounts.
Review authenticators, roles, memberships and mailbox settings changed during the incident window.
Reset credentials and revoke sessions before re-enabling.
Verify identity with a recovery method that matches the account's assurance level.
Notify the user after every recovery.
Do not restore attacker-created accounts.
Reissue service account credentials to the owning workload and confirm old ones fail.
Watch restored accounts closely for an agreed period.

D3-RUAA Restore User Account Access: Returning Accounts Safely After an Incident