Credential brokering is the process of using a trusted identity proof to issue a separate credential for a target system that cannot accept the original identity natively. It is useful for compatibility, but it also becomes a control point for scope, duration, logging, and revocation.
Expanded Definition
Credential brokering sits between an originating identity proof and a target system that cannot consume that proof directly. In NHI environments, that often means a broker exchanges one trusted assertion for another credential with a narrower audience, shorter lifetime, or different format. The concept is related to federation and token exchange, but usage in the industry is still evolving and definitions vary across vendors.
Used well, brokering reduces friction for legacy platforms while preserving central control over issuance, audit, and revocation. Used poorly, it becomes a bypass layer that quietly accumulates standing privileges, stale mappings, and weakly governed exceptions. The operational goal is to keep the broker authoritative without turning it into an indiscriminate minting service. Guidance in NIST SP 800-63 Digital Identity Guidelines helps frame identity assurance, even though the standard does not prescribe every brokering pattern used for machine identities today.
The most common misapplication is treating credential brokering as a one-time integration fix, which occurs when teams reuse broad broker-issued credentials across multiple systems without scoping or expiry discipline.
Examples and Use Cases
Implementing credential brokering rigorously often introduces latency and governance overhead, requiring organisations to weigh compatibility gains against the cost of tighter issuance controls, logging, and renewal logic.
- A workload identity from a modern control plane is exchanged for a short-lived database credential so a legacy service can authenticate without storing the original secret. This pattern is safer when paired with Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- A CI/CD platform brokers access to cloud APIs during deployment, issuing time-bound permissions only for the pipeline stage that needs them. That approach reduces blast radius, as discussed in the CI/CD pipeline exploitation case study.
- An AI agent receives a brokered credential to call an internal tool, but the broker restricts the tool scope and records the request chain for later review. This aligns with the control expectations described in the OWASP Non-Human Identity Top 10.
- A SaaS integration uses brokering to convert an external SSO assertion into an app-specific token, avoiding direct password storage while maintaining traceability.
- A secrets platform brokers access for ephemeral automation jobs, then revokes the issued credential as soon as the task completes, limiting exposure if the job is compromised.
Broking is especially valuable when a target system cannot natively trust the source identity format, or when policy requires a different session lifetime than the upstream identity can provide.
Why It Matters in NHI Security
Credential brokering is where compatibility and control collide. If the broker is misconfigured, it can quietly reintroduce the very risks NHI programs are meant to remove: long-lived secrets, privilege creep, weak revocation, and limited attribution. That is why broker policy should be treated as security logic, not just plumbing. The broader NHI problem is already severe: The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM maturity, and 59.8% want simpler non-human access management with dynamic ephemeral credentials.
Those findings matter because brokering is often introduced exactly where organizations are already struggling with hybrid estates, secret sprawl, and inconsistent access controls. The broker becomes a high-value enforcement point for scope, duration, logging, and revocation, but only if teams resist the temptation to issue broad reusable tokens. Research on Guide to the Secret Sprawl Challenge shows how quickly unmanaged credentials accumulate, while incidents like the MongoBleed breach illustrate the downstream cost of exposed or overextended access paths. Organisations typically encounter the real impact only after a brokered credential is abused, at which point credential brokering becomes operationally unavoidable to investigate and tighten.
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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and brokered credential exposure risks for non-human identities. |
| NIST SP 800-63 | AAL2 | Identity assurance guidance informs how brokered credentials should inherit trust and expiry. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control maps directly to credential brokering scope and revocation. |
Issue brokered credentials only at an assurance level appropriate to the target system's sensitivity.
