A structured process for asking, approving, and provisioning software access. In identity governance, it is not just a support queue. It is a decision path that must preserve approval evidence, ownership, and revocation history so access can be reviewed and removed later.
Expanded Definition
An app request workflow is the governed sequence used to request, review, approve, provision, and later revoke software access. In NHI and IAM environments, the workflow is more than ticket routing: it is the evidence chain that shows who asked, who approved, what entitlement was granted, and under what policy. That matters because access decisions are often delegated across managers, application owners, security teams, and automation, and each handoff can weaken accountability if records are incomplete.
Definitions vary across vendors, but the security-relevant core is consistent: the workflow should preserve ownership, approval rationale, scope, and expiration so access can be revalidated. This aligns closely with NIST Cybersecurity Framework 2.0, especially where identity governance supports access control and auditability. In practice, the workflow should also account for NHI-specific cases such as service accounts, API keys, and agent access, where requests may be automated but still require traceable approval and revocation paths. The most common misapplication is treating the app request workflow as a help desk convenience, which occurs when approvals are granted without policy checks, ownership validation, or revocation linkage.
Examples and Use Cases
Implementing app request workflows rigorously often introduces friction for requesters, requiring organisations to weigh faster onboarding against stronger governance and later revocation control.
- A developer requests access to a production API. The workflow records application owner approval, time-bound access, and the ticket ID that links to the eventual key issuance.
- An AI agent needs a scoped service account for a specific job. The request is approved by the system owner, then provisioned with least privilege and an expiration date.
- An analyst asks for access to a SaaS app. The workflow routes approval through the manager and app owner, while the system logs the justification for future recertification.
- A third-party integration requests credentials. The process verifies vendor ownership, contractual scope, and offboarding requirements before any secret is issued, as discussed in the Ultimate Guide to NHIs.
- A temporary exception is needed during incident response. The workflow grants short-lived access, then forces revocation and evidence retention once the incident closes.
For control design, the workflow often benefits from pairing with standards-based identity guidance such as NIST access governance concepts and approval traceability, rather than ad hoc ticket comments alone.
Why It Matters in NHI Security
App request workflows become critical because NHI access often outlives the original business need. NHIMG reports that 97% of NHIs carry excessive privileges and that only 5.7% of organisations have full visibility into their service accounts, a combination that makes weak request handling especially dangerous. When access is approved without a durable audit trail, teams lose the ability to prove why a secret, token, or service account exists, who owns it, and when it should be removed. That creates a direct path to privilege creep, shadow access, and failed offboarding.
The workflow is also a governance control point for secrets lifecycle management. If the request record does not connect to rotation, expiration, and revocation, then compromise response becomes slow and ambiguous. The NIST Cybersecurity Framework 2.0 reinforces the need for controlled identity operations, while Ultimate Guide to NHIs shows how common secret sprawl and weak visibility are in real environments. Organisations typically encounter the cost of a poor app request workflow only after an access review, breach investigation, or offboarding failure, at which point the workflow becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | App request workflows govern request, approval, and lifecycle evidence for NHI access. |
| NIST CSF 2.0 | PR.AA | Identity governance and access authorization map to controlled access decision processes. |
| NIST Zero Trust (SP 800-207) | Zero Trust treats access as continuously verified, not permanently granted after a request. |
Require recorded approval, ownership, and revocation data for every non-human access request.
