Post-quantum readiness: which dependency prevents your company from changing?
Before buying a quantum-protection promise, identify what needs to change and who can accept that change without interrupting business operations.
Leer en portuguésIn this article
- The announcement describes development and experimentation
- Start with a dependency that has business consequences
- Inventory needs traceability rather than secret material
- Request a verifiable supplier plan
- The exercise needs continuity and denial cases
- A decision to proceed needs outstanding questions
- Frequently asked questions
- Related reading
- Sources and references
By Pentesty
The announcement describes development and experimentation
In its September 21, 2026 announcement, CTI Renato Archer reported its Army partnership on AURORA. It describes requirements, prototypes and experimentation, including possible future links. It does not establish protection already operating in businesses. Separately, NIST’s migration project addresses cryptographic inventory and post-quantum interoperability. These inform readiness questions without equating quantum-communication research with completed enterprise migration.
Start with a dependency that has business consequences
Choose a function such as document signing, branch connectivity or application authentication. Identify the protected information, how long it must remain confidential and which systems verify authenticity. This makes discussion concrete without depending on a prediction about when a computer capable of breaking the protection in use will exist.
Map the route across application, library, certificate, equipment and supplier. Record who can change each component. The supplier-chain analysis helps reveal dependencies missing from a commercial vendor register. Where another organization operates a layer, turn missing visibility into a formal question for its owner.
Inventory needs traceability rather than secret material
Connect each cryptographic use to the function it supports. For an authorized connection, document what was observed, where and when. Compare that observation with application documentation and operator confirmation. Partial discovery cannot represent the whole environment, especially where internal services or embedded components exist.
Do not gather private keys or protected content merely to complete a spreadsheet. Identifiers and controlled references may be enough to connect evidence. Define inventory access and retention because the record also describes important organizational relationships.
- Function: the activity and information depending on protection.
- Component: the identified application, library or service.
- Accountability: who updates it and confirms compatibility.
- Evidence: origin, date, coverage and remaining unknowns.
Request a verifiable supplier plan
Ask which products and versions are covered, which dependencies must change and how compatibility will be demonstrated. Distinguish intended support, available implementation and accepted deployment. A sales presentation can begin the conversation without establishing that a capability is enabled in the company’s contract and configuration.
NIST distinguishes cryptographic discovery from interoperability testing. Use that distinction to organize received answers. A change may work between two components while still requiring confirmation from another partner, document validator or recovery tool. Record limits rather than turning a pilot into general certification.
The exercise needs continuity and denial cases
Prepare a staging sample with fictitious data. Run the function before and after the candidate configuration, checking results, errors, time and resources under the same recorded conditions. Include a case that should be denied. Confirm the application contract without developing custom algorithms or improvising cryptographic combinations.
Define recovery if the change interrupts a client or partner. The recovery dependency analysis helps check who can reach the destination and restore the function. Avoid an alternative that restores operation by silently suspending the protection that justified the project.
A decision to proceed needs outstanding questions
Prioritize by sensitivity, required protection lifetime, replacement lead time and coordination difficulty. State these assumptions instead of announcing one universal risk date. Different systems may need different sequences, with the teams accepting operational consequences involved.
Keep results, candidate configuration, decisions and open questions. Reassess when suppliers publish relevant support or the application changes. Useful progress makes a change identifiable, testable and reviewable without assuming that the word quantum resolves permissions, software defects or recovery.
G7: connect readiness with the next renewal cycle
Editorial update: October 16, 2026
The G7 Cybersecurity Working Group call to action, published by ANSSI on September 3, 2026, recommends phased planning, inventory, dependency mapping and using renewal cycles for the post-quantum transition. The document addresses governments and organizations across sectors. It is joint guidance; it does not itself create a law or a mandatory worldwide deadline.
To make that guidance verifiable, select an already planned renewal and ask the supplier to identify the product, version, dependencies and proposed compatibility test. Record what is available, what requires development and who accepts the change. Compare the evidence with the function that must keep operating, including an authorized recovery path. Use the company's schedule to define next steps without turning a commercial forecast or completion of a pilot into evidence of comprehensive protection.
Frequently asked questions
Is AURORA already deployed in my business?
The reviewed announcement describes a partnership and development involving experimentation. It does not establish enterprise deployment or commercial availability of universal protection.
Are quantum communication and post-quantum migration the same deliverable?
The cited projects address different objectives and paths. Ask suppliers to define the product, proposed protection and components actually covered.
Must inventory store private keys?
This article proposes identifying uses, dependencies, owners and evidence. Avoid collecting secret material where controlled references meet the review’s purpose.
Does compatibility testing prove algorithm security?
It can confirm behavior exercised in an integration. Algorithm, implementation and compliance validation require their own criteria and evidence beyond a functional test.
Sources and references
- CTI Renato Archer: AURORA cooperation and development
- NIST NCCoE: migration, inventory and interoperability
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.