Access request management is now a governance problem, not a ticketing one

At a glance

What this is: This is an access request management guide that argues access workflows must be governed with policy, approvals, audits, and least privilege.

Why it matters: It matters because access requests now sit inside broader IAM, NHI, and privileged access programmes, where weak approval design creates entitlement sprawl across humans and non-human identities.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Zluri's guide to access request management and least privilege

Context

Access request management is the control point where users, workloads, and service identities are granted or denied access to systems, data, and applications. In practice, it only works when requests are tied to policy, role design, and review, rather than handled as ad hoc fulfilment.

The article treats access requests as a governance mechanism for reducing overprivilege, improving auditability, and limiting exposure from unmanaged access. That framing is relevant across human IAM, NHI governance, and agentic systems because the failure mode is the same: access is granted faster than it is justified, reviewed, or revoked.

Key questions

Q: How should security teams govern access requests for both users and service accounts?

A: Security teams should use the same governance model for both, but apply it to the correct actor type. Requests need an owner, a justified business purpose, approval boundaries, and a revocation path. For service accounts, that also means tying the grant to rotation, expiry, and lifecycle offboarding rather than leaving the credential active after the original use case ends.

Q: Why do access request workflows so often create overprivilege?

A: They create overprivilege when approval logic focuses on convenience instead of actual entitlement scope. Broad roles, inherited permissions, and missing segregation of duties let a simple request unlock far more than the task requires. The result is access that is technically approved but operationally excessive, which makes later review harder and breach impact larger.

Q: What breaks when access reviews are not connected to entitlement data?

A: Reviews become ceremonial. If reviewers cannot see the real application permissions behind a role or group, they certify access that no longer matches need or duty separation. That leaves dormant privilege in place and creates a false sense of control, especially in environments where access is inherited across multiple systems.

Q: How do organisations reduce the risk of stale access after offboarding?

A: They need an automated revocation path that is tied to the same identity record used for approval. Access should be removed when employment, contract, or service conditions end, and the organisation should verify that removal across all linked applications, secrets, and delegated accounts before closing the record.

Technical breakdown

Access request approval workflows and entitlement drift

Access request management is the workflow layer that turns a request into an entitlement. The technical risk is not the request form itself, but how approvals, routing, and provisioning create durable permissions that outlive the business need. If requests are not bound to role design, expiry, and periodic certification, the system accumulates entitlement drift. That drift becomes worse when permissions are inherited across applications, groups, and service-linked access paths, because the approver often sees only the front door, not the downstream blast radius.

Practical implication: define approval paths that create time-bound, scope-limited access and force every request to map to an accountable owner and expiry condition.

RBAC, segregation of duties, and access review controls

RBAC reduces decision complexity by assigning access through roles rather than one-off grants, while segregation of duties blocks conflicting capabilities from landing in the same account or workflow. Access reviews then test whether the granted access still matches the person or system's current function. The control failure is usually not lack of policy, but mismatch between role design and actual application entitlements. When roles become too broad, reviews become ceremonial because too many permissions are hidden inside inherited or shared access paths.

Practical implication: reconcile role definitions against application-level entitlements and remove conflicting combinations before the next certification cycle.

Audit trails, offboarding, and revocation latency

A request-management programme only becomes defensible when it can prove who asked, who approved, what was granted, and when it was revoked. That is why audit trails and deprovisioning speed matter as much as approval quality. If revocation lags, the organisation keeps a stale permission window open after role changes, termination, or vendor offboarding. In NHI environments, that same pattern applies to API keys, tokens, and service accounts, where the access can remain active long after the human process that created it has ended.

Practical implication: measure revocation latency as a control metric and require evidence that every approved request has a corresponding offboarding path.

Threat narrative

Attacker objective: The attacker seeks durable access that can be used to move beyond the original business request and reach sensitive systems, data, or administrative functions.

1. Entry occurs when an access request is approved without a tight link to role need, so the resulting entitlement is broader than the task requires.
2. Escalation follows when overly broad permissions, shared roles, or missing segregation of duties allow the identity to reach systems or data outside its intended scope.
3. Impact appears as data leakage, privileged misuse, malware propagation, or audit failure because the organisation cannot prove that access was necessary, bounded, and revoked in time.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access request management is no longer a service desk concern; it is entitlement governance. The article correctly frames requests as a security control, but the deeper issue is that approval workflows often define access faster than governance can review it. That means request handling must be treated as part of the broader identity control plane, not as a fulfilment queue. Practitioners should read every access request as a statement about who can justify privilege.

