A structured record used to request, assess, approve, or deny access to a system, application, or entitlement. In identity governance, it should capture the business reason, target asset, requester identity, and approval context so the decision can be audited and repeated consistently.
Expanded Definition
An access request ticket is the audit-ready workflow record that documents who asked for access, what access was requested, why it was needed, who approved it, and when the decision took effect. In NHI and IAM programs, the ticket is not just a helpdesk artefact; it is the control point that ties entitlement changes to business justification and approval evidence.
For non-human identities, the same pattern applies to service accounts, API keys, secrets, and machine entitlements, but the context is often stricter because the requester may be an automation workflow or delegated operator rather than the identity that will actually use the access. Definitions vary across vendors on whether the ticket is the request itself, the approval record, or the full lifecycle case file, so practitioners should treat it as the authoritative chain of evidence rather than a single form field. NIST guidance on identity assurance and access control is helpful here, especially OWASP Non-Human Identity Top 10, which frames access control failures as a common NHI risk. The most common misapplication is treating the ticket as a clerical intake form, which occurs when approvals are detached from the actual entitlement granted.
Examples and Use Cases
Implementing access request tickets rigorously often introduces workflow latency, requiring organisations to weigh faster provisioning against stronger review and auditability.
- A developer requests a new API key for a CI/CD pipeline, and the ticket captures the repository, environment, expiration date, and approver so the key can be traced back to a business change.
- A platform team requests temporary elevation for a service account to reach a production secret, with the approval tied to a change window and a named compensating control.
- An operations analyst requests read-only access to a logging system, and the ticket records the role, scope, and justification to support periodic recertification.
- A third-party integrator requests an NHI entitlement for cross-organisational data exchange, and the case references both contract scope and onboarding review. This is where the governance lessons in Ultimate Guide to NHIs become practical.
- A security reviewer compares ticket fields against the failure patterns described in the 52 NHI Breaches Analysis, looking for missing expiry dates, vague justification, or approval bypasses.
Access request tickets are most valuable when they are searchable, time-bound, and linked to the exact entitlement object that changed.
Why It Matters in NHI Security
Access request tickets matter because they are often the only durable proof that an NHI entitlement was intentionally granted rather than left standing by default. When tickets are incomplete, the organisation loses the ability to explain why a service account exists, why a token was issued, or why a machine role has broad access. That creates direct exposure in recertification, incident response, and least-privilege enforcement. The risk is not theoretical: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which means weak ticketing practices can quickly turn into over-provisioned access paths.
Tickets also become important when an incident forces teams to reconstruct the access path after compromise. In that moment, practitioners need to answer who approved the grant, whether the request matched the business need, and whether the entitlement should have expired. The guidance in OWASP Non-Human Identity Top 10 aligns with this operational reality, while the Ultimate Guide to NHIs — Key Challenges and Risks underscores how visibility gaps and privilege sprawl compound one another. Organisations typically encounter the need to audit access request tickets only after a breach, at which point the ticket becomes unavoidable to prove scope, accountability, and revocation timing.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Request records are a core control surface for NHI access governance and approval traceability. |
| NIST CSF 2.0 | PR.AC-4 | Access approvals map to least-privilege permission management and review. |
| NIST SP 800-63 | IAL2 | Identity proofing and accountable approvals underpin trustworthy access requests. |
Require every NHI entitlement to be requested, approved, and retained as auditable evidence.
