How do organisations decide when ticket-based provisioning is acceptable versus a direct integration?

Why This Matters for Security Teams

The decision between ticket-based provisioning and direct integration is really a question about control, latency, and failure tolerance. Ticket workflows can preserve approval evidence when a platform has no reliable API, but they also create manual handoffs that slow response and increase the chance of drift. In NHI governance, that matters because standing credentials and delayed revocation are common failure points, as NHI Mgmt Group notes in the Ultimate Guide to NHIs.

Security teams often default to tickets because they are familiar to auditors, yet tickets do not scale well for high-volume entitlements, ephemeral access, or agentic systems that need near-real-time authorization. That is where direct integration becomes the stronger pattern: it can enforce policy, log changes, and revoke access automatically. NIST guidance on security and privacy controls reinforces the need for timely, accountable control execution rather than ad hoc approval trails. In practice, many security teams discover ticketing is no longer acceptable only after a delayed access change has already extended exposure.

How It Works in Practice

The practical decision starts with three questions: can the target system support automation, how risky is the access change, and how quickly must the change occur. Ticket-based provisioning is usually acceptable when the system is legacy, vendor-restricted, or operationally brittle, and when the request is infrequent enough that a manual path does not create material exposure. It is most defensible when the ticket captures requester, approver, time of action, and completion evidence.

Direct integration is preferable when the access event is routine, time-sensitive, or tied to a higher-risk NHI such as a service account, API key, or agent identity. In that model, the ticket may still exist as the governance record, but the actual provisioning action is executed through an API, webhook, or workflow engine. That reduces human error and supports consistent enforcement of expiry, rotation, and offboarding. The NHI Lifecycle Management Guide is useful here because it frames provisioning as one step in a broader identity lifecycle, not a standalone event.

• Use tickets when automation is technically impossible or too risky to deploy immediately.
• Use direct integration when the same entitlement is requested repeatedly or must be revoked quickly.
• Keep a ticket even for automated changes if audit evidence, segregation of duties, or exception handling is required.
• Define a time-to-complete threshold so manual handling does not become an unreviewed permanent pattern.

This guidance tends to break down in environments with many short-lived identities, CI/CD pipelines, or agentic workloads because the delay between request and fulfilment becomes a security issue rather than an administrative inconvenience.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance auditability against response time. That tradeoff is most visible in systems that are partially automatable: a ticket may approve the change, while a human still pastes the credential or updates the entitlement by hand. Best practice is evolving, but current guidance suggests treating that pattern as transitional, not as the steady state.

One common edge case is vendor software that exposes only partial APIs. In those cases, a ticket can remain the control wrapper while scripts handle the repeatable steps, preserving traceability without full manual execution. Another edge case is emergency access. For break-glass scenarios, a direct integration with strong logging and automatic expiry is usually safer than waiting for a ticket queue, provided the workflow is tightly governed.

For NHI-heavy environments, the threshold for accepting tickets should be lower than for human access because machine identities are typically numerous, highly connected, and prone to over-privilege. The Top 10 NHI Issues page and the NHI Mgmt Group finding that only 5.7% of organisations have full visibility into their service accounts both point to the same operational reality: if a ticket is the only control, the organisation may be documenting risk rather than reducing it.

Ticketing is acceptable when it is the least-bad option for a constrained system, but it should be revisited whenever the process becomes frequent, urgent, or security-critical. Where possible, move toward direct integration for provisioning and reserve tickets for exceptions, approvals, and compensating control evidence.

Related resources from NHI Mgmt Group

• How should organisations decide whether to integrate AI agents with other security platforms through protocol-based connections?
• When should organisations prioritise enrollment-based access over manual provisioning for unmanageable applications?
• How should organisations decide when to keep traffic direct versus inspect it?
• When should organisations prioritise a gateway-based integration over direct model API access?