← Back to Blog Tutorials

Key Rotation Policies for PQC

11 min read

When a security engineer first encounters post-quantum cryptography, the algorithms get most of the attention. ML-KEM, ML-DSA, SLH-DSA, lattices, hashes, the math behind it all. But the operational discipline of how you actually use these keys, especially the question of how often you rotate them, gets surprisingly little airtime. NIST has spent decades documenting key management hygiene in publications like SP 800-57. The arrival of PQC does not throw out that hygiene. It refreshes it.

This article covers what NIST recommends for key rotation, why those recommendations exist, what changes when you swap classical algorithms for post-quantum ones, and what a sensible rotation policy looks like in 2026 and beyond.

What NIST SP 800-57 Says About Cryptoperiods

NIST Special Publication 800-57 Part 1 Revision 5 is the foundational document for key management in the U.S. federal context. The relevant concept here is the cryptoperiod: the period during which a specific key is authorized for use, or the period during which protected data remains in use with that key.

NIST distinguishes two types of cryptoperiods:

Originator usage period (OUP): how long a key may be used to apply cryptographic protection (encrypt new data, sign new artifacts).
Recipient usage period (RUP): how long a key may be used to verify or decrypt previously protected material.

The OUP is typically shorter than the RUP. You stop using a key to sign new things long before you stop accepting signatures it produced.

The recommended cryptoperiods in SP 800-57 vary by key type. Roughly:

Symmetric data encryption keys: 1-2 years OUP, up to 5 years RUP
Asymmetric authentication keys (signing): 1-3 years OUP, longer RUP
Asymmetric key transport keys (KEMs): 2 years OUP, longer RUP
Master keys for key derivation: as long as practical, but no longer than necessary

These are guidelines, not laws. The actual rotation cadence in your organization should be informed by the threat model, the data lifetime, the cost of rotation, and any regulatory constraints.

Why Rotation Matters Even More with New Algorithms

Post-quantum algorithms are new. They are based on mathematical assumptions (lattice problems, hash-based constructions, code-based problems) that have received intense scrutiny but have not been deployed at internet scale for as long as RSA or elliptic-curve cryptography. NIST FIPS 203, 204, and 205 are stable standards as of 2024, but the implementation ecosystem is still maturing.

This argues for shorter cryptoperiods at the start of your PQC deployment, not longer ones. Here is why:

Implementation bugs are more likely. When a software defect is found in a PQC library, you want a rotation cadence that limits exposure. If you rotate keys every 90 days and a bug is disclosed, the worst-case window is 90 days plus the disclosure-to-patch latency.
Side-channel research is ongoing. Cache-timing, power-analysis, and electromagnetic side channels against ML-KEM and ML-DSA implementations are an active research area. New mitigations get published and shipped. Rotation forces you to incorporate those mitigations.
Parameter updates are possible. Although NIST has standardized specific parameter sets, future revisions may emerge. Shorter cryptoperiods make it easier to migrate.
The hybrid construction interacts with both halves. If you are using ML-KEM-768 + X25519 hybrid, a flaw in either half could push you toward rotation. With two algorithms, you have two vectors to monitor.

The flip side is also true. Rotation is operationally expensive. You have to coordinate key generation, distribution, retirement, and archival. Make rotation too frequent and you generate operational risk to mitigate cryptographic risk.

A Sensible Default Cryptoperiod for PQC

Based on NIST guidance and current PQC implementation maturity, here are reasonable defaults for an organization running QNSQY-style file encryption:

Key type	Originator usage period	Recipient usage period
ML-KEM-768 + X25519 file encryption keypair	1 year	7 years
ML-DSA-65 + Ed25519 file signing keypair	1 year	5 years
Argon2id-derived password keys	per-file	per-file
AES-256-GCM data encryption keys (DEKs)	per-file (ephemeral)	per-file
HKDF salts	per-file	per-file

The per-file ephemeral DEKs and salts are the easiest part. A new DEK every file is the standard pattern in envelope encryption.

The harder part is the long-lived asymmetric keypairs. The 1-year OUP gives you four chances per year to incorporate library updates, parameter migrations, or security advisories. The 5-7 year RUP lets you decrypt or verify older files without forcing a giant migration every year.

Hybrid Construction Considerations

QNSQY uses hybrid construction: ML-KEM combined with X25519, ML-DSA combined with Ed25519. This affects rotation in two ways:

