Notifications
Clear all
Topic starter
08/07/2026 6:54 pm
TL;DR: SSO reduces login friction, but up to two-thirds of critical business applications still sit outside SSO coverage, leaving weak passwords, informal sharing, and unmanaged contractor access exposed, according to Bitwarden. The security problem is not authentication alone, but the credential layer that remains when SSO does not reach every app.
NHIMG editorial — based on content published by Bitwarden: Single Sign-On (SSO) limitations and the case for password management
By the numbers:
Questions worth separating out
Q: What breaks when organisations rely on SSO alone for all application access?
A: SSO alone leaves direct-login applications outside central policy, audit, and lifecycle control.
Q: Why do non-SSO applications increase identity risk in enterprises?
A: Non-SSO applications increase identity risk because they often rely on direct credentials that are harder to monitor, rotate, and revoke.
Q: How should teams handle third-party access when SSO is not available?
A: Use a governed access model with auditable sharing, least-privilege scope, and explicit revocation steps.
Practitioner guidance
- Map every application outside SSO coverage Build and maintain a separate inventory of legacy tools, vendor portals, personal business accounts, and unintegrated SaaS so they can be governed as a distinct risk class.
- Replace informal password sharing channels Eliminate email, chat, and verbal credential handoffs for vendors and contractors, and move external access to controlled, auditable sharing and delegation workflows.
- Enforce password policy on direct-login systems Apply unique-password generation, secure storage, and policy enforcement to every application that cannot participate in SSO, including legacy and specialist tools.
What's in the full article
Bitwarden's full article covers the operational detail this post intentionally leaves for the source:
- Examples of the specific application classes that typically fall outside SSO onboarding
- The survey findings behind password sharing behaviour across email, chat, and conversation
- How password managers support emergency access, contractor access, and secure sharing workflows
- The practical distinction between SSO coverage and credential policy enforcement in day-to-day operations
👉 Read Bitwarden's analysis of SSO blind spots and credential security gaps →
SSO blind spots: what IAM teams still need to secure?
Explore further
08/07/2026 7:16 pm
SSO is a control plane, not a complete credential strategy. The article's core point is that authentication centralisation does not equal identity governance completeness. Applications outside federation still require password protection, auditability, and lifecycle control, which means IAM teams should stop treating SSO coverage as a proxy for overall security maturity.
A few things that frame the scale:
- 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 shows how quickly governance breaks once identity control moves beyond the human user boundary.
A question worth separating out:
Q: Who is accountable for credentials that sit outside SSO controls?
A: Accountability should stay with the application owner and the identity governance team together. The application owner defines the business need, while IAM sets the control standard for password storage, sharing, and revocation. If the credential is outside SSO, it is still inside the organisation's governance boundary and must be treated that way.
👉 Read our full editorial: SSO blind spots leave credential risk outside enterprise coverage
