By NHI Mgmt Group Editorial TeamBased on Bitwarden: “Why SSO isn't enough” (October 21, 2025)

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.


At a glance

What this is: This analysis argues that SSO improves access control only for the applications it reaches, while unmanaged credentials, sharing, emergency access, and contractor accounts remain outside its protection.

Why it matters: IAM teams need a coverage model that treats SSO and password management as complementary controls, because the residual credential estate is where enterprise risk and audit gaps persist.

By the numbers:

  • 53% of IT decision-makers share passwords via email, according to Bitwarden.
  • 41% of IT decision-makers share passwords through chat, according to Bitwarden.
  • 31% of IT decision-makers share passwords through conversation, according to Bitwarden.

Context

Single Sign-On centralises authentication, but it does not magically convert every business application into an SSO-integrated asset. Many enterprises still run a mixed application estate with legacy systems, vendor portals, personal accounts used for work, and new SaaS tools that never fully enter the federation layer.

That creates an identity governance problem, not just a login problem. Where SSO ends, credentials still exist, still need protection, and still need lifecycle controls across employees, contractors, vendors, and emergency access scenarios.


Key questions

Q: What breaks when SSO does not cover every business application?

A: The enterprise loses consistent authentication, password policy enforcement, and auditability for the apps that fall outside federation. Those systems keep local credentials, shared accounts, or informal access paths, which creates a separate governance problem that SSO does not solve. IAM teams should treat non-SSO apps as a distinct control surface, not an edge case.

Q: Why do unmanaged credentials increase security risk in organisations with mixed SSO and non SSO applications?

A: Unmanaged credentials create risk because they often lack owners, rotation schedules, and audit history. They usually appear when an application does not support SAML or OIDC, or when teams copy passwords into shared workspaces to keep business moving. That leaves real access in place without clear accountability, which expands the attack surface and complicates audit readiness.

Q: What do security teams get wrong about SSO as a security control?

A: Many teams assume SSO solves both access control and password hygiene. In practice, SSO improves sign-on consistency but does not automatically fix weak passwords, password reuse, unauthorised sharing, or applications that cannot support SSO. If those edges are unmanaged, the organisation can still face breaches, help desk load, and inconsistent policy enforcement.

Q: How should organisations govern contractor access when SSO is unavailable?

A: Use explicit provisioning, controlled sharing, and timed revocation for contractor credentials instead of ad hoc handoffs. Contractors should be governed through the same lifecycle discipline as other non-human or external access paths, with a clear owner, a defined end date, and an auditable record of who received what access.


Technical breakdown

Why SSO coverage leaves a credential layer behind

SSO brokers authentication for integrated applications, usually through federation, but it does not replace the underlying credential model of systems that cannot join the trust chain. If an application does not support SSO, the user still needs a local password, shared account, or alternate access path. That residual credential layer becomes the real risk surface: it is outside central sign-in policy, often outside MFA enforcement, and frequently outside audit visibility. The result is a split control environment where one part of the estate is federated and the other part remains identity fragmented.

Practical implication: Map which applications are outside SSO and treat them as separate governance domains, not as exceptions that can be ignored.

Why informal password sharing persists around non-SSO apps

When teams cannot route access through SSO, they often fall back to email, chat, or verbal sharing to keep work moving. That is not just a convenience issue. It removes accountability, breaks audit trails, and makes it impossible to know who holds the credential after the original request. In practice, the access control shifts from policy to human memory. For IAM and PAM teams, that is a signal that the credential itself, not the login experience, needs governance.

Practical implication: Replace informal sharing with controlled credential vaulting and auditable sharing workflows for any application that sits outside federation.

How contractor and emergency access expose the limits of SSO

Temporary external access and emergency access are lifecycle problems, not sign-in problems. SSO can authenticate the end user when access is already provisioned, but it does not solve how credentials are issued, shared, revoked, or recovered when a vendor, contractor, or key employee changes state. That is why password management and emergency access workflows sit alongside SSO rather than beneath it. The control objective is to keep access short-lived, attributable, and recoverable even when federation is unavailable or inappropriate.

Practical implication: Govern contractor and break-glass access with explicit provisioning, sharing, and revocation workflows that do not depend on SSO coverage alone.


Threat narrative

Attacker objective: Use the unmanaged credential layer outside SSO to reach business applications and accounts that were not protected by the enterprise federation model.

  1. Entry occurs when users, contractors, or vendors rely on applications that are outside SSO coverage and therefore depend on local credentials or informal sharing.
  2. Credential access expands when those passwords are reused, stored insecurely, or exchanged through email, chat, or conversation without an audit trail.
  3. Impact follows when a compromised or untracked credential gives an attacker access to business systems that the enterprise assumed were protected by SSO.

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

