A request header used to carry an authenticated user or workload identity across infrastructure layers. In secure designs, the header is only trustworthy when injected by verified upstream systems, because a client that can set the same header can impersonate identity and alter authorisation outcomes.
Expanded Definition
An identity header is a trust-bearing request header used to carry an authenticated user or workload identity across infrastructure layers. It is common in reverse-proxy, service-mesh, API gateway, and federated access patterns where one trusted component asserts identity to downstream services.
The key boundary is trust, not syntax. A header with a familiar name is not inherently authoritative; it becomes meaningful only when downstream systems accept it exclusively from a verified upstream source. If untrusted clients can set or overwrite the same header, the header stops being an identity signal and becomes an impersonation vector.
Usage varies across vendors and architectures. Some systems treat identity headers as internal routing metadata, while others use them as part of authorisation decisions. That distinction matters because an identity header should not replace the actual authentication layer that established the identity in the first place. The practical rule is simple: the header can propagate identity, but it should never originate trust on its own.
Examples and Use Cases
Identity headers show up wherever one layer authenticates on behalf of another and needs to pass identity context downstream without redoing the full login flow at every hop.
- A gateway verifies a user session, then forwards a signed or otherwise controlled identity header to microservices that enforce per-user access rules.
- A service mesh injects workload identity into internal requests so adjacent services can apply tenant or role-aware policy without exposing credentials to each service.
- An internal admin portal passes a verified operator identity to audit services so actions can be attributed consistently across distributed systems.
- A backend API receives identity context from a trusted edge proxy and uses it for logging, entitlement checks, or request scoping.
- A federated integration inserts an identity header after authentication so downstream legacy systems can consume identity context they could not establish themselves.
The tradeoff is convenience versus trust boundary complexity. Identity headers reduce repeated authentication handling, but they also create a sharp requirement for header sanitisation, proxy enforcement, and clear source-of-truth ownership.
Security Implications
If an identity header is accepted from the wrong place, the failure is usually impersonation rather than simple spoofing. A client that can inject the same header may be treated as another user, another workload, or an internal actor with broader access than intended.
That can lead to broken authorisation, misleading audit trails, tenant crossover, and privilege escalation inside otherwise well-protected networks. The risk is especially acute when downstream services trust the header more than the authentication context that created it.
Misuse often shows up as inconsistent identity attribution across services, unexplained access grants, or logs that appear to identify a caller but cannot prove where the identity claim came from. NHIMG notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which reflects how often machine-facing trust paths become the real attack surface. For identity headers, the practitioner clue is whether the header is being treated as evidence or merely as forwarded context.
Domain and Governance Relevance
Identity headers matter in NHI governance because they often sit at the boundary between authenticated machine activity and downstream authorisation. When the asserted identity belongs to a service account, workload, or agent, the header becomes part of the machine identity chain rather than a simple transport convenience.
That changes governance in two ways. First, ownership must be clear: which trusted layer injects the header, which services are allowed to consume it, and which systems may never accept it directly. Second, lifecycle controls matter because the identity represented by the header may map to credentials, tokens, or certificates whose revocation and rotation determine whether the header still reflects a valid actor.
In practice, identity headers are a control surface for trust propagation. In NHI-heavy environments, they deserve the same scrutiny as any other machine identity assertion because downstream privilege often follows the header, not the original user interaction.
Risk and Threat Considerations
Identity headers create a material trust-boundary risk when downstream systems cannot distinguish a genuine upstream assertion from a client-supplied value. That makes them attractive for impersonation, authorisation bypass, and lateral movement inside service-to-service paths.
Failure mechanism: the weakness appears when proxies fail to strip inbound copies, services trust header contents without verifying source, or multiple layers independently interpret the same header as authoritative. An attacker then supplies or relays a forged identity claim and inherits the privileges attached to it.
Impact: the result can be account impersonation, tenant data exposure, incorrect audit attribution, and privilege escalation across internal applications. In distributed systems, one compromised trust point can contaminate downstream access decisions at scale.
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 CIS Controls v8, CIS Controls v8, MITRE-ATTACK and MITRE-ATTACK set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity headers propagate non-human identity across services and must be trusted only from verified sources. |
| Recommendation: Treat forwarded identity as untrusted unless its origin and injection point are enforced. | ||
| CIS Controls v8 | 6.3 | Identity headers can expose sensitive identity context if passed or logged without controls. |
| Recommendation: Protect identity-bearing headers from unauthorized disclosure and unsafe handling. | ||
| CIS Controls v8 | 8.2 | Header-based identity often depends on proxies, gateways, and internal services that must be controlled. |
| Recommendation: Know which components can set, pass, or consume identity headers. | ||
| MITRE-ATTACK | T1550 | Forged identity headers can be abused as alternate trust material to impersonate a caller. |
| Recommendation: Block abuse of forwarded identity claims as a substitute for authentic proof. | ||
| MITRE-ATTACK | T1134 | Identity headers may carry or represent delegated access context that attackers try to alter. |
| Recommendation: Detect and prevent manipulation of identity-bearing trust context. | ||
Practitioner Guidance
What to watch for: the critical question is whether the header is ever allowed to enter from an untrusted boundary. If the same value can arrive from a client, a test harness, or an intermediate service that was not meant to assert identity, the trust model is already weakened.
Governance implication: teams should treat identity-header ownership as a policy decision, not an implementation detail. The source system, allowed propagation path, and consuming services need a single, explicit trust contract so the header remains contextual metadata instead of a bearer of authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
