The list of applications formally integrated with single sign-on and therefore known to the identity platform. In this context, the catalogue is only one part of governance because it can miss apps used outside SSO or outside approved workflows.
What the SSO catalogue is used for
An SSO catalogue is the identity platform’s official inventory of applications integrated for single sign-on. It helps teams know which apps are onboarded, which trust relationships exist, and where SSO policy should be enforced.
It is most useful as a governance view, not a complete map of all software in use. A catalogue can be accurate for approved SSO apps while still missing shadow IT, locally approved exceptions, or direct sign-ins that bypass the identity platform entirely.
Why the catalogue matters for identity governance
The catalogue creates a practical boundary around what the identity team can manage directly. If an application is in the catalogue, it should have an owner, an expected authentication path, and a clear lifecycle for approval, review, and removal.
That boundary is important because SSO integration usually implies a formal trust relationship, such as federation or token-based sign-in. OpenID Connect Core 1.0 is a useful reference for how identity is layered onto OAuth 2.0 in federated login flows.
For practitioners, the catalogue is also a visibility mechanism. If it is the only source of truth, gaps can appear whenever business units adopt apps outside approved workflows or when legacy access paths survive after SSO is enabled.
What belongs in the catalogue, and what can be missed
A strong catalogue usually includes the application name, the SSO protocol or integration type, the owner, the identity provider relationship, and the provisioning or deprovisioning path. That information helps distinguish a merely known app from one that is actually governed.
The catalogue can miss important exposure if it only records formal integrations. Apps reached with local passwords, shared links, embedded credentials, or ad hoc vendor logins may remain outside the catalogue even though they still handle corporate data.
This is why catalogue governance should be read alongside broader identity controls. NHIMG’s Identity Provider and SSO Security Guide explains the trust and session risks around SSO itself, while the IAM and Identity Provider Buyer's Guide frames SSO as part of a wider identity platform decision rather than a standalone feature.
How teams should think about the catalogue as a control surface
An SSO catalogue is not just a list, it is a control surface for access governance. It supports application rationalisation, ownership assignment, offboarding decisions, and review of whether an app should remain federated, be retired, or be re-integrated under a cleaner trust model.
Because the catalogue is only as complete as the onboarding process behind it, organisations should treat it as a governed register that must be reconciled with app discovery, procurement records, and access telemetry. NHIMG’s Workforce Identity Security Guide is relevant here because it treats SSO, federation, provisioning, and session handling as one operational system, not separate problems.
In practice, a catalogue is valuable when it helps answer three questions quickly: what is connected, who owns it, and what would break if access were removed.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SSO catalogues track which apps rely on organizational user authentication. |
| IA-5 — Authenticator Management | Catalogues should reflect the lifecycle of tokens, assertions, and related sign-in material. | |
| Recommendation — Verify each catalogued app uses approved organizational authentication paths. Track and retire authentication material for every app in the catalogue. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | An SSO catalogue is an application inventory for governed identity-connected systems. |
| GV.OC-03 — Roles, responsibilities, and authorities are established and communicated | Catalogue governance depends on clear ownership for each integrated application. | |
| Recommendation — Keep the SSO catalogue synchronized with the broader application inventory. Assign and communicate ownership for every app listed in the catalogue. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | The catalogue functions as an inventory of identity-integrated applications and their trust relationships. |
| Recommendation — Maintain the catalogue as a controlled inventory of federated applications. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org