Container Image Signing in the PQC Era: Supply Chain Considerations

A production Kubernetes cluster trusts container images because those images carry valid Cosign or Notation signatures. Those signatures are valid because they were made with ECDSA P-256 keys. ECDSA P-256 is on NIST's deprecation schedule under IR 8547 (November 2024), with planned disallowed status by 2030 for new deployments in security categories 2 and above. Container image signing for enterprise production systems sits comfortably within security category 2.

The PQC migration question for container supply chains is therefore not "should we do this" but "how many separate places in the build, sign, and verify pipeline use classical signatures, and in what order must they be migrated?" The answer is more places than most DevSecOps teams realise, and the order matters.

Every Place a Classical Signature Lives in the Trust Chain

Working through a typical CI/CD pipeline from commit to deployment, classical signatures appear at these points:

1. Developer commit signatures. Git commit signing via SSH or GPG keys, both classically vulnerable.
2. Build pipeline attestation. SLSA provenance records, signed with ECDSA or Ed25519 via the Dead Simple Signing Envelope (DSSE) format.
3. Container image manifest signing. Cosign or Notation signatures over the OCI image manifest, using ECDSA P-256.
4. Transparency log tree head signature. Rekor, the Sigstore transparency log, signs its Merkle tree heads with ECDSA.
5. Registry authentication certificate. TLS, classical, used for registry connections.
6. RFC 3161 timestamp. In Notation signatures, the timestamp authority signs with a classical algorithm.
7. Fulcio-issued certificate. In keyless Sigstore signing, Fulcio issues short-lived ECDSA P-256 certificates bound to OIDC identity.
8. SLSA provenance chain. in-toto link and layout files, signed with classical keys across all supply chain steps.

Items 2, 3, and 7 are the minimum migration scope for post-quantum container supply chain integrity. The OCI registry stores signatures as separate OCI artifacts; a 3,309-byte ML-DSA-65 signature stored as an OCI artifact is well within registry capacity and presents no format incompatibility. Size increase is a storage cost at trivial scale and a minor bandwidth consideration on manifest retrieval, neither of which is a blocking concern.

The 70-to-72-byte ECDSA P-256 signature that currently sits in Cosign or Notation grows to 3,309 bytes for ML-DSA-65 (security category 3) or 7,856 bytes for SLH-DSA-SHA2-128s. Container registries must accommodate these sizes in their metadata and manifest handling; none of the major OCI-compatible registries have format constraints that would prevent this.

SHA-256 Is Not the Problem

A common confusion in this space conflates two different cryptographic roles. OCI image manifests include SHA-256 digests of every layer, and images are content-addressed by SHA-256. Grover's algorithm provides only a quadratic speedup for hash inversion: SHA-256 retains approximately 128 bits of post-quantum security. Container image layer integrity does not require PQC migration. The SHA-256 infrastructure is fine.

The classical vulnerability is in the digital signatures over the image manifest, not in the layer digests. ECDSA P-256 for signing is a discrete logarithm problem on an elliptic curve, which Shor's algorithm solves efficiently. SHA-256 for content addressing is a preimage problem, which Grover's algorithm addresses only quadratically. These are different cryptographic operations serving different security functions, and their migration requirements are different.

Sigstore's Migration Path

Sigstore's keyless signing mode uses Fulcio to issue short-lived OIDC-bound certificates, eliminating long-term key management. The implication for PQC migration is often misread: because there are no long-lived keys to rotate, teams assume keyless signing means no key migration work. The opposite applies at the infrastructure level.

Fulcio is the certificate authority at the centre of keyless Sigstore. It issues every short-lived signing certificate in the keyless flow. Migrating keyless Sigstore signing to ML-DSA requires migrating the Fulcio CA root to ML-DSA, updating the OIDC-bound certificate issuance to carry ML-DSA public keys, and updating the Rekor transparency log tree head signatures. These are central infrastructure changes, not per-team key rotations. A team using keyless signing today faces fewer migration touchpoints than a team managing long-lived signing keys, but the Fulcio and Rekor components are systemic dependencies that the whole ecosystem shares.

The expected migration sequence for Sigstore is a hybrid phase: ECDSA and ML-DSA signatures stored as separate OCI artifacts for the same image, allowing ML-DSA-capable verifiers to use the PQC signature while legacy verifiers fall back to ECDSA. This parallel-signature approach avoids a hard cutover that would break deployments. It does introduce one operational risk: a Kubernetes cluster running an OPA Gatekeeper or Kyverno policy that checks only for ECDSA Cosign signatures will silently ignore the ML-DSA signature during the hybrid phase. Verification policy must be updated alongside signing configuration, not after it.

For the Notation signing path with RFC 3161 timestamps, the timestamp token signature from the timestamp authority also appears in the Notation trust chain. If the TSA signs with a classical algorithm and that timestamp is part of the trust chain, the full provenance record is not post-quantum even if the container signature itself has migrated. The weakest link in the chain determines the overall security posture.

SLH-DSA for Long-Lived Container Provenance

ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) serve different use cases in container supply chain signing. For high-frequency image build pipelines where signing throughput matters, ML-DSA-65 at 3,309 bytes is the practical choice. Signing throughput for ML-DSA is substantially faster than RSA at equivalent security levels; the performance argument runs clearly in ML-DSA's direction.

