Add recommendations for quantum data protection to QS01

[syedDS]

The changes requested by Roger A.Grimes

[arik-barkay]

please elaborate on the addition

[RogerAGrimes]

General Comment: There appears to be two different audiences/needs addressed in a single Top 10 list: Post-Quantum Implementers and Quantum Computer program users. Do others feel that two different Top 10 Lists might make more sense.

Add these to How to Prevent under QS01:
Physically or logically isolate critical data to prevent eavesdropping
Implement an allowed protection mechanism that is quantum-resistant, such as quantum cryptography, quantum networking, quantum key distribution, etc.

Add this to How to Prevent under QS02:
Enable perfect forward secrecy on data streams where possible

Add this to How to Prevent under QS03:
Investigate how Merkle Tree Certificates will impact your environment

Comment: I believe TPM 2.0 is crypto-agile and previous versions may be upgradeable (TPM is mentioned in document)

[andyatsage]

General Comment: There appears to be two different audiences/needs addressed in a single Top 10 list: Post-Quantum Implementers and Quantum Computer program users. Do others feel that two different Top 10 Lists might make more sense.

This seems to be intentional, based on the following statements in the project README:

QS01-QS07 address the migration surface - risks to organisations whose existing classical cryptography must be replaced with post-quantum equivalents. QS08-QS10 address the platform surface - risks to organisations running workloads on quantum computing platforms.

Separate lists might make more sense, but I don't think the space has evolved enough to specifically call out 10 individual weaknesses for both. (But let's see what new candidate entries get proposed!)

[RogerAGrimes]

Elaborating on: Add these to How to Prevent under QS01:
Physically or logically isolate critical data to prevent eavesdropping
Implement an allowed protection mechanism that is quantum-resistant, such as quantum cryptography, quantum networking, quantum key distribution, etc.

Roger: The existing suggested protections don't include these two points. Deleting or isolating data and systems from potential attack have long been a way to protect legacy systems that can't be upgraded. The existing protections did not include quantum solution protections.

[RogerAGrimes]

A post-meeting (8/3/26) new risk addition...and I'm not sure of the title, but essentially it might fit under the compliance topic suggested by another member. That is the risk of a gov't, legal, or regulatory agency abruptly cutting off access to quantum computers that you are using to run your business, similar to what happened with OpenAI a few weeks ago...where the US government didn't agree with how OpenAI was addressing a risk and immediately executed an order forbidding any foreign organizations and even foreign employees from accessing the involved system. This sent a shudder throughout the AI industry and world. It's a supply-chain risk. If you are a foreign government (or even a domestic entity), there is risk in using a system that the govt/law/regulatory agency may say, without notice, that you can no longer use. The risk with quantum is real. Once the first CRQC is announced, if it's before critical gov't functions and critical infrastructure are ready, can the involved nation-state simply declare that CRQCs and similarly capable systems can't be used? Is this a compliance, supply chain, governance, or guardrail risk?

[RogerAGrimes]

Another relevant example to the compliance risk addition I mentioned above is: QKD. QKD is a relevant post-quantum protection that should be available to all who want to take advantage of it. But NIST does not all QKD to be used in any NIST-compliant system, which indirectly means that the Fortune 500 or anyone else hoping to sell to the US gov't will not use QKD.