TL;DR: Password managers reduce storage risk, but enterprise exposure still grows when credentials are reused, auto-filled on phishing sites, or used from unmanaged devices, according to Island and cited breach research. The governance gap is not the vault; it is the lack of runtime control over where, when, and under what conditions credentials are actually used.
At a glance
What this is: Island argues that password governance breaks down when control ends at login and does not follow credentials through the live session.
Why it matters: IAM and PAM teams need runtime credential governance because storage controls alone do not stop credential reuse, phishing-site autofill, or unmanaged-device access.
Context
Password governance is the set of controls that determines not only where credentials are stored, but where they can be used, on what device, and under which policy conditions. The failure in many enterprises is that vault security and login security are treated as the same problem when they are not.
Island's article focuses on the gap between credential storage and credential use. That matters for identity programmes because passwords, shared accounts, and autofill behaviour become governance issues only when the live session, device posture, and target domain are part of the control plane.
Key questions
Q: What breaks when password governance stops at the vault?
A: Governance breaks when the organisation can secure stored credentials but cannot control where, when, or on what device they are used. That gap leaves reuse, phishing-site autofill, and unmanaged-device sign-ins outside policy, so login becomes the point of exposure rather than the point of control.
Q: Why does password reuse still create enterprise risk after a breach?
A: Password reuse turns a single exposed secret into a multi-system access problem. If users reuse the same password across services, attackers can attempt credential stuffing against enterprise accounts long after the original breach. Breach-aware password screening reduces that risk by refusing secrets that already circulate in the wild.
Q: How can organisations tell whether password governance is working?
A: They should measure ticket reduction, reset completion time, audit trail quality, and whether emergency recovery works across all connected identity systems. A good programme shortens recovery without creating uncontrolled privilege, inconsistent policy enforcement, or gaps in post-incident review.
Q: What is the difference between vault security and session-level password control?
A: Vault security protects the stored secret. Session-level password control governs the live act of using that secret, including whether it may be revealed, autofilled, copied, or shared under current enterprise conditions.
Technical breakdown
Why vault security is not enough for password governance
A password vault protects the stored secret, but it does not automatically govern the session in which that secret is consumed. Once a password is injected, the enterprise needs controls for device posture, trusted domain validation, runtime integrity, and audit context. Without those controls, the same credential can be reused across personal and business accounts, copied into unmanaged flows, or applied on a look-alike phishing page before any downstream detection can react.
Practical implication: treat password use as a live access event, not just a storage event.
How runtime controls change credential risk
Runtime credential controls extend governance into the browser or app session so the organisation can decide whether the credential may be revealed, autofilled, copied, or shared. That shifts enforcement from a static vault policy to an identity-and-device policy that can respond to posture checks, session integrity, domain verification, and MFA state. The important distinction is that the control now binds the secret to the environment in which it is used, which is where enterprise risk actually materialises.
Practical implication: bind credential release to device, domain, and session policy before the password is exposed.
Why shared accounts need revocable, auditable access
Shared accounts are difficult to govern because the real password often becomes the weakest link in offboarding, collaboration, and accountability. A governed sharing model can hide the underlying password, keep the account usable only within an approved runtime, and preserve revocation and auditability. That design matters because the governance problem is not collaboration itself, but whether shared access can be withdrawn cleanly without leaving the credential reusable outside policy.
Practical implication: move shared access away from plaintext password exchange and into revocable session governance.
Threat narrative
Attacker objective: The attacker wants quiet, legitimate-looking access that can be sustained through reused or misused credentials.
- Entry occurs when a user or contractor supplies reused credentials, accepts autofill on a spoofed login page, or signs in from an unmanaged endpoint.
- Credential access then persists because the password is usable outside the original vault context and may be exposed through copy, reuse, or uncontrolled browser behaviour.
- Escalation follows when legitimate logins give attackers or unauthorized users quiet access that can be reused across applications and sessions.
- Impact is prolonged unauthorized access, weaker auditability, and a wider breach path because the organisation governed storage but not actual credential use.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Session-level governance is the real boundary for password security. Vault protection reduces theft risk, but it does not answer the enterprise question of where a credential may be used. Once credentials can be autofilled, reused, or shared outside a governed runtime, the control plane has already shifted past the vault. The practitioner conclusion is simple: identity governance must follow the credential into the live session.
Browser-native credential enforcement is a governance model, not a convenience feature. The article shows why policies tied to device posture, trusted domains, and runtime integrity matter more than vault encryption alone. That does not replace password management, but it redefines the control surface around the browser session where most credential abuse now happens. The practitioner conclusion is to manage password use as part of access governance.
Shared credentials expose the weakness of login-only controls. Shared accounts remain difficult because offboarding, audit, and revocation are all weaker when the password itself is exposed to users. A governed sharing model changes the failure mode by keeping the secret inside an approved runtime and making access revocable and auditable. The practitioner conclusion is that collaboration controls must be built around controlled use, not password disclosure.
Credential reuse is a policy failure before it is an incident. Reuse across business and personal accounts, contractor logins from unmanaged devices, and autofill on phishing pages all show the same pattern: the enterprise allowed a secret to travel beyond its intended boundary. That makes password governance a lifecycle and runtime problem, not just a storage problem. The practitioner conclusion is to treat credential use as governed access, not a user convenience event.
From our research library:
- The average user manages 70 to 100 passwords, many of them outside centralised identity platforms.
What this signals
Password governance now depends on the live session. The practical boundary for enterprise control is no longer the vault, but the browser or app session where the password is consumed. That means identity teams need to think about device posture, trusted domain checks, and session integrity as part of credential governance rather than as separate security concerns.
Credential use must be bound to policy at runtime. When a password can be autofilled on a spoofed site or used from an unmanaged laptop, the organisation has lost control before the security team can observe the event. The programme implication is that password governance has to be enforced at the moment of release, not retrofitted after login.
Passwords remain a governance problem because reuse and sharing defeat static controls. The article's central lesson is that convenience-oriented password tooling does not eliminate enterprise risk when users, contractors, and shared accounts move credentials across boundaries. IAM and PAM teams should treat controlled credential use as a policy domain in its own right.
For practitioners
- Define runtime credential policy Set explicit conditions for when passwords may be revealed, autofilled, copied, or shared, and tie those conditions to device posture, trusted domains, and session integrity.
- Block unmanaged-device credential use Prevent password release when endpoint posture does not meet policy, including missing EDR, untrusted network conditions, or unmanaged personal devices.
- Separate shared access from password disclosure Use governed sharing or tokenised access so shared accounts remain revocable and auditable without exposing plaintext credentials to end users.
- Instrument credential-use telemetry Track which user, device, session, and policy context surrounded each credential use so security teams can investigate password reuse and abnormal login conditions.
Key takeaways
- Password managers reduce storage risk, but they do not on their own govern where a credential is used or who can use it.
- The article frames password reuse, phishing-site autofill, and unmanaged-device access as session-level governance failures rather than vault failures.
- Enterprise teams need runtime controls for device posture, trusted domains, and auditable sharing if they want password governance to match how work actually happens.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 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-07 — Long-Lived Secrets | The article shows why passwords that outlive their intended context remain governable only at the vault if not controlled at use. |
| NHI-10 — Human Use of NHI | The article centres on humans using credentials across browsers, devices, and shared contexts. | |
| Recommendation — Reduce long-lived password exposure by binding credential release to live policy conditions. Limit human handling of credentials by enforcing governed autofill, sharing, and use conditions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password lifecycle, reuse, and release controls map directly to authenticator management. |
| Recommendation — Apply authenticator management controls to govern password issuance, use, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is about whether access permissions and credential use are enforced at runtime. |
| Recommendation — Align credential use with entitlement checks and runtime authorisation policy. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat narrative centres on credential misuse and reuse as the enabling access pattern. |
| Recommendation — Map exposed password-use paths to credential access techniques and monitor for reuse-driven entry. | ||
Key terms
- Session-level password governance: Controls that govern not only where a password is stored, but where and under what conditions it may be used. In practice, this means binding credential release to device posture, trusted domains, session integrity, and audit context rather than treating login as the end of governance.
- Protected Sharing: Protected sharing lets multiple users access a credential without exposing the secret in plain text. It reduces leakage risk by preserving audit trails and limiting who can see or export the underlying password, which is especially important for shared accounts and operational teams.
- Runtime Credential Governance: Runtime credential governance is the practice of controlling secrets at the moment an identity uses them, rather than only when they are created or stored. For AI agents and other NHIs, this means retrieval, scope, and revocation are enforced during execution, when misuse actually occurs.
- Credential reuse risk: The security exposure created when the same password is used across multiple accounts or services. Once reused, a single leak, phishing event, or endpoint compromise can unlock several access paths, making login activity look legitimate while broadening the blast radius of one stolen secret.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org