Data-at-rest, code signing, secrets and identity: the other migration domains

Data-at-rest encryption

Most encrypted storage uses a symmetric cipher (AES-256) for the bulk data and asymmetric crypto only to wrap or transport the data-encryption key. The good news: AES-256 is not meaningfully threatened by quantum computers, so the bulk data does not need re-encryption for algorithmic reasons. The exposure is the key wrapping — if a data key is wrapped with RSA and that wrap is harvestable or long-lived, migrate the wrapping to an ML-KEM-based mechanism. Confirm bulk symmetric key sizes are adequate (256-bit), then focus effort on the key hierarchy above them.

Code and firmware signing

Signing migrates to ML-DSA or, for maximum assurance on roots of trust, SLH-DSA. What makes signing special is the verification horizon: firmware signed today may be verified by devices in the field for a decade or more, so even though signatures are not harvestable, the artifacts you sign now must remain trustworthy long into the quantum era. That argues for migrating firmware and secure-boot signing earlier than the non-harvestability of signatures alone would suggest.

• Ensure verifiers in the field can validate the new signature format before you sign production artifacts with it.
• Consider dual/parallel signing during transition so both old and new verifiers are satisfied.
• Account for larger signatures in constrained firmware update mechanisms.

Secrets management and KMS

Key-management systems and secret stores are where key wrapping, rotation, and crypto policy concentrate — which makes them a high-leverage place to build agility. Migrate the key-wrapping algorithms to PQC KEMs, verify HSM and KMS support for the chosen algorithms, and use the KMS as the central policy point that defines which algorithms are sanctioned. A KMS that already tags keys with algorithm identifiers and rotates cleanly turns downstream data-at-rest migration from surgery into a policy change.

Identity tokens and federation

JWTs, SAML assertions, and OIDC tokens are signed by identity providers and verified by relying parties. Migration means both the issuer and every verifier support a PQC signature algorithm — a coordination problem more than a cryptographic one, since a single lagging relying party blocks cutover. Inventory the verifier population, introduce PQC signing behind algorithm negotiation where the token format allows it, and treat federation partners you do not control as supply-chain dependencies with their own readiness timelines.