Post-quantum cryptography: preparing a verifiable migration

Preparing a migration to post-quantum cryptography means identifying the exposed functions, then verifying their replacement on specific paths. Three factors determine the first piece of work: how long the data must remain secret, how long systems will take to change, and whether devices can be updated. A claim of “post-quantum compatibility” answers none of these questions on its own.

This report is for people coordinating applications, security and suppliers. It first explains what changes in secret establishment and signatures. It then provides an inventory, a completed supplier capability sheet and a fictional pilot in which an unfavourable result actually blocks wider deployment. The running example is a document exchange service between a company and its partners: simple enough to draw, yet already involving several protection boundaries.

Standards and institutional positions are linked to their sources. The numerical examples, frameworks and proposed decisions are teaching tools, without any company having been audited or any product tested. Pnebbula’s methodology, in French distinguishes these levels of evidence. They remain separate through to the final decision: a capability can be documented, installed, negotiated or observed on a connection, with a different conclusion at each stage.

A specific threat, different functions

Post-quantum cryptography, commonly abbreviated to PQC, covers mechanisms designed to withstand classical attacks and relevant quantum attacks. They run on classical systems, in software or hardware. Installing a quantum computer in the company is not a prerequisite. ANSSI distinguishes, in particular, key establishment and signatures, whose resistance continues to rely on studied cryptographic assumptions. A standard provides something that can be analysed; it does not provide invulnerability.

The threat concerns certain widely used public-key constructions. Their principle allows a public key to be distributed while the corresponding key is kept private. Depending on the construction, this serves to establish a secret or verify a signature. RSA and commonly used classical constructions based on elliptic curves are among the families threatened by a sufficiently capable quantum computer. NIST explains the challenges of their transition, without announcing that current machines can break the reader’s communications.

The qubit count in an announcement therefore does not establish when an attack could occur. The full computation would require suitable operations and reliability, rather than simply a collection of components. The guide to physical and logical qubits, in French explains this distinction. For an IT manager, uncertainty about the date does not remove the work to be done now: identifying uses that are difficult to replace and information whose confidentiality must last.

Symmetric encryption performs another role. It protects data using a shared secret, for example during a communication session. A key-establishment mechanism helps participants obtain such a secret; a signature helps verify an origin and integrity within a chain of trust. Replacing these functions with one “post-quantum” button would hide their respective requirements. Symmetric key sizes and hash functions still need to be considered under the recommendations that apply to them.

The distinction from quantum key distribution, or QKD, avoids another confusion, explained by the NCSC in its account of quantum networking. PQC changes the cryptographic mechanisms executed by classical systems. QKD uses quantum phenomena to distribute key material and requires suitable infrastructure. QKD does not, by itself, authenticate the parties. The functions therefore do not overlap completely: announcing a way to distribute a key does not, for example, address migration of the update verifier in a sensor. The boundary is therefore not “software versus hardware”; it concerns the mechanism and the service provided.

In the fictional document exchange service, a first question therefore concerns the secret established between the partner’s browser and the gateway. A second concerns authentication of that gateway. A third concerns the connection it opens to the origin server. All three can evolve at different speeds. Naming them makes it possible to request a specific supplier test instead of a general statement about the product.

Reason about timescales without predicting the breakthrough

The threat of collection now followed by future decryption explains why preparation can be useful before a relevant machine arrives. NIST describes this scenario: an adversary can retain encrypted exchanges to attempt to decrypt them later. This proves neither that a particular flow has been intercepted nor that it will be decrypted. It requires examining how long its contents must remain confidential.

Consider two fictional situations. One message contains a public timetable that loses its relevance after a day. Another contains an industrial design the company wants to keep secret for twelve years. Exposure to the same mechanism does not create the same stakes. The second situation requires looking beyond the transmission date. The contents may retain their value long after the server that sent them has been replaced.

Migration time matters too. An isolated component may be updated quickly; a device fleet requires tests, validations, replacements and agreement between several organisations. One way to reason about this is to record a remaining confidentiality period and an estimated transition period. Their sum represents a preparation horizon, not a quantum prediction. It shows what happens if the organisation waits before starting to discover its fleet.

