Managed, Vaulted, And Unmanaged Accounts

What the classification means

Managed, vaulted, and unmanaged accounts describe different privilege control states, not different identity types. The classification tells teams whether an account is actively governed, only partly contained, or outside the control boundary entirely. That makes it a practical way to compare control coverage, ownership, and exposure across privileged estates.

A managed account is under routine platform control, so access, rotation, and review can be enforced consistently. A vaulted account may be stored in a protected repository but still depends on weaker operating assumptions, especially if rotation is incomplete or usage is not tightly governed. An unmanaged account is the most exposed because it sits outside the remediation and oversight process.

Why the distinction matters

The value of the label is operational: it lets security teams separate accounts that are governed by policy from those that only appear to be controlled. That distinction matters because remediation priorities are usually driven by the least controlled accounts first, especially where privileged access, shared credentials, or service accounts are involved.

The classification also helps explain why two environments with similar account counts can have very different risk profiles. A small number of unmanaged accounts can create more exposure than a larger set of managed ones, because the unmanaged set is where rotation gaps, stale access, and hidden dependencies tend to accumulate.

For the underlying security problem, the issue is often not the account itself but the control state around it. That is why inventory quality, ownership clarity, and enforcement consistency matter as much as the existence of a vault or a platform.

How teams measure governance coverage

To use the model well, teams need a repeatable way to classify accounts from the actual control evidence, not from intent. An account should be treated as managed only when the control plane can demonstrably administer it, not merely when it is documented as such. Vaulted status should also be tested carefully, because storage alone does not prove rotation, policy enforcement, or reduced exposure.

This is where account inventory and exception handling become important. If an organisation cannot identify where privileged accounts live, who owns them, and what mechanism controls them, it cannot reliably say how much of the estate is managed versus vaulted versus unmanaged.

Good governance uses the classification as a coverage metric. It shows how much of the account estate is inside enforced lifecycle control, how much remains partially contained, and where remediation work still needs to move accounts into the governed boundary.

What good control states look like in practice

Managed accounts should have a clear owner, enforced lifecycle handling, and a control path that can rotate, disable, or review access without manual workarounds. Vaulted accounts should be treated as transitional or constrained, not as a finished state, because protected storage without full lifecycle control can leave residual risk.

Unmanaged accounts should be treated as a remediation queue, not as a stable category. In practice, they usually indicate a gap in discovery, migration, or exception management. The security goal is to reduce the unmanaged population over time and convert vaulted accounts into genuinely managed ones wherever possible.

Used this way, the classification becomes a decision aid for privileged access governance, helping teams prioritise the accounts most likely to carry hidden access, incomplete rotation, or weak accountability.

Risk and Threat Considerations

Unmanaged and only partially governed accounts create a predictable security gap because they are harder to rotate, review, and revoke reliably. That makes them attractive to attackers and dangerous to defenders, especially when the accounts have elevated access or long-lived credentials.

Failure mechanism: Control-state drift lets privileged credentials persist outside normal governance, so stale access, shared use, or missed rotation can survive long after the account should have been remediated.

Impact: The result can be unauthorized access, persistence, lateral movement, or privilege abuse, particularly when an unmanaged account is tied to a high-value system or administrative workflow.

Practitioner Guidance

Why practitioners should care: Treat the three states as a governance ladder, not as labels of convenience. The classification is most useful when it drives remediation priority, ownership assignment, and progress measurement across the privileged account estate.

Governance implication: Define clear criteria for when an account counts as managed, when vaulting is acceptable as an interim state, and what evidence is required before an account can be considered under control. Without those rules, teams often overstate coverage and undercount exposure.

Practitioner takeaway: If an account cannot be demonstrated as managed by evidence, assume it still belongs in the remediation backlog.

Related resources from NHI Mgmt Group

• What is the difference between managed IdP accounts and unmanaged social IdPs for access governance?
• Why do local accounts create more IAM risk than centrally managed identities?
• Why do application-local accounts create more NHI risk than centrally managed identities?
• Why do shared service accounts still create risk even when secrets are vaulted?