TL;DR: Centralized password vaults reduce password sprawl but do not control what happens after authentication, according to Unixi’s analysis of AiTM phishing, SaaS coverage gaps, and session-token theft. The real governance problem is that static secrets and post-login blind spots persist long after the login itself appears secure.
At a glance
What this is: This is an analysis of why password vaults do not solve post-authentication risk, and its key finding is that session compromise, not password guessing, is the real control gap.
Why it matters: It matters because IAM teams need controls that address authentication, session governance, and unmanaged SaaS exposure, not just secret storage and password reuse.
By the numbers:
- In April 2026, Microsoft documented an Adversary-in-the-Middle phishing campaign that targeted over 35,000 users across 13,000 organisations over three days.
- Even a fully deployed password vault typically covers only 15% to 30% of an enterprise’s actual web footprint.
- Somewhere between 50% and 85% of enterprise applications simply don’t support the SAML or OIDC standards that traditional SSO and IdPs rely on.
- Independent research from Keeper Security reveals that 75% of employees admit to violating basic password best practices even when corporate tools exist.
👉 Read Unixi's analysis of password vault limits and post-login risk
Context
Password vaults are often treated as a complete answer to credential management, but they only centralize secrets. The real problem is what happens after the login succeeds, when the browser session, token, or downstream SaaS access is outside the vault’s control.
For IAM teams, that creates a gap between password governance and session governance. If an organisation focuses only on storing secrets more safely, it can still leave unmanaged web apps, token relay attacks, and non-SAML portals outside the identity programme.
The article argues that the better question is not whether passwords are stored centrally, but whether the enterprise can control access after authentication across the full web footprint. That is a typical enterprise condition, not an edge case.
Key questions
Q: How should IAM teams reduce risk when password vaults do not control post-login sessions?
A: Treat the vault as one layer, not the control objective. IAM teams should pair secret management with phishing-resistant authentication, session monitoring, and a separate review of unmanaged SaaS applications. The key question is whether access remains governable after the login succeeds, because that is where AiTM phishing and token theft create the real exposure.
Q: Why do SaaS apps create identity governance gaps?
A: SaaS apps create governance gaps because access often expands through delegated permissions, shadow IT, and untracked app ownership. Once an app is connected, it can retain data access long after the original approval is forgotten. That breaks joiner-mover-leaver assumptions and makes offboarding incomplete unless app ownership and review cadence are explicit.
Q: When should organisations move beyond password vaulting?
A: When the main risk is no longer password theft but session compromise, credential relay, or access sprawl across SaaS applications. Vaulting can reduce secret exposure, but it does not solve the architectural problem of post-authentication governance. Organisations should move beyond vaulting when the access model depends on static secrets that attackers can reuse.
Q: What is the difference between protecting a password and governing a session?
A: Protecting a password means keeping the secret from being exposed or reused easily. Governing a session means controlling what happens after the user authenticates, including token use, browser activity, and downstream application access. That distinction matters because many modern attacks exploit the session outcome, not the password itself.
Technical breakdown
Why static secrets fail after authentication
A password vault protects a secret before login, but it does not govern the session created after the secret is accepted. In AiTM phishing, the attacker positions a proxy between the user and the real service, relays the valid login, and captures the token or session artefact that follows. The password itself may never be stolen directly, which is why secret storage alone cannot stop post-authentication abuse. This is the difference between protecting a credential and governing the authenticated session that credential unlocks.
Practical implication: treat session control and phishing-resistant authentication as separate requirements, not as features covered by vault rollout.
Why unmanaged SaaS breaks SSO assumptions
Traditional IdP and SSO coverage depends on applications supporting federation standards such as SAML or OIDC. The article’s point is that a large share of enterprise web apps do not, which means identity control is uneven across the application estate. When an app cannot be federated cleanly, the organisation falls back to reusable credentials, manual exceptions, or coverage gaps. That creates a fragmented identity plane where governance is strongest in the apps that are easiest to integrate and weakest where users actually spend time.
Practical implication: inventory non-federated applications separately and treat them as a distinct governance population.
Why static credential centralisation creates a high-value target
Centralising reusable secrets improves administration but also concentrates risk. A vault becomes a single place where compromise can expose a large credential estate, and attackers only need one successful path into that store or the processes around it. The article frames this as structural risk, not just implementation risk, because the architecture assumes the secret remains the security boundary. Once adversaries target the login flow, the vault no longer prevents credential relay, session theft, or application-level abuse.
Practical implication: reduce dependence on reusable secrets by shifting high-risk access paths to dynamic or application-specific credentials where possible.
Threat narrative
Attacker objective: The attacker’s objective is to obtain a valid authenticated session that can be reused without needing the password again.
- Entry occurs through adversary-in-the-middle phishing, where a fake login proxy relays the user to the real service and captures the valid authentication flow.
- Credential access succeeds at the session layer, because the attacker receives the token or authenticated session artefact after the login rather than guessing the password.
- Impact follows when the attacker reuses the active session to access unmanaged SaaS applications or bypass the intended protection of the password vault.
Breaches seen in the wild
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
- GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static credential centralisation is not identity governance. The article exposes a common enterprise assumption that putting passwords in a vault meaningfully governs access. That assumption fails because the security boundary moves after login, and the vault has no authority over the authenticated session. Practitioners should treat vaulting as a hygiene control, not as the governance layer for access.
Post-authentication control gap: The real weakness is not password storage, it is the absence of governance over what happens after the login handshake. AiTM phishing succeeds because it attacks the session outcome, not the secret at rest. That means the control model must account for token relay, browser session theft, and unmanaged SaaS use as first-class identity problems.
Federation coverage defines the blast radius of identity control. When only part of the SaaS estate supports SAML or OIDC, identity governance becomes selective rather than universal. The article’s 15% to 30% coverage claim points to a practical truth: most enterprises do not have uniform control over where users authenticate, which means the weakest applications set the real risk ceiling.
Dynamic credentials are a category shift, not a vault feature. Eliminating reusable secrets changes the governance model because the organisation is no longer trying to protect a static credential database. That reduces exposure to secret theft and relay attacks, but it also forces IAM teams to rethink provisioning, application compatibility, and session accountability across the web footprint.
Secret sprawl and SaaS sprawl are the same governance failure at different layers. Employees bypassing corporate tools and apps that resist federation create parallel identity systems outside formal control. The practitioner conclusion is that identity governance has to span secret lifecycle, application coverage, and user behaviour together, or the control plane remains incomplete.
From our research:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report.
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
- That is why the NHI Lifecycle Management Guide matters for teams trying to move from credential storage to governed identity operations.
What this signals
Static secret control will keep underperforming until teams separate authentication from session governance. The practical lesson for IAM programmes is that password vaults, IdPs, and SSO do not create end-to-end control unless they also address what happens after the login handshake. Teams should review where session tokens, browser state, and unmanaged SaaS use sit outside policy enforcement, especially in environments with many exceptions. This is where the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 become useful references for control mapping.
Coverage gaps are the real governance problem, not vault adoption alone. A programme can have strong password hygiene and still leave most applications outside federation. The article’s core signal is that identity teams need a separate control plane for non-federated SaaS, exceptions, and legacy portals, because the highest-risk apps are often the least integrated. That is where the Guide to the Secret Sprawl Challenge helps teams think about unmanaged credential paths.
Session-centric identity security will matter more as phishing kits mature. Once attackers can relay a valid login, the value shifts from secret storage to session assurance, token handling, and continuous verification. The programme implication is that IAM, PAM, and security architecture teams should align access design with phishing-resistant authentication and stronger policy enforcement at the point of use. For that reason, NIST SP 800-63 Digital Identity Guidelines is a relevant anchor for modern authentication choices.
For practitioners
- Map post-login control gaps Identify where your current IAM stack stops at authentication and does not govern the browser session, token, or application activity that follows. Use that map to prioritise the highest-risk SaaS portals.
- Separate federated and non-federated apps Build a distinct inventory for applications that do not support SAML or OIDC, because these are the places where reusable credentials and exceptions accumulate fastest.
- Reduce reliance on reusable secrets Target the systems that still depend on static passwords or shared credentials and move them toward dynamic, application-specific authentication where operationally feasible.
- Review phishing-resistant access paths Prioritise access methods that resist token relay and session theft, especially for privileged users and high-value SaaS applications.
Key takeaways
- Password vaulting reduces secret sprawl, but it does not govern the authenticated session that follows login.
- The biggest risk in the article is structural coverage failure, because large parts of the SaaS estate still sit outside federation and vault control.
- IAM teams should shift attention from storing credentials more safely to controlling access after authentication across the full application footprint.
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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Static vs Dynamic Secrets | The article centres on static secret exposure and the limits of reusable credentials. |
| Recommendation — Replace reusable passwords with dynamic authentication paths where static secrets still carry the highest risk. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The post is about access governance after authentication and across application boundaries. |
| Recommendation — Review access permissions across federated and non-federated apps and tighten authorisation at the point of use. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is relevant because overbroad access increases the impact of session compromise. |
| Recommendation — Limit application and session privileges so a stolen token cannot traverse the wider environment. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Verify Explicitly | The article highlights why post-login trust must be continuously verified, not assumed. |
| Recommendation — Apply explicit verification at access time rather than trusting a successful login to remain safe. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | The piece focuses on authentication methods that reduce phishing and token relay exposure. |
| Recommendation — Use phishing-resistant authentication methods that reduce reliance on reusable passwords and relayable sessions. | ||
Key terms
- Post-Authentication Governance: Post-authentication governance is the control layer that manages access after an identity has already been verified. It covers entitlements, approvals, privilege changes and removal, and it is where many identity programmes fail because they stop at login assurance.
- Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
- Federation Coverage Gap: The portion of an application estate that cannot be governed through normal SSO or federation controls such as SAML or OIDC. It forces exceptions, reusable credentials, or alternate access paths, which creates inconsistent identity governance across the environment.
- Static Secret Centralisation: The practice of storing reusable credentials in a shared vault or similar repository. It improves administration but also concentrates risk, because compromise of the repository or its surrounding workflow can expose a large portion of the credential estate at once.
What's in the full article
Unixi's full article covers the operational detail this post intentionally leaves for the source:
- The specific arithmetic behind the 15% to 30% application coverage estimate for password vaults and how it maps to real enterprise web footprints.
- The detailed comparison of password manager coverage against SAML and OIDC adoption gaps across SaaS applications.
- The Key Derived Authentication model and how dynamic passphrases are generated at login time without a stored central secret.
- The pricing examples and portal-by-portal coverage issues that explain why many applications remain outside traditional SSO deployment.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org