Discovery is not protection

Executive summary

The question enterprises face about post-quantum cryptography (PQC) is no longer whether to migrate, or to which algorithms. NIST published its first three post-quantum standards in August 2024 ^[1][2][3]. In October 2026 it published the final version of its transition plan: quantum-vulnerable public-key algorithms will be deprecated after 2030 and disallowed after 2035 under NIST standards and guidelines ^[4]. The open question is how to organize a transformation that touches almost every system an organization runs.

This paper makes two arguments. The first is about where the work is. We describe the Enterprise PQC Transformation Landscape: four domains where cryptography lives, two layers that run through all of them, and the categories of solutions that address each part. No single vendor or product covers the whole map, and a large part of it changes only when the organization changes it itself.

The second argument is about how to approach the work. Most PQC programs are organized as a sequence: discover, assess, plan, then transform. Discovery is indispensable, and every transition plan cited in this paper starts there. But discovery does not protect anything. An organization can identify every vulnerable asset it owns and still leave every one of them exposed. Under harvest-now, decrypt-later attacks, that gap has a cost, because data captured during the discovery phase cannot be recalled when protection improves later.

You can discover 100% of your cryptographic vulnerabilities and still have 100% of them exposed.

From these arguments we derive an execution model with five elements:

1. Map the landscape. Understand which domains, layers and owners the transition touches, and which parts vendors will modernize versus which the organization must change itself.
2. Separate knowledge from protection. Treat discovery as the source of knowledge, not as evidence of risk reduction.
3. Discover and transform in parallel. Start mitigating known, well-characterized exposure while discovery continues, with each engine feeding the other.
4. Measure protection. Report exposure actually removed, not only assets catalogued.
5. Build for cryptographic agility. Make this migration the last one that has to be run as a crisis.

The landscape also reveals a gap. None of the solution categories, on its own, operates cryptography for applications as one governed service across keys, algorithms and engines, or re-protects what is already encrypted. Chapter 4 describes that gap; Chapter 11 describes how ANKATech addresses it.

This document is a companion to The Cryptographic Control Plane whitepaper, which introduces the CAPA framework (Crypto Agility Posture Architecture) ^[5], and to Crypto agility beyond the quantum clock, which develops CAPA's first pillar ^[6]. Where that paper asks how expensive the next cryptographic change will be, this one asks a more immediate question: how much of the current exposure is actually being removed.

How to read the evidence in this paper

Every claim in this paper belongs to one of five categories, and the text signals which. Citations in brackets refer to the references at the end of the document.

We never attribute our interpretations to the institutions we cite. NIST, the NCSC and the EU recommend starting with a cryptographic inventory ^[4][7][8]. The NCSC describes its phases as interrelated and NIST names early deployments alongside inventory, but none of them proposes running discovery and transformation as two parallel engines, or reporting protection metrics separately from discovery metrics. Those are our conclusions, and this paper explains why we think the evidence supports them.

The conversation is fragmented, the problem is not

PQC has moved from research to regulation faster than most organizations have moved from awareness to execution. The standards and the calendar are now fixed. What is still missing is a shared picture of the work.

2.1 The deadlines are set

NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024 ^[1][2][3]. On 27 October 2026 it published the final version of NIST IR 8547, which states that NIST will deprecate all quantum-vulnerable cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035 ^[4]. The same report records that, under Executive Order 14412 and OMB Memorandum M-26-15, US federal agencies must move their high-value assets and high-impact systems to post-quantum key establishment by 31 December 2030 and to post-quantum signatures by 31 December 2031 ^[4].

Outside the United States the milestones converge. The UK NCSC asks organizations, particularly large organizations and operators of critical national infrastructure, to define their migration goals, complete discovery and build an initial plan by 2028, carry out their highest-priority migration activities by 2031, and complete migration by 2035 ^[7]. The European coordinated roadmap expects every Member State to have implemented its first steps by the end of 2026, and high-risk use cases to be transitioned as soon as possible and no later than the end of 2030 ^[8].

