PQC Migration for DevOps and Platform Engineering Teams: Where Cryptographic Debt Hides

Enterprise PQC migration conversations usually start with TLS certificates and public-key infrastructure. That is a reasonable starting point, but it misses a substantial portion of the cryptographic surface that DevOps and platform engineering teams own and operate every day: Vault transit keys, Terraform state encryption, service mesh identity, container signing chains, and Kubernetes cluster data encryption.

Security teams inventorying application-layer PKI rarely reach the infrastructure layer. The result is that a well-resourced PQC programme can complete its first phase, declare the certificate inventory finished, and leave behind a Vault installation running RSA-2048 transit keys, a Terraform backend with RSA-wrapped state encryption, and a service mesh rooted in an ECDSA P-384 CA that will not be rotated for a decade.

NIST IR 8547 Initial Public Draft (November 2024) provides the deprecation taxonomy. RSA-2048, RSA-3072, and ECDSA/ECDH variants (P-256, P-384) are Category 2 (deprecated for new systems after 2030) or Category 3 (disallowed after 2035). These are the default key types in every infrastructure tool this article covers. The 2030 deadline is already inside the ten-year support lifecycle of infrastructure deployed today. Platform teams that start this inventory in 2027 will not have enough runway.

Why DevOps Teams Own Cryptographic Infrastructure and Do Not Know It

The Scope of Infrastructure-Layer Crypto

Platform engineering teams deploy and operate infrastructure that generates, stores, and transmits cryptographic key material as a routine function. This is not incidental. Infrastructure-as-code state file encryption, secrets management, service identity, container image integrity, and cluster data encryption are all cryptographic operations with specific algorithm choices, key types, and rotation schedules.

When a security team conducts a cryptographic inventory, the standard scope is application-layer PKI: TLS certificates, code signing certificates, and certificate authority hierarchies. The platform layer sits below this. A Vault transit key used by forty microservices to encrypt database fields is not visible in a TLS certificate scan. A Terraform state file encrypted under an RSA-2048 KMS key is not in the certificate inventory. NIST IR 8547 (November 2024 IPD) provides the deprecation taxonomy used here, categorising RSA and ECDSA among the algorithms scheduled for deprecation.

RSA-2048, RSA-3072, and ECDSA/ECDH at P-256 and P-384 are Category 2 or Category 3 under IR 8547. They are also the defaults in HashiCorp Vault, AWS KMS, Azure Key Vault, Istio, Linkerd, and Cosign. Starting a CBOM (cryptographic bill of materials) exercise without reaching these layers produces an incomplete picture. For guidance on building a comprehensive cryptographic asset register, see the cryptographic asset register build guide.

Applying Mosca's Inequality to Infrastructure Crypto

Mosca's inequality states that if the time to migrate (x) plus the sensitivity lifetime of data encrypted today (y) exceeds the estimated time to a cryptographically relevant quantum computer (z), action is warranted now. For application data, y is the retention period of the encrypted records. For infrastructure crypto, y has a different character: it is the key rotation lag.

A Vault RSA-2048 transit key rotated annually is at risk only for the year it is in use. But Vault transit keys in practice are frequently not rotated on annual schedules. Installations that predate enterprise PQC guidance commonly have three-to-five year rotation gaps. A key that was generated in 2021 with RSA-2048 and has not been rotated is inside the risk window under any reasonable CRQC estimate that places Q-Day in the 2033-2035 range. The rotation lag is the variable that moves the inequality from borderline to satisfied.

Terraform State File Encryption: The Invisible Key

AWS S3 SSE-KMS and Azure Key Vault Encryption at Rest

Terraform remote state stored in Amazon S3 with SSE-KMS uses AWS KMS Customer Managed Keys. The default KMS CMK uses RSA-2048 for key wrapping. As of May 2026, AWS KMS does not offer ML-KEM-768 or ML-KEM-1024 as a CMK type. For a current readiness comparison across AWS, Azure, and GCP key management services, see cloud KMS PQC readiness across AWS, Azure, and GCP. AWS has announced a PQC roadmap, but ML-KEM CMK types are not in production.

The exposure point is the RSA wrap key, not the bulk state data. Terraform Cloud and Terraform Enterprise use AES-256-GCM for the state data itself. AES-256-GCM is post-CRQC safe against confidentiality attacks: Grover's algorithm halves the effective key length, leaving AES-256 at roughly 128-bit equivalent security, which remains adequate. The vulnerability is in the RSA key wrapping layer above AES-256-GCM. Shor's algorithm breaks RSA. The CRQC that breaks the wrap key reveals the AES key that decrypts the state.

Azure Terraform backends using Azure Blob with customer-managed keys via Azure Key Vault face the same pattern. The default RSA-2048 or RSA-3072 key in Azure Key Vault's BYOK path is the exposure point. This is not a cloud provider failure: it is a default configuration that was secure before CRQC became a planning concern and now needs a migration path.

HashiCorp Vault: Transit Keys and Seal Wrap

HashiCorp Vault's transit secrets engine is the most widely deployed software-based HSM substitute in cloud-native infrastructure. It handles encryption, decryption, signing, and verification for applications that pass data through the Vault API rather than managing keys locally. Vault Enterprise uses a Transit Auto Unseal mechanism backed by an external KMS, with the default KMS wrap key type being RSA-3072 or AES-256 depending on the backend.