Assume, solely to illustrate the calculation, twelve years of confidentiality and three years of transition. The combined horizon is fifteen years from the chosen starting point. This does not mean an attack will arrive in fifteen years, or that a company has fifteen years in which to act. It is a reminder that some data transmitted during the work will need to remain protected long after it ends. Changing the confidentiality period or discovering a device that cannot be updated changes the priority.

Signatures introduce a different timescale. Software signed today may be installed or verified throughout a device’s long life. The team must distinguish when it accepts a signature, how long it trusts the chain, and whether the verifier can be changed. For archives, retaining evidence and potentially renewing its protection depend on the system and its framework. Changing an algorithm does not automatically resolve preservation of every past document.

This time-based view avoids treating everything as equally urgent. Starting an inventory of an exposed service does not mean immediately switching all its clients. Conversely, waiting for a certain timetable can conceal long procurement and replacement lead times. The useful decision concerns a present action: document a sensitive use, reserve a test environment, question a supplier, or include a verifiable requirement in the next renewal.

From final standards to a service that is actually protected

Three final standards published on 13 August 2024 describe different functions. FIPS 203 defines ML-KEM, a key-encapsulation mechanism. FIPS 204 defines ML-DSA for signatures. FIPS 205 defines SLH-DSA, a stateless signature scheme based on hashing. These names identify mechanisms without, by themselves, describing the protocol that will use them or the product that will distribute them.

The operation of a key-encapsulation mechanism, or KEM, can be understood in three steps. Key generation produces a public encapsulation key and a private decapsulation key. Another party uses the public key to encapsulate: it obtains both a shared secret and a ciphertext to transmit. The holder of the private key decapsulates that ciphertext to obtain the corresponding secret when execution proceeds correctly. The text of FIPS 203 defines these operations for ML-KEM.

The secret is produced by this operation; encapsulation does not take an arbitrary pre-existing secret and encrypt it as a message. In a communication construction, the result can contribute to deriving the keys that then protect the data. ML-KEM therefore does not directly encrypt an entire file or provide its author’s signature. Renewal of key pairs and whether they are ephemeral depend on the protocol chosen: this functional explanation does not prescribe a universal key-generation policy.

Once this mechanism is understood, the path to the service becomes clearer. A library implements it; a protocol gives it a place; a product exposes the capability; a configuration permits it; two parties negotiate it. A break at any stage limits the conclusion. The presence of a library in software does not prove it is used during the connection. A capability enabled at the gateway does not prove its use on the next connection.

A certification is read with the same precision: object, version, assumptions and scope. A component’s label does not automatically transfer to the system integrating it. To prepare a purchase, the useful document connects function, version, protocol, configuration and evidence. A field that remains unknown identifies a test to perform; it should not be filled with the brand’s reputation.

The version of the references also matters. NIST announced the final NISTIR 8547 report in October 2026; an earlier draft no longer represents that latest state. The FIPS 203 and FIPS 204 notices indicate potential corrections to consult alongside the relevant implementations. Tracking these does not invalidate the standards as a whole. It is part of maintenance, just as tracking software versions and applicable recommendations is.

Hybridisation: a construction to examine

ANSSI recommends hybridisation during the transition: combining established classical mechanisms and post-quantum mechanisms to retain current assurances while addressing the new threat. Its FAQ distinguishes general recommendations from requirements within the regulated scope. It also identifies exceptions to systematic use of hybridisation for certain hash-based signatures, including SLH-DSA. This exception does not rank every signature product from best to worst; it concerns identified constructions.

For key establishment, imagine two contributions, one classical and one post-quantum, entering a secret-derivation process. The property sought is that protection does not collapse when just one contribution fails, under the assumptions of the chosen construction. Two algorithm names on a sheet do not demonstrate that property. The combination method, parameters, inputs actually bound to the session and code must match an analysed construction suited to the protocol.

