Managed, Vaulted, And Unmanaged Accounts

Managed Accounts: What the Classification Means

“Managed” accounts are the most controlled part of the spectrum. They are tied to a privileged access platform or equivalent control plane, so ownership, use, and often rotation are governed centrally rather than left to local administrators or application teams.

This classification matters because it tells you whether an account is inside an enforceable control boundary, where access can be reviewed, mediated, and measured. In practice, managed status is less about the account’s label and more about whether the organisation can actually enforce policy over it.

That distinction is why managed accounts are usually the preferred remediation target when teams are reducing standing privilege, consolidating ownership, or bringing high-value credentials under service account governance.

Vaulted Accounts: Stored, But Not Fully Controlled

Vaulted accounts sit in an intermediate state. Their secrets are stored in a vault, which improves custody and visibility, but the account is not necessarily subject to continuous rotation, policy enforcement, or complete lifecycle governance.

That is why “vaulted” should not be treated as equivalent to “managed.” Vaulting reduces exposure by centralising secret storage, but the account can still carry stale permissions, non-expiring credentials, weak owner discipline, or delayed deprovisioning if the surrounding process is incomplete.

For teams dealing with credential lifecycle, the practical issue is that storage alone does not remove risk. A vaulted account may still need rotation, ownership review, and tighter dependency mapping, especially where automation relies on it for persistent access. NHIMG’s Guide to NHI Rotation Challenges explains why rotation becomes harder as dependencies, exceptions, and long-lived access paths accumulate.

Unmanaged Accounts: Outside the Control Boundary

Unmanaged accounts are the accounts that escape central governance altogether. They may exist because of legacy systems, shadow IT, emergency access, local tooling, or simple inventory gaps, but the common feature is that they are not being administered through the privileged access boundary.

This classification is operationally important because unmanaged accounts are often where ownership ambiguity, excessive privilege, and forgotten access persist. They can remain active long after the business need ends, and they are easy to overlook precisely because they are not visible in the same workflow as managed accounts.

That is why unmanaged accounts are usually the highest-priority remediation class in account governance. They are the places where inventory, ownership, and enforcement are weakest, and where remediation most directly improves control coverage. The broader lifecycle issues are well covered in NHI Lifecycle Management Guide.

How Teams Use the Classification in Practice

The value of the managed, vaulted, and unmanaged split is that it turns a vague account inventory into an actionable control model. Teams can use it to prioritise cleanup, measure how much privilege sits inside the control plane, and identify where governance is only partial.

In mature programmes, the classification also helps distinguish between storage and control. A vaulted account may be a good interim state, but a managed account is the stronger governance outcome because it ties the credential to review, rotation, and ownership. An unmanaged account, by contrast, is evidence that the account is not yet under reliable policy enforcement.

That is also why service-account oversight matters so much in this taxonomy. Many of the riskiest accounts are not human logins at all, but application and integration accounts that outlive their original purpose. Service Account Security Guide is a useful reference when the classification needs to be paired with real governance action.

Risk and Threat Considerations

Misclassification can hide the real exposure. If a vaulted account is assumed to be fully managed, teams may miss stale privileges, unused but still valid access, or secrets that are stored securely but never rotated. Unmanaged accounts create the biggest blind spots because they can be abused without the usual review, monitoring, or decommissioning controls.

Failure mechanism: Attackers and insiders benefit when credentials remain active outside the normal control boundary, especially if ownership is unclear or rotation is inconsistent. The risk is amplified when the same account is reused across systems or retained after the original business purpose has ended.

Impact: Compromise can lead to persistent access, privilege escalation, lateral movement, and delayed detection. In governance terms, unmanaged accounts also weaken auditability because the organisation cannot confidently prove who owns the account, how it is protected, or when it should be revoked.

Practitioner Guidance

Governance implication: Use this classification as an inventory control signal, not a naming exercise. The important question is whether the account is actually under enforceable policy, lifecycle management, and review. If it is not, calling it “vaulted” should never be allowed to substitute for managed status.

What to watch for: Look for credentials that are stored centrally but never rotated, accounts with uncertain ownership, and legacy or integration accounts that never pass through the same review cycle as privileged human access. Those are the cases where the label and the control reality tend to diverge.

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?