A digital lock is usually judged by how well it resists attack today, but a responsible organisation also asks whether it can be changed tomorrow without tearing down the door. Quantum computing introduces an apparent exception to a sensible rule: do not replace stable protection with novelty before evidence is available. The exception does not invalidate prudence; it reveals everything the rule must include. Some data must remain secret for decades, certain adversaries can store them now and try to decrypt them later, and complex infrastructures take years to renew certificates, protocols and devices. Preparation does not mean declaring that a devastating quantum machine is imminent. It means knowing where cryptography lives, distinguishing risks, testing standardised alternatives and building agility so the next key can be installed in a verifiable way. Magic promises a date and a universal solution; engineering works with horizons, dependencies, tests and reversible plans.
The lock metaphor is useful if it is not taken literally. Cryptography does not protect a single door: it authenticates users, signs updates, encrypts files, establishes sessions, validates transactions and preserves record integrity. The same algorithm may appear in shared libraries, security modules, industrial equipment, mobile applications and contracts with third parties. Replacing it requires knowing which property it supplies, which keys it uses, how long the data live and what would happen if the transition failed.
The quantum threat does not affect every component equally. Widely deployed public-key algorithms based on factoring or discrete logarithms would be exposed to a sufficiently large, error-corrected quantum computer. Symmetric cryptography and hash functions are treated differently: increasing key sizes or adjusting parameters can provide margins against known quantum speed-ups. Saying that “cryptography will be broken” erases these distinctions and encourages purchases without architecture.
The exception explains the rule of prudence#
The right rule is not to wait until danger becomes visible, but to demand proportionate evidence before acting. In security, evidence includes the period for which data retain value, the adversary’s capability, the duration of migration and the harm caused by interruption. If a medical record must remain confidential for thirty years and its system takes eight years to renew, the relevant clock does not start on the day a capable machine appears. It starts when somebody can copy encrypted traffic in the expectation of opening it later.
The right rule is not to wait until danger becomes visible, but to demand proportionate evidence before acting.
This pattern is called harvest now, decrypt later. It does not prove that all traffic is being stored and cannot set a date for quantum progress. It does change the analysis for long-lived information. Risk combines uncertainties: the adversary may not retain the material, the algorithm may resist for longer, or the data may lose their value. A rigorous institution writes down those assumptions, assigns owners and reviews the scenario; it does not turn uncertainty into advertising certainty.
Early preparation has another, less spectacular reason: inertia. A certificate may be renewed in minutes, but a certified medical device, a railway controller or a satellite cannot follow the same cadence. Some equipment lacks remote updates, archive formats must remain readable for decades, and partners do not all change at once. The quantum exception explains why a maintenance rule must include replaceability from the design stage.
Map first, then choose the new key#
A cryptographic inventory connects assets to concrete uses. It records protocol, algorithm, key size, library, version, owner, supplier, location, protected data, confidentiality period and operational dependency. It also identifies firmware signatures, machine identities, backups and internal links that rarely appear in a superficial scan. The objective is not to produce an enormous spreadsheet but a view that makes prioritisation and change location possible.
Automated discovery should be complemented by interviews and configuration evidence. A scanner may detect a suite negotiated on the network, but not a public key embedded in powered-off equipment or a signature used only during recovery. Contracts reveal services where the organisation does not control the algorithm. Every finding needs a confidence level and observation date; an inventory without maintenance quickly becomes a historical photograph.
The NIST institutional page on post-quantum cryptography brings together the evaluation process and resulting standards. Its value for an inventory is not to turn algorithm names into a shopping list, but to provide stable technical references for comparing uses, parameters and implementations. Transition begins by connecting those references to real systems, not by installing an unfamiliar library everywhere.
Standards, implementations and trust#
An algorithm selected after public evaluation is not identical to a secure implementation. Code may leak information through execution time, power, memory or faults; a poor random generator can ruin correct keys; an integration may validate a certificate incorrectly. Testing must include known vectors, interoperability, handling of invalid inputs, performance under load and observation of side channels where the context requires it.
In 2024, NIST published initial standards for post-quantum key-establishment mechanisms and signatures. The NIST standardisation project documentation distinguishes competitions, drafts, standards and work that remains open. That distinction protects against two opposite errors: waiting for impossible perfection or deploying an experimental proposal as though it were final. Governance should define which states are admissible in the laboratory, pilot and production.
New constructions have different sizes, timings and failure profiles. Larger certificates and signatures can affect packets, constrained memory or logs. Testing must therefore cover the entire path: generation, storage, rotation, negotiation, revocation, auditing and recovery. A quick speed test does not reveal every boundary. Security lives in the complete key life cycle and in the system’s behaviour when something goes wrong.
Cryptographic agility without a magic button#
Cryptographic agility is the ability to replace algorithms, parameters, keys and providers without redesigning every application. It requires explicit interfaces, versioned configurations, separation between business logic and cryptographic operations, telemetry and rollback procedures. It does not mean allowing any algorithm through configuration: flexibility without policy can reactivate weak options. Useful agility is governed by approved lists, tests and retirement dates.
Hybrid modes combine a traditional and a post-quantum technique during a transition. They can reduce the risk of relying exclusively on a new implementation, provided that their composition preserves security when at least one component works as expected. Duplicating mechanisms also increases size, complexity and the surface for mistakes. “Hybrid” is not an automatic seal; the protocol must specify how secrets are combined, how messages are authenticated and how downgrade by an attacker is prevented.
The CISA post-quantum cryptography roadmap emphasises inventories, supplier assessment and transition planning. It is institutional guidance, not a universal calendar. Each organisation must combine it with its regulation, budget cycles and service criticality. Preparing interfaces and contracts may deliver immediate value even if a particular replacement is postponed.
Case 1: a hospital protects long-lived medical records#
A hospital finds that its external connections are well managed, but diagnostic-image backups use a product whose recovery depends on a proprietary format and old certificates. The information remains sensitive for decades. The team does not immediately replace the entire platform: it classifies data by useful life, documents flows, asks the supplier for its roadmap and creates a test copy that can be migrated without touching the clinical archive.
The pilot selects a non-critical exchange channel and compares traditional, post-quantum and hybrid negotiation. It measures latency, message size, device compatibility, audit logging and behaviour when a key is invalid. Clinical evaluation participates because a delay acceptable in archiving may be dangerous in emergency care. The resulting decision applies new protection to selected exchanges and keeps others behind compensating controls until equipment is validated.
The case avoids two false promises. It does not claim that the new algorithm anonymises data or resolves excessive permissions. Nor does it wait for a quantum announcement to locate dependencies. The principal gain is operational: the hospital knows who can change each lock, how long it would take, which data need priority and how legitimate access will be preserved during an emergency.
Case 2: a factory does not stop production for a certificate#
A factory has controllers with an expected fifteen-year life. Some verify firmware through a signature fixed in hardware and can be updated only during a scheduled shutdown. The inventory reveals that renewing the central application is insufficient: the chain includes the manufacturer, integrator, boot module, signing server and manual recovery procedure. Quantum risk is mixed with a present problem of obsolescence.
A test bench receives a firmware version capable of recognising two trust chains for a limited period. The team tries a valid package, an altered package, an authorised old signature and an interrupted transition. It measures memory, boot time and the ability to return to a safe version. The new key is not activated in production until a power failure has been shown not to brick the controller.
The manufacturer agrees to publish formats, support dates and cryptographic components in future deliveries. The quantum exception therefore explains a more general rule of resilience: no essential mechanism should remain permanently tied to an invisible algorithm. The project does not buy urgency; it buys verifiable maintainability and coordinates change with normal industrial safety windows.
Case 3: a university brings order to identities and signatures#
A university operates web portals, wireless networks, research repositories, student credentials and software signatures. An announcement proposes to “make the whole campus quantum”. Leadership turns the slogan into questions: which secrets live longest, which signatures must be verified in twenty years, which systems depend on third parties, and which services can provide a laboratory without affecting enrolment or payroll.
The first pilot signs an internal package with a post-quantum scheme alongside the current mechanism. Repositories store the algorithm, parameters, date, trust chain and validation evidence. A compromised key is simulated, and clients are checked to ensure they do not silently accept the weaker option. Students and staff receive a restrained explanation: the test evaluates migration and does not demonstrate an invulnerable network.
The university publishes negative interoperability results and keeps a reproducible test suite. That transparency allows suppliers to correct problems and prevents each faculty from improvising. Success is not the number of services displaying a post-quantum label, but fewer unknown dependencies, named owners and evidence that historical signatures will remain interpretable when tools change.
Prioritise with horizons, not prophecies#
A priority matrix can cross four variables: information lifetime, exposure to capture, migration time and impact of compromise. Systems holding durable data and renewing slowly deserve early attention. An ephemeral, easily updated service without persistent secrets can wait while its inventory improves. This classification avoids applying the same expenditure to a medical archive, a public web page and an isolated sensor.
The ENISA publication on the current state of post-quantum cryptography and mitigation helps place families of methods, threats and transition within a European framework. It should be read alongside sector obligations and local assessments. An institutional source supplies vocabulary and references; it does not replace the system owner’s analysis or automatically certify a commercial product.
Useful indicators measure inventory coverage, the share of assets with an owner, contracts with agility requirements, reproducible pilots, key-rotation capacity and recovery time. Counting installed algorithms may reward rushed deployment. Formal exceptions should also be recorded with their reason, compensating controls, review date and owner. A documented exception does not break policy; it shows where policy meets the real world and how compliance will be restored.
A prepared lock means a prepared organisation#
The programme ends up being less exotic than its trigger. It needs architecture, procurement, asset management, training, continuity tests and communication. Security leaders coordinate, but data owners, engineering, legal counsel and suppliers decide what can change and when. A common forum prevents the technical team from promising confidentiality contradicted by access processes, or procurement from renewing a dependency without transition requirements.
Responsible communication separates possibility, demonstrated capability and operational risk. It sets no baseless countdown, does not call everything currently deployed obsolete and does not present standards as talismans. It explains which systems have been examined, which assumptions remain open and what the next decision threshold will be. This preserves trust and allows correction if technology or context advances differently.
Preparing the lock before receiving the key means making the mechanism visible, reserving room for change and rehearsing replacement without blocking the door. The quantum exception teaches that prudence is not immobility: it means acting earlier when harm has a long memory and repair needs time. A mature organisation does not claim to predict the future. It demonstrates that it can recognise a signal, compare standardised options, change under control and continue providing service throughout the transition.