The PQC status of Vault transit is a roadmap item. HashiCorp announced a PQC enterprise roadmap in 2024, but ML-KEM integration in Vault transit is not available as of May 2026. There is no committed GA date for production-ready ML-KEM support. Teams relying on Vault for infrastructure encryption need to track this roadmap and factor it into their migration planning, rather than assuming the platform will handle the transition automatically. For an overview of crypto-agile architecture principles that apply while waiting for platform PQC support, see crypto agility architecture principles 2026.

Transit key rotation in Vault is configurable but not automatic. The CBOM for a Vault installation needs to enumerate all transit key types, rotation schedules, and wrap key algorithms. This is a manual exercise unless a CBOM generation tool with Vault integration is in the pipeline. RSA-2048 and ECDSA P-256 transit keys in Vault installations that predate enterprise PQC guidance are common and are the primary inventory target.

GitOps and Signed Commits: GPG and Sigstore

GPG-Signed Commits and Sigstore Keyless Signing

Git commit signing using GPG (RFC 4880) defaults to RSA-4096 or ECDSA P-384 signing keys. A signed commit history provides audit integrity guarantees that depend on the long-term unforgeability of the signing key. For infrastructure-as-code repositories, this is not an abstract concern. Terraform state repositories and Kubernetes manifest repositories have effectively permanent integrity sensitivity: a forged commit that appeared legitimate could retroactively justify an infrastructure change that should not have been made.

Sigstore's keyless signing model uses OIDC-backed ephemeral keys via the Fulcio certificate authority, with ECDSA P-256 for signing and Rekor transparency log entries. The Fulcio CA root certificate is ECDSA P-384. The Sigstore project has published a PQC roadmap with active work on ML-DSA (FIPS 204) integration, but production keyless signing with ML-DSA is not yet deployed. SLSA Level 3 build provenance attestations rely on the Sigstore/Cosign signing stack. A SLSA-compliant pipeline inherits this migration dependency.

Service Mesh mTLS: Istio and Linkerd Identity

Istio's certificate authority (now part of Istiod) issues workload certificates using ECDSA P-256 by default. The short certificate lifetime, twenty-four hours by default, is often cited as a mitigation for key compromise risk. It is a partial mitigation. The root CA issuing those short-lived certificates typically has a ten-year lifetime. The root CA is the CRQC exposure point, not the workload leaf certificates. Compromising the root CA under CRQC enables retrospective decryption of all traffic ever secured by the mesh's identity chain.

Linkerd follows the same architecture. The trust anchor and issuer certificate have longer lifetimes and constitute the cryptographic root of the mesh identity chain. Linkerd's identity controller issues ECDSA P-256 certificates. Both Istio and Linkerd are working toward PQC-capable CAs, but the migration path is not yet production-ready in upstream releases.

SPIFFE/SPIRE, the underlying workload identity specification used by both systems, does not yet define a PQC-compatible SVID (SPIFFE Verifiable Identity Document) format. The SPIFFE specification Working Group has PQC support as a roadmap item. Platform teams operating service meshes need to monitor this specification evolution, as a SVID format change will require coordinated migration across the mesh deployment.

Kubernetes etcd Encryption at Rest

Kubernetes etcd stores all cluster state, including Secrets objects. The --encryption-provider-config flag enables at-rest encryption using AES-256-GCM or AES-128-GCM. AES-256-GCM is the documented recommendation and is post-CRQC safe for confidentiality. AES-128-GCM is not: Grover's algorithm reduces its effective security to 64-bit, which is inadequate against a CRQC. If your cluster is running AES-128-GCM, upgrading to AES-256-GCM is a near-term action that does not require waiting for ML-KEM support.

The key encryption key for etcd at-rest encryption is typically stored in a cloud KMS. If that KEK is an RSA-wrapped AES key, the RSA wrap layer is the CRQC exposure point. Managed Kubernetes services including Amazon EKS, Azure AKS, and Google GKE use cloud KMS for etcd encryption. The migration path for each depends on when the respective cloud KMS supports ML-KEM CMK types. This is a provider dependency that platform teams need to track.

Container Image Signing and the PQC Roadmap

Cosign (part of the Sigstore ecosystem) supports keyful signing with ECDSA P-256 or RSA-2048 and keyless signing with OIDC-backed ephemeral ECDSA P-256 keys from Fulcio. The Open Quantum Safe project has an experimental Cosign fork with ML-DSA (FIPS 204) support, but this is not merged into upstream Cosign as of May 2026. For a detailed treatment of PQC supply chain signing, see container image signing and PQC supply chain security.

The integrity risk for container signing is analogous to the HNDL risk for encrypted data. Base OS images and approved production images stored in registries may not be rotated frequently. A signature from 2025 on an image that remains in production in 2034 needs to remain unforgeable under CRQC. If the signing key used in 2025 was ECDSA P-256, it will not be. Teams should begin tracking image age and signature algorithm for long-lived production images as part of their CBOM exercise.

The migration sequence for platform engineering teams should follow NIST IR 8547 Category 2 deadline logic: begin algorithm migration for infrastructure crypto by 2027 to allow adequate time for the integration complexity involved. Discovering that Vault transit does not yet support ML-KEM in 2029 is not a viable contingency. For the full PQC migration roadmap, see PQC migration strategy for cybersecurity leaders.

Start Your Infrastructure Crypto Inventory

Quantum Security Defence works with DevOps and platform engineering teams to build CBOMs for infrastructure-layer cryptographic assets, map them to NIST IR 8547 deprecation status, and sequence migration against vendor roadmaps. If your organisation's PQC programme has not yet reached the infrastructure layer, contact us to discuss a targeted infrastructure crypto assessment.