What happens when organisations rely on SSO alone without a password manager for the rest of the estate?

Any application or account not integrated with SSO becomes a separate risk point, often managed by individual users with weaker habits and less oversight. That can leave sensitive services outside central policy, slow down administration, and increase the chance that credentials are reused or poorly shared. A layered approach is needed to cover both federated and non federated access.

SSO centralises authentication only for the applications that are actually federated. Anything outside that trust boundary still needs a practical way to generate, store, share, and rotate credentials. When organisations assume SSO covers everything, unmanaged accounts tend to drift into personal browsers, notes, spreadsheets, shared mailboxes, or ad hoc vaults, which weakens control and makes recovery slower when staff change or secrets are exposed.

A password manager fills the gap for the long tail of systems that cannot or should not be tied to the IdP, including vendor portals, break-glass access, legacy apps, and one-off administrative logins. That matters because the estate is usually mixed, not perfectly federated. The more applications sit outside central sign-in, the more the organisation depends on consistent secret handling rather than federation alone. IAM and Identity Provider Buyer’s Guide is useful here because it treats SSO as one control in a broader access stack, not the whole strategy.

In practice, the question is not whether SSO is valuable, it is whether the remaining access surface has an equivalent control pattern. If not, users become the control plane for those accounts, and that usually means weaker password choices, more reuse, and less visibility into who has access. Password Security and Password Manager Guide covers why shared and reused credentials are a recurring failure mode in mixed estates.

Why SSO-only estates weaken governance and increase credential drift

SSO creates a clean governance model only when the majority of access can be routed through it. Outside that model, the organisation loses central policy enforcement for password length, reuse resistance, sharing rules, and periodic review. That creates a split estate, where federated access is well governed but non federated access is invisible or semi-managed.

The operational effect is usually slower administration and weaker accountability. Help-desk teams cannot revoke or reissue access consistently if they do not know where credentials are stored, and managers cannot easily attest to who still holds access to legacy SaaS tools, third-party consoles, or emergency accounts. A layered approach also gives you a cleaner path to migration, because it lets you reduce password exposure while still supporting systems that cannot join SSO yet. Identity Provider and SSO Security Guide is a useful companion for the federated side of that split.

There is also a lifecycle problem. SSO can deprovision users centrally only for integrated applications, but the rest of the estate still needs manual or separately automated offboarding. If credentials are not inventoried and rotated as part of that process, old access can survive role changes and departures, which makes the organisation depend on memory instead of governance.

What a layered access model should cover

A sensible control model treats SSO and password management as complementary. SSO should handle the highest-value federated path, while a password manager handles the residual estate, shared administrative credentials, and exceptions that need strong secret hygiene. That division of labour is what keeps the access model coherent when the application portfolio is uneven.

For practitioner teams, the key design choice is whether every non-SSO account has an owner, a recovery path, and a rotation rule. If any of those are missing, the account is effectively unmanaged even if it is technically reachable. The goal is not to preserve passwords forever, it is to stop passwords from becoming invisible shadow infrastructure while the organisation transitions toward stronger authentication. OpenID Connect Core 1.0 is the foundational reference for the federated layer, but it does not solve the residual credential problem by itself.

For the non federated remainder, password manager policy should be explicit about shared vault ownership, emergency access, rotation after staff changes, and what types of credentials may never be stored in personal tools. That is the difference between a managed exception and a hidden dependency. In mixed estates, the safest pattern is not to ask users to remember more, but to reduce what humans have to handle directly.

Risk and Threat Considerations

When SSO is treated as the only control, the residual estate becomes attractive to attackers because it is often weaker, less monitored, and easier to abuse through reused passwords, credential stuffing, phishing, or exposed shared logins. The risk is not just compromise, but also the blast radius of an account that bypasses central policy and recovery processes.

Failure mechanism: Non federated applications and shared administrative logins accumulate outside the IdP, so password hygiene, rotation, and revocation depend on individual behaviour or manual follow-up. That creates stale access, poor visibility, and a larger opportunity for credential reuse or theft to succeed.

Impact: Attackers gain a second route into the estate even when SSO is strong, and administrators lose the ability to answer basic questions about who has access, how it is stored, and whether it was revoked on time. In serious cases, a single unmanaged password can become the weak link that defeats otherwise well-designed federation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers managing passwords and other authenticators outside SSO.
	IA-2 — Identification and Authentication (Organizational Users)	SSO is the central organisational-user authentication path for integrated apps.
	AC-2 — Account Management	Non-SSO accounts still need owner, lifecycle, and deprovisioning control.
Recommendation — Manage residual credentials with rotation, protection, and revocation rules. Centralise workforce sign-in through federated authentication where possible. Inventory and retire non federated accounts through formal account management.
ISO/IEC 27001:2022	A.5.16 — Identity management	Mixed estates need identity governance across federated and non federated access.
	A.5.17 — Authentication information	Password managers govern authentication material that sits outside SSO.
Recommendation — Maintain an identity inventory that includes residual non-SSO accounts. Protect non-SSO credentials with controlled storage and handling rules.

Practitioner Guidance

What to prioritise: Inventory every account that is not behind SSO, then separate them into user-facing, shared, break-glass, and legacy admin access. The highest-risk group is usually shared or privileged access that still relies on passwords, because that is where reuse and poor storage are most damaging.

What to verify: Confirm that each non federated account has an owner, a rotation path, and a recovery process that does not depend on a person remembering where the secret was saved. If the organisation cannot revoke or rotate the credential on demand, treat the account as a governance gap rather than a convenience exception.

Practitioner takeaway: SSO reduces the number of places users sign in, but it does not eliminate the need for disciplined secret handling across the rest of the estate. Mature teams design for the mixed reality, federate what they can, and manage everything else with the same seriousness they apply to central identity.