Authentication remains a separate function. Sharing a secret with someone is not enough to establish their identity. A system that changes key establishment while retaining its classical signatures has passed a milestone, whose scope needs to be described. Claiming at that point that every function of the service benefits from the same protection would give the reader false information. The ANSSI technical paper on TLS 1.3, dated 2 February 2026, explains this separation during the initial handshake. Its account of software remains that of its publication date.

The fictional service illustrates a second trap. The partner’s browser establishes a first connection with a gateway, which terminates that connection. The gateway then opens another connection to the origin server. Observing the expected construction on the first connection tells us nothing about the second: the peers, configuration and sometimes the responsible team change. The pilot’s architecture drawing will therefore name both connections. The encapsulation diagram above explains the KEM operations without drawing those network terminations.

The compatibility policy must then specify what happens to an old client. For a transitional population, the service may permit a classical mechanism; on a path requiring the new construction, it may have to refuse the connection. This choice is made before the test, with the service owner. The expected outcome is observable in both cases. A silent success with a different mechanism would make protection coverage impossible to calculate.

The team does not build a hybrid mechanism from this illustration. It selects a recommended construction, its supported integration and the peers that can use it. The question to resolve then becomes measurable: on the selected connection and population, is the intended construction negotiated, is the expected authentication verified, and does compatibility behaviour follow the written policy?

Inventory use cases and their chains of trust

A useful inventory starts with a business function. Which service must remain available? What harm would disclosure or falsification cause? Who receives the data, who verifies signatures, who distributes keys, and who maintains the components? This starting point avoids a list of algorithms without an owner. Cryptography can be present in a library, a device, a browser or an outsourced service that the team does not directly control.

The NCCoE migration project separates cryptographic discovery from interoperability testing. This organisation highlights a limitation of scanners: discovering a presence is not enough to demonstrate the behaviour of a complete system. Conversely, establishing a successful connection does not prove every component has been inventoried. Interviews with service owners, documentation and technical observations complement one another.

The following sheet is an entirely fictional example. Its time periods show how to document a situation and do not describe any company. Each row connects a use case to an owner, a horizon and missing evidence. A version number, an owner and a link to evidence are enough to prepare the discussion; private keys remain in their management systems. The inventory itself may reveal architectural information: access should reflect the sensitivity of those references.

For each row, distinguish observed, declared, inferred and unknown. A supplier promising a future version provides a dated declaration. A test capture provides an observation within a scope. A deduction based on a library name remains an inference until actual invocation has been established. This discipline permits progress without claiming that an initial discovery campaign is exhaustive.

The chain of trust must then extend beyond the team’s boundaries. An application may depend on an identity provider, a certification authority, a network provider and a security-module manufacturer. Replacing one building block sometimes requires several parties to change at the same time. A very short internal timetable does not remove those dependencies. The register must state who can change what and which version the peer can accept. The guide to mapping technological dependencies, in French explores this distinction between a component’s presence, the possibility of replacing it and recovery that has actually been tested.

The inventory ultimately becomes a revisable snapshot. A new service, a merger of applications or a change of subcontractor can introduce other cryptographic uses. To limit obsolescence, connect a review to specific events: renewal, a major release, a change in network boundary or an incident. A new network termination thus triggers a review of the affected connections; a change of owner triggers handover of the evidence. The inventory becomes a maintenance tool when a specific event causes an assigned update.

Read a supplier response without treating it as general proof

Return to the fictional document exchange gateway. The supplier announces a post-quantum capability in a version available for a pilot. The capability sheet must let the team prepare its test without borrowing advertising language. The product name and version identifier below are invented; they designate no commercial offering or result observed by Pnebbula.

The first consequence is immediate: this document prepares a test on the inbound connection, rather than a statement about the entire service. The unanswered question about the origin connection becomes a targeted request. A second test or a documented response will be needed for that connection. The team can proceed on the first path while keeping the limit in writing, without interpreting an absent response as absent cryptography.

Statuses change with the evidence. If an authorised capture shows the negotiated construction on an identified client, that capability becomes observed for that session and configuration. The mechanism announced in the documentation remains declared until the corresponding path has been tested. Inferring another application’s capability because it includes the same library remains an inference: there is still no proof that it invokes the function. The state of a partner device missing from the inventory remains unknown. These four words lead to different next actions.

