Notifications
Clear all
Topic starter
09/07/2026 3:23 pm
TL;DR: ITGC access control succeeds or fails on the underlying identity model, not on audit-day evidence, according to Zluri. The core issue is that role design, provisioning, recertification, and de-provisioning must work as a lifecycle system, or least privilege quietly degrades across human and non-human identities.
NHIMG editorial — based on content published by Zluri: ITGC Access Controls: Models, Building Blocks, and a Rollout Plan
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.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams design access controls for both humans and non-human identities?
A: Security teams should design one access control lifecycle that covers employees, service accounts, API keys, and automation identities, then tailor the rules by actor type.
Q: Why do role-based access models often drift into excess privilege?
A: Role-based models drift when they are built from existing access rather than actual job requirements.
Q: What breaks when de-provisioning depends on manual tickets?
A: Manual de-provisioning breaks because it depends on someone remembering to file and complete a request across every application an identity touched.
Practitioner guidance
- Map access controls to lifecycle events Tie provisioning and de-provisioning to HR hire, move, and termination events for the systems that create the most risk, then extend the same pattern to additional applications once the handoff is reliable.
- Redesign roles from job function, not inherited access Review the top privilege-heavy roles and rebuild them around actual duties, data sensitivity, and system criticality so the role model does not preserve historical over-granting.
- Bring non-human identities into scope from the start Inventory service accounts, API keys, automation credentials, and other NHI access alongside employee access so recertification and offboarding do not leave machine identities outside governance.
What's in the full article
Zluri's full post covers the operational detail this post intentionally leaves for the source:
- A walkthrough of RBAC, ABAC, and PBAC implementation choices for access control programmes.
- A practical rollout sequence for provisioning, de-provisioning, and recertification across HR and application systems.
- Examples of how role models, lifecycle triggers, and review cadence fit into a working ITGC programme.
- Specific guidance on discovery, app inventory, and automation handoffs that support implementation.
👉 Read Zluri's guide to ITGC access control models and rollout planning →
ITGC access controls: what IAM teams should build before audit?
Explore further
09/07/2026 3:41 pm
Access control is an identity lifecycle problem before it is an audit problem. The source article correctly treats provisioning, recertification, and de-provisioning as connected building blocks rather than isolated tasks. That matters because the failure mode is usually not a broken control at the point of testing, but a control that never received clean lifecycle data in the first place. Practitioners should judge access control by whether it can survive change, not just by whether it can survive review.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should be accountable for access reviews and revocation outcomes?
A: HR should own the lifecycle event that starts the change, application owners should define what correct access looks like, IT and security should automate the enforcement, and audit or compliance should verify that reviews produced real action. Accountability fails when any one of those groups assumes the handoff is someone else’s problem.
👉 Read our full editorial: ITGC access controls need lifecycle design, not audit-day fixes
