Why do access reviews miss orphaned service account permissions?

Why orphaned service account permissions slip past access reviews

Access reviews are strongest when reviewers can test each permission against a clear business purpose, owner, and lifecycle state. Orphaned service accounts break that logic. Without inventory, ownership, or documented purpose, reviewers can only see entitlements in isolation, so excessive or outdated access often survives because nobody can confidently challenge it.

That failure is usually structural, not just procedural. A service account can look “valid” because it still exists in a platform, but if it is not tied to a current application, workload, or system, the review has no reliable context for deciding whether the access is still needed.

When access reviews depend on reviewers manually reconstructing context from tickets, code, or tribal knowledge, orphaned accounts are the easiest records to rubber-stamp. The account may have been created for a project that ended, migrated, or changed owners, leaving permissions behind while the original approval trail aged out.

What makes orphaned permissions hard to judge

The core issue is that entitlement review is a judgment problem, not just a list reconciliation problem. If the reviewer cannot answer who owns the account, what it supports, and when it should expire, then the review turns into a guess about intent instead of a decision based on evidence.

Missing lifecycle data also hides the difference between legitimate standing access and forgotten access. A service account without an owner or rotation record may still be necessary, but the absence of documentation means the reviewer cannot safely distinguish active operational dependence from dormant privilege.

At scale, this becomes a visibility problem across platforms. In environments with many apps, pipelines, databases, and cloud workloads, orphaned permissions tend to accumulate where account creation is easy but lifecycle governance is weak, especially when teams provision access faster than they retire it.

How to reduce missed orphaned service account access

Strong reviews start before the attestation campaign. The most effective control is a maintained inventory that records owner, purpose, expiry, and dependency for each service account, so the reviewer can validate necessity instead of reverse-engineering it during the review window. NHIMG’s NHI Ownership and Accountability Guide is useful here because it focuses on assigning ownership and handling ownerless identities, which is the exact gap that makes orphaned permissions hard to assess.

Review workflows should also force exceptions when context is missing. If the account has no owner, no current purpose, or no expiry, the safe default is to treat it as a cleanup candidate, not as approved standing access. That is especially important when the permission set is broad, privileged, or tied to production systems.

Good programs do not rely on review outcomes alone. They pair reviews with offboarding, rotation, and decommissioning processes so that orphaned access is removed when the workload ends, not rediscovered months later in another certification cycle. NHIMG’s NHI Offboarding and Decommissioning Guide is directly relevant because it covers safe retirement steps for machine identities and revocation of associated credentials.

For organisations that want the review to remove access rather than merely record it, the review process itself should be attestation-driven and event-driven. NHIMG’s NHI Ownership Attestation Campaigns Guide is helpful because it ties owner confirmation to usage evidence and non-response handling, which are both critical when the account otherwise looks ownerless.

Practitioner Guidance

What to verify: Before trusting a completed review, confirm that every service account has an owner, an application or workload dependency, and a retirement trigger. If any of those fields are missing, the review result should be treated as incomplete even if the permission was marked approved.

Decision rule: If a service account cannot be linked to a living system and a named owner, prioritise removal or time-bounded exception handling over preservation of access. That is the point where the risk is no longer about review quality alone, but about ungoverned standing privilege.

What practitioners underestimate: Orphaned permissions often persist because the review owner assumes someone else still knows the context. In practice, the absence of context is itself the control failure, and the longer it persists, the more likely the account will drift from “unknown but harmless” to “unknown and privileged.”

Practitioner takeaway: Access reviews miss orphaned service account permissions when governance data is incomplete, so the fix is to make ownership and lifecycle evidence a prerequisite for approval, not a nice-to-have attachment.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• When does a service account become a compliance problem?
• Why do role-based access reviews miss the most dangerous permissions?