Because an organisation can know who has an account without knowing what that account can do. Account management covers lifecycle and existence, while access control covers privilege scope, which is where lateral movement risk usually grows. Treating them separately helps teams find orphaned authority that inventory alone will miss.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle governance depends on inventory and removal of unused identities. |
| Recommendation — Maintain a current account inventory and remove inactive or unauthorized accounts promptly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Separating accounts from access requires independent control of credential and authenticator lifecycle. |
| AC-2 — Account Management | This question is about governing account existence and lifecycle as a distinct control function. | |
| AC-6 — Least Privilege | Access control governance is about limiting what an active account can do. | |
| Recommendation — Rotate, revoke, and track authenticators separately from account status. Define account creation, review, disablement, and removal as a formal lifecycle process. Limit each account to the minimum permissions required for the business task. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity lifecycle governance requires separate treatment of identity existence and access rights. |
| A.5.18 — Access rights | Access rights need their own review and control because they can outlive account status. | |
| Recommendation — Assign ownership and lifecycle rules for each identity and its permissions. Review, adjust, and revoke access rights independently from account provisioning. | ||
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?