PCI DSS 4.0 makes automated key rotation an IAM control

At a glance

What this is: This is a PCI DSS 4.0-focused analysis of automated cryptographic key rotation for JWT signing and encryption keys, with the key finding that rotation, retirement, and auditability are now compliance expectations rather than optional hygiene.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly depend on governable key lifecycles, and manual rotation does not scale cleanly across federated token ecosystems.

Context

PCI DSS 4.0 tightens the governance of cryptographic key lifecycles, especially where keys protect authentication data, cardholder data, or token flows. In practical terms, that means signing and encryption keys cannot be treated as static infrastructure artefacts once they are embedded in identity and API trust chains.

For identity teams, the important shift is not just stronger cryptography. It is the move from ad hoc key handling to auditable lifecycle control across JWT issuers, consumers, and the systems that publish public keys for verification.

Key questions

Q: How should teams rotate JWT signing keys without breaking production traffic?

A: Plan rotation as a staged lifecycle event. Publish the new public key through JWKS, keep the old key available through a defined grace period, and make sure clients refresh key material before the old key is retired. The safest approach is to test cache behavior, token TTL, and fallback verification together, not separately.

Q: Why does manual key rotation fail in distributed token ecosystems?

A: Manual rotation fails because multiple issuers and consumers need the same key state at the same time, and human coordination introduces delay, drift, and audit gaps. Once a key is shared across JWT verification paths, the control depends on consistency across systems rather than isolated administrative action.

Q: What breaks when old signing keys are not retired on schedule?

A: Token verification remains possible with material that should no longer be trusted, which extends the useful life of compromised or obsolete keys. In practice, that creates a wider exposure window, weaker audit evidence, and confusion about which key should be trusted for new versus in-flight tokens.

Q: What is the difference between JWKS publication and key retirement?

A: JWKS publication makes current public keys available to relying parties for token verification, while key retirement removes old key material from active use after the grace period ends. Both are part of the same lifecycle, but only retirement closes the trust window created by rotation.

Technical breakdown

Why automated key rotation is now a compliance control

PCI DSS 4.0 moves key rotation from a good practice into a governed requirement. For JWT environments, the relevant distinction is between signing keys, which prove token integrity, and encryption keys, which protect token confidentiality. Both depend on asymmetric key pairs and both create lifecycle obligations: generate, distribute, rotate, retire, and log. Automation matters because manual handling introduces drift, inconsistent cadence, and broken audit evidence across multiple issuers and consumers.

Practical implication: treat key rotation as a controlled lifecycle process, not a developer convenience task.

How JWKS supports distributed key verification

A JWKS endpoint lets relying parties retrieve the current public keys needed to verify tokens without hard-coding key material. The issuer publishes a new public key, clients use the key identifier to select it, and old keys remain available only for a limited grace period while in-flight tokens age out. That model reduces coordination overhead, but it also makes key metadata, publication timing, and retirement discipline part of the trust architecture.

Practical implication: govern JWKS publication and retirement as part of the identity trust boundary, not as a separate engineering detail.

Why auditability changes the operating model

PCI DSS 4.0 expects every meaningful key event to be observable: creation, use, rotation, revocation, and retirement. That requirement matters because audit evidence is no longer an after-the-fact spreadsheet exercise. It becomes part of the control itself, especially when multiple participants exchange tokens and must prove that old keys were retired on schedule and that new keys were propagated reliably.

Practical implication: integrate key-event logging with central monitoring so rotation can be proven, not merely claimed.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Automated key rotation is now an identity governance requirement, not a crypto preference. PCI DSS 4.0 changes the control question from whether keys should rotate to whether their lifecycle can be enforced, observed, and proven at scale. That matters because JWT trust chains fail operationally long before they fail cryptographically. The practitioner conclusion is that cryptographic governance now sits inside IAM and NHI lifecycle design.