NIST also reminds organizations of how long this kind of change takes: the journey from algorithm standardization to full integration into information systems can take 10 to 20 years ^[4].

2.2 Each vendor frames the problem as what it sells

Much of the market conversation is shaped by the capabilities each vendor commercializes:

• Discovery vendors frame PQC as an inventory problem: find the algorithms, build the cryptographic bill of materials (CBOM), score the risk.
• Network vendors frame it as a protocol upgrade: hybrid TLS, quantum-safe VPNs, updated gateways.
• HSM, KMS and cloud providers frame it as a platform capability: new algorithms in the key store or the managed service.
• PKI vendors frame it as a certificate lifecycle problem.

Each of these is a real part of the work. None of them is the whole of it. An organization that adopts one vendor's framing can make genuine progress on its part of the map while large areas of exposure stay untouched, and while its reports suggest the program is on track.

The framing the conversation leaves out is control: who governs and operates cryptography across all of these, and who re-protects what is already encrypted? Chapter 4 returns to this question.

2.3 Two questions: where, and how

This paper offers a vendor-neutral answer to two questions. Chapters 3 and 4 answer where: where cryptography lives in an enterprise, what must change in each place, and which categories of solutions address which parts. Chapters 5 to 9 answer how: how to run the transformation so that it reduces exposure early rather than only describing it well.

PQC is not a single technology upgrade. It is an enterprise transformation that must change cryptography in several places at once, under different owners.

The landscape: where cryptography lives

The Enterprise PQC Transformation Landscape organizes the work into four transformation domains and two cross-cutting layers. Domains are places where cryptography is used. Layers are capabilities that every domain depends on. The distinction matters because the owners, the interventions and the pace of change are different in each.

3.1 Four transformation domains

Network and transport. TLS, VPNs, IPsec, gateways, load balancers, proxies, service-to-service links and enterprise messaging. This is where network vendors are adding hybrid and post-quantum key exchange through software, firmware and configuration updates, and where NIST places an early priority: TLS protects data in transit for nearly every federal system and service, and NIST recommends ML-KEM-768 as the default parameter set for key establishment ^[4]. The benefit of vendor upgrades is real, but adoption depends on both endpoints, on interoperability and on configuration. An organization benefits from its vendors' roadmap; it should not assume that the roadmap modernizes all of its infrastructure.

Platforms and storage. Databases, storage systems, cloud services and enterprise platforms. Symmetric encryption is largely not the issue: NIST does not expect to need to transition away from its approved symmetric standards as part of the PQC migration ^[4]. What must be examined is everything around the symmetric key: how it is generated, wrapped, distributed, protected and recovered, and which public-key mechanisms the platform uses for key exchange, authentication and replication. Part of this transformation depends on the platform vendor, and part on how the organization has configured and integrated it.

Data and cryptographic assets. Encrypted files, archives, documents, backups, B2B exchanges and other protected objects that already exist. This is the domain most often missed, because upgrading a network or a platform does not change data that was protected before the upgrade. A file whose content is encrypted with AES and whose content key is wrapped with RSA carries a quantum exposure through the RSA wrapping, even though AES remains adequate. Removing it requires re-wrapping or re-encrypting the asset itself.

Application cryptography. Cryptography embedded in applications, libraries, APIs, digital signatures and integrations. A large enterprise may run hundreds of applications that call classical algorithms directly. Changing them can mean code changes, library upgrades, regression testing and redeployment, application by application. It does not always have to: centralizing cryptographic services behind a stable interface can move much of that change out of the applications themselves, a related pattern to what NIST describes as a cryptographic API that separates applications from the implementation of the algorithms themselves ^[9].

Vendors will modernize what they own. Data you have already encrypted, and the cryptography inside your own applications, change only when you change them.

3.2 Two cross-cutting layers

Some cryptographic capabilities are not a place but a dependency. Treating them as additional domains would hide the fact that every domain relies on them.

