An Integration Catalog is a structured inventory of available connectors, with enough metadata to support discovery, ownership, deployment, and governance. In identity environments, it helps teams manage integrations consistently, reduce shadow connections, and make onboarding or change processes easier to control and audit.
Expanded Definition
An Integration Catalog is more than a list of connectors. In NHI and IAM operations, it is the governed record of what an integration does, who owns it, what identities or secrets it uses, what environments it touches, and how it is approved, monitored, and retired. That distinction matters because a connector without metadata becomes a hidden dependency, while a catalog entry can support lifecycle control, access review, and incident response.
Definitions vary across vendors, and no single standard governs this yet. Some teams treat the catalog as an internal developer portal for approved integrations, while others use it as a compliance inventory that maps each connection to risk, business owner, rotation cadence, and rollback plan. In a Zero Trust model, that inventory becomes operationally useful because every integration is a potential trust edge, especially where service accounts, API keys, or delegated OAuth access are involved. The NIST Cybersecurity Framework 2.0 aligns well with this governance view because it expects asset visibility, ownership, and control discipline across the environment. The most common misapplication is treating an integration catalog as a static app list, which occurs when teams fail to record the identity, privilege, and secret dependencies behind each connector.
Examples and Use Cases
Implementing an integration catalog rigorously often introduces maintenance overhead, requiring organisations to weigh faster onboarding against the cost of keeping ownership and secret metadata current.
- A SaaS-to-SaaS OAuth connector is cataloged with owner, approval date, scopes, token location, and rotation interval so that a future consent review can be completed quickly.
- A CI/CD integration that deploys to production is added to the catalog with its service account, environment boundaries, and rollback contact, reducing the chance of a shadow deployment path.
- An internal API bridge is referenced alongside the NHIMG analysis of the Klue OAuth Supply Chain Breach, where delegated access became an attack path rather than a simple productivity feature.
- A third-party analytics plug-in is cataloged with data classification and change-notification requirements, then checked against NIST Cybersecurity Framework 2.0 categories for governance and monitoring.
- A shadow AI app integration is promoted into the catalog only after security review, following the lesson from Vercel Context.ai OAuth Supply Chain Breach, where unmanaged connections increased exposure.
Why It Matters in NHI Security
Integration catalogs are a control point for reducing secret sprawl, unknown trust relationships, and unowned access paths. They help teams see which connectors depend on API keys, OAuth grants, certificates, or service accounts, and that visibility is essential when the environment includes third parties and automation. NHI Management Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how quickly an overlooked integration can become the breach entry point.
This is where the catalog connects governance to response. If a connector is not recorded, it is harder to rotate its credentials, revoke its access, or confirm whether it still belongs in production. Catalog discipline also improves offboarding because abandoned integrations often keep working long after the business owner has forgotten them. The pattern is especially dangerous in environments with large numbers of service accounts, where discovery is weak and privileges are broad. The most useful catalogs link each integration to its risk owner and to the exact operational action needed when something fails. Organisations typically encounter the urgency of an integration catalog only after a token leak, OAuth abuse, or compromised connector forces emergency containment, at which point the catalog becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Integration catalogs support visibility and governance for non-human identity attack paths. |
| NIST CSF 2.0 | ID.AM | Asset management covers the need to know what integrations exist and who owns them. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit trust evaluation for each integration edge and dependency. | |
| NIST SP 800-63 | Digital identity assurance informs how credentials and delegated access should be documented. | |
| OWASP Agentic AI Top 10 | Agentic systems rely on tool and connector inventories to prevent unsafe autonomous access. |
Inventory every connector with owner, purpose, secret type, and lifecycle status before approving use.
