Workload identity proves who the workload is, usually through attestation and short-lived certificates or tokens. Credential brokering is the translation layer that turns that proof into a resource-specific credential for systems that do not accept the native identity. In practice, the first answers trust and the second answers compatibility.
Why This Matters for Security Teams
Workload identity and credential brokering solve different problems, and confusing them creates design gaps that show up later as outages, overprivileged access, or secret sprawl. Workload identity is the cryptographic proof that a workload is what it claims to be. Credential brokering is the compatibility layer that converts that proof into a format a downstream system accepts. The distinction matters most in hybrid environments where old systems still expect passwords, API keys, or static certificates. Guidance from the SPIFFE workload identity specification treats identity as the foundation, while NIST SP 800-63 Digital Identity Guidelines reinforces the broader principle that proof and assertion are not the same thing.
NHIMG research shows why this separation matters operationally: the Critical Gaps in Machine Identity Management report found that 57% of organisations lack a complete inventory of machine identities, which makes it hard to know what is authentic, what is brokered, and what is simply unmanaged. That is especially dangerous when teams rely on brokers as if they were the identity source. In practice, many security teams encounter credential leakage only after a brokered path has been over-trusted instead of through intentional identity design.
How It Works in Practice
In a well-formed model, workload identity comes first. The workload authenticates using an attested identity method, such as a SPIFFE ID, an OIDC token bound to the runtime, or a short-lived certificate issued after environment checks. That identity can then be evaluated against policy to determine whether the workload should be allowed to request a credential for a specific target. Credential brokering sits in the middle: it exchanges verified workload identity for a resource-specific credential, often translating into a database login, cloud access token, message broker secret, or legacy application certificate.
This is why the two controls should be designed separately. Workload identity answers who the workload is. Brokering answers how an authenticated workload gets something a downstream service can understand. In modern NHI architectures, that often means ephemeral credentials and short TTLs rather than static secrets. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it highlights the difference between durable secrets and short-lived access material. The Guide to SPIFFE and SPIRE is also helpful for understanding how identity can be issued independently of the final target system.
- Use workload identity for attestation, authentication, and policy input.
- Use credential brokering only when the target system cannot consume the native identity.
- Prefer short-lived, automatically revoked credentials over long-lived shared secrets.
- Log the exchange from identity to credential so auditors can trace both trust and access.
NHIMG’s research also shows the human side of this problem: the 2024 Non-Human Identity Security Report found that 23.7% of organisations still share secrets through insecure methods like email or messaging apps, which is exactly what brokering should eliminate, not extend. These controls tend to break down in legacy estates where applications only accept static credentials because the broker becomes the new secret warehouse.
Common Variations and Edge Cases
Tighter brokering often increases integration overhead, so organisations have to balance compatibility against the risk of creating another high-value credential service. That tradeoff is real, especially when brokers sit between cloud-native workloads and legacy databases, mainframes, or vendor platforms that cannot natively consume workload identity. Current guidance suggests treating the broker as a temporary translation layer, not the security boundary itself. The identity boundary should remain at the workload.
There is no universal standard for every brokering pattern yet. Some teams broker to a database-native credential, others mint an OAuth token, and others issue a certificate that is consumed by a sidecar or gateway. What matters is that the broker does not become a static secret dispenser. Once that happens, the organisation loses the security value of workload identity and recreates the same secret sprawl seen in breaches like the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign.
The practical rule is simple: if the target accepts native workload identity, use it directly; if it does not, broker only the minimum credential required, for the shortest possible time. That approach aligns with the OWASP Non-Human Identity Top 10 and keeps the compatibility layer from becoming the identity system itself.
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-03 | Separates workload identity from secret handling and brokered credentials. |
| NIST SP 800-63 | Distinguishes identity proofing from downstream credential issuance and use. | |
| NIST CSF 2.0 | PR.AC-1 | Access control must verify identity before granting resource-specific access. |
Bind brokered access to verified workload identity and enforce least privilege at request time.
