A soft delete marks an identity record as inactive or deleted without permanently removing it from storage. This preserves recoverability when an account is removed by mistake and can support safer reactivation, but it still requires clear governance over what access remains during the inactive state.
Expanded Definition
Soft delete is a lifecycle control that marks a non-human identity record as deleted, disabled, or inactive while retaining the underlying data for recovery, audit, and controlled reactivation. In NHI environments, this often applies to service accounts, API keys, application identities, and machine certificates where immediate purging could disrupt dependent workloads or remove evidence needed for incident response.
Definitions vary across vendors on whether soft delete is a data-retention feature, an access-control state, or both. In practice, NHI Management Group treats it as a governance state that must be paired with explicit rules for entitlements, token validity, secret rotation, and restoration approval. That distinction matters because a record can be inactive in the directory while still being usable elsewhere if tokens, cached credentials, or downstream permissions remain live. The NIST Cybersecurity Framework 2.0 is useful here because soft delete sits at the intersection of protect, detect, and recover activities, not just record management.
The most common misapplication is assuming soft delete fully removes access, which occurs when teams deactivate the record but fail to revoke issued secrets or update dependent integrations.
Examples and Use Cases
Implementing soft delete rigorously often introduces operational friction, requiring organisations to weigh recovery speed and auditability against the cost of additional entitlement cleanup and reactivation approval steps.
- An API service account is soft deleted after an application is retired, but the team also revokes its tokens and rotates any shared secrets to prevent lingering access.
- A mistakenly removed CI/CD bot identity is restored from soft delete after approval, preserving deployment history while the associated permissions are revalidated.
- An incident responder places a suspicious workload identity into soft delete, then uses the retained record to reconstruct where the identity was used before containment.
- A cloud platform keeps deleted machine identities recoverable for a defined retention period, aligned to internal audit requirements and the guidance in the Ultimate Guide to NHIs.
- A security team compares soft delete behavior with the lifecycle expectations in the NIST Cybersecurity Framework 2.0 to ensure inactive identities are not still operationally trusted.
In mature environments, soft delete is also used to support legal hold or forensic preservation, but only when the retained object cannot be mistaken for an active identity. NHIMG’s Ultimate Guide to NHIs shows why lifecycle controls must be paired with visibility and offboarding discipline, especially where service accounts are embedded in automation.
Why It Matters in NHI Security
Soft delete becomes a security issue when teams treat deleted identities as harmless remnants instead of potentially privileged objects with lingering access paths. That is especially dangerous in NHI estates, where identities outnumber human users by 25x to 50x and 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs. If the soft-deleted record remains linked to valid secrets, long-lived tokens, or inherited roles, the organisation may believe an identity is gone while the attack surface is still intact.
This concept also matters for governance because it forces a clean separation between identity record retention and access revocation. The retained object should support audit, recovery, and incident analysis, while operational access must be explicitly removed or time-bounded. That discipline aligns with the NIST Cybersecurity Framework 2.0 and prevents soft delete from becoming a loophole in offboarding, especially in automated pipelines and federated environments where one disabled record can mask many active permissions. Organisations typically encounter the risk only after an access review, incident investigation, or failed reactivation, at which point soft delete becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Lifecycle and deprovisioning controls apply when deleted NHIs may still retain access. |
| NIST CSF 2.0 | PR.AC-4 | Access management governs whether inactive identities still hold usable privileges. |
| NIST Zero Trust (SP 800-207) | DP-1 | Zero trust requires continuous verification even for identities marked inactive. |
| NIST SP 800-63 | Identity lifecycle and credential status are central to assurance and recovery decisions. | |
| NIST AI RMF | GV.1 | Governance requires clear rules for retention, restoration, and residual access risk. |
Define soft delete policy, retention periods, and restoration controls as formal governance requirements.
