Notifications
Clear all
Topic starter
25/06/2026 3:17 pm
TL;DR: Delayed or manual user deprovisioning leaves former employees, contractors, and moved staff with lingering access across apps, cloud tools, and VPNs, turning offboarding into a breach window, according to SecurEnds. The governance failure is assuming provisioning matters more than revocation, when access removal is what keeps IAM and IGA defensible.
NHIMG editorial — based on content published by SecurEnds: What Is User Deprovisioning?
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: What breaks when user deprovisioning is handled manually?
A: Manual deprovisioning breaks when revocation depends on people remembering every connected system.
Q: Why do organisations need automated deprovisioning in IAM and IGA?
A: Automated deprovisioning reduces the gap between an offboarding event and actual access removal.
Q: How do teams know whether deprovisioning is actually working?
A: Teams should look for complete revocation, accurate logs, and a low count of active accounts after termination or role change.
Practitioner guidance
- Tie offboarding to an authoritative event source Use HR status changes as the trigger for account closure, license removal, and entitlement revocation across all connected systems.
- Reconcile every downstream system after revocation Verify that VPN, SaaS, cloud consoles, shared storage, and directory groups were actually removed, not just marked for removal.
- Measure orphaned access as a governance metric Track accounts that remain active after termination, role change, or contract end, and report the count to IAM and audit owners.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step explanation of automated deprovisioning workflows across HRMS, IAM, and IGA systems.
- A practical comparison of manual and automated offboarding tasks for security and compliance teams.
- Detailed coverage of SCIM, RBAC, and ABAC integration patterns for access removal.
- Common deprovisioning failure points and implementation pitfalls that affect real deployments.
👉 Read SecurEnds' guide to automated user deprovisioning and offboarding →
User deprovisioning and offboarding gaps: what IAM teams miss?
Explore further
25/06/2026 4:43 pm
Revocation is the control that proves offboarding happened. Provisioning creates productivity, but deprovisioning is what determines whether the identity boundary closes cleanly when employment ends or role change occurs. If revocation is delayed, incomplete, or unverifiable, the organisation has not finished the lifecycle, it has merely changed the employment record. Practitioners should treat access removal as the audit-grade end state of identity governance.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when former users still retain access?
A: Accountability sits with the identity and application owners who failed to ensure access was removed when the business event occurred. HR may trigger the event, but IAM, IGA, and system owners are responsible for making revocation complete, auditable, and timely. Regulatory frameworks expect that access ends when the need for access ends.
👉 Read our full editorial: User deprovisioning is the control that closes offboarding risk
