ENISA Guidance for PQC

1. What the ENISA guidance is—and is not

The cited ENISA source is titled Post-Quantum Cryptography: Anticipating Threats and Preparing the Future. It was published on 13 May 2021 and is identified in the source set as current. The source describes ENISA’s view of the emerging problem and provides technical recommendations; it is not presented as an EU regulation, implementing act, or universally binding compliance instrument. Accordingly, organisations should distinguish three different questions: what ENISA recommends, what a national authority or regulator may require in a particular jurisdiction, and what a specific contract or internal policy mandates. The evidence cited for this article does not establish a general legal deadline applicable to all organisations.1234

ENISA’s stated concern is that widely used public-key cryptographic schemes are expected to become breakable when sufficiently capable quantum computers exist. The transition is expected to take years because systems and protocols must be integrated, tested, governed, and funded. That combination of uncertain technology timing and lengthy migration makes preparation a risk-management activity rather than a decision to wait for a single forecast date.1

2. ENISA’s practical recommendations

The ENISA evidence identifies several actions that organisations can begin before quantum computers capable of breaking current public-key systems are widely available. First, develop guidelines for major use cases. The purpose is to assess trade-offs and identify which systems and cryptographic approaches best match each application scenario. A public web service, a long-lived device, a certificate hierarchy, a backup archive, and an operational technology channel may have different performance, lifecycle, authentication, and availability requirements. A single enterprise-wide configuration should therefore not be assumed to be appropriate everywhere.1

Second, new protocols and major changes to existing protocols should be PQC-aware. This means considering how a protocol will negotiate, authenticate, exchange keys, manage certificates, handle larger messages or keys, and preserve downgrade resistance when PQC mechanisms are introduced. ENISA’s message is broader than selecting an algorithm: integration with existing systems and protocols is required, and organisations need knowledge that is not limited to external standards alone.1

Third, ENISA identifies hybrid systems as one possible transition approach. In the cited passage, hybrid systems may add PQC as an extra layer alongside pre-quantum cryptography. ETSI’s later deployment-considerations document adds important technical caution: hybrid schemes can provide backward compatibility or help mitigate vulnerabilities in a PQC implementation, but they increase protocol, implementation, and key-management complexity. Hybrid security and hybrid interoperability are not automatically the same, and algorithm negotiation must be protected against downgrade attacks.15

3. Binding requirements, recommendations, and forecasts

A useful governance discipline is to classify every PQC statement by authority and status. The ENISA source supplies recommendations and threat preparation. The NIST FIPS documents in the source set are final standards published on 13 August 2024: FIPS 203 specifies ML-KEM, while FIPS 204 and FIPS 205 specify digital-signature standards. FIPS 203 states that it became effective immediately upon final publication and that its three ML-KEM parameter sets are approved to protect sensitive, nonclassified communication systems of the US federal government. That federal approval is not, by itself, a universal requirement for organisations outside that scope.46

The standards also preserve an important limitation: conformance does not guarantee that an implementation or the surrounding system is secure. FIPS 203 places responsibility on the implementer to build a secure module, and FIPS 204 and FIPS 205 similarly state that conformance does not ensure a particular implementation is secure or that a conforming product secures the overall system. Enterprise assurance therefore requires secure implementation, key management, identity binding where relevant, testing, operational controls, and system-level risk assessment—not a certificate or algorithm name alone.467

Forecasts and indicative timelines require a separate label. The NCSC source, published 20 March 2025, describes PQC migration as a mass technology change taking years and gives key target dates primarily for technical decision-makers and risk owners of large organisations, critical national infrastructure operators, and companies with bespoke IT. Its evidence says that by 2028 organisations should define migration goals, perform a full discovery exercise, and build an initial plan. Those are NCSC milestones for its stated audience, not ENISA deadlines. The Canadian Cyber Centre’s roadmap, current as of 23 June 2025, likewise describes a recommended roadmap for Government of Canada nonclassified IT systems and says the migration will require significant commitment and take several years.23

4. What an enterprise should do with the guidance

An enterprise implementation programme should start with ownership and discovery. Identify executive accountability, technical owners, risk owners, procurement, architecture, legal or regulatory specialists, and the teams responsible for certificates, identity, networks, applications, devices, archives, and operational technology. Then create an inventory of key services and applications; record the data held, its value to an adversary, and its expected lifetime; identify protection in transit and at rest; and map the systems through which the data is processed. The NCSC evidence describes these as core discovery activities and notes that older cryptographic services may have evolved in a fragmented way, making both discovery and mitigation harder.2

Prioritisation should combine cryptographic exposure with business consequence and time horizon. Give early attention to data that must remain confidential for a long time, services with long-lived certificates or devices, high-value identity and signing systems, externally exposed key establishment, and systems whose replacement or upgrade cycle is slow. Do not focus only on confidentiality. In industrial control environments, the integrity of sensor readings and commands can be critical even where the underlying data does not require strong confidentiality. Internet-connected industrial devices may also provide an entry point into control networks, while resource constraints, difficult servicing locations, proprietary protocols, and lack of upgradeability can make migration especially difficult.1