The supplier response must also distinguish the delivered version from the roadmap. A planned feature may guide a renewal; it does not belong in the column of available capabilities. The useful milestone is receipt of a supported version, with documented restrictions and a way to test it. If the milestone slips, the programme retains the announced date and the reviewed decision, instead of turning a promise into protection already obtained.

Support also concerns corrections and the ability to change. Who tracks the library? Who decides to update the product? How does the operator learn that a recommendation has changed? The answers determine part of the work remaining after the pilot. The buyer needs neither private keys nor confidential details unrelated to their role. A version, a boundary, a restriction and a verification procedure are often more useful than a volume of documents unconnected to the service.

The sheet can be used to compare two proposals. If one covers key establishment and the other only signatures, their rows are not equivalent despite the same commercial adjective. If the first remains experimental and the second is supported, the difference also concerns operations. The choice follows the expected function and the system’s lifetime; no brand compensates for a function absent from the contractual scope.

Prioritise using explicit conditions

Priority should not depend on a score whose calculation nobody can explain. The first condition concerns the need for protection: long-lived confidential data, an update that must remain authentic, or a critical service. The second concerns inertia: equipment that is difficult to change, end of support, or numerous partners. The third concerns the ability to act: an available version, a test environment, an owner and a way to establish the outcome.

An organisation can start with a highly sensitive service even if it cannot yet migrate it. The first action will then be to resolve a blocking dependency. Conversely, a service that is easy to update may provide a good technical exercise without representing the main business risk. The two choices serve different purposes. The first reduces a strategic uncertainty; the second tests a deployment method.

Imagine that the sensors in the earlier table can no longer receive a new verifier after manufacture. The question of the next purchase becomes urgent to investigate, regardless of the number of daily connections. For the public website, the provider may already offer a documented option. The question then becomes coverage of clients and the path to the origin. The same priority label would not adequately describe these two tasks.

This approach recommends three clear outcomes. If the use is poorly understood, complete the inventory and classification before choosing a construction. If the need is established but the components are unavailable, prepare renewal and track versions with a review date. If the need, responsibilities and capabilities are sufficiently documented, start a bounded pilot with failure criteria. None of these outcomes means a purchase is automatically authorised.

A lack of visible technical novelty does not mean a lack of progress. A purchasing clause made verifiable, a confirmed update capability or a previously unknown dependency can shorten a future transition. These results need to retain their proper names: preparation, capability or observation. Calling them a completed migration would lose the information that makes it possible to decide what comes next.

A pilot that can fail and explain why

The fictional pilot concerns the connection between a partner client and the document exchange gateway. It covers neither file storage nor the next connection to the origin server. Two modern client families, labelled A and B, are represented by their exact versions in the test record. An older family, C, is used to check the compatibility policy. These names are teaching references, with no real browser or product evaluated.

The team first records a baseline: the same service, clients, network path and documented load, before enabling the candidate construction. It records the intermediaries on that path. It measures establishment of a new connection separately from exchanges that reuse a session. Changing the server, network and construction together would prevent a difference being attributed to the mechanism alone. If a simultaneous change is essential, the report limits its interpretation.

The business owner sets the criteria before the test: a functioning service, compliant authentication, the expected mechanism observable for A and B, known behaviour for C, and resource limits acceptable for this use. Establishment times, volumes, errors and recovery are recorded with their units and context. There is no latency threshold proposed here for every reader. Failure against a security criterion blocks wider deployment even if the average response time appears good.

Now suppose A and B succeed, but C connects without information distinguishing classical fallback from the candidate construction. The test has not demonstrated an encryption failure. It has revealed an inability to establish the expected coverage. The decision is to retain the test group and obtain a means of observation or an appropriate rejection policy. Extending deployment to the entire fleet would create a migration rate that could not be justified.

Another case must fail in the ordinary sense in order to pass the test: the connection using an untrusted certificate must be rejected under the intended policy. In the scenario, this check takes place only in the authorised test environment. If the connection is accepted, the key-establishment mechanism may have worked while leaving an authentication defect. This result blocks production use until it is understood and corrected. A series of successful connections would not have revealed the same limitation.

