Soft deletion marks a record as removed without physically erasing it. In SCIM and identity governance, that preserves auditability and makes mistaken deprovisioning reversible while still preventing the account from remaining active.
Expanded Definition
Soft deletion is a lifecycle state in which a record is marked inactive, suspended, or removed from operational use without being physically erased from the system of record. In SCIM-driven provisioning, identity governance, and directory workflows, that distinction matters because the identity can be hidden from normal access paths while preserving an auditable trail for review, recovery, and downstream reconciliation. It is especially relevant where deletion is not merely a data event but a control decision affecting account state, entitlement inheritance, and recovery windows.
Definitions vary across vendors on whether soft deletion means disabled, deprovisioned, archived, or logically removed, so practitioners should always verify the exact state transition and side effects. In NHI operations, soft deletion should be paired with explicit handling for tokens, API keys, certificates, and delegated authorisations so that an “inactive” record does not still enable access. The NIST Cybersecurity Framework 2.0 reinforces the need for controlled asset and identity lifecycle management, which is the governance layer where soft deletion belongs.
The most common misapplication is treating soft deletion as equivalent to revocation, which occurs when teams hide the account in the UI but leave active credentials, grants, or sync rules in place.
Examples and Use Cases
Implementing soft deletion rigorously often introduces reconciliation overhead, requiring organisations to balance recoverability and auditability against the cost of tracking state across connected systems.
- A service account is marked deleted in the identity platform, but retention policies preserve the record so investigators can review who approved it and when it was last used.
- A SCIM target receives a deprovision event that disables the account and preserves the object in a recoverable state, while a separate workflow rotates or revokes attached secrets.
- An application admin mistakenly removes an automation identity; soft deletion lets the security team restore access after validation instead of rebuilding entitlements from scratch.
- During incident response, investigators correlate deleted NHI records with activity logs to determine whether an API key was still usable after account removal, a pattern discussed in the Ultimate Guide to NHIs.
- A cloud directory uses soft deletion to preserve audit evidence while the organisation applies policy-driven cleanup aligned to identity governance and NIST Cybersecurity Framework 2.0 recovery controls.
Why It Matters in NHI Security
Soft deletion matters because NHI risk is often caused by identity states drifting out of sync with actual access. If a record is “deleted” but its credentials, cached permissions, or synchronization links remain live, the organisation has created a false sense of closure. That is especially dangerous in environments with high secret sprawl and delayed offboarding. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which means deleted records can still leave exploitable access paths open. The same challenge is reflected in broader NHI governance guidance in the Ultimate Guide to NHIs.
Practitioners should treat soft deletion as one control in a larger chain that includes revocation, secret rotation, audit retention, and sync integrity. It should support compliance and forensics without becoming a substitute for actual removal of access. Organisationally, the control is only as strong as its downstream automation and review logic.
Organisations typically encounter the operational cost of soft deletion only after a supposedly removed NHI still authenticates during an incident, at which point the term 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 SP 800-63, NIST Zero Trust (SP 800-207) 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-05 | Soft deletion must not leave active NHI credentials or entitlements behind. |
| NIST CSF 2.0 | PR.AA | Identity lifecycle and access-state control are central to soft deletion handling. |
| NIST SP 800-63 | Digital identity assurance depends on reliable lifecycle transitions and revocation. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuously verified access states, including deleted identities. | |
| NIST AI RMF | AI governance depends on lifecycle controls for agents and service identities. |
Pair logical deletion with revocation, secret rotation, and access-state verification before closing the record.
Related resources from NHI Mgmt Group
- What is the difference between hard matching and soft matching in identity sync?
- What breaks when delegation revocation is not tied to client deletion?
- What breaks when retention and deletion rules are not tied to inventory data?
- What breaks when employee offboarding is handled as a simple account deletion?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
