Cerbos native JWT verification reduces policy drift in identity checks

At a glance

What this is: Cerbos adds native JWT verification so policy conditions can use trusted claims without custom token parsing in every service.

Why it matters: For IAM and security teams, centralised verification reduces inconsistent access decisions across services and makes JWT governance easier to audit across NHI and human identity flows.

By the numbers:

• Credentials remain a leading initial action in breaches at 24 percent in 2024.
• The 2024 Verizon DBIR shows use of stolen credentials as the top initial action at 24 percent.

👉 Read Cerbos' article on native JWT verification and policy claims

Context

JWT verification is the control that turns a bearer token from an untrusted string into an access signal you can use in policy. In practice, the problem is not token format alone. It is whether issuer, audience, expiry, and signature checks happen consistently everywhere the token is consumed, especially in environments where multiple services make independent authorisation decisions.

Cerbos addresses that governance gap by moving verification into the policy decision layer and exposing claims to conditions after validation. For identity teams, that matters because duplicated parsing in application code creates drift, hidden exceptions, and review blind spots across NHI and human access paths.

The primary topic here is centralised JWT handling, but the broader identity lesson is familiar: when trust checks are scattered across services, access policy becomes hard to reason about and harder to audit. Standardising verification at one control point is often the difference between consistent enforcement and accidental privilege acceptance.

Key questions

Q: How should security teams centralise JWT verification across services?

A: Security teams should verify JWTs once at a policy decision point, then expose only validated claims to downstream logic. That reduces duplicated parsing, keeps issuer and audience checks consistent, and makes audits easier. The key is to treat token verification as part of access control, not as application boilerplate.

Q: Why do JWT claims create risk when each service handles them differently?

A: JWT claims become risky when services parse, trust, or transform them in different ways. Inconsistent audience checks, issuer checks, and clock-skew handling can produce different authorisation outcomes for the same token. Centralised validation removes that drift and gives identity teams one place to enforce trust decisions.

Q: What should teams do when JWKS keys rotate frequently?

A: Teams should rely on JWKS endpoints, define a refresh interval or honour cache headers, and map requests to the correct keyset explicitly. That keeps verification current without restarts and avoids the common failure mode where stale keys force teams into temporary exceptions that outlive the migration.

Q: How do you know whether JWT verification is actually working as intended?

A: You know it is working when every service rejects the same invalid token for the same reason and valid tokens are accepted only after issuer, audience, expiry, and signature checks pass. If acceptance differs across services, the control is fragmented and the identity trust boundary is not stable.

Technical breakdown

How native JWT verification changes the policy decision path

Cerbos reads the bearer token from the request, validates it against a configured key set, and only then exposes claims under request.auxData.jwt. That sequence matters because policy evaluation is separated from token parsing. Instead of every service decoding claims and reimplementing checks, the policy engine becomes the single place where signature, expiry, not-before, issuer, and audience logic are enforced before attributes are used in CEL expressions.

Practical implication: centralise verification in the policy layer and remove token parsing from each caller.

JWKS caching, rotation, and multi-keyset handling

The engine can load keys from a remote JWKS endpoint or local files, and it respects HTTP cache headers or an explicit refresh interval. That gives teams a way to handle signing-key rotation without restarts while still keeping verification strict. Multiple keysets also matter in migration scenarios, where a request may need to be matched to the correct issuer or environment before the claims are trusted.

Practical implication: configure rotation and cache behaviour explicitly so key freshness does not depend on manual redeploys.

Issuer, audience, and subject checks in policy conditions

Once verified, claims such as iss, aud, and sub can be combined with principal and resource attributes inside policy logic. This is the important part of the control plane story: the token is no longer being trusted because it exists, but because it matches the intended issuer, the intended audience, and the intended subject for the requested action. That removes a common source of subtle authorisation bugs.

Practical implication: enforce issuer, audience, and subject consistency in policy rather than relying on application code conventions.

Threat narrative

Attacker objective: The attacker aims to reuse a valid-looking token to gain access across services that should not have accepted it.

1. Entry occurs when an attacker presents a stolen or otherwise exposed bearer token to downstream services that trust the request without consistent verification.
2. Escalation happens when applications duplicate JWT parsing and miss checks such as audience, issuer, or clock skew, allowing claims to be accepted out of context.
3. Impact is unauthorised access through inconsistent policy decisions, where one service accepts a token that another service would have rejected.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Centralised JWT verification is an identity governance control, not just an application convenience. When every service parses and validates tokens differently, policy drift becomes inevitable. A central verifier makes issuer, audience, and signature checks enforceable once and reused everywhere, which is exactly the kind of consistency identity governance depends on. Practitioners should treat token verification as part of access policy design, not as incidental plumbing.

