ANSSI (France) PQC Guidance

1. What the cited evidence says about ANSSI

The first and most important conclusion is evidentiary: the cited bundle does not include a source published by ANSSI, a French ministry, a French regulator, or a French legal instrument. Its primary sources are NIST, NSA, ETSI, the UK National Cyber Security Centre, the German Federal Office for Information Security, ENISA, and the Canadian Centre for Cyber Security. Consequently, this article cannot verify the existence, current status, scope, wording, or legal effect of an ANSSI PQC document. That limitation is not a finding that ANSSI has issued no guidance; it is a limitation on what this closed bundle permits the article to assert.1

The distinction matters because technical standards, regulator guidance, government roadmaps, and binding legal requirements have different effects. For example, FIPS 203 states that it becomes effective immediately upon final publication, while FIPS 204 and FIPS 205 describe implementation qualifications and place responsibility for the security of the overall implementation on the responsible authority. Those statements describe the relevant NIST standards and their implementation context; they do not, on the cited evidence, impose obligations on French private organisations or public bodies. [claim-2, claim-3]234

2. The technical baseline available in the cited source set

The strongest standards evidence in the cited source set is from NIST. FIPS 203, published as final on 13 August 2024, specifies the Module-Lattice-Based Key-Encapsulation Mechanism, ML-KEM, and identifies three parameter sets with different security-strength and performance trade-offs. The same source explains that public-key key-establishment and digital-signature systems based on integer factorisation and discrete logarithms would be at risk if large-scale quantum computers were realised. FIPS 203 also cautions that conformance to the standard does not by itself ensure that a particular implementation or product is secure.2

FIPS 204, also final and published on 13 August 2024, specifies a module-lattice-based digital-signature standard. Its qualifications emphasise private-key protection, secure implementation, and the difference between conforming to a standard and securing the overall system. The source further notes that digital signatures are most useful when bound to an identity and that secure key management is essential. These points are relevant to enterprise migration because replacing an algorithm is not equivalent to completing identity, certificate, key-management, implementation, and operational assurance work. [claim-3, claim-5]3456

FIPS 205 specifies a stateless hash-based digital-signature standard. Like FIPS 204, its qualifications state that standard conformance does not ensure that an implementation or the wider system is secure. The cited passage also says the standard will be reviewed every five years to account for advances and innovations. That review statement reinforces the need for organisations to preserve the ability to change cryptographic components rather than treating a single deployment choice as permanently settled. [claim-3, claim-6]342

ETSI TR 103 966 V1.1.1, dated 2024-10, provides deployment considerations for hybrid schemes and protocols. It explains that hybrid deployment may mitigate vulnerabilities in post-quantum implementations or provide backward compatibility, while also increasing protocol, implementation, and key-management complexity. It warns that hybrid negotiation must be protected against downgrade attacks and that the requirements may differ between confidentiality and authentication. The report expressly does not provide guidance on whether hybrid schemes should be used. [claim-7, claim-8]7

3. Binding requirements, recommendations, and forecasts

Within this bundle, the clearest binding language belongs to the individual documents and their stated scopes. FIPS 203, FIPS 204, and FIPS 205 are final NIST standards, but the cited passages do not state that they are mandatory for French organisations. The Canadian roadmap is expressly a recommended roadmap for migration of nonclassified Canadian government IT systems, and the UK NCSC timeline is aimed primarily at technical decision-makers and risk owners of large organisations, critical national infrastructure operators, and companies with bespoke IT. Those scopes should not be silently transferred to France.56

The cited source set also contains recommendations and planning expectations. ENISA recommends that new protocols or major changes to existing protocols be PQC-aware and discusses hybrid systems as an additional layer alongside pre-quantum cryptography. The Canadian Cyber Centre recommends early migration, enterprise-wide analysis of hardware, software, infrastructure, and data, and procurement clauses addressing PQC support and cryptographic agility. These are useful engineering and governance signals, but the evidence does not convert them into ANSSI rules. [claim-10, claim-11]16

Forecasts and indicative timelines must be handled separately. ENISA says that transition is expected to take years because of complex processes and financial costs. The UK NCSC describes PQC migration as a mass technology change taking a number of years and gives indicative milestones, including a 2028 milestone for migration goals, discovery, and an initial plan. That is UK guidance, not a French deadline. The cited evidence supports planning urgency, but not a universal date for France. [claim-4, claim-12]51

4. Practical implications for organisations in France

Even without attributing a rule to ANSSI, the evidence supports a disciplined enterprise programme. Start by identifying key services and applications, recording the data held—including expected lifetime and value to an adversary—and identifying how data is protected in transit and at rest. Map the systems through which those services and data are processed, including hardware, software, protocols, certificates, keys, and external dependencies. The NCSC describes this discovery and assessment as the starting point for migration, while the Canadian roadmap similarly calls for understanding cryptography usage across the enterprise. [claim-5, claim-11]56

