Access brokerage is a pattern where users connect through a control plane instead of handling underlying credentials directly. It reduces secret exposure, centralises policy enforcement, and improves auditability because the user never receives the reusable password or key.
Expanded Definition
Access brokerage is an NHI access pattern in which a control plane brokers authentication and authorisation so a user or workload can reach a target system without ever handling the reusable secret directly. That distinction matters because the broker becomes the policy enforcement point, while the credential remains protected behind a managed trust boundary. In practice, access brokerage often sits alongside brokering patterns used in PAM, ZTA, and NHI governance, but no single standard governs this term yet and usage in the industry is still evolving. The clearest mental model is that the broker issues, mediates, or presents access on demand, rather than distributing a long-lived password, API key, or certificate to the requester. This reduces blast radius, supports logging, and makes revocation more actionable. For a broader NHI context, NHI Management Group’s Ultimate Guide to NHIs explains why secret handling and lifecycle control are foundational to this model, and the OWASP Non-Human Identity Top 10 places secret exposure and privilege misuse in direct focus. The most common misapplication is treating simple credential forwarding as brokerage, which occurs when a gateway relays a reusable secret instead of mediating access through policy-controlled issuance.
Examples and Use Cases
Implementing access brokerage rigorously often introduces latency and operational dependency on the broker, requiring organisations to weigh tighter control and auditability against added complexity and a new availability tier.
- A developer authenticates to a brokered portal, and the control plane opens a session to a database without revealing the database password.
- A CI/CD pipeline requests temporary access to a cloud environment through a broker, rather than storing long-lived keys in build scripts.
- A support analyst uses a broker to reach a production service account, with approvals, session recording, and time-bound access enforced centrally.
- A workload federation flow exchanges identity assertions for scoped access, aligning with brokered trust patterns described in the Ultimate Guide to NHIs and access federation guidance in CISA Zero Trust Maturity Model.
- An incident response team uses broker logs to reconstruct who accessed a secret-backed system, improving forensics compared with direct credential sharing.
In standards terms, the closest operational parallels come from access mediation and federated trust patterns, but implementations vary across vendors and environments. The 52 NHI Breaches Analysis is useful for seeing how weak secret handling turns into real compromise pathways.
Why It Matters in NHI Security
Access brokerage matters because it changes who ever sees the credential and therefore who can leak, reuse, or overprivilege it. In NHI environments, the risk is not just authentication failure; it is uncontrolled distribution of secrets across pipelines, scripts, operators, and third parties. NHI Management Group reports that 96% of organisations store secrets outside of secrets managers, a signal that direct secret handling remains deeply embedded in everyday operations. Brokered access helps reduce that exposure by making policy, rotation, and revocation centralised rather than scattered across endpoints. It also supports better alignment with the OWASP Non-Human Identity Top 10 and with Zero Trust expectations that every access request should be explicitly mediated. When brokerage is absent or poorly designed, teams often discover excessive standing access only after a secret leak, a compromised pipeline, or an audit finding, at which point access brokerage 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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) 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 access patterns that reduce exposure. |
| NIST Zero Trust (SP 800-207) | JSDM | Zero Trust mediates every request through policy, matching brokerage behavior. |
| NIST CSF 2.0 | PR.AC-1 | Access permissions and controlled entry are core to brokered identity flows. |
Broker access so users never receive reusable secrets and enforce logged, time-bound control.
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