For performance, the distribution matters as much as the average. Errors, slower clients and differences between paths explain what a central value can hide. The ANSSI paper on TLS 1.3 describes changes in exchange sizes and how the protocol handles them. Larger messages alone do not prove IP fragmentation, an additional round trip or a failure in an intermediary device. TLS messages, TLS records, TCP segments and IP packets belong to different layers. The pilot measures the actual path instead of inferring its behaviour from the byte count.

The report retains versions, configuration, population, policy, measurements and cases not covered. The NCCoE organises, among other work, interoperability testing in controlled environments; its findings can guide this protocol. Its verdict does not transfer to a different infrastructure. The pilot’s outcome identifies which families can move to the next stage, the corrections required and evidence still missing. It provides a usable decision, including when that decision is to wait.

Move from pilot to fleet without losing coverage

Moving to the fleet turns technical evidence into a coverage problem. In the pilot, the team knows which clients were tested. In operation, variants may remain absent from the list: rarely connected workstations, partner applications, recovery procedures or devices that communicate only on certain dates. Discovering these variants does not necessarily invalidate the pilot. It limits the conclusions it was legitimate to draw and identifies groups that still need examination.

The denominator must therefore be stated. A rate calculated from connections does not describe an application migration rate. A very active device may generate most traffic while many rarely used devices remain to be addressed. Conversely, counting updated products does not demonstrate the share of exchanges in which the new protection is active. A monitoring table can therefore retain two columns: updated devices and connections observed with the expected construction. Each column specifies its denominator and period.

Consider a small fictional example. An organisation knows of three hundred devices within a scope and has updated two hundred and forty. Installation coverage is therefore eighty per cent on that denominator. The remaining sixty devices are identified by their support status and use. Without observation of the negotiated mechanism, these numbers still provide no rate of active protection. If the inventory subsequently reveals fifty additional devices, the measure must be recalculated for the new scope and both dated states retained. No percentage replaces inventory quality.

A progressive deployment can organise this uncertainty. The team chooses a client family, observes behaviour, documents exceptions and then decides on the next family. Progress must not be presented as universal statistical proof: groups may differ in software, network and use. Its value is operational. It connects each change to an observation and limits the number of possible causes when an incident occurs.

The compatibility exception can be completed within the same example. Assume that family C represents thirty of the three hundred inventoried devices and that its active mechanism remains impossible to observe. The register places them outside demonstrated coverage. It names the fleet owner, the supplier dependency and a review after thirty days, a period chosen solely for the exercise. Closing this exception requires a supported version and a new test, or an explicit decision about retaining the classical service. Reaching the date does not demonstrate resolution.

Monitoring must remain proportionate. Retaining communication contents is not necessary to establish every piece of information useful to migration. Information about versions, negotiated mechanisms and errors may suffice, depending on the architecture. Its collection must follow the organisation’s security and confidentiality rules. The migration record should state what is observed and what cannot be observed, rather than request more detailed logs by default.

A closure decision ultimately concerns an explicit scope. It can establish that the inventoried families have been addressed, their active mechanisms verified and the remaining exceptions governed. It does not make security a permanent property. A new service or supplier change can reopen part of the work. Useful closure hands the next team an operationally usable state, with its evidence and review rules.

Costs tied to observable operations

Transition costs are not limited to an algorithm’s computation time. Uses must be discovered, dependencies corrected, tests organised, components updated, peers tracked and evidence maintained. A licence cost may exist; it is not inferred here from a public standard. Commercial prices, network tariffs and staff costs must come from the organisation’s context or current offers.

A first teaching calculation shows how to distinguish volume from billing. Assume a fictional service opens one million new connections per day. Further assume that the change under study adds three thousand bytes per new connection, measured at an explicitly chosen boundary. The extra volume is three billion bytes per day, or three decimal gigabytes. Over thirty days, it reaches ninety decimal gigabytes. These assumptions represent no real implementation of ML-KEM or TLS.

