SSO Coverage Guide: Measure the Gap, Budget the SSO Tax, Close Local Logins

Most organisations that say "everything is behind SSO" mean that their main apps have an SSO integration, while local passwords, unenforced settings and apps on plans without SSO quietly keep a second way in. An app counts as covered only when the identity provider is the only route for people to authenticate, and when every exception is known, owned and protected. This guide is for identity and security teams who need to measure real SSO coverage, decide which apps to bring under the IdP, budget for the plan upgrades vendors charge for SSO, and switch off local login without locking anyone out. It assumes the IdP itself is configured well (see the Identity Provider and SSO Security Guide) and that you already know which apps exist (see the Shadow SaaS and Unsanctioned App Discovery Guide).

Key takeaways

• Integration is not coverage. An app with SAML or OIDC configured but local passwords still accepted is a second, weaker front door that offboarding and conditional access do not control.
• Measure three numbers, not one. Track apps integrated, apps enforced (local login off) and the share of accounts in each app that actually authenticate through the IdP.
• The SSO tax is a procurement problem. CISA's Secure by Demand guide asks buyers whether a vendor supports standards-based SSO at no additional cost; put that question into every renewal.
• Enforcement has predictable casualties. Bots, service accounts, contractors and break-glass admins break first, so inventory them and give each a deliberate path before you switch local login off.
• Exceptions need compensating controls. Where an app must keep local accounts, use a vault, phishing-resistant MFA, network restrictions and a named owner, and review the list every quarter.

What "covered" actually means

NIST SP 800-63C, in the SP 800-63-4 suite, allows a relying party to let subscribers access their account through direct authentication instead of federation, and notes that in that case there is no federation transaction and therefore no federation assurance level. The relying party must then follow SP 800-63B for those authenticators. Put plainly: every local login path sits outside whatever assurance your IdP provides. Grade each app on a simple ladder.

Level 4 matters because SSO alone stops new logins but does not always end existing sessions or delete the account. See the SCIM Provisioning Guide for the provisioning half.

Measuring coverage

Start from the sanctioned app inventory, then join three data sources per app: the IdP's application list, each app's admin console export of users and their authentication method, and the app's sign-in log. Coverage is the result of that join, not the count of tiles on the IdP dashboard.

• App integration rate: sanctioned apps with an active SSO integration divided by all sanctioned apps.
• App enforcement rate: apps where local login is disabled for all but governed exceptions, divided by integrated apps. This is the number that matters most and is usually far lower than the first.
• Account coverage per app: accounts whose last sign-in came through the IdP divided by all active accounts in the app. Accounts with a recent local password sign-in in an app marked "SSO" are the finding.
• Orphan rate: app accounts with no matching active IdP identity. These are leavers, contractors created directly in the app, or shared logins.
• Exception count and age: local accounts held as exceptions, with owner and last review date.
• Critical app weighting: report the rates separately for apps holding source code, customer data, finance or production access, since one unenforced admin console outweighs ten unenforced wikis.

Worked example: an organisation reports 120 sanctioned apps and 96 SSO integrations, an 80 percent integration rate. The account join shows that only 41 of those 96 apps reject local passwords, so the enforcement rate is about 43 percent. Inside the "SSO" apps, 9 percent of active accounts signed in with a local password in the last 90 days, and 3 percent have no matching IdP identity at all. Of the 55 unenforced apps, 12 hold customer data or production access. Those 12 become the first enforcement wave, the orphan accounts go to the offboarding team the same week, and the board metric changes from "80 percent on SSO" to the enforcement rate for critical apps, which is the number an attacker with a stolen password actually faces.

Pull authentication method from app logs where they exist; many SaaS audit logs record whether a sign-in was SAML, OIDC, password or token based. Where an app cannot tell you, record it as "unknown" and treat it as level 1 until proven otherwise. The ISPM Guide covers tooling that automates this join across many apps.

The SSO tax and how to budget for it

"SSO tax" is the industry term for selling SAML or OIDC support only on a higher plan than the one a team would otherwise buy. It is the most common reason apps stay at level 0. CISA's Secure by Demand guide asks buyers to check whether a manufacturer supports integrating standards-based SSO for customers at no additional cost, and whether features such as logging and SSO are in the baseline version of the product. Use that framing in procurement rather than treating SSO as an optional extra.

Build the business case from the cost per user of the upgrade against the controls it replaces: manual offboarding effort, separate MFA enrolment, password resets and audit evidence collection. Small organisations may reasonably accept exceptions for a handful of low-risk tools; large organisations should treat SSO as a non-negotiable requirement for anything holding customer or production data.

Closing local login gaps

Turning SSO on is usually one checkbox; turning local login off is where projects stall. Each SaaS product names the setting differently, so work from the vendor's own documentation. Two common examples follow; platforms are listed alphabetically and the order is not a ranking.

GitHub

