The post-quantum transition does not come from a single instrument. It comes from a stack of regulations, transpositions, roadmaps and standards. They are all here, grouped by how directly they apply to you, each with a note on what it actually means.
It is easy to get lost in the list. In practice only a handful of these create a legal obligation for an organisation in Romania: NIS2, through OUG 155/2024, DORA for financial services, GDPR for personal data, and, contractually, standards such as ISO 27001 and PCI DSS.
The rest do not bind on their own. But the roadmaps and guidance — the European one from 2025, the DNSC roadmap of May 2026, the ENISA guidance — are what fix the dates and the interpretation. When a supervisor assesses whether your measures meet the state of the art, that is where they look.
The technical standards become relevant later, at implementation: which algorithms, which hybrid schemes, which migration methodology.
Direct legal or contractual force. If you fall within scope, these are not optional.
Roadmaps, guidance, official positions. They set the dates and the interpretation supervisors measure against.
Standards, specifications, methodologies. They matter once you move to implementation.
Instruments with direct legal or contractual force over organisations in Romania. If you fall within their scope, these are not optional.
Romania's national roadmap. Sets the EU-aligned milestones: cryptographic asset inventory by end-2026, high-risk systems migrated by 2030, full transition by 2035. Formally a recommendation, but DNSC measures against these dates.
Open the document →Romania's transposition of NIS2. The primary citation for any Romanian NIS2 obligation. Establishes DNSC as competent authority and mirrors the EU fine ceilings (€10M / 2% of turnover).
Open the document →The regulatory technical standard for ICT risk management under DORA. This is where the crypto-agility requirement sits, along with the explicit obligation to update cryptographic technology in line with cryptanalytic developments.
Open the document →Articles 6, 8, 9 and 28 are the cryptographically relevant ones. Article 9 covers cryptographic controls; Article 28 covers third-party risk — the basis for any supply-chain discussion.
Open the document →Article 21(2)(h) is the cryptography requirement; Article 21(1) carries the 'state of the art' language. Article 7 concerns national strategies. Applied in Romania through OUG 155/2024.
Open the document →Article 32 ('Security of processing') requires state-of-the-art technical measures. An independent legal hook, separate from NIS2 and DORA — particularly relevant for personal data with a long confidentiality life.
Open the document →Directly enforceable cryptography requirements (Section 9) for the listed digital service providers. Cascades outward through procurement clauses into other sectors.
Open the document →Requires products to support security updates across their lifetime — the Commission and ENISA tie this to PQC upgradability. Annex I holds the design obligations. Fines up to €15M / 2.5% of turnover.
Open the document →The DORA technical standard on ICT third-party risk. Read alongside Article 28: PQC roadmap requirements have to be passed down to ICT suppliers.
Open the document →Establishes the EU Digital Identity Wallet framework and revises trust services. The ETSI TS 119 series is being updated with PQC migration paths.
Open the document →The registration and notification procedure under OUG 155/2024. Operational rather than PQC-specific, but part of the framework Romanian entities have to meet.
Open the document →The methodology for assessing service disruption and assigning entity risk levels under OUG 155/2024. Operational rather than PQC-specific.
Open the document →Control A.8.24 (cryptography) is increasingly read by auditors as requiring PQC readiness. The 2026–27 audit cycles will probe this.
Open the document →Includes quantum-readiness expectations within the cryptography requirements. Becomes contractually mandatory through the card schemes.
Open the document →Roadmaps, guidance and official positions. Not binding in themselves, but they set the dates and the interpretation supervisors measure against.
The document that fixes the European dates: national transitions beginning end-2026, critical infrastructure migrated by 2030, broad transition complete by 2035. Also sets out the risk-based prioritisation model.
Open the document →The US migration schedule: legacy public-key algorithms deprecated after 2030, disallowed after 2035. The international benchmark other national roadmaps align to or deliberately depart from.
Open the document →170 pages. Formally a companion to Implementing Regulation 2024/2690, but used as the operational reference for NIS2 generally. The cryptography section is the essential part.
Open the document →Proposes an Article 7(2)(k) requiring Member States to include PQC transition policies in national strategies. Recital (8) is the firmest EU statement on quantum risk so far.
Open the document →DNSC's interpretation of what 'state of the art' cryptography means. Covers the case for PQC, harvest-now-decrypt-later, hybrid approaches and the migration framework.
Open the document →The Commission Recommendation that set up the coordination process. It is the legal basis for the machinery that produced the June 2025 roadmap.
Open the document →The French authority's positions on PQC. Notable for the three-phase approach: classical, then hybrid, then pure PQC. Relevant for organisations with French operations.
Open the document →Mandates PQC by 2035 for US national security systems. Globally relevant because it cascades through US federal procurement to NATO suppliers.
Open the document →The standards, specifications and methodologies you reach for at implementation time, when the conversation moves from what is required to how it is done.
Germany's national cryptographic recommendations. The first major EU authority to require hybrid PQC. Shapes procurement requirements across regulated EU industries.
Open the document →The practical companion to NIST IR 8547. Volume A is the executive summary, Volume B the methodology and architecture, Volume C the discovery and interoperability testing.
Open the document →Specifies hybrid key exchange constructions (classical plus PQC). Used together with the NIST standards for concrete deployment patterns.
Open the document →A strategic migration guide from ETSI's quantum-safe cryptography working group. Useful as a methodology reference for sequencing the phases.
Open the document →The standardised key encapsulation mechanism. Three parameter sets (ML-KEM-512, 768, 1024).
Open the document →The standardised post-quantum digital signature algorithm, lattice-based.
Open the document →Stateless hash-based signatures. Larger than ML-DSA, but resting on more conservative security assumptions — it relies only on the security of the hash function.
Open the document →A backup KEM, code-based. Insurance against future cryptanalysis of ML-KEM. Still in draft.
Open the document →Implementation guidance for the ISO 27001 controls. Used alongside it.
Open the document →The standards for qualified electronic signatures and seals. Being updated with explicit PQC migration paths.
Open the document →Where the real deployment patterns are defined, ahead of formal standardisation. The X25519MLKEM768 hybrid that Chrome and Cloudflare already ship comes from these drafts.
Open the document →In a half-day briefing we move from the stack of documents to what actually applies to you, and to a first step your board can adopt.