SSO coverage is a governance boundary, not an enterprise security boundary. SSO reduces authentication risk only for the apps it can federate, which leaves a residual estate of legacy systems, vendor portals, shadow IT accounts, and new SaaS tools outside that control plane. The important question is no longer whether SSO is deployed, but which credentials still exist where federation does not reach. Practitioners should treat that gap as a separate governance domain.

The unmanaged credential layer is where identity control breaks down most often. Once an application sits outside SSO, the enterprise usually loses policy consistency, auditability, and lifecycle control over passwords, shared accounts, and emergency access. That is why the real problem is not authentication alone, but the persistence of credentials that SSO never governed. Residual credential estate is the right concept here: the accounts and secrets left behind after federation has done all it can.

Informal sharing is a control failure, not a workflow quirk. Email, chat, and verbal credential handoff replace accountable access with convenience-driven access, which undermines both audit and revocation. This pattern affects employees, contractors, and vendors alike, so it cannot be handled as a narrow user-behaviour issue. The implication is that identity programmes need a governed sharing path for non-SSO access, not just stronger sign-in for federated apps.

SSO and password management solve different parts of the same identity problem. SSO governs authenticated entry to integrated applications, while password management and emergency access govern the long tail of credentials that remain outside that perimeter. That distinction matters because enterprises increasingly operate hybrid application estates where a single control model cannot cover every access path. Practitioners should align controls to the application’s federation status, not to an assumption of universal SSO coverage.

From our research library:

  • Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Residual credential estate: the apps outside SSO are often the ones that carry the weakest governance, because they keep passwords, sharing, and recovery paths outside the federation model. That means IAM teams need to measure coverage by application class, not by whether SSO is deployed at all.

SSO should be treated as one control layer in a broader identity stack, not as the control that eliminates the need for password management. For mixed estates, the practical objective is to make every credential either federated, vault-governed, or explicitly break-glass managed.


For practitioners

  • Inventory all non-SSO applications Build a living register of legacy systems, vendor portals, shadow IT accounts, and new SaaS tools that sit outside federation so each one has an explicit control owner.
  • Replace informal password sharing Route shared access through governed vaults and auditable workflows so access granted by email, chat, or conversation is no longer the default.
  • Separate contractor lifecycle controls Define short-term provisioning, review, and revocation steps for vendors and consultants, because SSO alone does not manage their credential lifecycle.
  • Define emergency access paths Document break-glass accounts, approval conditions, and recovery steps for critical systems that may not be reachable through normal SSO flows.

Key takeaways

  • SSO improves access control for federated applications, but it does not govern the full credential estate.
  • The main exposure sits in the applications and access paths that remain outside federation, where sharing and local passwords still persist.
  • IAM teams need to pair SSO with password governance, contractor lifecycle controls, and break-glass access so coverage is based on the application, not the assumption.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageNon-SSO credential sharing and storage outside vaults creates exposure of secrets and passwords.
Recommendation — Scan for exposed credentials in email, chat, and local storage, then revoke and replace any leaked secrets.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe article centers on managing passwords and other authenticators outside SSO coverage.
Recommendation — Enforce authenticator lifecycle controls for every application that still relies on local credentials.
MITRE ATT&CKTA0006 — Credential AccessThe attacker value in this pattern comes from obtaining or abusing unmanaged credentials outside federation.
Recommendation — Map unmanaged credential paths to credential access tactics and prioritize the systems that still depend on passwords.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is fundamentally about ensuring access coverage and authorization consistency across mixed estates.
Recommendation — Review entitlements for apps outside SSO and close authorization gaps where access is not centrally governed.

Key terms

  • Residual Credential Estate: The set of credentials, accounts, and access paths that remain outside SSO or centralized federation. These are often the places where password reuse, informal sharing, and weak lifecycle control survive because the primary authentication platform does not govern them directly.
  • Federation Boundary: A federation boundary is the point where identity assertions move between systems, directories, or providers. It is where token trust, session validation, and revocation often become fragile, especially when enterprises mix protocols and ownership models across cloud and on-premise environments.
  • Break-glass Access: Break-glass access is an emergency path that bypasses normal access controls when standard authentication fails or a critical incident demands immediate intervention. It must be tightly time-bound, logged, and reviewed, because it exists to restore operations without becoming a permanent back door.
  • Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.

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 programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org