Should organisations rely on JWKS refresh or hard-coded signing keys?

Use JWKS refresh for production token trust whenever the issuer supports rotation. Hard-coded keys create a brittle trust model, increase operational friction during rotation, and make it easier for stale signing material to remain active longer than intended.

Why JWKS refresh is the safer default than hard-coded signing keys

JWKS refresh keeps token validation aligned with the issuer’s current signing material. That matters because signing keys are supposed to rotate, expire, and sometimes be revoked after compromise or operational change. Hard-coded keys turn that live trust relationship into a static dependency, which is fragile the moment the issuer needs to replace a key.

With JWKS, the verifier can fetch current public keys from the issuer’s published set and continue validating tokens across rotations. With hard-coded keys, every verifier becomes a maintenance point, and one missed update can leave services unable to validate legitimate tokens or, worse, still trusting retired material longer than intended.

For teams that want a concrete example of how stale signing material can become a security problem, the Microsoft Storm-0558 key breach 2023 shows why the lifetime of a signing key is part of the trust boundary, not just an implementation detail.

What operational and security trade-offs change with JWKS versus embedded keys?

The main trade-off is between resilience to rotation and local simplicity. Hard-coded keys may look easy in a single-service prototype, but they create brittle coupling across environments, teams, and release schedules. JWKS adds a dependency on key retrieval and cache handling, but it removes the need to redeploy every verifier whenever the issuer rotates keys.

That operational difference becomes material when tokens are used broadly across APIs, SSO, or service-to-service trust. A refresh-based model also supports overlapping key validity during rotation, which is the safer pattern when issuers need to publish a new key before retiring the old one. Static embedding breaks that overlap unless every consumer is updated on time.

The key-management discipline behind that decision is well covered in NHIMG’s Cryptographic Key Management Guide, which ties key lifecycle, rotation, and cryptoperiod thinking to practical verification controls.

When is hard-coding a signing key actually a bad fit?

Hard-coded signing keys are a poor fit whenever the issuer controls rotation, the trust relationship spans more than one application, or the key protects production token validation. They are especially weak when the key is long-lived, shared across systems, or stored in code and configuration that many people can copy. In those cases, the key becomes difficult to govern and easy to forget.

Hard-coding also makes incident response slower. If a signing key is suspected to be exposed, a refresh-capable verifier can move with the issuer’s replacement plan. A hard-coded verifier needs coordinated redeployment, which increases the window where stale material may remain accepted. NHIMG’s Coupang Signing Key Breach is a reminder that signing material lifecycle failures can persist as an exposure problem long after the original event.

Risk and Threat Considerations

Static signing keys create a larger blast radius when a key is exposed, copied, or forgotten during retirement. An attacker who obtains an old but still trusted signing key can continue forging tokens until every verifier stops accepting it, which turns a key-management issue into a direct trust compromise.

Failure mechanism: Verifiers that embed keys do not inherit the issuer’s rotation state, so any missed redeploy, cache, or config change can preserve trust in stale material.

Impact: Token forgery, prolonged unauthorized access, failed revocation, and operational outages during emergency rotation all become more likely when the trust anchor is static.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST SP 800-57 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	JWKS refresh and key retirement depend on managing signing material lifecycle.
Recommendation — Automate key rotation, revocation, and retirement for signing material.
NIST SP 800-57	NIST SP 800-57 Part 1 — Key Management	The question is fundamentally about signing-key lifecycle and rotation policy.
Recommendation — Apply key-lifecycle policy and cryptoperiod planning to verifier trust.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Signing-key handling and rotation are cryptographic control concerns.
Recommendation — Define cryptographic key handling and rotation requirements for token trust.
OWASP ASVS	V9 — Self-contained Tokens	JWT validation depends on correct signing-key handling and token trust decisions.
Recommendation — Validate token-signing keys dynamically and reject stale trust material.

Practitioner Guidance

What to verify: Confirm that the issuer publishes JWKS with clear rotation behavior, supports overlapping validity during key rollover, and exposes enough metadata for verifiers to choose the correct active key. If any consumer still depends on embedded keys, treat that as technical debt with a defined retirement date.

Decision rule: Use JWKS refresh for production token validation unless there is a narrow, documented reason to pin a key temporarily during a controlled migration. If you must pin, make the exception time-bound and ensure there is a tested path back to issuer-driven refresh.

Practitioner takeaway: Token verification should track the issuer’s key lifecycle, not freeze it in application code; the more broadly a signing key is trusted, the more important it is that rotation be automatic and observable.