Post-Quantum Identity Migration Without Re-Architecting

Regulatory Framework

The post-quantum regulatory landscape solidified rapidly. NIST issued FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) and FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) in August 2024, followed by FIPS 205 (SLH-DSA, derived from SPHINCS+) the same month, and continues HQC selection and FALCON standardization as FN-DSA. These are no longer drafts — they are binding federal information-processing standards that downstream regulation now references directly.

In the United States, National Security Memorandum 10 (NSM-10) and the CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) directive set explicit migration milestones for National Security Systems: software and firmware signing mandates active migration through 2025–2027, and the broader CNSA 2.0 transition requires exclusive post-quantum operation by 2033 for most categories and by 2030 for new acquisitions of certain classes. CISA, NIST, and the NSA jointly issued the Post-Quantum Cryptography Initiative roadmap to coordinate the federal civilian and defense transitions, and OMB memoranda push agency inventory and migration-plan deliverables on a schedule already in execution.

In the European Union, the NIS2 Directive imposes cryptographic-agility obligations on essential and important entities, and the European Commission's Coordinated Implementation Roadmap for Transition to Post-Quantum Cryptography sets coordinated milestones across member states. The German BSI Migration Roadmap to Post-Quantum Cryptography requires high-protection-need systems to be transitioned, with hybrid mechanisms acceptable only as a transitional step. ANSSI in France has published guidance favoring hybrid post-quantum/classical schemes for the migration window and pure post-quantum thereafter. The IETF is finalizing hybrid TLS drafts for ML-KEM in TLS 1.3 key establishment and parallel work in IKEv2, SSH, and X.509 certificate profiles.

The regulatory direction is uniform across jurisdictions: cryptographic-scheme migration is no longer optional, the timeline has tightened from speculative to operational, and the cost of migration depends almost entirely on architectural choices made before the standards were finalized.

Architectural Requirement

The architectural requirement that flows from CNSA 2.0, NIS2, and the BSI roadmap is precise. Every system that uses public-key cryptography for identity, authentication, or signing must be capable of operating under ML-DSA or SLH-DSA signatures and ML-KEM key encapsulation, must support hybrid composition during the transition window, and must permit re-rotation as PQC schemes themselves are revised in response to ongoing cryptanalysis. The requirement explicitly demands cryptographic agility — the property that the underlying primitive can be substituted without rebuilding the systems that depend on it.

The requirement is more demanding for long-lived deployments. Vehicles entering production today will operate for fifteen to twenty years; defense platforms have multi-decade lifecycles; industrial-control and infrastructure systems remain in service for thirty years or more. These deployments will cross the PQC transition window in the field, will likely cross a second cryptographic transition before retirement (as either ML-DSA parameter sets are tightened or new schemes replace lattice-based candidates if structural breaks emerge), and cannot be recalled for cryptographic rebuild. The architecture must permit credential rotation in the field under whatever connectivity and operator access conditions the deployment context allows.

Why Procedural Compliance Fails

Procedural compliance with CNSA 2.0 and NIS2 — the pattern of meeting the migration mandate by inventorying cryptographic dependencies, scheduling certificate replacements, deploying hybrid TLS configurations, and rotating signing keys on the regulator's calendar — fails when the underlying architecture has embedded the cryptographic scheme as a structural assumption rather than as a substitutable primitive.

The first structural embedding is in certificate format. X.509 certificates carry algorithm identifiers, but downstream consumers frequently embed assumptions about key sizes, signature lengths, and validation performance. ML-DSA signatures are an order of magnitude larger than ECDSA; SLH-DSA signatures are larger still and more expensive to verify. Systems sized for elliptic-curve signature footprints — embedded devices with constrained flash, network protocols with tight MTU budgets, hardware security modules with fixed signature buffers — face hardware-level revision rather than configuration-level migration.

The second structural embedding is in trust-hierarchy semantics. PKI architectures commonly assume specific revocation mechanisms (CRL, OCSP, OCSP stapling) whose performance properties depend on signature size and verification cost. PQC migration changes the operational economics of these mechanisms. Systems that hardcoded refresh intervals, cache strategies, and reachability assumptions around ECDSA performance characteristics require redesign of the revocation layer, not merely re-issuance of certificates.

The third structural embedding is in protocol framing. TLS 1.2 and earlier protocol generations frame cryptographic exchanges in fields and structures designed around classical key sizes. Hybrid PQC TLS works in TLS 1.3 because TLS 1.3 was designed with extensibility for key-exchange evolution; it does not work cleanly in TLS 1.2, and many fielded systems remain on TLS 1.2 for compatibility reasons. The procedural answer — upgrade to TLS 1.3 across the fleet — is itself a multi-year project that runs in parallel with the PQC migration.

The fourth structural embedding is in software signing and secure-boot chains. Manufacturers embedded RSA-2048 or ECDSA P-256 verification keys in ROM, in eFuse, in immutable bootloader stages. Migrating those chains to ML-DSA or SLH-DSA verification requires hardware revision for new units and, for fielded units, often requires either accepting that secure-boot remains on the legacy primitive (creating a long tail of pre-PQC verification surface) or accepting that field replacement is the only migration path. CNSA 2.0 timelines do not accommodate either choice gracefully.