Identity and trust. PKI, certificate authorities, certificates, digital signatures, code signing and trust stores. Network handshakes, platform authentication, signed documents and software releases all depend on this layer, and its exposure behaves differently from that of encryption, as Chapter 6 explains.

Key management. Generation, storage, wrapping, distribution, rotation, recovery and destruction of keys, through HSMs, KMS and application-level key stores. Every domain consumes keys, and the key hierarchy determines how far a single compromise can reach. PQC changes the algorithms that wrap and exchange keys; it does not, by itself, fix a key hierarchy that was badly designed.

3.3 A condition across every domain: long-lived systems

Operational technology, IoT, embedded devices, smart cards and other systems with long service lives appear in more than one domain. They are where the assumption that the vendor will update them is weakest, because some cannot be upgraded in the field at all. The NCSC acknowledges that there will be “a small set of more rarely used technologies for which migration by 2035 may be more difficult” ^[7], and NIST states that systems that cannot support post-quantum cryptography should be identified and prioritized for replacement or decommissioning ^[4]. For these systems the decision is often not how to migrate, but what to isolate, replace or retire.

3.4 What changes, and who changes it

The last column is the reason the landscape matters. Most of what vendors will deliver lands in the first two rows. Most of what organizations will have to deliver themselves lands in the last two.

The PQC solution ecosystem

No single vendor solves the entire PQC transformation. Solutions fall into categories, and each category is strong in some parts of the landscape and silent in others. This chapter places vendors only according to capabilities they document publicly; it does not assume that a vendor lacks a capability we did not find.

4.1 Solution categories

Vendor examples reflect each vendor's public documentation as of November 2026, as cited, and are not an exhaustive evaluation. Other vendors also offer capabilities in these categories.

4.2 Vendor upgrades are necessary, and partial

Cloudflare is a good example of a vendor doing its part well. In February 2026, Cloudflare reported that well over 60% of human-generated TLS traffic to its network was protected with hybrid ML-KEM ^[15]. On the connection from Cloudflare to its customers' own servers, however, post-quantum key exchange depends on the origin supporting it, and Cloudflare reports that the share of origins supporting post-quantum key exchange has grown to 12.8% ^[25].

The vendor moved. Most of the other side of the connection has not.

The same pattern applies across the table. An HSM that supports ML-KEM protects new keys generated with it; it does not change the wrapping of keys created before. A post-quantum certificate secures new handshakes; it does not re-protect a document signed last year.

4.3 Status matters: support, validation and certification

Vendor documentation describes capabilities at different stages, and procurement decisions should distinguish them. Entrust, for example, reports that the post-quantum algorithms in its nShield firmware achieved validation under NIST's Cryptographic Algorithm Validation Program, while the FIPS 140-3 validation of the module itself had been submitted rather than completed ^[21]. Thales reported FIPS 140-3 Level 3 validation of Luna HSM v7.9 as in progress in July 2025 ^[20]. Algorithm support, algorithm validation and module certification are three different milestones.

4.4 Discovery platforms are moving toward remediation

Several discovery platforms now document remediation workflows, policy enforcement or automated migration tasks ^[13][14]. That is a positive development, and the argument of Chapter 5 is not that these products only inventory. It is that the act of discovery, however complete, changes no protection; and that coordinating migration tasks is different from re-protecting data that was already encrypted and applications that call cryptography directly.

In the public documentation reviewed for this paper, we found no explicit description by the discovery and remediation vendors cited above of re-encrypting existing data at rest or re-wrapping the content keys of stored files and archives. SandboxAQ lists “encryption remediation” among AQtive Guard's preview capabilities without specifying whether it extends to stored data ^[14]. This observation is limited to the documentation cited, and is not a statement about their roadmaps.

4.5 What none of them does on its own

Read across the last column of the table and a pattern appears. Each category modernizes its own piece of the landscape. None of them, on its own, operates cryptography for the organization's applications as one governed service across keys, algorithms and engines, or re-protects what is already encrypted.

Each category modernizes its own piece. Nobody is serving cryptography to the applications as a whole.