Both halves rotate together. When you rotate the keypair, you generate new ML-KEM and X25519 keys at the same time. They are bundled into a single QNSQY identity.
An attack on one half does not necessarily force rotation. If a defect is found in X25519 (extremely unlikely at this point), the ML-KEM half still provides security against quantum adversaries. If a defect is found in ML-KEM, the X25519 half still provides security against classical adversaries. Hybrid construction is the belt and braces of the PQ transition.

The practical implication is that you can rotate on a schedule rather than reactively. A 1-year cryptoperiod is comfortable when both halves are working as designed. If a defect surfaces, you can do an emergency rotation. The schedule is the baseline, not the only trigger.

Rotation Triggers: Time Versus Event

NIST SP 800-57 distinguishes between time-based rotation and event-based rotation. A complete policy includes both:

Time-based triggers:

End of the originator usage period
End of the recipient usage period
Annual security review

Event-based triggers:

Suspected key compromise
Departure of a privileged user with key access
Discovery of a defect in the cryptographic library or implementation
Migration to a new algorithm or parameter set
Regulatory or compliance change (e.g., new NIST guidance)
Hardware change (e.g., HSM upgrade)

Most organizations under-invest in event-based triggers. The audit trail tends to focus on calendar-based rotation. A mature program treats compromise indicators (failed login bursts, unusual API patterns, IDS alerts on the key custody hosts) as rotation triggers, not just incident-response triggers.

Operational Mechanics of PQC Key Rotation

Here is what actually happens when you rotate a PQC keypair in a QNSQY workflow:

Generate new keypair. qnsqy keygen --dsa ml-dsa65 --out new-identity.key. The CLI generates ML-DSA-65 + Ed25519 hybrid keys and ML-KEM-768 + X25519 hybrid keys, all bound to a single identity record.
Publish new public keys. The recipient public key is uploaded to your key directory or shared with counterparties. This is the same workflow you would use for any public-key system.
Begin using the new keypair. New files are encrypted to the new public key and signed with the new signing key. Mark the old keypair as "deprecated for new use."
Old keypair remains valid for decryption and verification. Files encrypted to the old public key can still be decrypted. Files signed with the old key can still be verified.
At end of recipient usage period, revoke the old keypair. Mark it as "invalid for any use." Any files still encrypted with it must be re-encrypted to the new key, or accepted as no longer accessible.

The hardest step is the re-encryption. If you have 10 TB of archives encrypted with last year's keypair, re-encrypting them when you rotate is expensive. The pragmatic approach is to set the recipient usage period to match the data retention period. Files that will be deleted at year 5 anyway do not need to be re-encrypted at year 4.

Avoiding Common Mistakes

Three rotation mistakes show up regularly in security audits:

Mistake 1: One-shot key per system. A keypair is generated when the system is provisioned and never rotated. Five years later, the keypair is still in use. This is a common pattern in legacy enterprise systems and a reliable finding in any thorough audit.

Mistake 2: Rotation without revocation. A new keypair is generated, but the old one is left in the trust store indefinitely. An attacker who compromised the old key can still produce valid signatures and decrypt new files (if recipients have not removed the old public key).

Mistake 3: Rotation without forward secrecy planning. A keypair is rotated annually, but all files signed with the old keypair remain bound to that keypair. If the old private key is compromised after retirement, every file it ever signed can be repudiated or the assumption of authenticity falls. This is why some workflows use ephemeral signing keys for high-value transactions.

QNSQY's per-file ephemeral DEK design addresses one form of forward secrecy: each file has its own DEK derived freshly. Compromise of one DEK does not compromise others. The asymmetric keypair compromise is a separate concern, addressed by limiting the cryptoperiod.

Audit Logging for Rotation

NIST SP 800-92 (Guide to Computer Security Log Management) and SP 800-57 both expect key management events to be logged. At minimum, log:

Key generation events (timestamp, key ID, algorithm, requestor)
Key activation events (when a key becomes the current production key)
Key deprecation events (when a key is marked for retirement)
Key revocation events (when a key is invalidated for all use)
Key archival events (when a retired key is moved to long-term archive)
Key destruction events (when a key is permanently destroyed)

These logs themselves should be integrity-protected. A common pattern is to ship them to a central SIEM with append-only storage and to sign each log batch.

Compliance Frameworks and Their Rotation Expectations

Different compliance regimes have different opinions about cryptoperiod and rotation cadence. Understanding which frameworks apply to your environment is necessary for setting the right policy.

PCI DSS v4.0 effective March 2024 includes Requirement 3.6.4 covering periodic key changes. The standard does not mandate a specific cadence but expects keys to be rotated based on industry best practices and the cryptoperiod analysis appropriate to the data sensitivity. For cardholder data environments, annual rotation of long-lived asymmetric keys is a common interpretation.

