Crypto-Agility as a CRA and PQC Twofer: One Abstraction Layer, Two Regulatory Drivers

Two separate regulatory drivers are pushing towards the same piece of architecture, and most firms are about to build it twice — once badly for the Cyber Resilience Act, then again, painfully, for the post-quantum migration.

The Cyber Resilience Act’s secure-by-design obligations and the EU’s post-quantum cryptography roadmap look like unrelated programmes owned by different people. They are not. Both reward exactly one property in your codebase: the ability to change a cryptographic algorithm without touching the application that depends on it. Build that property once, deliberately, and you answer a CRA auditor in 2027 and a post-quantum migration in 2030 with the same layer. Skip it, and you will be excavating hard-coded crypto out of every service twice.

Two deadlines, one underlying property

The CRA entered into force in December 2024. Its vulnerability-reporting obligations begin on 11 September 2026, and the main manufacturer obligations — including the essential cybersecurity requirements in Annex I — apply from 11 December 2027. Those requirements expect products to protect the confidentiality and integrity of data by, among other things, encrypting relevant data at rest and in transit using state-of-the-art mechanisms, and to ship security updates for a defined support period. “State-of-the-art” is not a fixed target. An algorithm that is state-of-the-art at conformity assessment can be deprecated inside the support window, and the CRA expects you to handle that through the update mechanism rather than by shipping a new product. I have written before about how the CRA quietly makes crypto-agility a product duty nobody priced in.

The post-quantum driver points the same way from a different angle. In 2025 the EU’s PQC workstream, under the NIS Cooperation Group, published a coordinated implementation roadmap for the transition to post-quantum cryptography. It asks Member States to have national roadmaps and pilot projects in place by the end of 2026, the transition of high-risk use cases substantially complete by the end of 2030, and broader medium- and low-risk systems migrated towards 2035. The target primitives are the NIST-standardised algorithms — ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures — most often deployed in hybrid combination with a classical algorithm during the transition. The board-level reading of the post-quantum problem is that the migration is measured in years and depends entirely on whether your systems can accept a new algorithm at all.

Put the two next to each other and the shared requirement is obvious. One demands you can replace deprecated cryptography inside a support period. The other demands you can replace an entire family of primitives across your estate within a decade. Both are impossible if the algorithm is named at the call site.

What the abstraction layer actually is

Crypto-agility is not a product you buy. It is a discipline about where algorithm names are allowed to appear. In an agile design, application code asks for a capability — “sign this document”, “establish a session key” — and never names RSA, ECDSA or ML-DSA. A thin provider layer resolves the capability to a concrete algorithm chosen by configuration and policy, not by the caller. Swapping the algorithm becomes a registry and configuration change, reviewed and rolled out through your normal release process, rather than a code change rippling through every service that happened to import a crypto library directly.

The interface is deliberately small. That is the whole point: the smaller the surface the application depends on, the fewer places you have to change when the primitive underneath moves.

// Package cryptoprovider abstracts signing so call sites never name an algorithm.
// Swapping RSA for ML-DSA, or for a hybrid, becomes a registry and config change,
// not a code change rippling through every service.
package cryptoprovider

import (
	"context"
	"fmt"
)

// Signer is the only cryptographic surface the application sees. Call sites
// depend on this interface, never on a concrete algorithm or library.
type Signer interface {
	// Algorithm reports what is actually in use, e.g. "rsa-pss-3072",
	// "ml-dsa-65" or "hybrid-ecdsa-p256-ml-dsa-65". Useful for inventory
	// and for the metadata a verifier needs to select a matching path.
	Algorithm() string
	Sign(ctx context.Context, digest []byte) ([]byte, error)
	Verify(digest, signature []byte) error
}

// Factory builds a Signer for a named algorithm from a key reference.
type Factory func(keyRef string) (Signer, error)

var registry = map[string]Factory{}

// Register wires an implementation to an algorithm identifier at start-up.
// Adding ML-DSA later means registering it here, not editing call sites.
func Register(alg string, f Factory) { registry[alg] = f }

// NewSigner resolves the algorithm chosen by policy for a given capability.
// The application asks for a capability; configuration maps it to an alg.
func NewSigner(alg, keyRef string) (Signer, error) {
	f, ok := registry[alg]
	if !ok {
		return nil, fmt.Errorf("cryptoprovider: no provider registered for %q", alg)
	}
	return f(keyRef)
}

Nothing here is exotic. The value is in the constraint it imposes: if a service reaches around this layer and calls a crypto library directly, that is now a reviewable defect, because it is a place the next migration cannot reach without code changes.

Negotiation, not just substitution

Swapping an algorithm on one system is the easy half. The harder half is that both endpoints of a protocol have to agree on the algorithm, and during a multi-year transition they will not all upgrade on the same day. That is why the roadmap leans on hybrid schemes: a message signed or a key established with both a classical and a post-quantum algorithm remains verifiable by a peer that understands only one of them. Your abstraction therefore needs to carry algorithm metadata alongside the ciphertext or signature, so a verifier can select the matching path rather than assuming a single global default. If the algorithm identifier is implicit — baked into the wire format or assumed by both sides — you have agility on paper and a coordinated flag-day migration in practice. Design the negotiation in now, while the only algorithm in the registry is the classical one, and the post-quantum entry slots in beside it later.

Where hard-coded crypto hides

The abstraction layer is only as good as your knowledge of what it has to cover, and this is where most programmes are weakest. A cryptographic inventory — increasingly called a cryptographic bill of materials — is the prerequisite for both drivers, because you cannot make agile what you cannot see. The obvious uses turn up quickly: TLS termination, database encryption, signed tokens. The ones that sink migrations are the quiet ones. Certificate pinning in a mobile client. A hardware security module with a fixed key type. Signed firmware where the bootloader itself verifies the signature and cannot be updated in the field. Third-party libraries and SaaS dependencies whose crypto you do not control and can only pressure a supplier to change. A dependency you cannot re-point through your abstraction is a dependency you have to manage by contract and roadmap instead, and it is far better to discover that in an inventory than in a 2030 migration that has already started.

What an auditor and a supervisor will actually ask

For the CRA, a conformity assessment against the Annex I requirements will want to see that you can identify the cryptography in your product and update it within the support period — not a slide claiming agility, but evidence: the inventory, the provider interface, a record of an algorithm actually swapped through it in test. For the post-quantum roadmap, the question your board should be asking internally is narrower and more useful than “are we quantum-safe yet” — it is “can we introduce a new signature and key-establishment algorithm across our estate as a configuration change, and if not, which systems block us and what is the plan for each”. The two evidence sets are nearly the same artefacts. That is the twofer: one abstraction layer, one inventory, one demonstrated swap, satisfying a product-conformity deadline in 2027 and de-risking a migration due in 2030.

The firms that build this once, on purpose, will treat the post-quantum migration as a configuration rollout. The firms that hard-code their way to CRA conformity in 2027 will meet the same primitives again in 2030 as an emergency — and pay, the second time, for the shortcut they took the first. The CRA deadline arrives before the one everyone is watching, and it is the cheaper place to get this right.