That missing role is what a cryptographic control plane provides: a layer that governs and operates cryptography across the other categories, while the root of trust stays in the organization's HSM or KMS. The concept is published as an open standard ^[26]. Chapter 11 describes ANKATech's implementation.

The term “control plane” is also used in adjacent categories. Keyfactor, for example, describes a Trust Control Plane for machine identity and cryptographic management, built around observing, analyzing, provisioning, orchestrating and governing certificates, keys, trust anchors and machine identities ^[27]. The page refers to coordinating cryptographic operations without detailing them; in the documentation reviewed for this paper, it does not describe performing encryption or signing for applications, or re-protecting stored data. The two scopes are different and can coexist.

Discovery is not protection

This chapter states the central distinction of the paper. It is deliberately blunt, because the confusion it addresses is common and costly.

Discovery does not protect anything. Period.

5.1 Why every framework starts with inventory

This is not a criticism of discovery. NIST describes the transition as “beginning with cryptographic inventories, migration planning, and early deployments” of PQC-enabled products and services ^[4]. The European roadmap calls the creation and maintenance of inventories of cryptographic assets “a first essential step and ‘no-regret’ move for every entity” ^[8]. CISA, NSA and NIST asked organizations to create a cryptographic inventory that offers visibility into how they use cryptography as early as 2023 ^[28], and the NCSC places a full discovery exercise among its 2028 milestones ^[7].

We agree with all of them. Without knowing where cryptography is, an organization cannot prioritize, plan or verify anything. But knowing about an exposure and removing it are different outcomes, and they are easy to confuse.

5.2 One million files

Consider an organization with one million files whose content keys are protected by quantum-vulnerable mechanisms. After twelve months of discovery it has found and catalogued all one million. The inventory is complete and accurate. The number of files whose protection has changed is zero.

The zero is precise, not rhetorical. It refers to the protection provided directly by the act of inventorying, not to the strategic value of the knowledge gained. That value is real. It is simply a different thing.

You can discover 100% of your cryptographic vulnerabilities and still have 100% of them exposed.

5.3 Knowledge progress versus protection progress

PQC programs generate two kinds of progress. Both are legitimate. Only one reduces risk.

The risk lies in reporting the left column as if it were the right one. A board that sees a completed inventory, a CBOM and a roadmap can reasonably believe the organization is safer. It is better informed. It is not yet safer.

Working on PQC and reducing PQC risk are not the same statement, and programs should not let them be read as one.

Harvest now, decrypt later: the cost of waiting

If discovery and protection were separated only by a reporting problem, the distinction would be a matter of good governance. Harvest-now, decrypt-later attacks turn it into a matter of exposure.

6.1 Capture does not need a quantum computer

In 2023, CISA, NSA and NIST warned that “cyber threat actors could be targeting data today that would still require protection in the future,” an operation they described as catch now, break later or harvest now, decrypt later ^[28]. NIST's final transition plan states the same risk: encrypted data remains at risk because of the harvest-now, decrypt-later threat ^[4].

Two consequences follow. First, exposure accumulates during discovery: if an organization spends one or two years only discovering and documenting, data protected by vulnerable mechanisms can keep being captured throughout that period. Second, modernizing later does not recall what was taken. Re-encrypting a file or upgrading a protocol tomorrow protects future captures; it does nothing for copies an adversary already holds.

Harvest now, decrypt later doesn't wait for your inventory to be completed.

6.2 Mosca's inequality

The argument does not depend on predicting the date of a cryptographically relevant quantum computer. It depends on three quantities that Michele Mosca formalized in 2015. Let x be the security shelf-life, how long keys and the information they protect must remain secure; y the migration time; and z the collapse time, until current public-key cryptography is broken. “If x + y > z, we have a serious problem today” ^[29]. NIST uses the same reasoning, which it calls Mosca's theorem, to explain the urgency of the transition ^[4].