GitHub Enterprise Cloud documentation describes a "Require SAML SSO authentication" option under the organisation's authentication security settings. Before you enable it, GitHub shows which members have not yet authenticated through the IdP, and enforcement then removes members and administrators who have not, including bots and service accounts without an external identity in the IdP. Removed users can rejoin by authenticating through SAML, and their access and settings are restored if they do so within three months. An enterprise-level SAML requirement overrides the organisation setting. For programmatic access, personal access tokens and SSH keys must be authorised for the organisation before they can reach protected content, which gives you a second inventory of credentials tied to the SSO organisation. Availability: as of November 2026 the SAML enforcement documentation sits in the GitHub Enterprise Cloud docs; confirm the plan for your organisation. See the How to audit GitHub Apps and OAuth apps in an organisation guide for the integration side.

Slack

Slack's help centre describes a "Require SSO authentication" setting that Workspace Owners and Org Owners manage. On Enterprise plans, organisation settings offer SSO member, guest and Frontline exclusions, which let administrators exempt defined groups. Each exclusion is a local login path and belongs on the exception register with an owner and a review date. Profile sync settings control whether names and email addresses follow the IdP. Availability: as of November 2026 Slack documents SSO on Business+ and Enterprise plans, and on Free and Pro plans only where a Salesforce org is connected.

Rollout steps for any app

1. Inventory accounts: export the app's users with last sign-in and method; match each to an IdP identity; tag bots, service accounts, contractors and admins.
2. Fix identity mismatches: align usernames or email attributes so every human has one matching IdP account; this is the main cause of lockouts.
3. Decide each non-human path: move integrations to the app's API tokens, OAuth apps or service accounts designed for machine use, stored in a secrets manager; do not leave a human login shared by a script. See the Service Account Security Guide.
4. Keep one break-glass path: a vaulted local admin with phishing-resistant MFA, alerting on every use, for when the IdP is unavailable. See the Break-Glass Account Guide.
5. Pilot: enforce for the IT team first, then one business unit, watching sign-in failures and helpdesk tickets for a week each.
6. Enforce and communicate: announce the date, publish the new sign-in route, then switch local login off for everyone except governed exceptions.
7. Reset residual passwords: where the app keeps stored passwords after enforcement, rotate or clear them so a later setting change does not revive old credentials.
8. Roll back cleanly: record the previous settings and keep the break-glass path tested, so you can relax enforcement for a single group rather than turning it off for all.

Where identity fits for non-human accounts

Coverage programmes stall on accounts that cannot do an interactive SSO flow: CI jobs, reporting connectors, monitoring probes and AI agents that were given a human-style username and password years ago. These are often exactly the accounts excluded from enforcement and from MFA. Treat them as non-human identities: give each one an owner, move it to a credential type meant for machines (API token, OAuth client credentials, key pair), keep the secret in a vault with rotation, and restrict where it can connect from. The How to Find Accounts Excluded From MFA and Conditional Access guide shows how to find the IdP-side equivalents.

Detection and monitoring

Once an app is enforced, any successful local password sign-in is either a governed exception or a finding. Build detections around that.

The Snowflake breach shows the pattern: attackers used infostealer credentials against accounts with password-only sign-in, no MFA and no network allow lists, some valid years after theft. Detection of password sign-ins on accounts expected to use the IdP would have stood out.

Framework mapping

Common failure patterns

• Counting tiles: reporting the number of apps in the IdP as coverage, while most still accept passwords.
• Admins exempted forever: local admin logins kept "in case SSO breaks", unvaulted and without MFA, which leaves the most powerful accounts outside the IdP.
• Scripts on human logins: an integration using a person's username and password blocks enforcement, so the whole app stays at level 1.
• Enforcement without deprovisioning: leavers cannot sign in through SSO but keep active sessions, API tokens or local accounts because SCIM was never set up.
• Exclusion groups that grow: guest and contractor exclusions added for a project and never removed.
• Accepting the SSO tax silently: security never sees the renewal, so a critical app stays on a plan without SSO for another year.

Practitioner checklist

• Grade every sanctioned app on the coverage ladder from unmanaged to enforced and provisioned.
• Report integration rate, enforcement rate and per-app account coverage separately, weighted for critical apps.
• Add the Secure by Demand SSO question, SCIM and audit log export to every purchase and renewal.
• Inventory bots, service accounts, contractors and admins in each app before enforcing.
• Move machine access to machine credentials held in a vault, never shared human logins.
• Keep one tested break-glass path per critical app with alerting on use.
• Pilot enforcement with IT, then a business unit, before switching local login off for all.
• Alert on any password sign-in to an enforced app and on changes to SSO or exclusion settings.
• Review the exception register quarterly and close exceptions at renewal.

Standards and references

• NIST: SP 800-63C, Digital Identity Guidelines, Federation and Assertions
• CISA: Secure by Demand Guide
• OpenID Foundation: IPSIE Working Group
• GitHub Docs: Enforcing SAML single sign-on for your organization
• GitHub Docs: About authentication with single sign-on
• Slack Help Center: Manage single sign-on settings
• MITRE ATT&CK: Valid Accounts: Cloud Accounts
• MITRE ATT&CK: Brute Force: Credential Stuffing

Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · SSO Integration Checklist · Shadow SaaS and Unsanctioned App Discovery Guide · MFA Coverage Measurement