When should security teams use JWE instead of only signing tokens?

Use JWE when the token payload contains sensitive information that should remain confidential outside the intended recipient, such as claims, scopes, PII, or internal business data. Signing alone proves integrity, but it does not hide the payload. If intermediaries can inspect or store the token, encryption becomes a necessary additional control.

Why This Matters for Security Teams

Signing a token answers one question only: has the payload been altered? It does not answer whether the payload should be readable by anyone who touches it in transit, in logs, or in downstream platforms. That distinction matters when tokens carry scopes, claims, or embedded business context that would create immediate blast radius if exposed. Current guidance from NIST Cybersecurity Framework 2.0 still maps this to a straightforward confidentiality control problem: protect data at rest and in motion based on sensitivity, not on convenience.

NHIMG research shows why this is not theoretical. In The 2025 State of NHIs and Secrets in Cybersecurity, 44% of NHI tokens were found exposed in the wild through platforms like Teams, Jira, Confluence, and code commits. That exposure pattern is exactly where JWS-only designs become risky, because integrity does nothing once a token is copied into an unreadable-but-valid form that still leaks enough context to be abused. In practice, many security teams discover the need for encryption only after a token has already been forwarded, logged, or pasted into a ticket.

How It Works in Practice

JWE is appropriate when the recipient must both authenticate the token and keep its contents confidential from intermediaries. In practice, that means the issuer encrypts the payload for a specific recipient key, while the recipient decrypts it after verifying it is the intended audience. If the architecture only needs tamper evidence and the claims are harmless if observed, signing alone is often sufficient. If the payload includes PII, internal tenant identifiers, embedded entitlements, or short-lived session context, encryption becomes the stronger default.

That distinction is especially important for NHI workflows where tokens move through brokers, gateways, queues, or observability stacks. A signed token may still be readable by reverse proxies, message handlers, or support teams with access to logs. The Guide to the Secret Sprawl Challenge shows how quickly sensitive material spreads once it lands outside its intended trust boundary. NIST’s framework language is useful here because it separates integrity from confidentiality and pushes teams to apply controls according to exposure risk, not token format.

• Use JWS when recipients only need to verify authenticity and the claims are safe to disclose.
• Use JWE when the payload contains secrets, sensitive claims, or business context that should stay opaque.
• Prefer short-lived tokens and narrow audiences so encrypted content has a smaller replay window.
• Keep encryption keys scoped to the recipient service, not shared across unrelated workloads.

For token-handling environments, this often pairs with the operational lessons in the Salesloft OAuth token breach, where stolen credentials became a direct path to downstream data access. These controls tend to break down when tokens must be inspected by multiple intermediaries because each inspection point expands the confidentiality surface.

Common Variations and Edge Cases

Tighter encryption often increases integration overhead, so teams have to balance confidentiality against operational complexity. That tradeoff is real in distributed systems, where debugging, message routing, and analytics may depend on reading token fields. Best practice is evolving, and there is no universal standard for when every token should be encrypted by default. The decision usually depends on who must read the payload and whether that exposure is acceptable.

One common edge case is nested tokens, where a signed JWS is wrapped inside a JWE. That pattern preserves integrity while hiding sensitive claims, but it also increases key management burden and can complicate validation logic. Another is internal-to-internal service traffic, where teams assume the network is trusted. The JetBrains GitHub plugin token exposure is a reminder that internal tooling and developer workflows often become the first place secrets leak, not the last. In those environments, encryption should be considered alongside JIT secrets, workload identity, and least-privilege access rather than as a standalone fix.

JWE is also not a substitute for revocation, audience restriction, or token minimisation. If a token is encrypted but still too powerful, compromise remains serious once the rightful recipient decrypts it. The practical rule is simple: sign for integrity, encrypt for confidentiality, and use both when the payload would be harmful if observed outside the intended trust boundary. For broader identity and governance context, NIST Cybersecurity Framework 2.0 remains the clearest external baseline for separating protection objectives from implementation choices.

Related resources from NHI Mgmt Group

• How should security teams use context-based authentication in high-risk environments?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams govern SaaS integrations that use OAuth tokens?