1. Establish scope and ownership. Identify business owners, security owners, infrastructure teams, procurement, legal and compliance stakeholders, and suppliers responsible for cryptographic services.
2. Create a cryptographic inventory. Record algorithms, protocols, certificates, key stores, libraries, modules, endpoints, embedded devices, hardware lifecycles, and data flows.
3. Prioritise by confidentiality lifetime, integrity impact, authentication importance, business criticality, exposure, and replacement lead time.
4. Assess migration paths. For each dependency, consider upgrade, replacement, architectural change, retirement, end-of-life operation, or explicitly documented risk tolerance.
5. Test interoperability and performance. Measure message sizes, bandwidth, computation, latency, certificate and key-management effects, failure handling, and operational monitoring.
6. Add procurement and architecture controls. Require support for approved standards and cryptographic agility where appropriate, while avoiding unsupported claims that a product is secure merely because it names a standard.
7. Maintain decision records. Document the source, version, scope, assumptions, residual risks, exceptions, and review triggers for every major migration decision.

Prioritisation should include systems whose principal risk is integrity rather than confidentiality. The NCSC notes that industrial-control and industrial-IoT environments may contain resource-constrained, difficult-to-service, embedded, proprietary, or non-upgradeable devices. It also notes that faulty sensor readings or commands can cause industrial-control failures even where the underlying data does not require strong confidentiality protection. This is a reminder not to rank systems solely by secrecy of stored data.5

The programme should also account for systems that cannot be migrated immediately. The NCSC describes options including moving to a compatible platform, retiring a service, running it until end of life, or tolerating the risk where justified. It also notes that some systems may not be vulnerable because they do not use public-key cryptography, while legacy physical infrastructure and outdated protocols may be unable to support PQC. Each exception should therefore be explicit, risk-assessed, time-bounded where possible, and connected to an ownership and monitoring decision rather than hidden in an inventory.5

5. Hybrid deployment and cryptographic agility

Hybrid deployment is not a universal answer. ETSI explains that combining a post-quantum algorithm with a traditional algorithm can support backward compatibility and, in some constructions, retain security if at least one component remains secure. However, it also warns that hybrid schemes may be less secure than a non-hybrid post-quantum mode when designed inappropriately, and that protocol negotiation must resist downgrade attacks. Algorithm combinations therefore require a documented security analysis for the particular protocol and use case. [claim-7, claim-8]7

A migration plan should distinguish hybrid security from hybrid interoperability. A hybrid arrangement may be selected because clients cannot be upgraded simultaneously, or because the organisation wants transitional protection while standards and implementations mature. Those objectives are not identical, and the security guarantees may differ. ETSI also advises against deploying post-quantum algorithms that have not undergone standardisation or sufficient analysis, even in a hybrid arrangement. [claim-8, claim-15]7

Cryptographic agility is the operational capability to change algorithms, parameters, protocols, implementations, or trust material without redesigning the entire service. The Canadian procurement guidance specifically recommends support for cryptographic agility and says that earlier inclusion of PQC clauses can reduce migration costs. For a French organisation, this is best treated as a procurement and architecture objective supported by the cited evidence—not as a claim that every French contract must contain a particular clause. [claim-11, claim-16]6

6. A controlled way to use this evidence

Use the cited source set in three layers. First, use the final NIST standards to understand the standardised algorithm families and implementation qualifications. Second, use ETSI and ENISA to frame protocol, hybrid, integration, and future-proofing questions. Third, use the NCSC and Canadian roadmap passages as examples of migration governance, discovery, prioritisation, procurement, and lifecycle planning. At every layer, retain the original publisher, document status, version, date, jurisdiction, and intended audience in the decision record. [claim-2, claim-7, claim-9, claim-11]2756

Do not use the cited UK milestones as French deadlines, the Canadian roadmap as a French government requirement, or NIST federal standards as proof of French legal applicability. Do not infer that a product is secure from algorithm conformance alone: the NIST standards expressly preserve implementation and system-level responsibilities. Finally, do not infer that hybrid deployment is recommended simply because ETSI explains how it may be used; the ETSI document states that it does not provide guidance on whether to use hybrid schemes. [claim-3, claim-8, claim-9, claim-12]34756

Conclusion

The cited source set cannot substantiate a current ANSSI PQC mandate, recommendation, or deadline because it contains no ANSSI or French primary source. It does support a practical, vendor-neutral preparation programme: inventory cryptography and data, prioritise long-lived confidentiality and critical integrity, use final standards carefully, evaluate hybrid designs rather than assuming them, require implementation and system-level assurance, and build cryptographic agility into architecture and procurement. French organisations should keep those conclusions separate from legal applicability and validate any French-specific obligation against the current competent authority. [claim-1, claim-4, claim-5, claim-11, claim-16]156