Choosing and deploying an enterprise password manager
Selection criteria, architecture, rollout, and the governance that turns a vault from a personal convenience into a managed control, including secrets for machines, not just people.
What to implement
Select a zero-knowledge, end-to-end-encrypted vault with SSO, SCIM provisioning, and admin recovery; enforce MFA on the vault; roll out in waves with real training; and pair the human vault with a proper secrets manager for application and machine credentials. Governance (recovery, offboarding, sharing policy) is what makes it a control rather than shadow IT.
A password manager is the practical mechanism that makes unique, high-entropy passwords possible at scale. Deployed well, it also becomes a source of truth for who can access what, and a way to kill shared-credential sprawl. Deployed badly, it's another silo people route around.
Selection criteria
- Zero-knowledge, end-to-end encryption: the vendor cannot read vault contents; encryption/decryption happens on the client.
- Modern KDF (e.g. Argon2) protecting the master password, and published security architecture / third-party audits.
- SSO integration and SCIM provisioning so accounts follow joiner-mover-leaver automatically.
- Admin-controlled account recovery: a way to restore access for a user who forgets their master password without the vendor holding a backdoor.
- Secure sharing with granular permissions and shared team vaults; per-item access, not all-or-nothing.
- Cross-platform clients and browser extensions with reliable, origin-checked autofill.
- Audit logging and reporting (weak/reused/breached password reports, sharing visibility).
Separate the human vault from the machine secrets store
A password manager is for humans. Application credentials, API keys, database passwords, and CI/CD secrets belong in a dedicated secrets manager (e.g. HashiCorp Vault, cloud KMS/secret stores) with programmatic access, short-lived leases, and rotation. Do not paste production secrets into a human password manager, and do not force humans to use raw secret stores.
Deployment
- Provision via SSO + SCIM so vault access is created and revoked with the identity lifecycle.
- Enforce MFA on the vault itself: ideally phishing-resistant, because it is now a high-value target.
- Configure recovery before go-live and test it: the recovery model is the first thing to validate.
- Migrate existing credentials in waves; use the tool's import and its reused/weak-password report to drive cleanup.
- Train users on master-password creation (a strong unique passphrase), autofill-based phishing resistance, and secure sharing instead of chat/email.
Governance that keeps it a control
- Define a sharing policy: what may be shared, via team vaults only, never via external channels.
- Handle offboarding: revoke vault access at termination and reclaim/rotate any shared credentials the leaver could see.
- Review breach and reuse reports on a cadence and drive remediation.
- Eliminate shared logins where possible in favor of individual accounts + SSO; where a shared credential is unavoidable, keep it in a shared vault with logging.
Evidence and health checks
Track adoption (active users vs licensed), MFA-on-vault coverage, count of reused/breached passwords still outstanding, shared-credential inventory with rotation dates, and confirmation that leavers lost vault access within the offboarding SLA. Verify recovery works by running a scheduled test.