Who should own role-based access certification in public sector IAM?

Why This Matters for Security Teams

In public sector IAM, role-based access certification is less about checking boxes and more about proving that an entitlement still serves a mission, service, or statutory need. Business and service owners are the only people positioned to judge whether access remains appropriate after staffing changes, procurement shifts, or program changes. IAM teams can orchestrate the review, but they cannot substitute for operational accountability.

This is especially important for non-human access, where workload accounts, service principals, and API keys often persist far beyond the original use case. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, while 97% of NHIs carry excessive privileges. That is why role reviews cannot be treated as a purely technical cleanup exercise. They are a governance control that must be owned by the people who understand the work, supported by the team that can execute the change. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both point to the same practical reality: ownership failures turn access review into a compliance ritual, not a risk reduction activity. In practice, many security teams encounter over-entitled access only after an audit finding, incident review, or service retirement has already exposed the gap.

How It Works in Practice

The most effective model is shared execution with clear decision authority. IAM or GRC teams should run the certification workflow, collect attestations, and track completion. Business owners and service owners should answer the actual question: does this person, workload, or vendor still need this access to perform the approved function? For public sector environments, that often includes validating program authority, data sensitivity, contractor scope, and whether access is tied to a specific service line or delegated operational duty.

For non-human identities, the review should be anchored to the workload itself, not just the human sponsor. That means checking which service account, token, or API key is tied to which application, whether it is still in active use, and whether the privilege set is broader than the service requires. Current guidance suggests pairing certification with inventory, telemetry, and expiration data, because access reviews without context tend to approve stale entitlements by default. The 52 NHI Breaches Analysis shows how often weak ownership and weak visibility combine into avoidable exposure.

• IAM teams administer the campaign, evidence, and escalation path.
• Business owners confirm whether access still aligns to mission need.
• Service owners confirm whether the entitlement is still required by the application or workflow.
• Security teams verify whether the privilege level matches policy and risk.

Where possible, map certifications to role definitions, service catalogs, and workload identity records rather than generic user lists. That makes it easier to remove obsolete access quickly and to distinguish a valid privileged exception from a stale entitlement. These controls tend to break down when ownership is unclear across shared services and interagency environments because no single reviewer has enough operational context to make a safe decision.

Common Variations and Edge Cases

Tighter certification ownership often increases administrative overhead, requiring organisations to balance review quality against review speed. That tradeoff is real in public sector IAM, where a central platform team may want consistency but service owners have limited time and fragmented accountability. Best practice is evolving, and there is no universal standard for this yet, especially for federated agencies and shared service providers.

One common edge case is delegated administration, where the person approving access is not the same person consuming the service. In those cases, the approver should still be the accountable business or service owner, not the system administrator. Another edge case is emergency or break-glass access, where certification should be retrospective and tightly time-bound rather than folded into routine recertification. For workload identities, the review should also consider whether a long-lived credential should be replaced with ephemeral access, which aligns better with dynamic systems and the guidance in the Ultimate Guide to NHIs — Key Challenges and Risks.

When public sector organisations rely on role labels alone, they miss context such as mission drift, service retirement, and inherited access from prior programs. That is where a control like certification must be paired with actual ownership, not just process completion. The Sisense breach is a reminder that standing access and weak revocation discipline can create outsized impact when credentials remain usable after their intended scope has ended.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• When does role-based access control stop being enough for IAM governance?
• Why does policy-based access control matter more than traditional role-based access in modern IAM?
• Who should own time based access controls in an IAM programme?