Our interpretation follows directly. An organization does not control z. It controls y. Every month spent only discovering is a month added to y for exposures it already understands. The European roadmap applies the same logic when, among its criteria, it classifies a use case as high-risk if compromising confidentiality after 10 years or more would still cause significant damage ^[8].

6.3 Confidentiality and authenticity have different clocks

Precision matters here, because not every exposure runs on the same clock. Harvest-now, decrypt-later is a threat to confidentiality: key exchange, key wrapping and encrypted data. NIST states explicitly that signatures are not vulnerable to it, and that an authentication system remains secure as long as its algorithms and keys are secure at the time authentication takes place ^[4]. NIST nevertheless considers the move to post-quantum signatures urgent, because that transition is longer and more complex ^[4].

Authenticity exposure is therefore set by trust lifetime rather than data lifetime: the risk is that a key or a signed object is still relied on once forgery becomes possible. NIST's example is code signing for devices whose verification code cannot be updated, which should be designed to require quantum-resistant signatures if they may still be in use when such computers exist ^[4].

The table is our synthesis of the NIST and EU criteria cited above. Separating the two clocks makes prioritization sharper and avoids treating every quantum-vulnerable asset as equally urgent.

Discover and transform in parallel

This is the point at which the paper stops diagnosing the problem and proposes an alternative.

Don't wait to finish discovering before you start protecting.

7.1 The limits of a strict sequence

In our experience, the sequence most programs follow is discover, assess, plan, transform. Read strictly, it means transformation starts only when the enterprise inventory is complete. In a large organization that can take years, and every one of those years extends the exposure of assets that were already well understood in month three.

The guidance itself does not require a strict reading. The NCSC sets out its activities in three periods but warns that “although they are set out sequentially, in practice they are interrelated” ^[7]. NIST describes the transition as “beginning with cryptographic inventories, migration planning, and early deployments” of PQC-enabled products and services ^[4]. The European roadmap calls inventory “a first essential step” and groups it with the other first steps due by the end of 2026 ^[8]. None of them proposes the model below; it goes further than the guidance, and we present it as our interpretation.

7.2 Two engines

We propose running two engines at the same time:

• The discovery engine identifies, inventories, assesses and prioritizes exposure across the landscape. It never really finishes, because systems keep changing.
• The transformation engine takes exposures that are known and sufficiently characterized, intervenes on them, verifies the result and records the reduction in exposure.

The engines feed each other. Discovery hands transformation a growing queue of ready candidates. Transformation hands discovery back what it learns in execution: hidden dependencies, owners, test results, and assets that no scan found.

One practical consequence follows. The transformation engine needs something that executes, not only something that decides. Re-encrypting an archive or changing the algorithm behind an application requires an operational capability, with keys, policy and evidence, and not only a plan. Chapter 11 returns to this.

This is not a proposal to change assets blindly. It is a proposal to stop holding well-understood exposure hostage to the completion of an enterprise-wide inventory.

7.3 Which exposures go first

An exposure is ready for the transformation engine when it meets most of these conditions:

1. The exposure is characterized. The algorithm, the key, the mechanism and the data it protects are known.
2. The value of acting early is high. Long confidentiality lifetime, high capture risk or a long-lived trust anchor, as described in Chapter 6.
3. Dependencies are mapped. The systems that read, write or verify the asset are known, and none will break silently.
4. The change is testable and reversible. There is a way to validate the result and to roll back if needed.
5. There is an owner and a mechanism. Someone is accountable, and a tool exists to perform the change at the asset's scale.

Encrypted archives, backups and B2B exchanges often meet all five early. Their exposure is easy to describe, their confidentiality lifetime is long, and re-protecting them does not require changing the applications that produced them.

7.4 Verifying the mitigation

Every transformation should close with evidence that exposure was actually removed: the asset is now protected by an approved mechanism, the old wrapping or key is retired, its consumers still work, and the change is reflected back in the inventory. Without this step the transformation engine produces activity instead of protection, which is the same error this paper warns against, one level down.

Measuring protection, not discovery

What a program measures is what it will optimize. If the only indicators are coverage of the inventory, the program will become very good at inventory.

