Cryptographic Key Management Guide: KMS, HSM, Signing

Cryptographic keys are the identities behind identities. A token signing key decides whose tokens an application trusts, a code signing key decides which software is genuine, and an encryption key decides who can read data and backups. Steal one and you can forge access, ship malicious updates or decrypt everything. Recent incidents show the pattern: a former employee used a signing key that was never revoked to forge tokens, attackers stole ASP.NET machine keys that kept them in after patching, and hard-coded keys shipped identically in every copy of a product. This guide covers the key lifecycle, key storage, access to keys, rotation and response to key compromise.

Key takeaways

Treat keys as non-human identities: inventory them, give them owners and govern access to them.
Protect high-value keys in hardware, in an HSM or managed KMS, so they can be used but not copied.
Control who and what can use a key as tightly as the key itself.
Define cryptoperiods and rotate on schedule, and know how to rotate in an emergency.
After a compromise, patching is not enough. Rotate every key the attacker could have read.

The keys that matter most

Key type	What it protects	If stolen
Token and assertion signing keys	JWTs, SAML assertions, session tokens	Attacker forges valid tokens for any user
Application machine keys	View state and cookie integrity in web frameworks	Tampered payloads accepted; code execution in some frameworks
Code and firmware signing keys	Software updates and packages	Malicious updates trusted by every customer
CA private keys	Certificates for TLS, mTLS, SSH and devices	Attacker issues trusted certificates
Data and backup encryption keys	Databases, files, backups	Data readable wherever copies exist
Key encryption keys and root keys	Other keys	Every key they wrap is exposed

Lessons from incidents

Coupang (2025): a former developer used a token signing key that was never revoked to forge access, exposing 33.7 million accounts. Offboarding must cover keys people had access to.
ToolShell (2025): attackers stole SharePoint ASP.NET machine keys, which kept code execution working after patching until the keys were rotated.
Gladinet (2025): identical hard-coded keys in every installation let attackers forge access tickets.
SolarWinds: a stolen token-signing certificate let attackers forge SAML tokens ("Golden SAML").
LastPass (2022): access keys and decryption keys available to a DevOps engineer unlocked encrypted backups.

The key lifecycle

NIST SP 800-57 Part 1 describes the stages every key passes through. In practice:

Generate with an approved algorithm and a good random source, inside the HSM or KMS where possible.
Register in an inventory with owner, purpose, algorithm, location, cryptoperiod and dependent systems.
Distribute and store without exposing plaintext key material, wrapped by a key encryption key or held in hardware.
Use only for its intended purpose, by authorised identities, with every use logged.
Rotate at the end of the cryptoperiod or on suspicion of compromise, with overlapping validity where verifiers need time to update.
Revoke and destroy when retired, and keep a record of destruction.

Storage: HSM, KMS and software

Hardware security modules keep keys in tamper-resistant hardware validated under FIPS 140-3; applications send data to the HSM to sign or decrypt rather than retrieving the key.
Cloud KMS services provide managed, hardware-backed keys with identity-based access policies and logging; many support importing your own key material or external key stores.
Secrets managers suit lower-value symmetric keys and application secrets, but do not give the same non-exportability. See the Secrets Management Guide.
Never hard-code keys in source code, images or firmware, or share one key across all customers or installations.

Controlling access to keys

Separate who can administer a key (create, rotate, delete, change policy) from who can use it (sign, decrypt).
Grant use only to the specific workload identities that need it, not to broad roles. See the Cloud Workload Identity Guide.
Require multi-person approval for exporting, deleting or changing policy on critical keys.
Log and alert on unusual key use, such as a signing key used from a new identity or at unusual volume.
Remove human access to production keys by default; use just-in-time elevation for maintenance. See the JIT Access Guide.

Rotation and compromise response

Publish verification keys through a mechanism that supports rollover, such as a JWKS endpoint with multiple active keys, so you can rotate signing keys without an outage.
Practise emergency rotation for each critical key before you need it.
After a compromise of any system that held or could read keys, rotate those keys, even if the vulnerability is patched.
For code signing key compromise, revoke the certificate, re-sign legitimate releases and tell customers what to trust.
Invalidate tokens and sessions signed with a compromised key. See the Token and Session Security Guide.

Preparing for post-quantum cryptography

A key inventory is also the foundation for moving to post-quantum algorithms, because you cannot migrate keys you cannot find. See the Post-Quantum Readiness for Identity and PKI guide.

Practitioner checklist

Inventory signing, encryption, machine and CA keys, with owners and dependent systems.
Move high-value keys into an HSM or managed KMS.
Remove hard-coded and shared keys from code, images and products.
Separate key administration from key use, and scope use to specific workload identities.
Set cryptoperiods and automate rotation with overlapping validity.
Rehearse emergency rotation, and rotate keys after any compromise of systems that held them.
Revoke key access as part of leaver processes.
Log and alert on unusual key use.

Cryptographic Key Management Guide: KMS, HSM and Signing Keys