Organisations should move to a password manager as soon as credentials support more than one person, more than one system, or any business-critical process. Once access needs ownership, review, or transfer, informal sharing stops scaling. A vault is the minimum control layer for keeping passwords usable without losing accountability.
Why This Matters for Security Teams
Ad hoc password sharing usually looks harmless until teams need to answer basic questions: who used the credential, when was it last changed, and how quickly can access be revoked. At that point, the issue is no longer convenience but control. A password manager creates a minimum accountability layer for shared access, which aligns with the governance expectations described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the access discipline reflected in the NIST Cybersecurity Framework 2.0.
The practical trigger is not headcount alone. It is shared dependency: multiple operators, recurring use, service continuity, or any password that supports a production process. Once a credential is reused across people or systems, informal sharing makes rotation, offboarding, and incident response slower and less reliable. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 73% of vaults are misconfigured, which means even the move to a vault must be deliberate and governed.
In practice, many security teams discover the weakness only after a contractor leaves, a system fails over, or a password must be changed under pressure rather than through intentional access design.
How It Works in Practice
The move from ad hoc sharing to a password manager should be treated as a control transition, not just a tooling choice. Start by identifying credentials that are shared by more than one person, used by service accounts, tied to business-critical systems, or copied into chat, email, spreadsheets, or tickets. Those are the highest-value candidates because they already lack clear ownership and create friction during recovery, audit, and offboarding.
A password manager or vault works when it adds three things: controlled distribution, traceability, and revocation. Users should access the secret through their own named account, not by copying the value into a group thread. Rotation should be planned, and emergency access should be constrained and logged. For broader NHI governance, this fits the lifecycle model in the NHI Lifecycle Management Guide and the risk patterns in Top 10 NHI Issues.
- Use named user access to the vault, not a shared vault password.
- Separate human access to the manager from machine-to-machine secrets stored inside it.
- Assign an owner for every credential, including review and rotation responsibility.
- Require offboarding steps that remove access to both the vault and the secret.
- Prefer short-lived or rotated secrets where the system can support it.
Current guidance suggests starting with the credentials that are shared most often and the ones that would cause the most disruption if exposed. That is also where controls usually fail if permissions are copied without ownership, because teams inherit a vault but continue running it like a shared spreadsheet.
Common Variations and Edge Cases
Tighter credential control often increases operational overhead, requiring organisations to balance faster collaboration against stronger accountability. That tradeoff is real, especially for small teams, incident response groups, and legacy environments where shared passwords are still embedded in application workflows. Best practice is evolving, but there is no universal standard for this yet: some environments can move straight to a vault, while others need a staged transition with rotation windows and temporary break-glass access.
One common exception is a legacy system that cannot support named accounts or modern rotation. In those cases, a password manager still helps by centralising custody and reducing exposure, but it does not solve the underlying design flaw. Another edge case is third-party access. If vendors require a shared credential, the risk is higher, because revocation becomes a coordination problem rather than an internal control. NHIMG’s regulatory and audit guidance highlights why that matters, especially when credentials support evidence, accountability, or change management.
For organisations trying to justify the change, the strongest case is usually operational resilience rather than abstract policy. If a password cannot be confidently reviewed, transferred, or revoked, ad hoc sharing has already become a liability. The control boundary should be moved before the first incident, not after the first audit finding.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shared passwords need rotation and lifecycle control, which this control addresses. |
| NIST CSF 2.0 | PR.AC-1 | Credential sharing requires controlled access and identity accountability. |
| NIST CSF 2.0 | PR.AA-1 | Password managers support traceable authentication for shared operational access. |
Move shared secrets into a managed vault and enforce ownership, rotation, and revocation on a fixed schedule.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
