I work in governance, risk, and compliance, and I'm usually the person putting an "SSO coverage: X%" number on leadership slides. The uncomfortable truth is that the figure usually comes from our identity provider: we list the applications registered there, divide by that same list, and then lower the result slightly so it appears to acknowledge gaps. Nobody has ever given me a trustworthy denominator.
The real application estate is scattered across identity-provider records, stale spreadsheets, partially maintained CMDBs, team-owned tools, expensive SaaS products that were never federated, vendor portals with shared accounts, corporate-card purchases, and newer AI or "citizen" tools. There is no authoritative inventory of everything the company actually uses, and ownership is spread across many teams.
So when I report 91% or 92%, I'm not deliberately misleading anyone, but I don't really know what the percentage represents. Published benchmarks are inconsistent, often come from vendors selling solutions, and may not reflect the same scope. After reviewing many audits, my bigger concern is population completeness in a heterogeneous environment.
Has anyone established a credible application denominator rather than simply using the identity provider's inventory? Did you combine expense records, browser or proxy telemetry, enterprise app registrations, procurement data, interviews, or another source? What did your actual application estate look like, and how did you define and measure SSO coverage?
4 Answers
If you have a secure web gateway, proxy, or similar network visibility, use its cloud-application reports to identify what employees are actually accessing. That gives you a more defensible denominator than the IdP alone. Browser telemetry or a dedicated SaaS-discovery tool can help find applications that aren’t configured for SSO.
In organizations I’ve worked with, initial SSO coverage was often around 70%, and I never managed to reach 100%. Banking, utilities, marketing platforms, and other specialized services are common gaps because they don’t support federation or make it prohibitively expensive. For those, the goal is usually compensating controls such as privileged session management, stronger MFA, password vaulting, and tighter access reviews.
Start by treating this as an inventory problem, not just an identity-provider reporting problem. If you use Microsoft 365, enterprise applications and app registrations are useful starting points, although some registrations won’t support SSO. Also review software billing and procurement records across several months. That can expose SaaS products that were purchased outside the normal process.
That helps with centrally visible services, but the hardest part is finding applications that never appear in the identity platform, especially team-owned SaaS and tools purchased outside procurement.
A lot depends on how the population is defined. An auditor may accept a clean percentage if the scope says “applications registered in the identity platform,” but that is not the same as coverage across all applications the company uses. Document the source, inclusion criteria, exclusions, ownership, and discovery limitations. Then report the metric as something like “SSO coverage of identified in-scope applications,” rather than presenting it as a complete enterprise figure.
Exactly. The percentage can be accurate within a narrow scope while still being misleading as an enterprise-wide number. The denominator and the discovery method need to be shown alongside it.
That seems closer to reality for unmanaged SaaS. We have a large cloud footprint, so discovering what is actually being used matters more than counting registrations.