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, and patching the hole you came in through does not take the key back. This guide covers the key types that matter most, lessons from recent incidents, the key lifecycle under NIST SP 800-57, storage in HSMs and cloud KMS, access to keys, rotation and compromise response, detection, and preparation for post-quantum cryptography. It is written for security architects, platform and PKI teams, and the application owners who hold signing and encryption keys.
Key takeaways
- Treat keys as non-human identities: inventory them, give each an owner and a purpose, and govern who and what can use them.
- Protect high-value keys in hardware, in an HSM or managed KMS, so they can be used but not copied. NIST IR 8587 says token signing keys for moderate and high impact systems must not sit on the servers that use them.
- Separate key administration from key use, and remove standing human access to production keys.
- Define cryptoperiods and rotate on schedule, with overlapping validity for verifiers, and rehearse emergency rotation before you need it.
- After a compromise, patching is not enough. Rotate every key the attacker could have read, invalidate what it signed or protected, and destroy all old copies.
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, drivers, packages and firmware | Malicious updates trusted by every customer or device |
| CA private keys | Certificates for TLS, mTLS, SSH and devices | Attacker issues trusted certificates |
| Application private keys (for example GitHub App keys) | The app's ability to mint access tokens | Fresh tokens for every installation until the key is revoked |
| 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 |
NIST SP 800-57 Part 1 Rev. 5 recommends that a key is used for only one purpose, and NIST IR 8587 says token and assertion signing keys must not be used for anything else. Mixing purposes widens the blast radius of any single theft.
Lessons from incidents
- Microsoft Storm-0558 Key Breach 2023: attackers forged tokens with a 2016 consumer signing key that should have been retired in 2021, and enterprise mail accepted them because key scope was not validated. NIST IR 8587 cites the incident: forged tokens from a single stolen signing key gave access to agency email.
- Coupang Breach 2025: a former developer used a token signing key that was never revoked to forge access. Investigators found keys stored on developer laptops, and a lawmaker said the keys had validity periods of 5 to 10 years.
- ToolShell SharePoint Exploitation 2025: attackers read SharePoint's ASP.NET machine keys, which kept code execution working after patching. Microsoft and CISA told defenders to rotate the keys and restart IIS.
- Gladinet Hard-Coded Keys 2025: every installation used the same AES key and IV, so attackers forged access tickets on any server. The ASP.NET Machine Key Attacks 2025 showed the same failure at scale: Microsoft identified more than 3,000 publicly disclosed keys copied into applications.
- SolarWinds Supply Chain Compromise: a stolen token-signing certificate let attackers forge SAML tokens.
- MSI Signing Keys Leak 2023 and NVIDIA Code-Signing Certificates Stolen 2022: firmware and driver signing keys leaked with stolen data. Malware signed with NVIDIA's expired but still trusted certificates appeared soon after.
- LastPass Breach 2022 and GoTo Breach 2023: decryption keys stored where attackers could reach them turned encrypted backups into readable ones.
- Leaked GitHub App Private Keys 2026: GitGuardian found 474 of 4,802 leaked GitHub App keys still authenticated, some years after exposure.
The key lifecycle
NIST SP 800-57 Part 1 describes the states a key passes through: pre-activation, active, suspended, deactivated, compromised and destroyed. In practice:
- Generate with an approved algorithm and a good random source, inside a validated cryptographic module where possible. NIST IR 8587 requires token signing keys to be generated in validated modules.
- Register in an inventory with owner, purpose, algorithm, location, cryptoperiod and dependent systems. The OWASP Key Management Cheat Sheet notes that a compromise-recovery plan needs an inventory of all keys and their use.
- 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: remove the key from published metadata, then erase operational, backup and archived copies, and record it.
Cryptoperiods set the rotation schedule. These are suggested maximums; shorter is better where rotation is automated.
| Key type | Suggested cryptoperiod | Source |
|---|---|---|
| Private signature key | 1 to 3 years | SP 800-57 Pt 1, Table 1 |
| Token and assertion signing key, high impact | No more than 90 days of active signing | NIST IR 8587 |
| Token and assertion signing key, moderate or low impact | Less than one year | NIST IR 8587 |
| Symmetric data encryption key | Under 2 years to apply protection; up to 3 more years to process | SP 800-57 Pt 1, Table 1 |
| Symmetric key-wrapping key | Under 2 years to apply protection | SP 800-57 Pt 1, Table 1 |
| Symmetric master or key derivation key | About 1 year | SP 800-57 Pt 1, Table 1 |
| Private authentication key | 1 to 2 years | SP 800-57 Pt 1, Table 1 |
Storage: HSM, KMS and software
| Option | Key exportable? | Best for | Watch for |
|---|---|---|---|
| Hardware security module | No, operations run inside the module | CA keys, code signing, root and token signing keys | FIPS 140-3 validation level and scope; operational cost |
| Cloud KMS | Usually no for service-generated keys | Data encryption, envelope encryption, many signing uses | Key policy scope; rotation limits for asymmetric keys |
| TPM, secure enclave, embedded processor | No | Device and workload keys | Security properties vary by implementation |
| Secrets manager | Yes, the secret is returned to the caller | Lower-value symmetric keys and application secrets | Key sits in application memory and possibly in logs |
| Files, code, images, firmware | Yes, to anyone who reads them | Never for production keys | Shared, hard-coded and copied keys |
- Isolation by impact level: NIST IR 8587 says systems at moderate impact or above must store signing keys in hardware-based, hardware-backed or otherwise isolated storage, must not persist them on the servers, VMs or containers that use them, and at high impact must also isolate the signing operation itself.
- Validation: the NIST Cryptographic Module Validation Program validates modules against FIPS 140-3. It states that FIPS 140-2 certificates move to the Historical List after 21 September 2026, so check the status of older HSMs and libraries.
- Know what rotation does: AWS documents that rotating a KMS key changes only the current key material and keeps older material to decrypt existing data, and Google Cloud KMS does not rotate asymmetric keys automatically.
- Never hard-code keys in source code, images or firmware, or share one key across customers or installations. See the Secrets Management Guide.
Controlling access to keys
- Split the roles: separate who can administer a key (create, rotate, delete, change policy) from who can use it (sign, decrypt, wrap).
- Scope use to workloads: grant use only to the specific workload identities that need it, not to broad roles. See the Cloud Workload Identity Guide.
- Multi-person control for exporting, deleting or changing policy on critical keys.
- No standing human access: OWASP says it is preferred that no humans can view keys, and that the key management system should at least account for everyone who can. Use just-in-time elevation for maintenance. See the JIT Access Guide.
- Offboarding: leaver processes must cover keys people could read, not just accounts. Coupang's key outlived its holder's employment.
- Keep keys apart from what they protect: the GoTo backups and the key for part of them were both reachable by the attacker.
- Review who can get copies: NIST IR 8587 says identity providers must document and regularly review the systems and personnel authorised to receive backup or archived keys.
Rotation and compromise response
NIST IR 8587 describes rotation at scale as: create new keys and metadata, expose them to all relevant systems, start signing with them, keep accepting the old keys until tokens they signed expire, then remove and delete the old keys. Publish verification keys through a mechanism that supports rollover, such as a JWK Set (RFC 7517), where the kid parameter lets verifiers choose among keys during rollover.
- Automate scheduled rotation: AWS KMS, Azure Key Vault and Google Cloud KMS all support rotation policies; Google advises against relying on irregular or manual rotation.
- Rehearse emergency rotation for each critical key, including how long verifiers take to pick up a new key.
- Rotate after host compromise: if any system that held or could read a key was compromised, rotate the key even when the vulnerability is patched, as ToolShell and Gladinet required.
- Re-encrypt, not just rotate: rotating a KMS key does not re-encrypt data protected by the old material. If an encryption key leaked, re-encrypt the data under a new key and destroy the old one.
- Code signing compromise: revoke the certificate, re-sign legitimate releases and tell customers what to trust. AnyDesk revoked its code signing certificate and replaced it after its 2024 breach. See the Code Signing Security Guide.
- Token signing compromise: remove the key from metadata, and invalidate tokens and sessions it signed. See the Token and Session Security Guide.
- Identify the damage: OWASP's compromise-recovery plan includes identifying all information that may be compromised and all signatures that may be invalid.
The Leaked Credential Response Playbook covers the wider incident steps.
Detection and monitoring
| Signal | Data source | Reference |
|---|---|---|
| Signing or decrypt calls from a new identity, network or at unusual volume | KMS and HSM audit logs | NIST IR 8587 logging |
| Key policy changes, exports, scheduled deletions or disabled rotation | Cloud audit logs | Change monitoring |
| Processes reading private key files or certificate stores, followed by network or compression activity | EDR telemetry | ATT&CK T1552.004 |
| SAML or token sign-ins with valid signatures but no matching authentication events | Identity provider and SaaS logs | ATT&CK T1606.002 |
| Use of retired key identifiers | Token validation logs | NIST IR 8587, section 5.1.1.5 |
| Private keys found in repositories, images or leak data | Secret scanning | OWASP NHI2 |
| Binaries signed with your certificates that you did not release | Threat intelligence, malware repositories | NVIDIA lesson |
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. NIST published its first three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. Its transition report, NIST IR 8547, was still an initial public draft when this guide was written; it proposes that quantum-vulnerable algorithms such as RSA and ECDSA at 112-bit security be deprecated after 2030, and that these families be disallowed after 2035.
- Record algorithm and key size for every key in the inventory, so quantum-vulnerable keys can be counted.
- Prioritise long-lived signing roots and data that must stay confidential for years.
- Prefer HSMs and KMS services with a published roadmap for the new algorithms, and design for algorithm agility.
See the Post-Quantum Cryptography Migration Guide and the Post-Quantum Readiness Guide.
Framework mapping
IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 (release 5.2.0) catalogue, the ISO/IEC 27001:2022 Annex A control list, the CIS Controls v8.1 list and the OWASP NHI Top 10 2025. This is an NHI Mgmt Group alignment, not an official crosswalk.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Key inventory and lifecycle | ID.AM-08 | SC-12, CM-8 | A.5.9, A.8.24 | 3 | NHI1 |
| Generation and protected storage | PR.DS-01 | SC-12, SC-12(2), SC-12(3), SC-13 | A.8.24 | 3 | NHI2 |
| Token and assertion signing keys | PR.AA-04 | IA-13(1) | A.8.24, A.8.5 | 3, 6 | NHI4 |
| Access to keys and separation of duties | PR.AA-05 | AC-5, AC-6 | A.5.3, A.8.2 | 5, 6 | NHI5, NHI10 |
| Cryptoperiods and rotation | PR.DS-01 | SC-12 | A.8.24 | 3 | NHI7 |
| No hard-coded or shared keys | PR.PS-06 | IA-5(7) | A.8.28 | 16 | NHI2, NHI9 |
| Code and firmware signing | ID.RA-09 | SI-7, SI-7(15) | A.8.25 | 2, 16 | No direct item |
| Certificates and PKI | PR.AA-03 | SC-17 | A.8.24 | 3 | NHI7 |
| Keys held by cloud providers | GV.SC-07 | SA-9(6) | A.5.23 | 15 | NHI3 |
| Monitoring key use | DE.CM-09 | AU-2, AU-6, SI-4 | A.8.15, A.8.16 | 8 | No direct item |
| Key compromise response | RS.MI-01, RS.MI-02 | IR-4 | A.5.26 | 17 | NHI2 |
Common failure patterns
- Patch and walk away: the vulnerability is fixed but stolen machine keys still work, as ToolShell and Gladinet showed.
- Keys that outlive their owners: no leaver step covers key access, so a former employee still holds a valid signing key, as at Coupang.
- Retirement that never happens: manual rotation stops after an outage and old keys stay trusted. The CSRB found this behind Storm-0558, as reported by BleepingComputer.
- Vendor or sample keys in production: the same key ships in every installation or is copied from documentation, so one disclosure opens every customer.
- Keys stored beside the data: decryption keys reachable from the same account or storage as the encrypted backups.
- Expired is not retired: platforms that still trust expired signing certificates keep stolen ones useful.
- Rotation that does not re-encrypt: teams rotate a KMS key after a leak and assume old ciphertext is now safe.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Keys in inventory with owner, purpose, algorithm and cryptoperiod | Visibility | Up, to 100% of known keys |
| High-value keys (signing, CA, root) held in HSM or KMS | Protection against copying | Up, to 100% |
| Keys past their cryptoperiod | Rotation discipline | Down, to zero |
| Keys with automated rotation | Operational maturity | Up |
| Humans with standing use or export rights on production keys | Insider and credential theft exposure | Down |
| Time to rotate a critical key in a rehearsal | Readiness for compromise | Down |
| Hard-coded or shared keys found in code, images and products | Hygiene | Down, to zero |
| Keys with algorithm recorded and post-quantum status assessed | Migration readiness | Up |
Implementation roadmap
| Phase | Actions | Outcome |
|---|---|---|
| First 30 days | Inventory token signing, code signing, CA, machine and backup encryption keys with owners; scan code, images and firmware for private keys; add key access to leaver checklists; turn on KMS and HSM audit logging | You know which keys matter and where they are |
| Days 31 to 90 | Move signing and root keys into HSM or KMS; split administration from use; remove standing human access; set cryptoperiods and enable automated rotation; publish verification keys through rollover-capable metadata | High-value keys cannot be copied and rotate on schedule |
| Days 91 to 180 | Rehearse emergency rotation for each critical key; build detections for unusual key use and retired key IDs; check FIPS 140-3 status of modules; record algorithms and plan post-quantum migration for long-lived keys | Compromise response is proven and migration is planned |
Practitioner checklist
- Inventory signing, encryption, machine, application and CA keys, with owners, purpose and dependent systems.
- Move high-value keys into an HSM or managed KMS, and keep signing keys off the servers that use them.
- Remove hard-coded, sample and shared keys from code, images, firmware and products.
- Separate key administration from key use, and scope use to specific workload identities.
- Set cryptoperiods and automate rotation with overlapping validity for verifiers.
- Rehearse emergency rotation, and rotate keys after any compromise of systems that held them.
- Re-encrypt data and destroy all copies of a leaked encryption key, including backups.
- Revoke key access as part of leaver processes.
- Log and alert on unusual key use, policy changes and use of retired key IDs.
- Record algorithms and key sizes to plan the post-quantum transition.
Standards and references
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- NIST: IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- NIST: FIPS 140-3, Security Requirements for Cryptographic Modules
- NIST: Cryptographic Module Validation Program
- NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards
- NIST: IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
- OWASP: Key Management Cheat Sheet
- IETF: RFC 7517, JSON Web Key (JWK)
- AWS: Rotate AWS KMS keys
- Google Cloud: Key rotation
- MITRE ATT&CK: T1552.004 Unsecured Credentials: Private Keys
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Secrets Management Guide · Leaked Credential Response Playbook · Encryption Guide · Post-Quantum Readiness Guide