This final post on Post-Quantum Cryptography (PQC) builds on our first two blog posts where we addressed Is Post-Quantum Cryptography for SLED Finally Coming? and NIST Post-Quantum Cryptography Standards Explained. This blog digs a little deeper into the tactical recommendations and addresses what “being ready” really means. We also address which deadlines are real, where to start first, how to be crypto agile, and how to jump start your crypto inventory.

Q-Day Timing Remains Uncertain, But Federal Mandates Are Not

For most leaders, PQC lives in the emerging but unknown category in security roadmaps. That changed in 2026. The US federal government’s original 2035 target hasn’t moved, but more immediate dates have been mandated. These new dates are for federal and contractor systems, however, non-federal PQC-savvy organizations are smart to follow their lead. Under current federal direction in Executive Order 14412 (June 2026), High Value Assets and High Impact Systems must transition to PQC for key establishment by December 31, 2030, and PQC digital signatures for high-priority systems by December 31, 2031. Organizations that support federal systems or handle federal Controlled Unclassified Information (CUI) data should expect these requirements to increasingly influence procurement, legal, and security expectations.

If your organization touches federal systems or federal CUI data in any way, the Executive Order directs the Federal Acquisition Regulatory Council to require contractor compliance with NIST’s PQC standards. That means PQC readiness is quietly becoming a procurement requirement, not just a security best practice.

NIST has also published IR 8547 (migration strategy and deprecation timeline) and CSWP 39 (cryptographic agility practices). Together, these are the two “gold standard” documents every organization can leverage to start their PQC journey.

Roadmap Priorities – Start with Key Agreements First

The overwhelming consensus treats key establishment and digital signatures as separate tracks, and your roadmap should too. They move at very different speeds for a specific reason. The current industry priority is moving to post-quantum key agreement. This is the highest value initiative to counter Harvest Now, Decrypt Later (HNDL) exposure, because it’s a straightforward software update on both endpoints using a hybrid model (classical + PQC together) that doesn’t touch your certificate infrastructure. Your classical existing RSA or ECDSA digital certificates can stay exactly as they are, while only the underlying key exchange changes. This relatively easy lift is why internet-facing TLS migration is well underway at major cloud and CDN providers. The good news is that industry adoption is accelerating across platforms, so some of your vendors and systems may already be PQC-compliant.

Here’s a priority list to start migrating your key agreements:

• Internet-facing TLS (customer portals, APIs, load balancers)
• VPN and SD-WAN tunnels – especially site-to-site and remote access
• Cloud workloads and service-to-service (east-west) API traffic
• Zero Trust and identity infrastructure (IdPs, federation service connections)
• Any long-retention encrypted data in scope for HNDL risk

Digital signature migration is the harder, slower track, because it requires touching certificate authorities, enterprise PKI, device certificates, code signing, and authentication workflows. This multi-party tangled web is expensive and risky to replace quickly. Complicating things further, Anthropic disclosed in July 2026 that its super hacker Claude Mythos Preview model uncovered a previously unknown mathematical weakness in HAWK, a lattice-based signature candidate under NIST review. The finding doesn’t affect production systems or the already-finalized ML-KEM/ML-DSA standards, but it’s a preview of how AI-assisted cryptoanalysis may accelerate scrutiny of PQC signature algorithm candidates — including ones not yet finalized.

The complicated signature landscape and rapid advancement of AI will surely continue to pose challenges. For these reasons, budget and plan for PQC digital signature migration to be a multi-year program.

Aim For Crypto Agility

Our second blog recommended enforcing crypto-agility for deployment flexibility while the emerging ecosystem tackles performance. Early testing indicates that the new NIST PQC standards perform comparably to today’s cryptography, but their larger key, signature, and ciphertext sizes may impact bandwidth-constrained environments and require architectural planning before broad deployment.

Therefore, most organizations will keep their PQC disabled but ready to be deployed when these challenges are solved. This approach works if your organization can swap cryptographic algorithms without a prolonged rebuild once it’s time to enable PQC.

Crypto-agility is now formally defined by NIST in CSWP 39 as the ability to replace cryptographic algorithms across protocols, applications, and infrastructure without disrupting operations. Practically, that means:

