The process of evaluating, approving, provisioning, and revoking access to applications or data through a governed workflow. In practice it sits between identity governance and operational IT, turning access decisions into auditable changes across directories, SaaS tools, and third-party services.
Expanded Definition
Access Request Management is the controlled process for asking for, reviewing, approving, provisioning, and later removing access to systems, datasets, and SaaS services. In NHI environments, it applies not only to people but also to service accounts, API keys, workload identities, and AI agents that need scoped permissions to operate safely. The discipline overlaps with identity governance, but it is operationally distinct because it turns policy into auditable change across directories, ticketing systems, cloud platforms, and third-party applications.
Definitions vary across vendors, especially when workflow automation, entitlement discovery, and access certification are bundled into one product category. For NHI Management Group, the important boundary is that access request management must enforce an explicit approval path, capture business justification, and create a revocation trail that can be verified later. That makes it a governance control, not just a service desk convenience. The relevant posture is reinforced by the OWASP Non-Human Identity Top 10 and the broader access principles in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a request form as the control itself, which occurs when approvals are recorded but entitlements are provisioned without scope checks or expiry enforcement.
Examples and Use Cases
Implementing access request management rigorously often introduces workflow latency, requiring organisations to weigh faster delivery against stronger entitlement governance.
- A developer requests temporary access to a production database, and the workflow grants time-bound permission with a required expiry date and manager approval.
- An AI agent needs access to a ticketing API, and the request is routed through policy checks that limit scope to the minimum toolset needed for the task.
- A contractor is granted SaaS access for a project, then automatically removed at contract end through a lifecycle process aligned with Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- A service account request is denied because the entitlement would allow broad write access, contradicting least-privilege expectations described in the Ultimate Guide to NHIs.
- An external supplier needs access to a shared storage workspace, and the request requires third-party risk review before provisioning.
In practice, these workflows work best when the request captures who or what is asking, why access is needed, how long it should last, and what evidence will support later review. For AI and NHI use cases, the request must also identify the identity type and the secret or token lifecycle that will be tied to the approval.
Why It Matters in NHI Security
Access request management matters because unmanaged approvals become standing privilege, and standing privilege is one of the fastest paths to compromise in NHI-heavy environments. NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, while 71% of NHIs are not rotated within recommended time frames. That combination means a weak request workflow often becomes a long-lived access problem that survives the original business need.
When access requests are not linked to revocation, logging, and periodic review, organisations lose the ability to explain why a service account, token, or API key still has authority months later. That creates audit findings, increases blast radius, and makes incident response slower because teams cannot quickly distinguish legitimate access from stale entitlements. The issue is especially acute for cloud services and third-party integrations, where the request may look complete but the underlying secret continues to work long after the project ends. These risks are discussed in Top 10 NHI Issues and 52 NHI Breaches Analysis, and they align with access governance expectations in NIST Cybersecurity Framework 2.0.
Organisations typically encounter this control gap only after an access review, breach investigation, or failed offboarding event reveals that the original request never translated into a timely revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and entitlement handling for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions management and controlled authorization. |
| NIST CSF 2.0 | PR.AC-1 | Requires identities and credentials to be managed before access is granted. |
Approve, provision, and review access through a governed workflow with periodic validation.
