A policy object that maps token claims from an identity provider to a service account or access scope in a target system. It defines which workload identities are allowed to exchange tokens, what conditions must match, and how the resulting access should be constrained.
Expanded Definition
A federation rule is the policy layer that turns a trusted token into usable workload identity within a target system. It maps claims from an external issuer, such as issuer, audience, subject, or group membership, to a service account, role, or access scope, and it also sets the conditions under which token exchange is allowed. In NHI programs, federation rules are part of the control plane for workload identity, not a generic routing rule or a simple allowlist.
Definitions vary across vendors, but the common pattern is consistent: a federation rule evaluates trust, asserts identity continuity, and narrows the resulting privileges so the target system does not grant more access than the source token justifies. That makes it closely related to policy enforcement in NIST Cybersecurity Framework 2.0, especially where identity proofing, access control, and continuous governance intersect.
The most common misapplication is treating a federation rule as a one-time login mapping, which occurs when teams allow broad token claims to resolve to persistent high-privilege access without validating scope, audience, or workload context.
Examples and Use Cases
Implementing federation rules rigorously often introduces operational friction, requiring organisations to weigh workload agility against the cost of tighter claim validation and more frequent policy maintenance.
- A Kubernetes workload exchanges a signed token for a cloud role only when the issuer, namespace, and service account all match the expected claims.
- A CI/CD pipeline assumes a deployment identity only if the token audience is the release service and the request originates from an approved build context.
- An API gateway maps external partner assertions to a constrained access scope, limiting the partner workload to read-only access on one resource set.
- A workload federation setup rejects tokens with mismatched audience values, preventing token replay across environments and reducing lateral movement risk.
- A zero trust deployment uses claim-based rules to replace static credentials with short-lived, policy-bound access, aligning with guidance described in the Ultimate Guide to NHIs.
For implementation patterns, workload identity federation guidance in NIST Cybersecurity Framework 2.0 is most useful when the rule must enforce least privilege across systems that do not share a native identity store.
Why It Matters in NHI Security
Federation rules matter because they define the trust boundary between token issuance and actual access. If the mapping is too broad, a compromised workload identity can impersonate multiple services or gain permissions far beyond its intended scope. If the rule is too permissive about claims, attackers can abuse weak audience checks, stale subjects, or overbroad group mappings to pivot into production systems. This is especially dangerous in environments where NHIs already outnumber humans by 25x to 50x and where 97% of NHIs carry excessive privileges, as documented in Ultimate Guide to NHIs.
Well-designed federation rules also reduce the reliance on long-lived secrets by making access conditional and short-lived rather than static. That supports broader governance goals in NIST Cybersecurity Framework 2.0, where identity-centric control and resilience are core priorities. Organisations typically encounter the cost of a weak federation rule only after a token is replayed, a pipeline is hijacked, or an external issuer is abused, at which point the rule becomes operationally unavoidable to fix.
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-05 | Federation rules govern token exchange and claim-to-access mapping for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and enforced through identity-based conditions. |
| NIST Zero Trust (SP 800-207) | AC-1 | Zero Trust requires continuous trust evaluation at the point of access. |
Restrict token exchange to explicit claims and map each workload to the minimum required access.
