Why do account management and access control need to be governed separately?

Why account management and access control must be governed separately

Account management answers whether an identity exists, is current, and should still be active. Access control answers what that identity can actually do. If you collapse the two, inventory can look healthy while privilege remains dangerously broad, which is how orphaned authority survives long after the account itself seems accounted for.

The separation matters because lifecycle events and permission decisions fail in different ways. An account can be properly created, reviewed, or disabled and still retain excessive access, inherited roles, delegated permissions, or privileged pathways that outlive the original business need. Those are different governance objects, and they need different controls, owners, and evidence.

That is why identity programmes usually treat provisioning, deprovisioning, and access review as related but distinct processes. IAM and IGA Basics separates authentication, authorization, access reviews, and entitlement management so teams can see whether the issue is account existence, permission scope, or both.

What breaks when account and access governance are merged

When governance is merged, teams tend to optimise for the easiest observable metric, usually account count. That can hide the harder question of whether the account still has standing privilege, cross-environment reach, or access to high-value systems. The result is a false sense of control, because an account inventory is not the same thing as an entitlement inventory.

In practice, the failure mode is simple: deprovisioning does not always remove every pathway, and access reviews do not always confirm whether the account should exist at all. A stale account with minimal rights is still a lifecycle problem, while a fresh account with excessive rights is an authorization problem. If you only govern one side, you leave the other side untouched.

Access models also behave differently depending on the type of access being granted. Authorisation Models Guide shows why role-based, attribute-based, relationship-based, and policy-based control need separate scrutiny when entitlement scope is the real issue.

How separate governance exposes orphaned authority and lateral movement paths

Separate governance is what lets teams find authority that inventory alone will miss. A dormant or orphaned account may still carry group membership, API scopes, delegated admin rights, or machine access that enables lateral movement even if the account is no longer actively used. That is especially important where privilege is inherited indirectly through roles, groups, or nested access paths.

Privileged access needs its own governance because the risk changes materially once an account can administer systems, rotate secrets, approve workflows, or reach sensitive data. Privileged Access Management Guide covers zero standing privilege, just-in-time access, and break-glass patterns that are not captured by basic account lifecycle checks.

For environments with service accounts, automation, or non-human identities, the distinction becomes even sharper. Service Account Security Guide highlights why machine accounts often need separate ownership, rotation, and least-privilege review rather than being lumped into human joiner-mover-leaver processes.

Practitioner Guidance

What to verify: Verify that every account review answers two different questions, “Should this account exist?” and “What can this account do right now?” If one review template tries to answer both, separate the evidence fields for lifecycle status, owner, entitlements, and privileged paths.

Decision rule: If an account is valid but overprivileged, treat it as an access-control failure first. If access is acceptable but the account has no current business owner or purpose, treat it as an account-management failure first. The remediation, approval path, and reporting line should differ.

What good looks like: Good governance shows an authoritative owner for each account, a current business justification, explicit entitlement scope, and a repeatable review cycle for privilege changes. The strongest signal is when orphaned accounts and orphaned permissions are both independently measurable.

Common mistake: Teams often close an offboarding ticket and assume access is gone. In reality, group membership, delegated admin, tokens, shared accounts, and service credentials can survive the account event unless entitlement cleanup is separately controlled.

Practitioner takeaway: Separate governance prevents the most dangerous blind spot in identity operations, a legitimate account that still holds authority no one is actively controlling.

Related resources from NHI Mgmt Group

• Why do account management and access control management matter so much in CIS?
• Should password management and privileged access be governed separately?
• What breaks when API management and identity are governed separately for machine-to-machine access?
• How should security teams run access reviews for non-human identities?