The calculation produces no cost in euros without a billing rule. Bytes may be counted differently depending on the supplier, traffic direction, commitments and other consumption. Nor does it produce an additional latency: message distribution, connection reuse and network behaviour are involved. Its value is to identify a measurement and contract to examine, rather than announce a general budget increase.

A second calculation separates initial work from operations. For twelve fictional services, assume half a day of discovery and one day of testing per service, followed by four days of common coordination. The total is twenty-two workdays. It remains to define who carries them out, which tasks can be combined and which dependencies are excluded. A discovery tool may change this breakdown, but buying it does not prove that tests will disappear.

These numbers are neither a market estimate nor a quotation. They make a budget open to examination. If three very different services are discovered behind a common name, the workload changes. If two partners have no compatible version, coordination delay may dominate technical time. A “post-quantum migration” line without assumptions does not reveal these causes.

The cost of waiting also deserves a description without an invented number. Renewal may provide an opportunity to request a documented capability. Missing that window may retain a component that is hard to change for a long time. This does not justify assigning an arbitrary monetary value to a future incident. The useful comparison concerns concrete operations: verify a capability now, test during planned maintenance, or later replace equipment that remains useful.

France and Europe: understand the scope of deadlines

The European Commission presents a coordinated approach, arising from an April 2024 recommendation followed by a roadmap published in June 2025. The page, updated in October 2026, indicates a start to transition in Member States before the end of 2026 and transition of high-risk uses by the end of 2030 at the latest. These markers concern coordination and priorities; they do not establish that every French company has an identical general obligation on the same date.

The roadmap publication page describes an initial high-level document addressed to Member States. For the reader, good practice is to separate this European framework, applicable national requirements, sector rules and contractual commitments. A date cited in a commercial article can mix these layers. The document must always be connected to its intended audience and scope.

ANSSI advises public and private organisations to include the threat in their risk analysis and begin an inventory. Its FAQ distinguishes that advice from the regulated scope and the process for products entering qualification. The reference to 2027 concerns an objective for evolving obligations for that qualification. It should not become an announcement that every application in every company will be prohibited by that deadline.

These indications remain useful when preparing a purchase even if a specific obligation has not been established. They encourage requests for functions, versions, upgrade paths and support limits. A company can prepare a requirement proportionate to the product’s lifetime and risk. The precise contents of a contractual clause or regulatory obligation nevertheless require analysis of the corresponding text and context.

The prospect of European autonomy lies in this ability to understand and verify. Choosing a European supplier does not remove dependencies on libraries, components or international standards. Choosing a foreign supplier does not demonstrate that a transition is impossible either. A map of responsibilities, versions and replacement options contributes more to a decision than geographic origin alone.

US sources also have their own scope. The NIST transition report is an important technical reference and addresses, among other things, the US federal timetable. That timetable is not transposed here into French law. Its value for a European operator is to understand functions, transition issues and the evolution of international suppliers while retaining an analysis of its own applicable framework.

Archives, constrained devices and outsourced services

Archives are a reminder that migration does not concern only new communications. The reader must distinguish the confidentiality of retained contents, protection of the keys granting access and verification of old evidence. Changing a network protocol does not automatically update the mechanisms used to retain or authenticate objects already stored. Retention policy and the responsible services must therefore participate in the inventory.

A false retrospective repair must also be avoided. If an adversary had already recorded a communication insufficiently protected against a future attack, securing subsequent exchanges would not erase that copy. This reasoning follows from the delayed-decryption scenario without presuming that interception actually took place. It justifies prioritising new sensitive exchanges while separately examining what can still be protected in storage systems.

Constrained devices pose another question: who will be able to update the verifier several years from now? An update mechanism itself depends on a chain of trust. Changing it may require an intermediate step, hardware support or physical intervention. A product sheet mentioning an algorithm does not necessarily describe that path. The purchasing record must request a demonstration of the procedure and identify what would become impossible after certain support deadlines.

Outsourced services do not remove the organisation’s work. They move some responsibilities. A provider may protect a connection to its platform while another connection to the origin system follows a different policy. The customer needs to know the boundaries, exceptions and observable information. They should not receive unnecessary technical secrets; properly scoped evidence of capability and operation may suffice for their role.