JWT claim reuse becomes dangerous when claims are trusted before they are normalised. The moment application code copies claims into request payloads, the team creates a second trust boundary it must now audit. That duplicated logic increases the chance of time-skew errors, algorithm confusion, and issuer mismatch. The practical conclusion is simple: trust claims only after a single, validated decision point has approved them.

Verification drift: the failure mode here is not weak JWTs, but inconsistent enforcement across services. The same token can be accepted in one path and rejected in another when key rotation, cache behaviour, or audience checks differ. That inconsistency turns access control into a probabilistic system. Practitioners should see this as a governance problem, because auditability depends on deterministic validation.

Stolen credential reuse remains the backdrop for token governance decisions. When breach data shows stolen credentials as a top initial action, the operational question is not whether tokens are convenient but whether they are consistently validated at the point of decision. Centralised JWT handling improves that decision quality across NHI and human access paths. Security teams should align policy enforcement with the place where trust is actually established.

Policy engines are now part of the identity trust perimeter. Once claims flow into policy conditions, the correctness of JWKS selection, cache refresh, and expiry checks becomes security-relevant infrastructure. That raises the bar for operational ownership and review. Practitioners should assign JWT verification the same control attention they give to federation and access review.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• Centralising token trust decisions aligns with the lifecycle problem discussed in the Ultimate Guide to NHIs, where visibility, rotation, and offboarding determine whether credentials remain governable.

What this signals

The operational signal here is that JWT handling is no longer just an authentication implementation detail. Once claims influence policy decisions, teams need a single trust boundary for validation, rotation, and audit. Verification drift: if different services accept the same token differently, the programme has already lost consistency. For broader identity governance context, compare this with the control model in the Ultimate Guide to NHIs.

With 91% of former employee tokens remaining active after offboarding, according to The 2025 State of NHIs and Secrets in Cybersecurity, token trust cannot be treated as static. That figure is a lifecycle warning, not just a secrets-management statistic. Teams should align JWT validation, key rotation, and offboarding controls so stale credentials do not survive beyond their legitimate use.

For IAM and NHI programmes, the forward signal is consolidation around fewer, more authoritative decision points. Centralised validation makes audits cleaner, but only if JWKS refresh, claim checks, and policy ownership are formally managed. Teams that already rely on OIDC should use this as a cue to tighten how request claims enter the authorisation layer, not to widen trust in the token itself.

For practitioners

• Centralise JWT verification at the policy layer Move signature, issuer, audience, and expiry checks out of application code and into one decision point so every service evaluates the same trusted claims.
• Define explicit JWKS rotation behaviour Set cache headers or a refresh interval, and document how each keyset is selected so key rotation works without restarts or ad hoc exceptions.
• Enforce claim consistency in policy conditions Require issuer, audience, and subject checks in CEL expressions before allowing a request to proceed, especially where multiple identity providers are in play.
• Audit duplicate token parsing paths Inventory services that still decode JWTs locally and remove any second validation path that could accept claims differently from the central engine.

Key takeaways

• Centralised JWT verification reduces drift by ensuring every service uses the same issuer, audience, expiry, and signature checks.
• The scale of credential risk remains high, with stolen credentials still a leading initial action in breaches and former employee tokens often left active after offboarding.
• Practitioners should move token trust into the policy layer, document JWKS rotation behaviour, and eliminate duplicate parsing paths.

Key terms

• Jwt Verification: JWT verification is the process of checking a token’s signature, issuer, audience, expiry, and not-before values before any claims are trusted. In identity programmes, it is the control that separates a usable assertion from an untrusted string, making access decisions auditable and consistent.
• Jwks: A JWKS, or JSON Web Key Set, is a published set of public keys used to verify signed JWTs. It supports key rotation by letting systems fetch updated signing material from a trusted endpoint instead of hard-coding keys or redeploying every time an issuer changes its keys.
• Claim Bridging: Claim bridging is the practice of exposing verified token claims to policy logic or downstream systems after validation. Done properly, it preserves trust boundaries. Done poorly, it creates a second interpretation layer where application code can reintroduce inconsistency, drift, or over-trust in token contents.
• Audience Restriction: Audience restriction limits a token to the service or resource it was meant for, usually through the aud claim. It prevents a valid token from being reused in the wrong context, which is essential when the same identity provider issues credentials to multiple applications or environments.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Cerbos: native JWT support for policy-driven verification and claims usage. Read the original.