Role-based access control only works when role design matches the actual application estate. RBAC is often described as a simplification layer, but in practice it can hide overgranting when roles are too coarse or mapped poorly to downstream entitlements. Segregation of duties then weakens because conflicting privileges sit inside the same role bundle. The implication is that access governance cannot stop at the role catalogue; it must inspect what the role truly unlocks.

Revocation latency is the real failure mode in access request governance. The article highlights revocation and audit logs, and that is where many programmes break down. Access that is approved quickly but removed slowly creates a standing privilege window that outlives the business need. For NHI programmes this is especially dangerous because the same pattern applies to API keys, tokens, and service accounts that often survive far beyond the request that created them.

Access request management must be evaluated as lifecycle control, not ticket workflow. The article's best practices point toward policy, review, and tool integration, but the governance question is whether the organisation can carry a request from approval to offboarding without losing accountability. That matters equally for human users and non-human identities. Practitioners should treat access requests as one stage in a lifecycle chain that ends only when access is provably gone.

Access request sprawl creates hidden identity blast radius. Each approved request increases the number of places where privilege can accumulate, be inherited, or be forgotten. That makes the governance problem broader than a single user or system account, because the access footprint can spread across apps, cloud platforms, and third-party tools. Teams should focus on the blast radius created by each approval, not just the speed of fulfilment.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For deeper context: 97% of NHIs carry excessive privileges, which is why request approval, scope control, and revocation all need to be treated as one governance chain, according to Ultimate Guide to NHIs.

What this signals

Access request management is becoming a control plane for entitlement sprawl. As organisations add more applications, more delegated access, and more non-human identities, request workflows are carrying decisions that used to be split across IAM, PAM, and operations. That makes request routing, approval quality, and revocation speed central to programme risk, not back-office hygiene.

Standing privilege remains the hidden failure mode behind many access programmes. When a request creates access that is never formally retired, the organisation has effectively turned a temporary need into a permanent entitlement. Teams should expect audit findings to focus less on how requests were approved and more on how long the access remained active after the business need ended.

Access request governance will increasingly have to span human, workload, and AI identities. The same lifecycle question now applies to employees, service accounts, and agent-like systems that receive delegated permissions. Programmes that keep request governance human-only will miss the fastest-growing sources of privilege accumulation.

For practitioners

• Map requests to roles and owners Require every access request to resolve to a named business owner, a clear role definition, and a documented justification before provisioning. If the request cannot be tied to an accountable role, reject it or route it back for redesign.
• Enforce segregation of duties at approval time Block requests that would combine conflicting permissions in the same identity, even when the request appears operationally convenient. Test the downstream application entitlements, not just the role label, before approving.
• Track revocation latency as a control metric Measure the time between role change, offboarding, or contract end and actual permission removal. Review any request path where revocation does not complete through the same governance channel that approved the access.
• Extend access governance to non-human identities Apply the same request, approval, and review discipline to API keys, service accounts, and automation identities that receive access through tickets or workflow tools. Tie every grant to expiry, rotation, and a verified offboarding path.

Key takeaways

• Access request management is an identity governance problem because approvals create durable privilege, not just workflow completion.
• The strongest risk signal in this model is revocation delay, especially where access survives role change, offboarding, or contract end.
• Teams should align requests, roles, segregation of duties, and offboarding into one lifecycle so granted access cannot outlive its business need.

Key terms

• Access Request Management: Access request management is the process for asking, approving, granting, reviewing, and removing access to systems or data. It turns entitlement into a governed workflow with ownership, justification, and audit evidence. In identity programmes, the control only works when approval, provisioning, and revocation stay linked across the full lifecycle.
• Segregation of Duties: Segregation of duties is an access control principle that prevents one identity from holding conflicting permissions that enable abuse or error. It limits fraud and operational risk by separating request, approve, execute, and review functions. In practice, it must be checked against real entitlements, not just role names.
• Revocation Latency: Revocation latency is the time between a decision to remove access and the point at which that access is actually gone. It is a practical measure of how long stale privilege remains usable after a role change, offboarding, or contract end. Shorter latency means smaller exposure and cleaner audit evidence.
• Identity Blast Radius: Identity blast radius is the scope of damage an identity can cause if it is misused, compromised, or overgranted. It reflects how far one access decision can spread across applications, data, and administrative functions. Strong governance reduces blast radius by constraining scope, duration, and inheritance.

Deepen your knowledge

Access request governance and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already handling approvals, revocation, or service account access, this is a useful next step.

This post draws on content published by Zluri: Access Management Access Request Management, an ultimate guide. Read the original.