ITGC access controls need lifecycle design, not audit-day fixes

At a glance

What this is: This is a guide to building ITGC access controls around RBAC, ABAC, lifecycle-triggered provisioning, recertification, and de-provisioning, with explicit attention to non-human identities.

Why it matters: It matters because IAM teams cannot rely on manual approvals and fragmented role design to prove least privilege across employees, service accounts, and automation identities.

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.

👉 Read Zluri's guide to ITGC access control models and rollout planning

Context

ITGC access control is the discipline of making sure identities only receive the access they need, and lose it when they no longer need it. The problem is that many programmes still treat access as a ticketing exercise rather than a lifecycle control, which leaves role drift, excess privilege, and orphaned access intact.

The source article is strongest where it connects access control to implementation detail: RBAC, ABAC, provisioning, recertification, logging, and de-provisioning. That same model has to cover non-human identities as well, because service accounts and automation credentials often outlive the business events that should remove them. For a broader NHI framing, see the Ultimate Guide to NHIs.

Key questions

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. The core test is whether access is granted, reviewed, and removed based on current need. If non-human identities sit outside that workflow, least privilege will degrade fast.

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. Once exceptions are baked into the role, every new assignment inherits them. Over time, that turns a clean entitlement model into a repository of historical access that no longer matches business need.

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. That creates delayed revocation, missed systems, and stale access with no current business justification. The more applications you have, the more likely the gap becomes systemic.

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.

Technical breakdown

RBAC, ABAC, and PBAC shape how access decisions are made

Role-based access control assigns entitlements to a job role, which makes review simpler but can hide over-granting inside broad bundles. Attribute-based access control adds context such as department, location, or data classification, while policy-based access control centralises conditional logic in a policy engine. In practice, these models are not mutually exclusive. Most mature environments blend them, with least privilege acting as the governing standard rather than a separate model.

Practical implication: Use the model mix that matches your governance maturity, then verify that each role or policy still maps to current business need.

Provisioning and de-provisioning are lifecycle controls, not admin tasks

Provisioning grants access when an identity first needs it, and de-provisioning removes it when the need ends. When those steps depend on manual tickets, the process inherits human delay, inconsistent approvals, and missed handoffs between HR, IT, and application owners. When they are tied to lifecycle events, such as hire, move, or termination, the access control model becomes enforceable rather than aspirational. This is where most real-world drift is created or prevented.

Practical implication: Automate lifecycle-triggered access changes for the highest-risk systems first, then expand to the rest of the application estate.

Recertification only works when the review evidence is retrievable

Recertification is the mechanism that catches access drift after the fact, especially for permissions that were valid once but no longer are. The control fails when reviews become ritualised, because a rubber-stamped certification does not prove that access was challenged. Logging and retrievable records matter because they make the review auditable and show whether the access model is actually shrinking or quietly expanding over time.

Practical implication: Measure how often recertification removes access, not just whether the review was completed on schedule.

NHI Mgmt Group analysis

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.

Least privilege degrades fastest when role design is based on history instead of function. A role model built from what users already have simply freezes legacy exception handling into policy. That creates a persistent entitlement debt that later shows up as excessive access during recertification. The practical conclusion is that role architecture has to be designed from job function and system criticality, not from inherited grants.

Non-human identities belong inside the same access control model, not outside it. Service accounts, API keys, and automation credentials often carry broader standing access than human users, yet they are commonly excluded from provisioning and review workflows. That exclusion creates a structural blind spot in ITGC programmes, because the identities most likely to accumulate privilege are also the ones least likely to be challenged. Practitioners should treat NHI scope as mandatory, not optional.

Manual handoffs remain the weakest point in ITGC access control. The article shows that a termination in HR does not automatically become revocation in applications unless the handoff is engineered. That is the same governance problem seen across identity programmes: the control is declared in policy, but the operational event never reliably reaches the systems that enforce it. The field should stop equating documented process with executed control.

Recertification is only meaningful when it changes access outcomes. A review cadence without measurable revocation, escalation, or remediation is governance theatre. The stronger benchmark is whether recertification reduces accumulated privilege, closes orphaned access, and leaves an evidentiary trail that can be reconstructed later. IAM and IGA teams should therefore optimise for outcome evidence, not review completion alone.

From our research:

• 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.
• For a broader lifecycle view, the Ultimate Guide to NHIs shows how rotation, offboarding, and visibility failures compound into governance debt.

What this signals

Access governance is shifting from point-in-time approvals to lifecycle assurance. Teams that still rely on manual revocation and quarterly reviews will continue to accumulate stale access faster than they can certify it. The practical signal is that automation around hire, move, and leave events is becoming the baseline for any credible IAM programme, especially where service accounts and API keys are in scope.

Role sprawl is now an operational risk, not just an audit nuisance. When roles mirror historical exceptions, every recertification cycle becomes an opportunity to rediscover the same excess access. Teams should expect stronger pressure to prove that their role model is being rebuilt from business function, not defended as a legacy catalogue.

The access control conversation now intersects directly with identity visibility, because you cannot govern what you have not inventoried. In practice, that means cross-checking SaaS, directories, and NHI inventory against the actual revocation workflow, not against the assumption that a policy document equals enforcement.

For practitioners

• 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.
• Measure whether recertification removes access Track the percentage of reviewed access that is actually revoked, adjusted, or escalated, because completion alone does not prove the control is effective.

Key takeaways

• ITGC access control fails when lifecycle events and enforcement are disconnected.
• Role design built from historical access creates durable excess privilege across both human and non-human identities.
• Automation, recertification, and NHI scope are the controls that turn access policy into provable governance.

Key terms

• Role-Based Access Control: A model that assigns access through predefined job roles rather than individual permissions. It simplifies review because auditors can validate role assignments, but it can also hide excess access if roles are built from historical exceptions instead of current business functions.
• Attribute-Based Access Control: A model that makes access decisions using attributes such as department, location, employment type, or data classification. It gives finer-grained control than role-only designs, but it still needs strong governance or the policy layer becomes difficult to explain and maintain.
• Recertification: A periodic review that confirms existing access still matches current business need. It is only effective when reviewers can see accurate entitlement data and when the review produces real removals or changes, not just a documented approval trail.
• Non-Human Identity: A digital identity used by software, services, automation, or infrastructure rather than a person. In practice this includes service accounts, API keys, tokens, and certificates, and it must be governed with the same lifecycle discipline as human access because it often carries standing privilege.

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.

👉 Zluri's full post covers implementation choices, ownership splits, and rollout sequencing for access control.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, IGA, or PAM programme, it is worth exploring.