Protect active signing keys

Deleting the signing key an environment is currently using breaks token verification for every client still trusting that JWKS. Signing-key management now refuses to delete an active key, persists revocation time, and shows status in the console.

This is the longer note behind the November 23 changelog entry.

How it works

Environment keys live in applications_environments_jwks with active, revoked, and revoked_at. Token issue and related paths fail if no active key is available.

In Security > Session management, each key shows status:

• In use — active
• Revoked — revoked, with the persisted revokedAt timestamp
• Inactive — neither

Delete and revoke actions are hidden for a key that is active or already revoked. You activate another key first (Use Key), then revoke the previous one. Revoke records revokedAt rather than dropping the row so history stays visible.

envSigninKeys is the management query the console uses to list keys.

Set it up

In the console, open Security > Session management:

1. Confirm which key is In use.
2. Create or select a replacement and choose Use Key.
3. Revoke the old key. Check the revoked date on the row.

Do not delete the last active key. Clients should keep reading JWKS so rotation does not require a coordinated restart if the previous key is still published until revoked.

Trust boundaries

Protecting delete is an operational safeguard, not a cryptographic proof that a key never leaked. Rotate if material was exposed.

A revoked key must not be used to issue new tokens. Verifiers that cached JWKS may still accept signatures until they refetch.

Try it

Add a second key, switch Use Key, and confirm delete is unavailable on the active row. The original release note is in the changelog.