Use multiple evidence sources, including finance data, direct app integrations, directories, and endpoint or browser signals, rather than relying on SSO alone. SSO shows federated access, but many SaaS tools are adopted outside that path. The goal is to build a reconciled inventory that can support access reviews, ownership assignment, and offboarding.
Why SSO Misses a Large Part of the SaaS Estate
SSO is only one visibility plane, so the inventory problem starts with understanding what it does and does not observe. If a team treats the IdP as the source of truth, it will miss apps adopted with local logins, card-based procurement, browser-based signups, or integrations provisioned outside the corporate path. That gap is why discovery has to combine identity, finance, endpoint, and directory signals.
In practice, the question is not whether an app supports federation, but whether the organization has any credible evidence that it is in use. A SaaS product can be business-critical long before it is formally tied to SSO, and that means ownership, access review, and offboarding decisions cannot wait for perfect federation coverage.
Teams usually undercount because the same app may surface differently in each dataset, for example as a vendor in accounts payable, a browser session on a managed device, or a connected app inside another platform. Reconciling those views is what turns discovery into inventory, and inventory into something usable for governance.
What Evidence Sources Actually Find Unmanaged SaaS Apps
A strong discovery program treats every source as partial, then cross-checks them. Finance data can expose purchased subscriptions and recurring charges, while procurement and expense reports often reveal shadow adoption before the security team sees a login trail. Directory and app catalog data show what was approved, not necessarily what is truly in use, so they need to be matched against real usage signals.
Endpoint and browser telemetry can identify SaaS domains that users visit, even when access is not federated through the corporate IdP. Direct app integrations, API connections, and admin console exports are also useful because many business teams wire SaaS into other systems without ever creating an SSO dependency. Those integrations are often the best clue that the app matters operationally.
A practical discovery model is to reconcile the same vendor across multiple records, then decide whether the app is approved, tolerated, or unknown. That classification matters because the remediation path differs: approved apps need ownership and lifecycle control, tolerated apps need risk review, and unknown apps need investigation before they are allowed to keep collecting data or retaining tokens.
How the Inventory Should Support Governance, Not Just Enumeration
The end goal is not a spreadsheet of names. It is a reconciled inventory that can answer who owns the app, how users authenticate, whether there is a federated path, what data the app touches, and how it will be removed if the contract or need disappears. Without those fields, discovery creates noise rather than control.
Once a SaaS app is identified, IAM teams should connect it to access reviews, vendor ownership, and offboarding playbooks. That is especially important for apps that started outside SSO, because they often retain local accounts, API tokens, or stale integration credentials that do not appear in routine IdP reports. Discovery therefore feeds both governance and containment.
For broader identity hygiene, the inventory should also distinguish first-party business systems from downstream SaaS integrations and personal productivity tools. The same app may appear low risk until it is linked to a high-value dataset, an automation workflow, or a shared mailbox, at which point the access decision changes materially. A useful inventory is one that captures those relationships, not just app names.
Risk and Threat Considerations
Unmanaged SaaS apps create blind spots for data exposure, offboarding failure, and token persistence. If the organization only watches SSO, an attacker or departing employee can continue using a direct login, an OAuth grant, or an integration secret that was never governed through the IdP.
Failure mechanism: The control fails when app ownership, authentication path, and integration inventory are stored in separate systems and never reconciled, so orphaned access survives user termination or vendor change.
Impact: Stale SaaS access can preserve unauthorized data access, weaken auditability, and make revocation incomplete even after the user account is disabled in the corporate directory.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | SaaS discovery requires an authoritative inventory of in-scope applications. |
| AC-2 — Account Management | Unmanaged SaaS apps create orphaned accounts and offboarding gaps outside SSO. | |
| IA-5 — Authenticator Management | Direct SaaS access often depends on secrets, tokens, or local credentials outside federation. | |
| Recommendation — Maintain a reconciled system inventory that includes SaaS apps, owners, and usage context. Track and disable SaaS accounts through a complete account lifecycle process. Inventory and rotate SaaS authenticators, tokens, and other credential material. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | A reconciled SaaS inventory is an asset-control problem, not just a discovery task. |
| A.5.15 — Access control | Discovery matters because SaaS access paths need governance even when they bypass SSO. | |
| Recommendation — Keep an accurate inventory of SaaS services, owners, and supporting assets. Define and enforce access control for each SaaS app and its authentication path. | ||
Practitioner Guidance
What to prioritise: Start with sources that can prove spend or active use, then enrich them with identity and endpoint evidence. That order usually finds the highest-value unknown apps fastest, because the business already paid for or depended on them.
What to verify: For every discovered app, confirm the owning team, authentication method, and whether any API tokens or non-SSO accounts exist. If those three fields are missing, treat the entry as incomplete for access review and offboarding purposes.
Common mistake: Do not equate “not in SSO” with “not in use.” The more reliable assumption is that the missing app may be more operationally embedded, because it was adopted outside the standard control plane.
Practitioner takeaway: The best SaaS discovery program is reconciliation-driven, not login-driven; if an app cannot be tied back to an owner, an authentication path, and a removal path, it is not yet governable.