SSO only governs the applications that support federation. Many business applications sit outside that boundary, so local passwords remain in use. A password manager is what extends governed credential handling to the long tail of applications that SSO does not cover.
Why password managers still matter when SSO is in place
SSO removes a lot of repetitive login handling, but it does not eliminate every credential problem in an organisation. The practical gap is coverage: many business systems, admin portals, legacy tools, vendor sites, and niche SaaS applications still use local usernames and passwords. A password manager gives teams a governed place to create, store, and retrieve those credentials consistently.
That distinction matters because SSO and password managers solve different parts of the access problem. SSO centralises authentication for federated applications; a password manager supports the applications that are outside the federation boundary, and it also helps with shared break-glass access, vendor logins, and accounts that cannot yet be migrated.
What SSO does not cover in the real world
In most enterprises, the long tail of applications is the reason password managers remain necessary. Some tools are too old to support federation, some are external services with limited integration, and some accounts exist outside the main identity platform by design. The answer is not to assume those passwords will disappear on their own, but to manage them with the same discipline as the rest of the access estate.
That is also why a password manager can be a control improvement even in a mature SSO environment. It reduces password reuse, removes the temptation to store credentials in browsers or spreadsheets, and makes it easier to rotate or share access without revealing the underlying secret to everyone who needs the account.
For that broader access context, it helps to distinguish the SSO layer from the credential layer by looking at how federated login and local secrets are actually handled in practice, as described in Identity Provider and SSO Security Guide and Password Security and Password Manager Guide.
How password managers reduce residual access risk
Password managers are not a substitute for SSO, they are the control that closes the residual gap. They help standardise credential generation, support stronger unique passwords for non-federated accounts, and make it practical to change secrets without relying on memory or informal sharing. That is especially useful where local passwords still exist but human behaviour would otherwise drift toward reuse and weak handling.
They also matter for incident containment. When a password is centrally managed, the organisation can revoke or rotate it faster after an exposure, and it has a clearer picture of where that credential is used. That reduces the chance that an old password quietly remains active in a forgotten application.
Because password managers are part of the governed credential layer, they also sit naturally alongside access governance work on workforce identities and broader credential hygiene, including the guidance in Workforce Identity Security Guide and the operational lessons in Password Security and Password Manager Guide.
Where organisations get this wrong
The most common mistake is treating SSO as if it removed the need for password governance everywhere. In practice, that leaves unmanaged local accounts, shared vendor logins, emergency access credentials, and the credentials used for exception workflows. Those accounts often become the weak link because they are outside the normal SSO monitoring path and are easier to overlook during reviews.
Another mistake is allowing the password manager to become an unmanaged convenience tool. If vault ownership, sharing rules, and recovery controls are not defined, the organisation may simply move risk from scattered passwords to a poorly governed vault. The tool is only effective when it is tied to account inventory, ownership, rotation, and offboarding.
When local secrets still exist, the relevant comparison is not SSO versus password managers, but governed versus ad hoc credential handling. That is why examples of token theft and credential compromise in federated environments, such as Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, are useful reminders that identity controls need coverage beyond the primary sign-in path.
Risk and Threat Considerations
When organisations over-rely on SSO, the residual password surface often becomes poorly inventoried and therefore easier to exploit. Attackers do not need every account, only the unmanaged ones: a single legacy login, vendor portal, or shared admin password can become a foothold for credential stuffing, phishing follow-on, or lateral access.
Failure mechanism: Federation protects the applications it covers, but any local account outside that boundary remains dependent on its own password quality, storage, and rotation discipline. If those secrets are reused, forgotten, or shared informally, they become a durable exposure even in an otherwise modern identity stack.
Impact: The result is avoidable account compromise risk, weaker offboarding, slower response to password exposure, and a larger blast radius when an attacker finds a non-federated account that still authenticates to business systems.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password managers control residual credentials that SSO does not cover. |
| IA-2 — Identification and Authentication (Organizational Users) | SSO addresses user authentication for supported applications, while exceptions still need governed auth. | |
| IA-9 — Service Identification and Authentication | Many non-SSO credentials are service or integration accounts that still need controlled handling. | |
| Recommendation — Manage non-federated credentials centrally and rotate them on a defined schedule. Use centralized authentication for supported applications and document exceptions explicitly. Apply separate controls to service and integration credentials outside the SSO boundary. | ||
| CIS Controls v8 | CIS-5 — Account Management | Password managers support control of accounts that SSO does not eliminate. |
| Recommendation — Maintain an account inventory and reduce unmanaged local credentials. | ||
Practitioner Guidance
What to prioritise: Inventory the applications that do not participate in SSO and treat their passwords as a separate governance population. That list usually includes legacy apps, third-party portals, emergency accounts, and shared operational logins.
What to verify: Confirm that the password manager is actually controlling the accounts SSO does not reach, not just serving as a convenience layer for a few users. You want clear ownership, rotation expectations, and recovery rules for every stored secret.
Common mistake: Do not allow “we have SSO” to become a proxy for “we have eliminated passwords.” In mixed estates, the quality of residual password handling often determines the real security posture.
Practitioner takeaway: SSO reduces the number of passwords people should type, but a password manager is what keeps the remaining passwords governed, unique, and recoverable where federation does not apply.
Related resources from NHI Mgmt Group
- Why do password managers still need strong governance if they use end-to-end encryption?
- Why do poor password practices still create risk even when organisations use password managers?
- Why do organisations need SCIM if they already use SSO?
- Why does weak password handling still create so much risk in organisations that use SSO?