Notifications
Clear all
Topic starter
08/07/2026 6:51 pm
TL;DR: Repeated compromise patterns around Passwordstate show why teams should separate human password storage, machine secrets, and privileged access instead of treating one vault as a universal control, according to Infisical. The governance problem is not just patching a product, but designing the right identity boundary for each credential type.
NHIMG editorial — based on content published by Infisical: Best Passwordstate Alternatives: What to Actually Use Instead
Questions worth separating out
Q: What breaks when one vault is used for human passwords, machine secrets, and privileged access?
A: The access model becomes inconsistent because each credential type has a different lifecycle, review cadence, and blast radius.
Q: Why do self-hosted password managers still create governance risk?
A: Self-hosting moves operational responsibility to the organisation, but it does not remove patching, monitoring, backup, or hardening requirements.
Q: How do teams decide whether a credential belongs in a password manager or a secrets manager?
A: Use the access pattern as the deciding factor.
Practitioner guidance
- Inventory the credential population by identity type Export the vault contents and tag each record as human password, machine secret, or privileged infrastructure access before choosing a replacement path.
- Split replacement decisions by governance problem Use a password manager for human credentials, a secrets manager for API keys and tokens, and PAM for databases, servers, and elevated access.
- Rotate anything stored during the compromise windows Treat the 2021, 2022, and 2024 to 2025 incident periods as exposure windows and rotate any credentials that could have been present then.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step migration guidance for moving credentials out of Passwordstate without losing inventory completeness.
- Tool-by-tool decision criteria for choosing between a password manager, secrets manager, and PAM platform.
- Product-specific implementation detail for Infisical, 1Password, Bitwarden, and cloud-native secrets managers.
- Operational notes on exports, API limits, and rotation sequencing during a live migration.
👉 Read Infisical's guide to replacing Passwordstate with the right credential controls →
Passwordstate alternatives: what should IAM teams replace it with?
Explore further
08/07/2026 7:12 pm
Passwordstate's real failure was category collapse, not a single bug. The article shows what happens when a password vault is stretched across three governance problems at once: human credentials, machine secrets, and privileged access. That mix invites control mismatch, because the access model that works for a person signing in does not govern service credentials or admin sessions cleanly. The practitioner takeaway is to classify the credential before you classify the tool.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: Who should own the risk when privileged access is checked out from a vault?
A: Ownership should sit with the team that governs the infrastructure being accessed, not only with the team that administers the vault. Privileged access introduces session evidence, approval, and expiry requirements that are separate from storage. Governance fails when vault administration is confused with access accountability.
👉 Read our full editorial: Passwordstate alternatives: separate human passwords from machine secrets