Procedural compliance treats the migration as a series of credential-rotation events. The architectural reality is that, where the cryptographic scheme is structurally embedded, the migration is a series of rebuilds disguised as credential rotations.

What the AQ Primitive Provides

The keyless-identity primitive treats identity as a continuity property rather than as a key-binding property. A device's identity is established by its participation in a hash-chain accumulator whose successor relationships are signed by whatever signature primitive the deployment selects. The hash function is substitutable; the signature scheme is substitutable; the verifier of the trust slope operates on observed signal characteristics — chain depth, corroboration density, signature verifiability under whatever scheme is currently in force — rather than on the algebraic properties of any particular cryptographic primitive.

Credential rotation is, under continuity-based identity, the ordinary operating mode rather than an exceptional event. Each successor hash in the chain represents a credential rotation from the previous state. Migrating from ECDSA to ML-DSA means that successor hashes after the migration point are signed under ML-DSA; the chain itself bridges the schemes through the rotation event, which is operationally identical to any other rotation. Migrating again from ML-DSA to a future scheme — or to SLH-DSA for high-assurance contexts where lattice-based confidence is insufficient — is the same operation, repeated.

Hybrid composition is a natural fit. A rotation event can sign the successor hash with both an ECDSA signature and an ML-DSA signature simultaneously, satisfying ANSSI hybrid requirements during the transition window without complicating the architecture above. The trust-slope evaluator accepts a successor as verified if any required signature in the composition verifies under the scheme currently in force; deprecating the classical signature is a configuration change at the verifier, not a re-signing of the chain.

The primitive composes cleanly with X.509 environments through a thin certificate-presentation layer that emits PQC-compliant certificates carrying the current chain head as the subject identifier. The certificate is short-lived because the chain is the authority; the certificate format is whatever the regulatory environment currently requires. When the certificate format itself migrates — to a future PQC-native format or to the IETF Composite Signatures profile — the chain underneath is unaffected.

Long-lived deployments inherit the same property. A vehicle, defense platform, or infrastructure node manufactured today carries a hash-chain seed signed under whatever scheme is current at manufacture; field rotation introduces new schemes as they become mandated; the device crosses CNSA 2.0, NIS2, and any subsequent transitions through credential rotation rather than through hardware revision or recall.

Compliance Mapping

Against CNSA 2.0, the primitive supports ML-KEM key encapsulation, ML-DSA signing, and SLH-DSA signing across the suite specified for National Security Systems, with credential rotation events that satisfy the audit trail requirements of NSM-10 implementation guidance. Against NIS2, the cryptographic-agility property is structural rather than aspirational: the architecture demonstrates agility by construction, not by procedural readiness assessment.

Against the BSI Migration Roadmap, the primitive supports the high-protection-need profile for hybrid mechanisms during the transition and pure post-quantum operation thereafter, with the rotation event providing the verifiable migration boundary that BSI evidence requirements call for. Against ANSSI hybrid guidance, the dual-signature rotation construction maps directly to the recommended composition pattern. Against the IETF hybrid TLS drafts, the primitive composes as the underlying identity layer above which TLS 1.3 hybrid key establishment operates without modification.

Against FIPS 203/204/205 themselves, the primitive uses the standardized schemes through their specified interfaces; the architecture does not introduce custom cryptographic constructions, only a substitution-tolerant identity model above the FIPS-validated primitives. Against software-signing and secure-boot mandates, the primitive's chain-based verification can be implemented in immutable boot stages with the verification primitive substitutable through chain rotation, eliminating the hardware-revision pressure that procedural migration creates.

Adoption Pathway

Adoption begins at the certificate-issuance layer. Existing X.509 environments retain their certificate-issuance pipelines and consumers; the keyless-identity primitive operates beneath, with certificates emitted as short-lived presentations of the current chain head. Migration to ML-DSA-signed certificates is a rotation event at the issuance layer; downstream consumers that accept the new signature scheme inherit PQC compliance immediately, and consumers that lag receive hybrid-composition certificates during the transition window.

The second adoption phase extends to software signing and secure-boot chains. New hardware revisions embed ML-DSA or SLH-DSA verification primitives in the immutable boot stage; chain-based identity above the boot stage permits subsequent migrations without further hardware revision. Fielded hardware retains its current verification primitive for the boot stage but migrates the application-layer identity to PQC schemes through the chain rotation, narrowing the legacy-cryptographic surface to the boot stage alone.

The third phase addresses long-lived deployments — vehicles, defense platforms, infrastructure. New units ship with PQC-native chain seeds; fielded units rotate to PQC schemes through whatever connectivity their deployment context allows, with the rotation event verifiable retrospectively when the unit returns to maintenance. The fourth phase addresses cross-jurisdictional deployment under divergent regulatory profiles: a single device can satisfy CNSA 2.0, NIS2, and BSI requirements simultaneously because the chain supports multi-signature composition and the trust-slope evaluator can be configured to require whichever subset of signatures the operating jurisdiction mandates.

The pathway is incremental, each phase delivers regulatory compliance independently, and the architectural primitive remains stable across the transition. The migration that procedural compliance treats as a multi-year, multi-billion-dollar architectural rebuild becomes, under continuity-based identity, a sequence of credential rotations executed on the regulator's timeline without disturbing the systems above.