SSO vs Password Manager for SaaS Access: When to Vault and When to Federate

Most organisations run SaaS access on two systems at once, single sign-on for the apps that support it and a password manager for everything else, and the boundary between them is usually an accident of licensing rather than a decision. That boundary decides who loses access when someone leaves, what an attacker gets from one stolen credential and how much evidence you have after an incident. This guide compares federation through an identity provider (IdP) with vaulting in an enterprise password manager as two ways of governing the same SaaS estate. It sets out the threat model and failure modes of each, gives a coverage rule for every class of account (SSO-tax apps, shared accounts, break-glass admins and non-human credentials) and walks through moving an app from the vault to SSO without locking anyone out. It is written for identity, IT and security teams who own SaaS access and assumes you already measure SSO coverage as described in the SSO Coverage Guide.

Key takeaways

• They are not substitutes. SSO removes the app password; a password manager protects a password that still exists. Federate wherever the app supports it and vault only what cannot be federated yet.
• Vaulting is a holding pattern, not a destination. Every vaulted SaaS login is a known exception with an owner, a reason (SSO tax, no SAML or OIDC, shared licence) and a review date.
• The vault becomes tier zero. Once it holds break-glass and admin logins, the password manager's own admin roles, recovery paths and export settings need the same protection as the IdP.
• Machine credentials belong in neither. API keys and integration tokens for SaaS belong in a secrets manager or a workload identity, not in a person's vault or an IdP app tile.
• Measure the exceptions, not the tiles. Track vaulted logins with no named owner, enforced SSO coverage and offboarding time for vaulted apps; they show where the two systems leak.

The short answer

Use SSO for any SaaS app that supports SAML 2.0 or OpenID Connect on the plan you hold or can justify buying, and enforce it so local passwords stop working. Use the password manager for three things only: apps that cannot federate today, accounts that must survive an IdP outage (break-glass), and the small set of shared logins that a vendor licenses as a single seat. Treat each vaulted login as a tracked exception and keep a migration path for it. CISA's Secure by Demand guide asks buyers whether a manufacturer supports standards-based SSO for customers at no additional cost, which gives procurement the lever to shrink the vaulted list at every renewal.

Side-by-side comparison

A third pattern sits between the two. Some IdPs can store and replay a password for apps with an HTML sign-in form. Products are listed alphabetically here. Microsoft Entra ID calls this password-based SSO: Entra ID collects the username and password and stores them encrypted in the directory, then submits them to the app on later launches, and Microsoft positions it for apps that do not support SAML and sign users in with a password. Okta calls this Secure Web Authentication (SWA), with five configurations ranging from "User sets username and password" to "Users share a single username and password set by administrator". In both cases the password still exists and users can still sign in to the app directly, so treat IdP password replay as vaulting with a better user experience, not as federation.

Threat model for each option

SSO

• IdP account takeover: one compromised identity opens every federated app. Phishing-resistant MFA, device conditions and session limits at the IdP carry the whole estate. See the Identity Provider and SSO Security Guide.
• Session and token theft: attackers who steal a session cookie after MFA (ATT&CK T1539 Steal Web Session Cookie) bypass the IdP until the session ends. Short app sessions and continuous evaluation matter more once everything is federated. See the Infostealer Logs and Session Token Abuse Guide.
• Federation trust abuse: a stolen signing key or a rogue federation trust lets an attacker mint assertions. See the Golden SAML and Federation Trust Abuse Defence Guide.
• Local login left on: an app with SAML configured but passwords still accepted keeps a second front door. NIST SP 800-63C allows a relying party to offer direct authentication alongside federation, but in that case there is no federation transaction and the relying party must follow SP 800-63B for those authenticators, so the IdP's controls do not apply to that path.

Password manager

• Vault compromise: NCSC's password manager buyers guide calls the password manager "a natural target", because one successful attack exposes every stored password. The LastPass breach showed the related risk inside an organisation: a keylogger captured an engineer's vault master password and the vault held cloud keys that opened customer backups (ATT&CK T1555.005 Password Managers).
• Recovery path abuse: NCSC warns that admin, team or provider recovery can be exploited and asks owners to understand who can perform it. A vault admin who can recover any member's vault is a privileged identity.
• Revealed and exported passwords: anyone who has seen a shared password keeps it after their vault access is removed. NCSC recommends that plain-text export is protected and that administrators can disable or audit it.
• Orphaned local accounts: the app account outlives the person because nothing deprovisions it. Removing the vault entry does not remove the account (ATT&CK T1078.004 Cloud Accounts).
• Per-app MFA gaps: the vault's MFA does not protect the app login. Unless each vaulted app has its own MFA, a phished or reused password works directly against the app.

