A workflow pattern where an access change is executed through a service management system rather than directly by the identity platform. It can improve operational reach, but it only strengthens security when the ticket is bound to verified entitlement state and governed approvals.
Expanded Definition
Ticketed fulfilment is an access administration pattern where a service management ticket becomes the operational trigger for an identity change, such as provisioning, deprovisioning, rotation, or temporary elevation. In NHI environments, the ticket is only meaningful when it is bound to a verified entitlement state, an approved request, and an auditable execution path. That distinction matters because a ticket alone is not an authorization control; it is a workflow artifact that can help coordinate human review, change management, and segregation of duties.
Definitions vary across vendors on whether ticketed fulfilment implies manual operator action, API-driven orchestration, or both. NHI Management Group treats it as a governance pattern rather than a security control by itself. Used well, it can complement a zero trust program and operationalize policies described in the NIST Cybersecurity Framework 2.0. The most common misapplication is treating ticket closure as proof of access removal when the identity platform was never reconciled against the actual entitlement state.
Examples and Use Cases
Implementing ticketed fulfilment rigorously often introduces latency and coordination overhead, requiring organisations to weigh operational reach against the risk of delayed or incomplete access changes.
- A developer requests a new API key through a service desk ticket, and the identity platform issues the credential only after the approved entitlement is confirmed against policy.
- A contractor offboarding ticket triggers revocation of cloud service account credentials, with the execution logged back to the ticket for auditability and replay prevention. NHI Management Group notes that only 20% of organisations have formal offboarding processes for API keys in the Ultimate Guide to NHIs.
- An emergency privilege elevation ticket authorizes a short-lived change, but the workflow also enforces time-bound expiry and post-use review before standing access can return.
- A secrets rotation request is routed through ITSM so that operations teams can coordinate maintenance windows, while the rotation engine still validates the current secret before replacement.
- A third-party integration request is tracked as a ticket because the procurement and security teams need evidence of approval before the NHI is allowed to call production systems.
These patterns align more cleanly when the service desk workflow is integrated with policy enforcement, rather than used as a parallel source of truth. For implementation context on identity lifecycles and operational controls, the Ultimate Guide to NHIs is the stronger reference point than generic ITSM guidance. Where ticketing is used alongside identity orchestration, teams often compare it with service account governance concepts in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Ticketed fulfilment matters because many NHI failures are not caused by the absence of a request process, but by a gap between request approval and actual credential state. If a ticket approves rotation but the secret remains valid, the organisation has paperwork without risk reduction. If a ticket approves removal but the service account retains excessive access, the workflow has failed as a control. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which means change workflows must be tightly bound to entitlement verification and not merely to documentation.
This term is especially important in environments with heavy operational reliance on service desks, because service management systems often become the place where accountability is recorded after the fact. When tied correctly to access policy, ticketed fulfilment helps prove who approved what, when it was executed, and whether the identity state actually changed. That is why it supports governance, auditability, and incident response without replacing them.
Organisations typically encounter the failure of ticketed fulfilment only after an access review, compromise, or failed offboarding reveals that the ticket closed before the NHI was truly revoked, at which point the workflow becomes operationally unavoidable to fix.
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 | Ticketed fulfilment must still enforce verified lifecycle changes for NHIs. |
| NIST CSF 2.0 | PR.AA-01 | Access approvals and entitlement changes should map to governed identity processes. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification beyond a ticket's existence. |
Use ticketed workflows to support controlled access administration and auditable change records.