Next, define technical decision points rather than selecting products prematurely. For each use case, assess whether the requirement is key establishment, digital signature, authentication, integrity, confidentiality, or a combination. Evaluate message and key sizes, bandwidth, computation, latency, certificate and trust-store changes, hardware support, random-number generation, side-channel exposure, logging, backup and recovery, and failure behaviour. For hybrid protocols, document which security property each component contributes, how negotiation is protected against downgrade, how mixed populations of clients are handled, and what the system does when only one mode is available.56

Build crypto-agility into architecture and procurement. The Canadian roadmap recommends clauses requiring PQC support compliant with applicable Cyber Centre recommendations, validated cryptographic modules, and crypto-agility that permits future configuration changes. It also notes that some product categories may not yet support PQC and that standards and network-configuration guidance continue to evolve. For organisations outside Canada, these are useful procurement principles rather than automatically applicable Canadian requirements: require clear algorithm and protocol support statements, migration paths, update commitments, lifecycle compatibility, testing evidence, and an ability to replace cryptographic mechanisms without redesigning the whole service.1

Finally, maintain a risk treatment for systems that cannot migrate immediately. The NCSC evidence identifies alternatives including migration to a compatible platform, retirement, operation until end of life, or tolerating the risk where justified. A system may also require no PQC action if it does not use public-key cryptography and is not vulnerable to the relevant quantum attack. Such decisions should be explicit, time-bounded where possible, owned by a risk authority, and revisited as standards, products, threat intelligence, and system lifecycles change.1

5. Standards, implementation, and assurance

Standards provide a foundation for interoperability and independent review, but they do not eliminate engineering responsibility. FIPS 203 specifies ML-KEM and identifies conditions for its security guarantees, including protection of randomness, decapsulation keys, and shared secrets. FIPS 204 and FIPS 205 address digital signatures and emphasise private-key secrecy and secure implementation. FIPS 204 also states that digital signatures are most useful when bound to an identity, and that certificate issuance involves identity and proof-of-possession assurances. These details matter when translating an algorithm standard into a production identity or trust architecture.467

ETSI TR 103 966 V1.1.1, published in October 2024, provides deployment considerations for hybrid schemes rather than a blanket recommendation to deploy them. It warns that inappropriate hybrids can be less secure than a nonhybrid PQC mode, that post-quantum algorithms may have different functionality and security properties from traditional algorithms, and that the eventual move to purely post-quantum protocols can avoid hybrid overhead and continued reliance on traditional components once confidence is sufficient. Organisations should therefore treat hybrid deployment as an engineered interim state with exit criteria, not as a permanent default.5

Testing should cover interoperability between traditional, hybrid, and PQC-aware clients; downgrade resistance; certificate-chain processing; key rotation and revocation; performance under realistic load; constrained devices; disaster recovery; and rollback or emergency reconfiguration. Testing evidence should be connected to the specific use case and implementation, because a standard’s conformance statement does not prove that the complete service is secure. Where implementation assurance is required, use the validation or certification regimes applicable to the organisation’s jurisdiction, sector, contract, and system classification.467

6. Reading ENISA alongside other authorities

The evidence shows why jurisdiction and scope must remain visible in a PQC programme. ENISA supplies EU-level agency guidance and recommendations. NIST’s FIPS standards are final US federal standards, with the cited FIPS 203 passage specifically addressing sensitive, nonclassified US federal communication systems. The NSA resource identifies its own post-quantum resources and refers to CNSS Policy 15, released 4 March 2025, but the cited passage does not provide the policy’s complete requirements. The UK NCSC gives indicative milestones for a stated audience, while Canada’s roadmap addresses Government of Canada nonclassified systems and directs departments handling classified or Protected C information to contact the Cyber Centre for advice.12463

For an organisation, the practical method is to create a requirements register. For every obligation or recommendation, record the issuing authority, jurisdiction, audience, document title, status, version, publication date, applicability, required action, evidence of implementation, and review date. This prevents an agency recommendation, a final technical standard, an indicative government milestone, and a contractual clause from being incorrectly treated as the same kind of requirement.1234

Conclusion

ENISA’s PQC guidance is best understood as an early-preparation and integration framework. It calls for use-case analysis, PQC-aware protocol design, future-proofing, and carefully evaluated transition approaches rather than a universal algorithm mandate or deadline. Enterprises should begin with cryptographic discovery and data prioritisation, then develop standards-based, crypto-agile designs, test implementations and protocols, address long-lived and difficult-to-upgrade systems, and assign explicit ownership to residual risk. The cited evidence supports urgency and structured preparation, but any binding requirement must be established from the authority, jurisdiction, sector, document status, and scope that actually apply.1234