An integration broker is a service that centralises connection handling between an application and third-party providers. It reduces application complexity, but it also becomes part of the identity trust boundary because it can store credentials, refresh tokens, and mediate authorization decisions.
Expanded Definition
An integration broker is the intermediary layer that handles authentication, token exchange, request routing, and provider-specific connector logic between an application and external services. In NHI security, it is more than middleware because it can hold long-lived secrets, refresh tokens, certificates, and policy logic that influences what the application is allowed to do. That makes the broker part of the trust boundary, not just an implementation convenience.
Definitions vary across vendors and architecture teams on whether the broker is treated as a pure integration component or as a delegated identity control point. NHI Management Group treats it as an identity-relevant system whenever it can mint, store, forward, or refresh credentials on behalf of workloads. This distinction matters because the broker may become a single concentration point for secret exposure, privilege escalation, or silent over-permissioning. For broader control context, the NIST Cybersecurity Framework 2.0 emphasises disciplined access, monitoring, and resilience around such critical dependencies.
The most common misapplication is treating the broker as a neutral transport layer, which occurs when teams ignore the credentials and authorization state it persists.
Examples and Use Cases
Implementing an integration broker rigorously often introduces operational concentration risk, requiring organisations to weigh simpler application code against stronger controls for credential custody, rotation, and auditability.
- A SaaS connector broker stores API keys for dozens of downstream services, so a single compromise can cascade across multiple business systems.
- An internal workflow platform uses the broker to exchange OAuth tokens with external partners, while the application itself never sees the partner credentials directly.
- A data pipeline broker normalises access to CRM, billing, and support tools, reducing integration sprawl but creating one privileged policy enforcement point.
- A broker mediates machine-to-machine access in a Zero Trust design, aligning with the governance guidance in the Ultimate Guide to NHIs and the service-identity principles used by SPIFFE.
- A legacy application uses the broker to wrap brittle vendor APIs, allowing controlled retries, throttling, and secret rotation without rewriting the core product.
Because brokers often centralise many integrations, they are useful for standardising logging and least-privilege enforcement, but they also demand stronger segregation of duties than a simple proxy or message queue.
Why It Matters in NHI Security
An integration broker becomes a security issue when it accumulates secret material, broad delegated access, and weakly reviewed connector permissions. NHI Management Group research shows that Ultimate Guide to NHIs reports 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges, which makes broker-centric architectures especially sensitive to sprawl and privilege inflation. Even when teams intend the broker to reduce complexity, poor lifecycle control can turn it into the fastest path from one compromised integration to many.
That is why broker governance should include secret inventory, rotation, connector-level scoping, and logging that can reconstruct which workload accessed which provider and when. The control objective aligns with NIST Cybersecurity Framework 2.0 by strengthening access control, detection, and recovery around a high-value dependency. Organisations typically encounter the full operational impact only after a connector is abused or a token leak is discovered, at which point the integration broker becomes operationally unavoidable to investigate and contain.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Brokers often store and forward secrets, which OWASP-NHI treats as a core risk area. |
| NIST CSF 2.0 | PR.AC-4 | Brokered access affects how identities are authenticated and authorized across systems. |
| NIST Zero Trust (SP 800-207) | Integration brokers sit inside the trust boundary and must be validated like other access paths. |
Inventory broker-held secrets, rotate them, and restrict connector permissions to least privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
