I handle GRC reporting, so I'm usually the person putting figures like "SSO coverage: 92%" on a slide. The uncomfortable truth is that the number often comes from our identity provider: we export the applications registered there and divide them by that same list, then adjust the result downward to suggest there are some gaps. Nobody has ever given me a reliable denominator.
There isn't a single, maintained inventory of everything the company uses. We have the identity provider, an outdated spreadsheet, partial CMDB and application-management records, team-specific tools, expensive SaaS products that were never federated, vendor portals with shared accounts, and software purchased directly by employees or departments. Some services are tied to corporate cards or free tiers and never go through procurement. The environment is too distributed for one central team to know everything, especially with newer AI tools and other shadow SaaS.
So when I report 92%, I'm not deliberately misleading anyone, but I can't confidently explain what population I'm dividing by. Even published industry benchmarks vary widely, and they usually come from vendors selling discovery or identity products.
For those who have actually measured this, how did you establish the application population? Did you combine identity-provider data with expense records, browser or proxy telemetry, software inventories, enterprise application registrations, or interviews with teams? What did your real baseline look like, and how did you handle applications that don't support SSO? I'm trying to understand whether this is a widespread measurement problem or a gap in my own process.
4 Answers
Start by defining the scope and the denominator instead of treating the identity provider as the inventory. A useful baseline can combine enterprise application registrations, procurement and recurring-expense data, CMDB records, and lists from business and technical owners. Then document exclusions, such as personal tools with no company data, and track unknowns separately rather than quietly counting them as covered.
If you have a secure web gateway, proxy, or similar telemetry, use its cloud-application reports to discover services that never appear in the IdP. Expense data collected over several months is another good signal. Browser-based discovery tools can also identify applications employees are actually using, though you still need to validate whether they handle company data and whether multiple URLs belong to one service.
This is especially useful for shadow SaaS. We found that decommissioning a paid service did not necessarily remove the account or data; the vendor simply moved us to a free tier, which created a separate security problem.
The important thing is to report the metric honestly: “92% of known in-scope applications registered in the inventory use SSO” is very different from “92% of all applications used by the company use SSO.” Keep an inventory-confidence or discovery-completeness metric beside the SSO metric. That makes the uncertainty visible and gives auditors a defensible explanation.
That distinction is exactly what I’ve been missing. The real problem is population completion in a heterogeneous environment, not just whether the IdP configuration looks healthy.
In practice, many organizations begin around 70% coverage when they compare the IdP against a broader application population. Reaching 100% is usually unrealistic because banking, utility, marketing, vendor, and legacy applications may not support SSO. For those gaps, document the reason and apply compensating controls such as stronger MFA, password-management requirements, privileged-session monitoring, or periodic access reviews.
The difficult part is that ownership is often distributed. Teams buy software on cards, use free tiers, or operate services that no central administrator knows about, so an IdP export will always miss part of the estate.