Manual key handling creates compliance debt as soon as multiple token consumers exist. Once a signing or encryption key is shared across issuers, relying parties, and deployment pipelines, human coordination becomes the weakest control in the chain. The article’s operating model shows that predictable cadence, metadata completeness, and auditable retirement are the real control surface. Practitioners should assume distributed token ecosystems will drift unless lifecycle rules are automated end to end.

Key rotation for JWTs exposes a broader identity trust pattern: public keys are infrastructure, private keys are privilege. That framing is useful because it aligns cryptographic governance with NHI thinking. A private signing key behaves like a high-value non-human secret, while the published JWKS becomes the verifiable trust source for the ecosystem. The conclusion for identity teams is to govern key material with the same lifecycle discipline applied to privileged machine identities.

Short-lived tokens and automated key retirement only work when issuance, verification, and revocation are coordinated. The article’s model assumes there is no durable manual handoff between old and new trust material. That assumption is now central to modern payment and API identity programmes. Practitioners should therefore design for continuous key turnover rather than periodic intervention.

Auditability is the decisive control because compliance evidence must match operational reality. A rotation schedule without logs, retirement records, and consumer refresh behaviour is not a defensible control in a PCI context. The field implication is straightforward: identity governance teams need key lifecycle telemetry that can survive audit review and incident investigation alike.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Key lifecycle governance now belongs inside identity programmes, not beside them. Once keys are used to sign or encrypt JWTs, they become part of the trust boundary that IAM and NHI teams must govern. The operational question shifts from ownership of the key store to control of issuance, publication, retirement, and audit evidence.

JWKS publication is a trust distribution mechanism, not a replacement for lifecycle discipline. Publishing current public keys helps consumers verify tokens, but it does not solve stale-key risk on its own. The real control is coordinated turnover of key material across issuers, consumers, and logs.

Cryptographic key management has a direct NHI analogue: the private key behaves like privileged machine identity material. That means the same programme discipline used for service accounts and other non-human credentials should be applied to key rotation, revocation, and traceability. Identity teams should align token trust with lifecycle telemetry, not with manual change windows.

For practitioners

• Automate key rotation on a fixed cadence Generate new signing and encryption key pairs programmatically and rotate them on a repeatable schedule rather than relying on manual operator action.
• Publish public keys through JWKS Expose only public verification material through a JWKS endpoint so clients can fetch the current key set without hard-coding key material.
• Retire old keys after the grace period Keep previous keys available only long enough to verify in-flight tokens, then remove them from both the JWKS endpoint and secure storage.
• Log every lifecycle event Record key generation, usage, rotation, revocation, and retirement in a central audit trail so compliance evidence matches the actual control state.

Key takeaways

• PCI DSS 4.0 makes regular rotation, retirement, and audit logging part of the control expectation for keys used in token security.
• Automated publication through JWKS helps distributed systems verify tokens consistently, but it only works when old keys are retired on schedule.
• IAM and NHI teams should treat cryptographic key lifecycles as governed trust assets, with evidence that proves rotation actually occurred.

Key terms

• JWKS: A JWKS, or JSON Web Key Set, is a machine-readable publishing format for public keys used by clients to verify signatures or encrypt tokens. It lets consumers fetch current key material automatically instead of relying on manual distribution, which is critical when keys rotate on a schedule.
• Key Rotation: The process of replacing a credential with a fresh one before the old credential becomes too risky or stale. For SSH, rotation only reduces risk when the old key is actually removed everywhere it was trusted, not just reissued elsewhere.
• Key Retirement: Key retirement is the controlled removal of a cryptographic key from active trust and future use. In NHI governance, retirement is the step that closes the validation window after rotation, ensuring old keys are no longer accepted by relying parties or retained in service longer than policy allows.
• JWT signing secret: A JWT signing secret is the cryptographic value used to sign or verify tokens so the recipient can trust the issuer. If exposed, it allows attackers to mint valid tokens or tamper with trust decisions, making its storage and rotation a core access-control concern.

Deepen your knowledge

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