For regulated environments where container image provenance may need to be verified years after the build, a different consideration applies. ML-DSA's security depends on the hardness of the Module Learning With Errors (M-LWE) problem. SLH-DSA's security reduces entirely to the collision resistance and preimage resistance of SHA-256, a more conservative security assumption with a longer track record. "Well-studied as of 2026" is not the same assurance as "hash-function second-preimage resistance under decades of cryptanalysis." For containers whose provenance records carry compliance or legal weight beyond the 2035 horizon, SLH-DSA-SHA2-128s at 7,856 bytes provides a more conservative anchor. [INFERRED: SLH-DSA signing throughput approximately 5 to 20 ms per signature in software; verify against current benchmarks before citing specific numbers for pipeline capacity planning.]

SLSA Provenance and in-toto: The Attestation Chain

SLSA (Supply Chain Levels for Software Artifacts) provenance records use the DSSE (Dead Simple Signing Envelope) format for signing SLSA attestations. DSSE is algorithm-agnostic by design: its envelope structure accommodates any algorithm identifier without requiring format changes. Migrating SLSA provenance from ECDSA to ML-DSA requires updating the algorithm identifier in the DSSE envelope and rotating the signing keys. The DSSE envelope itself does not need to change.

As of Q1 2026, no SLSA version included an explicit ML-DSA or SLH-DSA requirement. The OpenSSF Scorecard does not yet check for PQC in supply chain practices. [ASSUMED: verify whether SLSA v1.1 or any later version has added PQC-related requirements or guidance between March 2026 and publication date.] Migration planning should not wait for SLSA or OpenSSF to mandate PQC; the driver is NIST IR 8547's deprecation schedule, which applies to ECDSA in security category 2 deployments regardless of whether SLSA references it.

The in-toto attestation framework, used by SLSA for chaining provenance across supply chain steps, specifies keys in a schema that is algorithm-agnostic at the specification level. Registering ML-DSA public keys in the supply chain root of trust and updating signing keys at each in-toto step is the migration path. The in-toto library requires a key schema update to handle ML-DSA key types; as of Q1 2026 this was not yet available in the reference implementations. [ASSUMED: verify current in-toto ML-DSA key schema support before publication.]

Building the Cryptographic Bill of Materials

The prerequisite for container supply chain PQC migration planning is a Cryptographic Bill of Materials (CBOM) for the entire build and signing pipeline. Without a CBOM, a platform team cannot determine whether their Notation implementation uses a TSA that has migrated, whether their Fulcio instance has updated its root, or whether any CI/CD step uses a classical signing key that sits outside the primary signing workflow.

A CBOM for a container supply chain should identify every signing key type (ECDSA P-256, RSA-2048, Ed25519) across each CI/CD component, every CA certificate in the trust chain, every TSA and its signature algorithm, and the Rekor instance's tree head signing key. For a supply chain producing 200 or more container images daily, manual CBOM construction is not realistic. Automated scanning of container manifests and certificate chains is the required approach. OWASP CycloneDX CBOM tooling and OWASP Dependency-Track have extended support for cryptographic asset tracking.

The CBOM output becomes the migration planning document. It identifies which signing keys are managed (long-term, requiring rotation), which are ephemeral (Fulcio-style, requiring central infrastructure migration), and which are in external dependencies (TSAs, Rekor, registries). For guidance on building a cryptographic asset register and cryptographic inventory methodology, those articles cover the discovery and classification framework that feeds CBOM construction.

Regulatory and Compliance Framing

Two regulatory references are relevant for container supply chain PQC migration timelines.

NIST IR 8547 (November 2024 IPD) places ECDSA on the deprecation schedule with planned disallowed status by 2030 for new deployments in relevant security categories. Container signing pipelines commissioned before 2026 using ECDSA P-256 will need migration plans before that deadline. The 2030 deadline applies to new deployments; existing infrastructure faces a separate sunset timeline that organisations should confirm against the final NIST IR 8547 publication.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, in force December 2024) applies to products with digital elements placed on the EU market. Its security-by-design requirements include supply chain integrity for container-based products. The CRA does not name ECDSA deprecation specifically, but its obligation to address known exploitable vulnerabilities creates a regulatory pathway: once NIST IR 8547 places ECDSA on the disallowed schedule, a product supply chain still using ECDSA for container signing has a documented known vulnerability. [INFERRED: this CRA pathway is a forward-looking legal inference, not a settled interpretation; review with legal before relying on it for compliance planning.] The CRA's 36-month transition period for most products from December 2024 points to enforcement from approximately December 2027.

Migration Priority Sequence

Given the scope of classical signatures across a container supply chain, migration should be prioritised rather than attempted simultaneously. A practical sequence:

1. Complete the CBOM. Identify every classical signature in the pipeline before committing to a migration architecture.
2. Migrate production container image signing (items 3 and 7 in the trust chain map above) first. These are the highest-value signing operations in terms of production security impact.
3. Enable hybrid signing during the transition period. Store both ECDSA and ML-DSA signatures as OCI artifacts. Update verification policies simultaneously.
4. Address SLSA provenance attestations (item 2). DSSE algorithm-agnosticity makes this operationally straightforward once the signing key infrastructure supports ML-DSA.
5. Migrate the Rekor tree head signatures (item 4) once Sigstore upstream ships ML-DSA Rekor support. This is a central infrastructure change; monitor the Sigstore project for ML-DSA roadmap announcements.
6. Address RFC 3161 TSA signatures (item 6) by switching to a TSA with a confirmed ML-DSA migration plan.

Developer commit signatures and git commit signing (item 1) are useful for supply chain integrity but are generally lower-priority than production image signing. Address them in a second phase once the primary signing operations are migrated.