They support both when every access grant and removal is logged, reviewable, and tied to a business event. Offboarding must remove application-level access, not just directory access, and audit teams should be able to trace who approved the entitlement, when it changed, and when it was revoked.
Why This Matters for Security Teams
Access request workflows are more than a ticketing step. They are the control point that proves whether access was approved for a business reason, whether it was removed when that reason ended, and whether the record can survive audit scrutiny. That matters for both human and non-human identities, especially where service accounts, API keys, and application entitlements outlive the people or projects that created them.
Without a disciplined workflow, offboarding becomes partial: directory access is removed, but application tokens, shared credentials, and delegated privileges remain active. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why lifecycle evidence is often incomplete in real reviews. audit readiness depends on Ultimate Guide to NHIs — Regulatory and Audit Perspectives and operational traceability, not assumptions that a deprovisioning event automatically cleaned everything up.
The same workflow also supports defensible access governance by tying each entitlement to an approver, timestamp, and revocation event. That is the difference between an access list and an audit trail. In practice, many security teams encounter missing revocations only after auditors ask for evidence that no longer exists.
How It Works in Practice
A strong access request workflow starts with a business trigger, such as role change, project end, contractor exit, or application retirement. The request should capture who is asking, what resource is involved, the approval basis, the intended duration, and whether the access is human or machine-based. For NHI-heavy environments, the workflow should also record the owning system, secret type, and downstream applications that depend on the entitlement.
From there, the workflow should enforce three things:
- Approval before grant, with a named approver and scope limited to the minimum required access.
- Automatic revocation at offboarding, including application-level permissions, tokens, certificates, and shared secrets.
- Immutable logging of the full lifecycle, so auditors can trace request, approval, change, and removal in order.
This is where access request tooling complements broader identity governance. The NIST Cybersecurity Framework 2.0 emphasizes governance and access control outcomes, while the OWASP Non-Human Identity Top 10 highlights the risk of long-lived, poorly governed non-human credentials. NHI Management Group also documents the scale of the problem in its NHI Lifecycle Management Guide, especially where service accounts persist beyond their intended use.
For audit readiness, teams should be able to show who approved access, what changed, when it changed, and how revocation was verified. That means linking the workflow record to directory actions, SaaS admin logs, PAM records, and secrets manager events when applicable. These controls tend to break down in distributed environments where application owners manage access outside central IAM and revocations happen manually.
Common Variations and Edge Cases
Tighter access workflows often increase operational overhead, requiring organisations to balance audit evidence against speed for urgent changes and break-glass access. That tradeoff is especially visible when the same access request process must cover both human users and NHIs, because machine credentials may need shorter TTLs, different approvers, and separate revocation paths.
Best practice is evolving for service accounts, CI/CD credentials, and agentic workloads, where a simple “remove the user” action is not enough. Current guidance suggests treating application entitlements as first-class offboarding targets, not secondary cleanup items. If the workflow cannot prove that a token was rotated, a certificate was invalidated, or an integration was decommissioned, the audit story is incomplete even if the directory account is gone.
Edge cases also arise with delegated admin models, shared accounts, and third-party integrations. In those environments, the request workflow should include a dependency check so revoking one identity does not break production unexpectedly. For a broader lifecycle view, Ultimate Guide to NHIs is useful because it frames access governance as an end-to-end process, not a one-time approval event. The biggest gap appears when offboarding is treated as an HR event instead of a full entitlement reconciliation across every application and secret store.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle revocation and secret removal are central to offboarding evidence. |
| NIST CSF 2.0 | PR.AC-4 | Access approval and removal workflows support least-privilege access control. |
| NIST AI RMF | AI governance needs lifecycle traceability for autonomous service identities too. |
Apply governance and accountability controls to prove who approved and revoked each agent entitlement.
