What breaks when access tickets are approved but not reconciled?

Why This Matters for Security Teams

When an access ticket is approved but never reconciled, the organisation is left with two conflicting sources of truth: the workflow record and the actual entitlement state. That mismatch breaks audit evidence, weakens recertification, and can leave dormant access in place long after a change request is marked complete. It also creates false confidence for teams that assume approval equals enforcement.

For non-human identities, the impact is sharper because service accounts, API keys, and workload credentials often bypass the same human-facing controls used for joiner-mover-leaver processes. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means reconciliation gaps are rarely isolated. They often hide in identity sprawl, ticket queues, and stale approvals that never reach the identity platform.

OWASP also treats non-human identity governance as a distinct control problem in the OWASP Non-Human Identity Top 10, because access workflows only work when the system of record is updated and checked against actual entitlements. In practice, many security teams discover reconciliation failures only after an access review, incident investigation, or offboarding event exposes the mismatch.

How It Works in Practice

Reconciliation is the step that confirms the approved request was actually carried out in the identity platform, directory, vault, PAM system, or application layer. In a healthy process, the ticket is not “done” until the entitlement state matches the approved decision. That means the approver, the executor, and the verifier all align on the same access outcome.

For NHI controls, that usually requires matching ticket metadata to concrete identity objects: service account names, API key IDs, certificate subjects, role bindings, or workload identities. A useful implementation pattern is to treat the ticket as evidence of intent, while the identity platform remains the authoritative source of state. The ticket should record what was approved, when it was provisioned, and what verification method confirmed the change.

• Compare approved requests against current entitlements on a scheduled basis.
• Flag tickets that were approved but never provisioned.
• Flag entitlements that exist without a corresponding approved request.
• Require closure only after automated or manual reconciliation evidence is attached.
• Feed mismatches into recertification, offboarding, and exception handling.

This aligns with the operational guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, especially where excessive privileges and weak visibility make entitlement drift harder to spot. It also matches the access governance emphasis in OWASP, where lifecycle control is inseparable from approval control. These controls tend to break down when access is granted across disconnected systems, because the ticketing tool cannot verify the final entitlement state without integration or periodic reconciliation.

Common Variations and Edge Cases

Tighter reconciliation often increases operational overhead, requiring organisations to balance stronger auditability against slower fulfilment and more exception handling. That tradeoff is real in mixed environments where some access is provisioned automatically and other changes are handled manually by platform owners.

Current guidance suggests treating high-risk NHI access differently from low-risk requests. For example, privileged service accounts, production API keys, and certificate-based access should usually require stronger verification than low-impact application roles. Where a platform cannot support automated reconciliation, best practice is evolving toward compensating controls such as secondary approval, evidence capture, or short-lived credentials with explicit expiry checks.

There is no universal standard for this yet, but the safest pattern is to reconcile against the authoritative system rather than the ticketing layer alone. That matters when a ticket is approved but the entitlement is changed incorrectly, partially applied, or later modified outside the request process. The same problem appears in breach investigations and offboarding, where a closed ticket may hide access that still exists in the directory or secret store. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often governance failures become visible only after the fact, not during the workflow.

Related resources from NHI Mgmt Group

• What breaks when service desks handle both support tickets and access decisions?
• What breaks when access requests are handled like ordinary support tickets?
• What breaks when mid-lifecycle access changes are handled through tickets only?
• What breaks when cloud access tools cannot see all delegated identities?