8.1 Two families of metrics

We recommend that PQC programs report two families of metrics, separately and side by side.

8.2 The indicator most programs miss

The most useful single indicator is the one most programs do not track: time from discovery to verified mitigation. It measures exactly the gap this paper is about. A program with a perfect inventory and a long discovery-to-mitigation time is well informed and still exposed.

For boards, a weighted measure of residual exposure says more than a count. A thousand short-lived session records and a thousand archives that must stay confidential for twenty years are not the same risk. Weighting residual exposure by data lifetime and trust lifetime, as Mosca's inequality suggests, aligns the metric with the actual risk.

Stop measuring what you've discovered. Start measuring what you've protected.

This does not mean that discovery should stop being measured. It means that the outcome of a PQC program is effective protection, not documented vulnerability.

Build for cryptographic agility

An organization about to invest years of effort in modernizing its cryptography should ask one more question: how do we avoid running the same project again the next time an algorithm, a threat or a standard changes?

9.1 PQC is not the destination

NIST defines crypto agility as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations” ^[9]. Our companion paper shows, with five recent cases, that the assessment of cryptographic mechanisms changes for reasons that include but are not limited to quantum computing ^[6]. PQC should therefore not be treated as the destination of the cryptographic architecture. The ability to keep evolving should be.

Make PQC transformation the beginning of cryptographic agility, not another one-time migration.

9.2 Four capabilities

9.3 The blast radius example

An application encrypts 500,000 files with AES-256-GCM. The algorithm is strong, and NIST does not expect to replace it in the PQC migration ^[4]. But if every file is encrypted under the same key and that key is compromised, all 500,000 are exposed.

An architecture that gives each file or group of files its own data key, wrapped by a key-encryption key, limits many compromise scenarios to a single file or group. The wrapping keys then become the critical point: their compromise widens the impact again, which is why they need the strongest protection, their own rotation policy and, in a PQC transition, a quantum-resistant wrapping mechanism.

The lesson is that a sound cryptographic architecture does not depend only on choosing resistant algorithms. It depends on how keys, assets and dependencies are managed over time, which is the subject of the CAPA framework ^[5].

Questions for the PQC steering committee

The following questions are designed to reveal, before a deadline does, whether a PQC program is producing protection or only knowledge:

1. Of the quantum-vulnerable assets we have already identified, how many have we actually re-protected?
2. What is our median time from discovery to verified mitigation, and which domains define its upper bound?
3. Which of our data must stay confidential for more than ten years, and is any of it still protected by quantum-vulnerable key exchange or key wrapping?
4. Which of our keys and signed objects will still be trusted in five years, and are any of them classical?
5. Which parts of our landscape will our vendors modernize, and which will not change unless we change them?
6. When we finish this migration, how many applications would we have to modify to make the next one?

Organizations that can answer these questions with evidence are running a transformation. Organizations that can only answer the first half of each question are running an inventory.

ANKASecure© in the landscape

A cryptographic control plane governs, operates and evolves an organization's cryptography as one service, while the root of trust stays in its HSM or KMS. The Cryptographic Control Plane is published as an open standard ^[26], described in ANKATech's companion whitepaper ^[5]; ANKASecure© is ANKATech's implementation of it. It is one participant in the ecosystem described in Chapter 4 and replaces none of the other categories: it governs and operates cryptography across them, and acts directly where only the organization can act.

11.1 Four capabilities

The root of trust stays in the HSM or KMS the organization chooses, and it can be more than one at the same time. Because the keys remain protected by that root of trust while operations can run in the control plane, adopting a new algorithm does not have to wait until every HSM or KMS in the organization supports it.

The control plane governs and operates cryptography across the ecosystem. It replaces none of it.

11.2 Where it fits, and where it does not

11.3 Re-protecting existing assets

Dedicated re-encryption and re-signing operations, including streaming operations for large data objects, allow information protected under an old mechanism to be moved to a new one without requiring the applications that created it to recreate the data. This is the transformation engine of Chapter 7 applied to the domain that vendor upgrades leave untouched.

11.4 Cryptography as a governed service for applications

Applications invoke stable cryptographic capabilities such as encrypt, decrypt, sign and verify against stable key identifiers. The mechanism behind each capability, including hybrid constructions and post-quantum mechanisms based on FIPS 203, 204 and 205, is governed by policy rather than embedded in application code. Every operation is recorded with its context, including the algorithm and key used, so that protection progress can be demonstrated rather than asserted.

11.5 Getting started

1. Exposure triage: from the organization's existing inventory, identify the exposures that meet the readiness criteria of Chapter 7.
2. Demonstration: ANKASecure© re-protecting a set of assets analogous to the organization's own, end to end, with evidence.
3. Scoped pilot: one high-value data set or one critical application flow transformed under policy, with keys anchored in the organization's chosen HSM or KMS.

Conclusion

Post-quantum cryptography is not a single technology upgrade. It requires coordinated transformation across networks, platforms, data and applications, supported by identity and key management layers that run through all of them. Vendors will deliver part of that transformation. Organizations will have to deliver the rest themselves, especially for data that is already encrypted and for the cryptography inside their own applications.

Discovery is essential for understanding cryptographic exposure, but discovery does not protect anything. With harvest-now, decrypt-later attacks, waiting has a cost: data captured today may remain vulnerable even after systems are modernized. Organizations should therefore move beyond discovery-driven programs toward coordinated execution, in which discovery, prioritization, transformation and validation progress in parallel and are measured by the exposure they remove. And because PQC will not be the last cryptographic change, the investment made now should leave behind lasting cryptographic agility.

The outcome of a PQC program is not a complete inventory. It is exposure that no longer exists.

References

1. [1] NIST. Module-Lattice-Based Key-Encapsulation Mechanism Standard. FIPS 203, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.203
2. [2] NIST. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.204
3. [3] NIST. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.205
4. [4] D. Moody, R. Perlner, A. Regenscheid, A. Robinson, D. Cooper. Transition to Post-Quantum Cryptography Standards. NIST IR 8547, October 2026. https\://doi.org/10.6028/NIST.IR.8547
5. [5] ANKATech Solutions INC. The Cryptographic Control Plane: Introducing CAPA, Crypto Agility Posture Architecture. Whitepaper V2, September 2026.
6. [6] ANKATech Solutions INC. Crypto agility beyond the quantum clock: why post-quantum migration is necessary, and why it is not enough. Whitepaper V1, October 2026.
7. [7] UK National Cyber Security Centre. Timelines for migration to post-quantum cryptography, March 20, 2025. https\://www.ncsc.gov.uk/guidance/pqc-migration-timelines
8. [8] NIS Cooperation Group, EU PQC Workstream. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, Part 1, Version 1.1, June 11, 2025 (published by the European Commission June 23, 2025). https\://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
9. [9] E. Barker, L. Chen, D. Cooper, D. Moody, A. Regenscheid, M. Souppaya, W. Newhouse, R. Housley, S. Turner, W. C. Barker, K. Kent. Considerations for Achieving Crypto Agility: Strategies and Practices. NIST CSWP 39-upd1, December 2025, updated June 29, 2026. https\://doi.org/10.6028/NIST.CSWP.39-upd1
10. [10] IBM. IBM Quantum Safe. Product page, accessed November 2026. https\://www.ibm.com/quantum/quantum-safe
11. [11] K. Patil. AppViewX PQC Assessment Tool – Kickstart Your PQC Readiness Journey with Complete Cryptographic Visibility. AppViewX blog, May 16, 2025. https\://www.appviewx.com/blogs/appviewx-avx-one-pqc-assessment-tool-kickstart-your-pqc-readiness-journey-with-complete-cryptographic-visibility/
12. [12] SandboxAQ. SandboxAQ Redefines Cybersecurity with Unified Cryptography Management. March 27, 2024. https\://sandboxaq.com/post/sandboxaq-redefines-cybersecurity-with-unified-cryptography-management
13. [13] IBM. IBM Quantum Safe (IBM Guardium Cryptography Manager). Product page, accessed November 2026. https\://www.ibm.com/products/guardium-quantum-safe
14. [14] SandboxAQ. AQtive Guard: Remediate. Product page, accessed November 2026. https\://www.sandboxaq.com/solutions/security/remediate
15. [15] S. Goldberg, A. Paul, D. Gauch. Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform. Cloudflare blog, February 23, 2026. https\://blog.cloudflare.com/post-quantum-sase
16. [16] F5. Integrating PQC. BIG-IP System: SSL Administration, version 21.1.0. Technical documentation, accessed November 2026. https\://techdocs.f5.com/en-us/bigip-21-1-0/big-ip-system-ssl-administration/integrating-pqc-on-the-client-side.html
17. [17] Palo Alto Networks. PAN-OS 12.1 IKE and Web Certificate Cipher Suites. Technical documentation, updated October 23, 2026. https\://docs.paloaltonetworks.com/compatibility-matrix/reference/supported-cipher-suites/cipher-suites-supported-in-pan-os-12-1/cipher-suites-supported-in-pan-os-12-1-ike-web-certs
18. [18] Amazon Web Services. AWS KMS adds support for post-quantum ML-DSA digital signatures. What's New, June 13, 2025. https\://aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures
19. [19] Oracle. JDK 24 Release Notes. March 18, 2025. https\://www.oracle.com/java/technologies/javase/24-relnote-issues.html
20. [20] B. Canavan. How to Become Quantum-Ready Today: Luna HSM v7.9 Delivers Real-World PQC, Validated by Thales PKI Technology Partners. Thales blog, July 29, 2025. https\://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
21. [21] Entrust. Entrust nShield HSMs Post-Quantum Cryptography Algorithms Achieve Validation from the NIST Cryptographic Algorithm Validation Program. Press release, September 10, 2025. https\://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
22. [22] Utimaco. Utimaco launches Quantum Protect solution and free PQC simulator. Press release, April 2, 2025. https\://utimaco.com/news/press-releases/utimaco-launches-quantum-protect-solution-and-free-pqc-simulator
23. [23] AppViewX. Private PKI Ready for AI and Quantum. Product page, accessed November 2026. https\://www.appviewx.com/products/pki/
24. [24] DigiCert. Post-quantum cryptography (PQC). Trust Lifecycle Manager documentation, June 26, 2026. https\://docs.digicert.com/en/trust-lifecycle-manager/post-quantum-cryptography-pqc.html
25. [25] S. Ahmad, Y. Jamal, A. Krivit. Automatic Key Exchange: faster, post-quantum secure origin handshakes for 45 billion daily connections (and counting). Cloudflare blog, September 8, 2026. https\://blog.cloudflare.com/automatic-key-exchange-for-origins/
26. [26] Cryptographic Control Plane. Open standard, CC BY 4.0. https\://cryptographiccontrolplane.org
27. [27] E. Boehm. The vision behind the Keyfactor Trust Control Plane. Keyfactor blog, May 7, 2026. https\://www.keyfactor.com/blog/the-vision-behind-the-keyfactor-trust-control-plane/
28. [28] CISA, NSA, NIST. Quantum-Readiness: Migration to Post-Quantum Cryptography. Factsheet, August 2023. https\://www.nccoe.nist.gov/sites/default/files/2023-08/quantum-readiness-fact-sheet.pdf
29. [29] M. Mosca. Cybersecurity in an era with quantum computers: will we be ready? IACR Cryptology ePrint Archive, Paper 2015/1075, November 2015. https\://eprint.iacr.org/2015/1075

ANKATech Solutions INC. ANKASecure© is a product of ANKATech Solutions INC. Vendor capabilities are described from each vendor's public documentation as cited and are not an exhaustive evaluation. This document is provided for information purposes and reflects the state of the cited sources as of November 2, 2026.