Architecture in words

SSO: the user authenticates to the IdP, which applies MFA and conditional access and then sends a SAML assertion or OIDC ID token to the app. The app trusts the IdP's signing key, maps the subject to a local account and starts its own session. Provisioning runs separately: SCIM creates, updates and deprovisions the app account. NIST SP 800-63C requires the IdP to use the provisioning API to deprovision relying party accounts for terminated subscribers unless retention rules prevent it, which is why SSO without SCIM leaves dormant accounts behind. See the SCIM Provisioning Guide.

Password manager: the user unlocks a vault, decrypts the stored credential and autofills it into the app's sign-in form. The app runs its own password check and any MFA it has. Modern enterprise password managers can authenticate the user to the vault through the IdP. Products are listed alphabetically. 1Password's Unlock with SSO lets members sign in with IdP credentials over OpenID Connect (Authorization Code Flow with PKCE) and uses encrypted credentials and a device key to unlock. Bitwarden's Login with SSO supports SAML 2.0 and OIDC and, in Bitwarden's words, "decouples authentication and decryption", with member decryption options handling the key so the IdP never receives it. Either way, SSO into the vault controls who opens the vault; it does not federate the apps inside it. See the Password manager (enterprise) integration security guide.

Coverage decision: which account goes where

Break-glass: keep at least one emergency account per critical tenant that does not depend on the IdP and store its credential in the vault or sealed offline, with alerts on every use. See the Break-Glass Account Guide.

Shared accounts: NCSC does not recommend sharing passwords between individuals and, where sharing cannot yet be avoided, lists controls an enterprise manager can provide: marking shared items clearly, logging who accessed a shared password and when, admin control of access per item, and syncing changes to everyone with access. NIST SP 800-53 AC-2(9) Restrictions on Use of Shared and Group Accounts is the matching control.

Non-human credentials: a person's vault is the wrong home for an API key that a pipeline or integration uses. It ties the credential to one person's device and login and hides it from NHI inventory. See Password Manager vs Secrets Manager.

Failure modes of each option

Migrating an app from the vault to SSO

Run it per app, starting with the apps that hold the most sensitive data or the most users.

1. Inventory every account in the app. Export users, roles and authentication method from the app's admin console and join it to the vault items for that app. Flag shared logins, service accounts and accounts with no matching person. See How to Find Accounts Excluded From MFA and Conditional Access.
2. Decide the path for the awkward accounts first. Service accounts move to an API token or OAuth client held in a secrets manager; shared logins become named users where the plan allows; one break-glass admin stays local and vaulted.
3. Configure SAML or OIDC and SCIM in a test tenant or with a pilot group. Match the app's user identifier to the IdP attribute (usually email or immutable ID) and check that existing accounts link rather than duplicate. NIST SP 800-63C requires an authenticated session for account linking functions.
4. Pilot with both paths open. Let the pilot group use SSO while local login still works. Watch the IdP sign-in log for failures and the app log for local logins from pilot users, which show habits or bookmarks still pointing at the old form.
5. Enforce SSO for everyone except named exceptions. Turn on the app's "require SSO" or equivalent setting. Keep the break-glass account excluded and test it the same day.
6. Retire the vaulted credentials. Rotate the old passwords to random values nobody holds, then archive the vault items with a note pointing to the SSO app.
7. Roll back cleanly if needed. The rollback is to relax enforcement, not to restore old passwords. Keep the break-glass path working throughout, and if SSO fails at scale, re-enable local login for a defined window and issue new passwords through the vault rather than reusing archived ones.
8. Close the exception. Update the exception register and the coverage metrics. Use the Password manager (enterprise) migration playbook if the vault itself is changing at the same time.

Decision guidance and trade-offs

