TL;DR: Password storage alone does not solve enterprise identity risk; lifecycle, revocation, and auditability do. Password Manager 2.0 extends workforce passwords into the same governance model used for secrets, keys, certificates, and privileged access, with SSO, RBAC, ABAC, audit, rotation, and zero-knowledge controls built in, according to Akeyless.
At a glance
What this is: This is an analysis of Akeyless Password Manager 2.0, which treats workforce passwords as part of a broader identity security platform rather than a consumer-style vault.
Why it matters: It matters because IAM teams have to govern passwords, secrets, and privileged access under one policy model if they want consistent audit, revocation, and lifecycle control across human and non-human identities.
👉 Read Akeyless's announcement on Password Manager 2.0 and enterprise governance
Context
Enterprise password management fails when it is treated as a standalone convenience layer instead of an identity control point. Once passwords, passkeys, rotated secrets, and privileged access sit in the same operational path, the governance question becomes who can access what, how that access is authenticated, and how fast it can be revoked across human and non-human identity programmes.
Akeyless is positioning Password Manager 2.0 as part of a wider identity security platform that already spans secrets, certificates, and privileged access. That matters because the boundary between workforce credentials and machine credentials is increasingly artificial in real environments, especially where auditors expect one policy model, one audit trail, and one revocation process.
Key questions
Q: How should security teams govern workforce password managers alongside secrets management?
A: They should treat both as part of one identity control plane. That means the same IdP, access policy, audit trail, and revocation logic should govern workforce passwords, rotated secrets, and privileged access. If the password manager cannot inherit enterprise controls, it becomes an exception that weakens the rest of the programme.
Q: Why do rotated credentials matter if passwords are already stored securely?
A: Secure storage protects the vault, but rotation limits the value of any credential if it is exposed later. Static passwords remain reusable until manually changed, which gives attackers and auditors a long-lived object to worry about. Rotation turns the credential into a managed lifecycle event instead of a permanent liability.
Q: What should enterprises look for in item-level audit controls?
A: They should look for logs that record who read, shared, updated, rotated, or deleted a specific secret, plus where those events can be exported for review. Vault-level logging is too coarse when auditors need evidence tied to a single account or credential. Item-level audit also supports faster incident investigation.
Q: Who is accountable when a password manager is used to store privileged access credentials?
A: Accountability stays with the organisation that owns the access policy and approves the credential lifecycle. The vendor may host or orchestrate the system, but it does not own the business decision about access scope, revocation timing, or audit retention. That responsibility sits with IAM, security, and control owners.
How it works in practice
How enterprise password managers differ from consumer vaults
Consumer-style password managers focus on storage and autofill, while enterprise-grade controls have to govern identity, policy, and recovery. In this model, the password store is only one object in a broader access system that includes authentication through the IdP, role-based sharing, attribute-based restrictions, and tamper-evident logging. The architectural difference is that the vault becomes part of the control plane rather than a user-side convenience layer. That is why items can be rotated, revoked, audited, and scoped by folder or item path instead of merely shared.
Practical implication: treat password managers as governance systems and require IdP integration, item-level audit, and revocation controls before rollout.
Why rotation and dynamic secrets change the risk model
Rotation replaces static credential persistence with a controlled lifecycle. A rotated secret changes on schedule or on demand while the downstream system is updated automatically, and a dynamic secret expires after a short session window. That design reduces the value of leaked credentials because the secret does not remain valid long enough to support prolonged abuse. It also collapses standing privilege, which is especially important when workforce and machine credentials live in adjacent operational workflows. The key point is that the secret is no longer an object that exists indefinitely outside its intended use window.
Practical implication: separate long-lived human passwords from time-limited operational credentials and enforce rotation for anything with production reach.
Zero-knowledge architecture and distributed fragments cryptography
Zero-knowledge here is not a policy promise, it is a cryptographic property. The platform claims the key is never assembled in one place, because fragments are generated and used as a distributed computation across locations, including the customer environment. That means the service can orchestrate access without holding plaintext or a complete key. For identity teams, the important distinction is between a vendor-managed vault and a design where the vendor is structurally unable to read what it stores. This changes the risk conversation for residency, compulsion, and delegated administration.
Practical implication: validate whether the architecture prevents plaintext reconstruction, not just whether the vendor says it will not access data.
NHI Mgmt Group analysis
Workforce password management now sits inside the same governance problem as secrets and privileged access. Once an organisation can store passwords, rotated secrets, passkeys, and remote access in one platform, the control question is no longer vaulting alone. The real issue is whether authentication, sharing, audit, and lifecycle rules are consistent across human and non-human use cases. That is a NIST CSF and OWASP-NHI governance problem, not a UI preference. Practitioners should evaluate consolidation through control consistency, not convenience.
Rotation without policy cohesion only reduces one kind of exposure. A rotated password helps, but it does not solve entitlement sprawl, poor offboarding, or unclear ownership. The same failure mode appears in human IAM and NHI programmes: a credential can be technically protected while still being operationally overexposed. This is why auditability at the item level matters more than vault-level reporting. Practitioners should assess whether the platform can prove who had access, when it changed, and whether revocation was actually enforced.
Zero-knowledge changes the assurance model from trust to structure. The strongest claim in this architecture is not feature breadth, it is that plaintext is never supposed to exist where the vendor can assemble it. That shifts due diligence away from policy statements and toward cryptographic design, deployment boundaries, and customer-controlled fragments. For regulated environments, that structural limitation is often more relevant than a marketing promise about confidentiality. Practitioners should test where the trust boundary actually sits before accepting a SaaS vault model.
Identity convergence is becoming the category signal, not the exception. The platform model described here reflects where the market is heading: passwords, secrets, certificates, and privileged access under one governance layer. That consolidation can simplify operations, but it also raises the bar for migration planning, access modeling, and rollback. Teams that still manage these domains separately will struggle to keep audit evidence coherent. Practitioners should re-evaluate fragmented identity tooling before operational debt turns into control failure.
Ephemeral credential trust debt: the core problem is not storing credentials securely, but reducing the lifetime and blast radius of anything that can still be reused. That concept applies equally to workforce passwords and machine credentials, because both become liabilities once they outlive the task or user they were created for. Practitioners should design for short-lived access patterns and prove that revocation is immediate enough to matter.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which is why governance models that mix storage, sharing, and access need stronger control boundaries.
- For a broader control baseline, review OWASP Non-Human Identity Top 10 alongside the governance patterns described here.
What this signals
Ephemeral credential trust debt: organisations that keep passwords, secrets, and privileged access in separate tools will keep paying the same governance tax in different places. The operational lesson is that revocation, rotation, and item-level audit need to be designed as one workflow, not stitched together after the fact.
The platform pattern described here is a strong signal that identity teams will be asked to justify tool sprawl more aggressively. If a password manager cannot inherit policy, logging, and lifecycle controls from the rest of the IAM stack, it will be harder to defend in regulated environments and harder to operationalise at scale.
For practitioners
- Map workforce passwords into the same identity policy model as secrets Require the password manager to inherit IdP authentication, RBAC or ABAC rules, audit export, and revocation processes already used for privileged access and secrets.
- Separate static credentials from short-lived operational access Use rotated passwords for user-facing accounts and dynamic credentials for high-risk systems where standing access should not persist between sessions.
- Verify item-level audit before approving enterprise rollout Check that read, write, share, and rotate events are logged per item, not only at the vault level, and that logs can flow to the SIEM you already use.
- Test zero-knowledge claims against your deployment boundary Confirm where plaintext can appear, which component holds customer-controlled fragments, and whether the vendor can complete cryptographic operations without reconstructing keys.
Key takeaways
- Enterprise password management is no longer just about storing secrets, because governance, audit, and revocation now define the control value.
- Rotation, dynamic access, and item-level logging are the controls that turn a vault into an identity system rather than a convenience layer.
- Teams should test whether the architecture can prove structural confidentiality, not just whether the vendor promises to respect it.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and lifecycle controls are central to the password and secret model described here. |
| NIST CSF 2.0 | PR.AC-4 | IdP-backed access and item-level sharing align directly with access control governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero-knowledge and least-privilege access boundaries map to continuous authorization principles. |
Map workforce passwords and secrets to NHI-03 and verify rotation and revocation are enforced consistently.
Key terms
- Item-Level Audit: Item-level audit records actions against a specific secret, password, or credential rather than only logging activity at the vault or system level. This gives security teams evidence for access review, incident response, and compliance because the record ties a discrete identity action to a discrete object.
- Dynamic Secret: A dynamic secret is a short-lived credential created for a specific session or task and discarded when it is no longer needed. Unlike a static password, it reduces standing access and narrows the time available for abuse, which makes it a strong fit for high-risk systems and privileged operations.
- Zero-Knowledge Architecture: Zero-knowledge architecture is a design in which the service provider cannot reconstruct plaintext credentials or keys from what it stores or orchestrates. The assurance comes from cryptographic structure, not policy alone, so the customer must understand where fragments live and whether the provider can ever assemble them.
What's in the full announcement
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Browser extension rollout details across Chrome, Edge, Firefox, and Safari for enterprise deployment planning
- Native mobile parity for iOS and Android, including how the user experience is configured in practice
- Distributed Fragments Cryptography implementation specifics, including how customer-held fragments support zero-knowledge operation
- Migration workflow details for importing from incumbent password managers and synchronising during cutover
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme maturity, it is worth exploring.
Published by the NHIMG editorial team on 2026-05-05.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org