HIPAA and HITRUST do not specify cryptoperiod numbers but require risk-based key management. Healthcare organizations typically align with NIST SP 800-57 cryptoperiods as the safe interpretation of HIPAA's risk-based requirements. The HHS Office for Civil Rights enforcement actions have not specifically penalized rotation cadence violations, but the general expectation is documented key management practices that align with NIST guidance.

CNSA 2.0 for US national security systems is more prescriptive. The suite specifies the algorithms (ML-KEM-1024, ML-DSA-87, AES-256, SHA-384) and the migration timelines. Rotation cadence within CNSA 2.0 follows the broader NIST SP 800-57 framework with classified-system considerations layered on top.

For European deployments under eIDAS qualified signatures, the European Telecommunications Standards Institute (ETSI) publishes specifications including ETSI TS 119 312 covering algorithm requirements. The qualified trust service framework expects keys to be rotated at intervals appropriate to the algorithm and the data sensitivity, with the qualified signature creation device (QSCD) supporting the rotation.

When designing a cryptoperiod policy, the practical step is identifying every applicable compliance regime and taking the strictest cadence as the binding constraint. Documentation should reference each applicable framework so auditors can trace the policy back to its compliance basis.

Frequently Asked Questions

How does PQC rotation differ from RSA rotation? The mechanics are nearly identical: generate new keypair, distribute new public key, deprecate old, eventually revoke. The differences are in the algorithm parameters and the size of the keys. ML-KEM-768 public keys are about 1184 bytes, larger than RSA-2048 (256 bytes) or Ed25519 (32 bytes). This affects key directories, certificates, and protocols that have key-size assumptions baked in.

Should I use longer or shorter cryptoperiods for PQC versus classical? Slightly shorter, especially during the early years of PQC deployment. The conservative 1-year OUP for ML-KEM and ML-DSA is reasonable for 2026. As implementations mature, the cryptoperiod can extend to NIST-recommended classical durations.

What if I need to rotate a key that has signed files I want to keep verifying? Keep the old public key in your verification trust store after the OUP ends. The RUP is exactly for this. Do not delete the old public key until the recipient usage period ends.

Can rotation be automated? Yes, and it should be. Manual rotation is error-prone. Tools like HashiCorp Vault, AWS KMS, and Cloudflare Keyless SSL can automate rotation of long-lived keys. For QNSQY in production, a cron-driven qnsqy keygen plus key directory update is the simplest automation.

Does PQ rotation require re-encrypting existing data? Not immediately. Existing data stays encrypted under the old keypair. You re-encrypt only when the old keypair's recipient usage period is about to end and the data still needs to live longer.

How does rotation interact with multi-recipient encryption? Multi-recipient encryption wraps a single content key under multiple recipient public keys. When one recipient rotates their keypair, the file already encrypted under their old key remains accessible to them only as long as they retain the old private key. To migrate the file to their new key, the file must be re-encrypted (or the wrapped key for that recipient slot must be re-wrapped). QNSQY's multi-recipient v1 design supports this through the FLAG_MULTI_RECIPIENT extension and the RecipientSlotsBlock structure. For organizations with significant multi-recipient encrypted archives, the rotation workflow should include scheduled re-wrapping of the recipient key slots aligned with each recipient's rotation schedule.

What is the rotation cadence for ephemeral PQC keys in TLS handshakes? TLS uses ephemeral key exchange keys per session, generated freshly for each handshake. This is per-session rotation, the strongest possible cadence. The long-lived keys in TLS are the certificate signing keys. Standard TLS server certificate validity is 90 days for ACME-issued certificates and 1 year for traditional CA-issued certificates. PQC migration does not change these cadences directly. The rotation discussion in this article is about long-lived application-level keys (file signing keys, identity keys for end-to-end encryption, code signing keys), not TLS session keys.

Sources

NIST SP 800-57 Part 1 Revision 5 (Recommendation for Key Management) — https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
NIST SP 800-92 (Guide to Computer Security Log Management) — https://csrc.nist.gov/publications/detail/sp/800-92/final
NIST FIPS 203 (ML-KEM Standard) — https://csrc.nist.gov/pubs/fips/203/final
NIST FIPS 204 (ML-DSA Standard) — https://csrc.nist.gov/pubs/fips/204/final
NSA CNSA 2.0 (Commercial National Security Algorithm Suite) — https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/
NIST SP 1800-38 (Migration to Post-Quantum Cryptography) — https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms
ETSI TS 119 312, "Cryptographic Suites for Electronic Signatures" — https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY