Crypto-agile Defence-in-Depth (CADD)

There is a misunderstanding on quantum-threats that is unfortunately being echoed by many industry practitioners including CISOs from large corporations and vendors. It is that we should not be worried about the quantum threat since cryptographic migration is not new. In the past, we have migrated from DES to 3DES to AES, and we have also migrated from MD5 to SHA1 to SHA256, and we are also in the midst of shifting from RSA to ECC. They trivialize being quantum-safe to migrating existing vulnerable public key algorithms (RSA, ECC, DH) to PQC (Post-Quantum Cryptography) or QKD (Quantum Key Distribution) and hence business-as-usual.

Post-Quantum Migration =/= Quantum-Safe

While it is true that the industry has successfully migrated cryptographic algorithms in the past, it is entirely wrong to equate being quantum-safe to post-quantum migration. Hear me out:

• The quantum threat is more than "Harvest-Now-Decrypt-Later (HNDL)".  HNDL refers to the threat whereby an attacker can collect the encrypted communications happening today (“harvest-now”), and use a quantum computer to decrypt the communications sometime in the near future (“decrypt-later”). We expect sensitive data such as transaction details (payee, account numbers, transaction values), emails (secret documents, customer agreements, product designs, financial reports) and customer information to be targeted by such attacks. But there are other quantum threats that will be coming in the future including: (i) tampering with fraudulent transactions; (ii) creating fake identities of users, login credentials and certificates; and (iii) reneging on previously signed documents. 
• PQC and QKD come with their own limitations. In August 2024, NIST (National Institute of Standards and Technology) standardized 3 PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) to replace RSA, ECC and DH. Yet in March 2025, NIST selected HQC as a backup algorithm "to have a fallback in case ML-KEM proves to be vulnerable". The simple question becomes how  much lead time does an enterprise have to switch to a different solution if and when ML-KEM is discovered to be vulnerable. Days? Hours? or minutes? Similarly, while the key-generation functionality in QKD has its basis in information-theoretic security, it has limited use-cases that cannot be used in many present day applications including biometric authentication, document-signing, etc.
• Being quantum-safe comes with overheads and tradeoffs. Increased processing, higher data storage and impact to the customer experience (CX) immediately comes to mind. In February 2026, Google has already announced that their Chrome browser will support MTC (Merkle Tree Certificates) instead including PQC certificates into their root store due to the expected increase in performance and bandwidth requirements. Product vendors claiming to have crypto-agility are essentially incorporating more algorithms within their product and delegating the deployment of quantum-safe cryptographic algorithms to their users. They forget that their users are not trained to fully understand that latest developments in quantum threats nor are the users sufficiently equipped to react speedily to changes when necessary (think zero-day attacks for cryptographic vulnerabilities).  

The simple question becomes how much lead time does an enterprise have to switch to a different solution if and when ML-KEM is discovered to be vulnerable. Days? Hours? or minutes?  - Time to re-think crypto-agility

It becomes clear that we need a new paradigm when thinking about being quantum safe and crypto-agility. 

Applying Defence-in-Depth to Crypto-agility

Current cybersecurity already relies on defence-in-depth, whereby protections are layered across the network, systems, applications, and data. This holistic approach ensures a more resilient architecture that can respond faster and more comprehensively to attacks. The same philosophy can applied to crypto-agility for quantum-safe solutions:

• Understanding Quantum threats. At the top layer, knowing what the vulnerabilities are, how they can be exploited, and how they will evolve will provide the basis for where and how the infrastructure should be defended. Threats may start from harvest-now-decrypt-later, shift towards certificate tampering and biometric cracking before getting to side-channel attacks using quantum sensing. Organizations won't be able to keep up with this ever-changing technological race, but someone needs to get this intelligence done.
• Managing vulnerabilities. With the intelligence provided, the next layer is responsible for discovering where the vulnerable assets are located, quantifying the extent of the potential damage, and validating the fix if the vulnerability has been resolved. Crypto-agility at this layer is about maintaining the delicate balance between quantifying the risk exposure of the infrastructure versus the overheads and impact to customer experience to resolve the problem.
• Mitigating weaknesses. The bottom layer is how we are mitigating the quantum threat. The classical defence-in-depth approach becomes more apparent here where quantum vulnerabilities can be fixed for (i) data-in-motion (e.g. TLS, VPNs); (ii) data-at-rest (e.g. email, document management); and (iii) identities (e.g. certificate, authentication). Crypto-agility becomes the intelligent design and use of the different quantum-resistant mechanisms across the layers to close out the vulnerabilities in the most cost-effective, timely or least disruptive way. We expect that vendors that offer only single point-products are unlikely to scale well.

pQCee's Crypto-agile Defence-in-Depth (CADD)

Over the past 3 years, the pQCee team has been focused on building out the various components and we are now ready to unveil pQCee's strategy for Crypto-agile Defence-in-Depth (CADD). 

At the top layer, we have QuICScript engine that is able to simulate quantum-attacks (see Shor's Algorithm).

At the middle layer, we have PacketQC which we are building into a post-quantum governance tool to help organizations start their migration journey (see how to start).

At the bottom layer, we have fine-grain offerings for:

• Data in Motion: QKDLite is a quantum key management middleware to seamlessly connect existing business infrastructure to Quantum technologies. (see VPN, StrongSwan, Digital QKD)
• Data at Rest: SafeQuard is a suite of quantum-safe cryptographic tools to defend against harvest-now-decrypt-later attacks. (see Form encryption, Windows CNG, Gmail encryption)
• Identities: InoQulate is a document security solution that protects PDF documents against quantum spoofing and tampering. (See pilot)

This becomes a comprehensive blueprint for any organization, large or small, that is serious about being quantum-safe.

We will have more to share as we continue our drive to help customers in their post-quantum journey. Please reach out at info@pqcee.com if you would like more information.

This article was first published at https://qcve.org/blog/crypto-agile-defence-in-depth