• Abstracting cryptographic logic out of application code and into centralized key management or API gateways.
• Standardizing vendor platforms and libraries that support algorithm negotiation rather than hardcoding.
• Treating PQC migration as the impetus to finally retire legacy crypto implementations.

Techniques for Establishing Your Cryptographic Inventory

The cryptographic inventory is a paramount initial step. The end goal is commonly referred to as your Cryptographic Bill of Materials (CBOM). Below are best practices for systematically mining your systems for where public-key cryptography typically hides. For detailed instructions, see the NIST cryptographic discovery references below.

1. Network-Based Discovery (TLS/SSL)

This active scanning technique uses Nmap and is free, scriptable, and works at scale. It finds live, in-use cryptography of known IPs. Output shows protocol version, cipher suite, and whether a connection offers a weak/vulnerable cipher.

2. Certificate and PKI Discovery

• Internal CA hierarchy: pull the full chain and document every intermediate and root cert, their algorithms, and key usage
• Public-facing certs: query Certificate Transparency logs for every domain you own. This surfaces certs issued by shadow IT or forgotten subdomains that never made it into your CMDB.
• Endpoint/server cert stores: for example, the cert_inventory.txt in Windows.
• Code-signing and root trust stores: compare your trusted root store against vendor root programs (e.g., Microsoft, Apple, Mozilla, and the Chrome Root Program) and flag any RSA/ECDSA root certificates that have many years left before expiration.

3. VPN / IPsec Tunnels

Pull configurations by vendor and capture the following:

• IKE version – IKEv1 is end-of-life from a security standpoint regardless of PQC. Flag any tunnel still on v1 for immediate remediation.
• Diffie-Hellman group number – this is the critical PQC-relevant field.
• PRF (Pseudorandom Function) and integrity algorithms – these govern key derivation and MAC generation for the session. Flag any config still using SHA-1 hash function and retire immediately. Acceptable replacements are SHA-256, SHA-384, or SHA-512. Then, separately, verify the underlying encryption algorithm (AES-256 or AES-256-GCM preferred).

4. Code Signing

• Inventory every Authenticode, Apple Developer ID, and Java/Android signing certificate in use across build pipelines
• Check whether signing keys live in HSMs (AWS CloudHSM, Azure Dedicated HSM, Thales)

5. Source Code & Application-Level Cryptography

Work with your development team to discover hardcoded or library-level cryptographic calls inside applications. Decouple this logic as noted above.

Closing Thoughts

NIST offers some very practical advice: don’t let inventory become the project. Building a full CBOM is valuable, but it can easily turn into an endless exercise. An agile approach can reap big rewards. When you find an easy win, execute it immediately rather than waiting for a complete inventory. This effort will take a few years, but momentum compounds and those small victories will show progress to an auditor or your board.

Here is a practical starting sequence:

• Govern it: name an executive owner and a cross-functional steering group now.
• Discover it: apply NIST’s discovery guidance using the techniques noted above.
• Be crypto-agile: centralize key management, so the next algorithm swap is a configuration change, not a rebuild.
• Pilot hybrid key exchange: low-risk, high-value, and the single best mitigation against SNDL exposure available today.
• Sequence signature migration: plan it as a multi-year PKI program and expect AI and ecosystem disruptions.

References

• Source: Quantum Readiness: Cryptographic Discovery
• Source: Securing the Nation Against Advanced Cryptographic Attacks – The White House
• Source: Discovering cryptographic weaknesses with Claude \ Anthropic
• Source: Post-Quantum Cryptography | CSRC
• Source:. Execution of the Migration to Post-Quantum Cryptography
• Source: IR 8547, Transition to Post-Quantum Cryptography Standards | CSRC
• Source: Considerations for Achieving Crypto Agility: Strategies and Practices | NIST

About the author

Adam is an Executive Strategic Security Advisor at nuHarbor, helping clients defend their castles. He has been on the front lines for over 20 years in advisory and industry roles at Deloitte, Delta Air Lines, and most recently in CISO roles for financial services and private equity firms. Adam serves nature conservancy non-profits in Western North and South Carolina and is a volunteer mountain bike trail builder for communities near Pisgah National Forest.