Encrypted Assertions

How encrypted assertions work

Encrypted assertions are a confidentiality layer on top of identity assertions. The assertion still carries claims about an authenticating party or subject, but encryption limits who can read those claims while they are in transit or at rest inside a federation message or token.

This matters because federation often crosses trust boundaries. If an assertion is intercepted, copied, logged, or inspected by an unintended intermediary, the confidentiality of the claims can be exposed even when the signature remains intact. Encryption helps preserve privacy over the contents without changing the basic role of the assertion in the trust flow.

Why they are used in federated identity

In federated authentication, the relying party needs the claims, but not every system that handles the message should be able to see them. Encrypted assertions support that model by ensuring only the intended receiver can decrypt and evaluate the content for authentication or authorisation decisions.

That makes them especially useful when the assertion may pass through shared infrastructure, brokers, gateways, or diagnostic pipelines. The security objective is not secrecy for its own sake, but controlled disclosure of identity data to the party that is supposed to consume it.

What encryption changes, and what it does not

Encryption protects confidentiality, but it does not replace authentication, integrity, or trust in the assertion issuer. The relying party still needs to verify that the assertion came from a trusted source and that the claims are valid for the transaction being processed.

It also does not remove the need to manage the surrounding token or message correctly. Headers, metadata, routing fields, and transport logs may still reveal context, and poor handling of keys or decryption endpoints can undermine the protection the encryption is meant to provide.

Operational considerations for implementation

The practical design question is where assertion confidentiality should be enforced, and which parties must be able to decrypt it. Teams should be clear about key ownership, recipient identity, and how the assertion is protected across every hop in the federation path.

Encrypted assertions are most effective when paired with disciplined federation configuration and clear trust relationships. If the receiving system cannot decrypt what it is meant to consume, or if too many components are allowed to access the key material, the control loses much of its value.

Risk and Threat Considerations

Encrypted assertions reduce exposure of identity claims, but they can create false confidence if organisations assume confidentiality alone solves federation risk. Weak key handling, overly broad decryption access, or logging of decrypted content can still expose claims that were meant to stay private.

Failure mechanism: An attacker or unintended intermediary gains access to the assertion content through key compromise, misrouted decryption, insecure storage, or an implementation that exposes plaintext after decryption.

Impact: Sensitive identity data, authentication claims, or authorisation-relevant attributes can be disclosed, replayed in adjacent flows, or used to support impersonation and privilege abuse.

Practitioner Guidance

Why practitioners should care: Encrypted assertions are only as strong as the federation path around them, so the control should be treated as part of a broader trust design rather than as a standalone safeguard. The key question is whether only the intended relying party can actually read the claims at the point of use.

What to watch for: Review whether assertions are encrypted end-to-end for the intended recipient, whether decryption keys are tightly controlled, and whether any observability or troubleshooting tooling could expose plaintext claims. If a message must be readable by multiple hops, the confidentiality promise is already weakened.

Related resources from NHI Mgmt Group

• What breaks when SAML assertions are not tightly validated?
• How do organisations decide whether encrypted computation is enough for a use case?
• What do teams get wrong when they rely on encrypted tunnelling for access security?
• How should security teams govern encrypted file access in enterprise environments?