• Pay the SSO tax when: the app holds regulated or customer data, has more than a handful of users, has admin roles that can change security settings or export data, or appears in an audit scope. Vault when the app is low-risk, has few users and its vendor offers per-app MFA.
• Use IdP password replay when: users need one portal and the app has an HTML form, but you accept that the password still exists. Prefer the password manager when users need to share credentials with logged access or when the credential must work during an IdP outage.
• Small organisations (under about 200 people) often cannot justify SSO-tier plans for every tool. Put SSO on email, the collaboration suite and finance tools first, and run everything else from the vault with SSO into the vault itself and app MFA on.
• Large organisations should make SSO and SCIM a purchasing requirement and treat the vaulted list as technical debt with a quarterly burn-down target. The vault then shrinks to break-glass, shared single seats and a short tail.

Worked scenario: a 900-person software company

The company has 140 SaaS apps. Sixty are federated through the IdP, but only 41 have local login switched off. Seventy-two live in the password manager, including 18 that support SAML only on an enterprise plan, 9 shared single-seat logins, 11 SaaS admin accounts and 23 API keys that engineers saved as vault items.

The team first moves the 23 API keys into the secrets manager, scopes them and rotates them, because they are the credentials most likely to be used outside a person's control. Next it enforces SSO on the 19 integrated-but-optional apps, starting with the CRM and the code hosting platform. For the 18 SSO-tax apps it ranks by data sensitivity and user count, pays for 6 upgrades at renewal and keeps 12 vaulted with app MFA on and a named owner. Break-glass accounts for the IdP and the three most critical tenants are vaulted in a separate collection with alerting on access. After two quarters the vault holds 30 SaaS logins instead of 72, every one has an owner and a reason, and SaaS offboarding is mostly the IdP disable plus SCIM.

Detection and measurement

What to log: IdP sign-in events per app with policy result; each SaaS app's local (non-SSO) sign-in events; vault events for item access, password reveal, export, sharing changes, admin recovery and policy changes; SCIM provisioning errors. Send all of them to the SIEM and alert on local sign-ins to enforced apps, any vault export, any recovery of another member's vault and any access to break-glass items.

• Enforced SSO coverage: share of in-scope apps where local login is off except named exceptions. Target above 90 percent for apps holding sensitive data.
• Vaulted exceptions with an owner and review date: target 100 percent.
• Machine credentials found in personal vaults: target zero, measured by periodic review of vault item types and names.
• Time to remove access for leavers on vaulted apps: including rotation of shared passwords they could see.
• Local sign-ins to enforced apps per month: should trend to break-glass tests only.

Framework mapping

Common failure patterns

• Counting tiles as coverage. An app tile in the IdP portal that replays a password or opens a SAML app with local login on is counted as "SSO", hiding the real exposure.
• Storing cloud keys next to personal logins. The LastPass breach shows how long-lived machine keys in a person's vault are only as safe as that person's device and master password.
• Federating the break-glass account. The emergency account is put behind the IdP for neatness and fails exactly when the IdP does.
• Vault admin sprawl. Helpdesk staff hold vault recovery rights to reduce tickets, creating a path to every member's vault that is rarely logged or reviewed.
• Enforcing SSO without an account inventory. Service accounts and integrations that used the app password stop working at go-live, and the quick fix is to turn local login back on for everyone.

Practitioner checklist

• Classify every SaaS app as federated and enforced, federated but optional, vaulted, or uncovered, and publish the numbers.
• Keep an exception register for every vaulted SaaS login with owner, reason (SSO tax, no federation, shared seat, break-glass) and review date.
• Turn on SSO into the password manager and require it for non-admin members; keep vault admins small, MFA-protected and logged.
• Disable or audit plain-text vault export and restrict password reveal on shared items.
• Move every API key, token and service account password out of personal vaults into a secrets manager.
• Keep one vaulted or offline break-glass account per critical tenant, outside the IdP, with alerts on use.
• Add "standards-based SSO and SCIM at no additional cost" to SaaS procurement and renewal questions.
• Run the vault-to-SSO migration per app: inventory, pilot, enforce, rotate old passwords, close the exception.
• Rotate shared passwords whenever someone with access leaves or changes role.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-63C-4 Federation and Assertions
• CISA: Secure by Demand Guide
• NCSC: Password manager buyers guide
• Microsoft Learn: Configure password-based single sign-on
• Okta: Overview of managing apps and SSO
• 1Password: Get started with Unlock with SSO
• Bitwarden: About Login with SSO

Related NHI Mgmt Group resources: SSO Coverage Guide · Password manager (enterprise) integration security guide · Passkeys vs Password Managers · Shadow SaaS and Unsanctioned App Discovery Guide · SSPM vs CASB