Centralised account management means IT controls permissions, security settings, and lifecycle processes through a common governance model. Unmanaged accounts sit outside that control, which makes it harder to enforce policy, review access, and support users consistently. In practice, unmanaged accounts increase the chance of shadow IT, weaker oversight, and fragmented identity administration across the organisation.
Centralised account management and unmanaged user accounts differ mainly in control, visibility, and lifecycle ownership. Centralised models give the organisation one place to set access rules, review accounts, and remove access when roles change. Unmanaged accounts bypass that process, so policy enforcement becomes inconsistent and account sprawl is harder to detect.
A centralised approach is not just an administrative preference, it changes how permissions are assigned and verified. With shared governance, teams can apply consistent standards for onboarding, offboarding, approval, and periodic review. Unmanaged accounts often develop through local exceptions, shadow IT, or one-off access grants, which creates fragmented identity administration and makes it easier for stale or excessive access to persist.
The practical difference also shows up in operational support and auditability. Centralised account management usually gives IT or security a reliable inventory of who has access to what, which systems are covered, and which controls apply. Unmanaged accounts weaken that picture, so troubleshooting, access certification, and incident response all take longer because the organisation has to reconstruct ownership and usage after the fact.
Why Centralised Governance Produces Safer Account Control
Centralised account management works because it ties access decisions to a common process rather than leaving them to individual teams or ad hoc administrators. That makes it easier to enforce least privilege, keep account changes traceable, and apply the same rules for approval, review, and removal across the environment. It also reduces the chance that a critical account outlives the need for it.
Unmanaged accounts are the opposite pattern: they may still function, but they sit outside the normal governance model. That creates hidden variance in permissions, password handling, logging, and ownership. Even when the initial use case is legitimate, the account can become an oversight gap if nobody is formally responsible for reviewing whether it is still needed or whether its access has drifted over time.
For organisations trying to standardise identity operations, the useful question is not whether every account must be identical, but whether every account is governed. The more exceptions you allow, the more your identity model depends on tribal knowledge instead of enforceable policy. A good central model makes exceptions visible, documented, and time-bounded rather than permanent by default.
What Unmanaged Accounts Change in Practice
Unmanaged accounts create risk because they break the normal lifecycle: provision, review, change, and deprovision. If an account is created outside central control, its permissions may never be recertified, its owner may not be clear, and its removal may depend on informal follow-up. That is how stale access, duplicate accounts, and inconsistent naming or entitlement practices accumulate.
They also make accountability harder. If a user can access a system through a locally created account, it is more difficult to prove who approved it, whether the permissions were appropriate, and whether the account was still in use after the person changed role or left. In a real incident, that ambiguity slows containment because responders must first determine whether the account was legitimate, dormant, or abused.
Unmanaged accounts can be especially problematic when they accumulate across departments or business units that each believe they are handling access “just for local efficiency.” In practice, that often means access is faster to create than to remove. The result is not only weaker governance, but a broader attack surface because more accounts remain valid for longer than the business actually requires.
How to Judge the Difference in an Audit or Access Review
The clearest test is ownership. A centrally managed account should have a defined owner, a standard approval path, and a repeatable review or offboarding process. If the account cannot be traced back to a control owner or cannot be reviewed through the normal identity process, it is effectively unmanaged even if someone still uses it.
Another useful test is coverage. If a team can create accounts, change permissions, or keep dormant access alive without going through the central process, then the governance model has a gap. That gap may be intentional for a narrow technical reason, but it should still be documented as an exception with a review date and a named owner.
From a control perspective, unmanaged accounts matter less because they exist and more because they are invisible to the mechanisms that keep access current. A mature review should therefore look for accounts that are outside the authoritative identity source, outside normal joiner-mover-leaver handling, or outside standard certification. Those are the places where access drift usually starts.
Risk and Threat Considerations
Unmanaged accounts increase exposure because stale, excessive, or undocumented access is easier to miss and harder to revoke. They also make it easier for shadow IT, insider misuse, or compromised credentials to persist without timely detection, especially where no central owner can validate whether the account should still exist.
Failure mechanism: When account creation, review, and removal happen outside the governing process, permissions drift and orphaned access accumulate. That weakens access control, audit logging, and offboarding, so the organisation loses both prevention and visibility.
Impact: The likely outcome is broader privilege exposure, slower incident response, and weaker assurance that access is still aligned to business need. In regulated or high-trust environments, unmanaged accounts can also create findings because the organisation cannot demonstrate consistent control over who can access sensitive systems.
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 | Centralised vs unmanaged accounts is an account management control issue. |
| Recommendation — Standardise account creation, review, and removal under one governed process. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question turns on governed account lifecycle and oversight versus unmanaged access. |
| AC-6 — Least Privilege | Unmanaged accounts commonly drift into excessive access beyond need-to-know. | |
| Recommendation — Require centralized account administration with defined approval, review, and deprovisioning. Limit each account to the minimum permissions needed for its approved role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Central governance versus unmanaged access is fundamentally an access control issue. |
| A.5.16 — Identity management | The topic depends on having authoritative ownership of account identities. | |
| Recommendation — Define and enforce access rules through a controlled identity process. Maintain a single source of truth for account identity ownership and lifecycle. | ||
Practitioner Guidance
What to prioritise: Treat “unmanaged” as a governance exception, not just an operational inconvenience. The first question is whether the account is outside the authoritative identity process, because that determines whether the issue is a review problem, a lifecycle problem, or a control failure.
What to verify: Confirm that every active account has a named owner, an approved purpose, and a removal path tied to offboarding or role change. If a local team cannot produce that evidence quickly, the account should be treated as a higher-risk exception until it is brought under control.
Practitioner takeaway: Centralised account management is valuable because it makes access governable; unmanaged accounts are dangerous because they make access discoverable only after something goes wrong.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between managing human accounts and non-human identities?
- What is the difference between service account lifecycle management and user account lifecycle management?
- What is the difference between database user auto-provisioning and manual database account management?