Crypto-agility helps address these situations if it becomes a demonstrated capability. NIST CSWP 39, updated on 29 June 2026, describes adapting algorithms while preserving security and operations. The expression does not mean offering every choice to every user. A policy must govern permitted constructions, changes, tests and the state actually used.

For a legacy service, delaying activation may be reasonable if no supported path is ready. Waiting must then be active: an owner, a named dependency, information awaited and a review date. Potential isolation or replacement requires a study specific to the system. This report does not propose a universal compensating measure; it provides a way to make the limitation visible before it is forgotten in a programme presented as complete.

Decide now and know what would change the decision

The first recommended task is an important use case whose peers can be described and for which evidence can be obtained. In the document exchange service, that starts with confidentiality periods, both connections and their respective owners. The team then completes the capability sheet and prepares tests of success, rejection and compatibility. This sequence produces usable knowledge before committing to wider deployment.

Three outcomes summarise decisions with distinct causes. A poorly understood use returns to the inventory. A documented use whose components do not yet offer a supported path informs renewal and supplier requests. A use with available versions, peers and test conditions can enter a bounded pilot. Moving into operation adds conditions for coverage, observation and recovery; it does not follow from starting the pilot alone.

A favourable result remains tied to a boundary. In the example, success on the inbound connection with A and B includes neither C, the connection to the origin nor document retention. Each gap receives an owner and an action. A new supported version may close an exception; a new peer may reopen part of the inventory. The programme can then explain why its scope changes.

New cryptanalysis, an updated recommendation or an interoperability incident may change the selected construction or priority. The NIST publication on crypto-agility helps frame this ability to evolve while maintaining service continuity. Migration is sufficiently documented when the team can show which functions are protected, on which paths, with what evidence and which exceptions remain open. This state, transferable to operations, is what the report should help build.

Self-assessment questionnaire

An editorial tool, with no data collection, scientific score or certification. Answer Yes only if evidence is available, No if the condition is missing, and Needs verification if it remains unknown.

Read the answers and choose the next action

For questions 1 to 3, any No or Needs verification answer first requires clarification of the relevant need, horizon or responsibility. A pilot without a defined purpose or decision-maker would produce a result that is difficult to use. For questions 4 to 8, address the missing criteria: inventory, technical verification, environment, resources or protocol. A Yes to question 5 does not compensate for a No to question 8.

Questions 9 and 10 prepare operations. If they remain open, a bounded test can provide information, but wider production deployment does not yet have its monitoring conditions in place. Ten Yes answers allow a decision on wider deployment to be considered with the relevant experts; they do not prove security or automatically authorise a purchase. The questionnaire displays the criteria to address without transmitting or retaining answers.

Preparation checklist

• Define a use case, a boundary and a dated protection requirement.
• Retain the evidence, version and owner of every priority dependency.
• Check recommendations and support for the candidate construction.
• Write the protocol, baseline and failure criteria before the test.
• Test representative peers, rejection and recovery behaviour.
• Observe the active state and name exceptions to the protected scope.
• Plan review, version changes and a decision on wider deployment.

Sources and scope

Primary sources consulted on 9 November 2026, supplemented on 10 November for the NCSC: ANSSI, PQC page and FAQ; ANSSI, TLS 1.3 technical paper v1.0 of 2 February 2026; NIST FIPS 203, 204 and 205, 13 August 2024; NIST CSWP 39upd1, updated 29 June 2026; NCCoE, Migration to PQC project; European Commission, PQC page updated 20 October 2026 and roadmap published 23 June 2025; NIST, announcement of the final NISTIR 8547 report, 27 October 2026, updated 2 November. NCSC, Quantum networking technologies, version 1.0 of 5 August 2025, for the PQC/QKD distinction. Precise links appear in the text and associated registers.

The calculations of three gigabytes per day, ninety per month and twenty-two workdays are entirely fictional simulations. The frameworks, questionnaire, diagrams and protocol are editorial syntheses. No product performance or company audit is claimed. The original NIST CSWP 39 page has been withdrawn and superseded: only the updated version is recommended here.