What breaks when access-request software is used without lifecycle governance?

The workflow can show who asked for access and who approved it, but not whether that access was later removed, rotated, or reviewed. That leaves standing privilege, stale entitlements, and weak audit evidence. Organisations end up with a complete ticket history and an incomplete identity control story, which is a common governance failure.

Why This Matters for Security Teams

Access-request software is useful for workflow and evidence, but it is not lifecycle governance by itself. The control gap appears when teams assume an approved request equals safe access for the rest of the identity’s life. Without provisioning, rotation, expiration, recertification, and offboarding tied together, approvals can outlive the business need and become standing privilege.

That matters most for non-human identities because service accounts, API keys, and tokens do not behave like employees. They are often embedded in pipelines, shared across systems, or left active after the originating workload changes. NHI Management Group’s research on The 2025 State of NHIs and Secrets in Cybersecurity shows that 91% of former employee tokens remain active after offboarding, which is a strong signal of how quickly lifecycle controls break down when approval history is treated as the whole story.

Security teams also miss audit impact: a ticket proves someone asked for access, but not that access was removed, rotated, or revalidated later. Current guidance from OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward continuous control, not one-time approval. In practice, many security teams encounter excessive access only after an account is reused, never recertified, and still trusted long after the original request has been forgotten.

How It Works in Practice

Lifecycle governance closes the gap between request, approval, use, review, and removal. For NHIs, that means every access grant should be tied to an owner, a purpose, a system scope, a time limit, and a revocation path. Access-request tooling can capture the decision, but lifecycle governance must enforce what happens next. The practical model is to connect the workflow system to identity provisioning, secret issuance, secret rotation, entitlement review, and deprovisioning so the identity state changes when the business state changes.

That usually includes three operational controls:

• Short-lived credentials for temporary access instead of static secrets that persist indefinitely.
• Automated expiration or rotation when the request window closes, the workload changes, or ownership changes.
• Periodic recertification that checks whether access is still required, not just whether it was once approved.

The NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce the same point: governance fails when teams stop at approval and never bind the approval to revocation. On the implementation side, this is where policy-as-code, secret managers, and identity governance systems should share state rather than operate as separate records. The ticket should point to the control, but the control should own the lifecycle.

Where this breaks down is in environments with shared service accounts, manually managed API keys, or legacy applications that cannot accept automated expiry or rotation because the application owner has no clean revocation mechanism.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance auditability against application compatibility and release speed. That tradeoff is real, especially when legacy systems, vendor integrations, or break-glass accounts cannot tolerate frequent reauthorization.

One common edge case is an approval workflow that exists for compliance evidence but is disconnected from the actual secret or entitlement. In that design, the access request becomes a paper trail while the credential lifecycle is managed somewhere else, or not managed at all. Another issue is delegated admin access, where a human approver signs off on access for a workload they do not own technically, leaving no effective control over rotation or removal.

Best practice is evolving, but current guidance suggests that lifecycle controls should be ownership-based, time-bound, and testable. The most reliable pattern is to require a named business or technical owner, an expiry date, and an automated check that verifies removal or renewal before the entitlement can remain active. NHI Management Group’s Guide to the Secret Sprawl Challenge is especially relevant here because unmanaged duplicates and forgotten copies often defeat otherwise solid request workflows. In practice, the problem is rarely the request itself; it is the orphaned access that survives after the request record is closed.

Related resources from NHI Mgmt Group

• What breaks when credential vaulting is used without lifecycle governance?
• What breaks when compliance automation does not have access governance behind it?
• How should organisations evaluate IGA software for access governance?
• What breaks when SSH keys are used as standing privileged access in trading environments?