Why do custom JWT claims create governance risk if they are not refreshed?

Because a claim can remain technically valid after the user’s real-world status changes. If the application uses that claim for access decisions, stale department, domain, or role data can grant access that no longer matches current policy. Refresh logic and revocation rules have to match the sensitivity of the page or API.

Why This Matters for Security Teams

Custom JWT claims are often treated as a convenient shortcut for authorisation, but they can become a governance problem the moment they outlive the facts they were meant to represent. If a department, role, tenant, or entitlement changes after token issuance, the application may still trust the old claim until expiry. That creates a gap between policy and enforcement, especially in systems that cache decisions or accept long-lived tokens.

This is not just an access-control nuisance. It is a lifecycle issue that belongs in the same conversation as Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the control expectations in NIST Cybersecurity Framework 2.0. Security teams usually focus on signing and expiry, but governance risk lives in the freshness of the claim data itself, not only the cryptographic validity of the JWT.

In practice, many security teams only discover stale claims after a moved employee, changed vendor, or revoked service account still has access to a sensitive API.

How It Works in Practice

A custom claim becomes risky when the application uses it as if it were a live source of truth. For example, a token might carry Top 10 NHI Issues style entitlements such as department, environment, region, or application tier. If those claims are not refreshed, the application may continue to honour an old authorisation state even after HR, IAM, or a provisioning system has changed it.

Good practice is to separate identity proof from entitlement freshness. The token should prove who or what presented it, while the current policy engine decides what that subject can do right now. That usually means shorter token TTLs, re-issuance on meaningful state changes, and revocation rules that can invalidate access faster than waiting for natural expiration. For sensitive APIs, current guidance suggests pairing JWT validation with runtime policy checks rather than trusting embedded claims alone.

• Use short-lived access tokens when claims reflect mutable business state.
• Refresh claims on role, department, tenant, or ownership changes.
• Prefer a central policy decision point for high-risk actions.
• Treat cached claims as advisory unless they are explicitly revalidated.

When claims represent service identity or automation context, teams should also review whether the application should rely on workload identity, not just opaque session data. That is especially important when the same token is reused across multiple APIs or downstream services. Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why auditability depends on being able to explain why access was granted at the time, not only that the token signature checked out.

These controls tend to break down when tokens are issued once and then reused across long-running sessions, batch jobs, or distributed microservice chains because the claim state drifts faster than the token is refreshed.

Common Variations and Edge Cases

Tighter claim refresh rules often increase latency and operational overhead, requiring organisations to balance freshness against user experience and service load. That tradeoff is real: some workflows cannot afford a full re-authentication every few minutes, while others are too sensitive to tolerate stale authorisation at all.

Best practice is evolving, but a few edge cases are already clear. Static claims are usually acceptable only when the attribute is effectively immutable, such as a stable service identifier. Mutable claims such as manager, cost centre, region, or role should be treated as time-sensitive. For highly sensitive systems, a claim may need to be refreshed on every privileged action, not just at login.

The governance risk is greater when downstream services make independent access decisions from embedded claims without a shared policy source. It is also greater in environments with federation, delegated administration, or cross-tenant access, because the claim may be valid cryptographically but stale semantically. In these cases, the right question is not whether the JWT is expired, but whether the claim still reflects current policy. For broader context on identity lifecycle controls, see Ultimate Guide to NHIs — Key Challenges and Risks and the NIST Cybersecurity Framework 2.0 approach to least privilege and continuous control.

Where organisations rely on long-lived tokens for convenience, stale claims usually surface only after an access review, an incident, or an audit finding rather than during normal operations.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?