A field guide to PQC migration

Run post-quantum cryptography (PQC) migration as a continuous loop of discover, decide, fix and monitor. This guide turns that idea into tactics a security team can run this quarter.

It draws on three sources. The first is Mark Carney’s SANS Emerging Threats Summit talk, A Field Guide to PQC Migration: Tactics, Techniques, and Procedures (June 2025), which describes how Santander inventories and governs its cryptography. The second is Crypto-Agility in Practice, the CyberRisk Alliance CISO roundtable in St. Paul on November 5, 2026, which supplies the 2026 threat estimates, policy deadlines and CISO playbook.

The third is RogueAI’s research on ArcQubit, a RogueAI partner platform: its six-phase program, its QuCode and QuTrust tools, and the FIPS mapping behind them. Wherever a recommendation points to a RogueAI partner, the guide says so and lists a free alternative beside it.

It’s written for CISOs, security architects and the engineers who will do the work. Part 1 frames the risk. Parts 2 and 3 are the hands-on tactics. Part 4 covers priorities, a worked example and the roadmap, and Part 5 covers people, a checklist and sources.

The quantum threat is still years away, but in 2026 both the deadlines and the attack estimates moved closer. Three signals matter.

The risk is already live because of harvest now, decrypt later: data recorded today can be decrypted once the machines exist. Carney’s point is that the exact date matters less than the fact that the standards themselves are changing now, starting with FIPS.

Key exchange is the easier fix. OpenSSL 3.5 and later, OpenSSH 10 and the major browsers already negotiate hybrid post-quantum key exchange by default, and sites behind Cloudflare or Google already complete PQC handshakes. Signatures and PKI are harder and slower.

You’re exposed when the time your data must stay secret, plus the time it takes you to migrate, outlasts the arrival of a capable quantum computer. This is Mosca’s inequality. Try it with your own numbers.

Carney uses data-retention rules to make this concrete. Set each data class’s retention period against a 2030 Q-Day and the urgency sorts itself.

Turn this into three questions for the CISO:

1. Which of our data must stay confidential for 7 to 10 years or more?
2. Where does that data cross networks someone could record?
3. What protects it today: RSA, ECC or Diffie-Hellman?

Run migration as a repeating loop, so the inventory keeps paying off after the first pass. Carney adapts the military OODA loop (observe, orient, decide, act) and adds a monitoring stage that feeds the next round of discovery.

Start where a critical data flow is exposed, put lower-risk flows such as development pipelines on the roadmap for later, and let monitoring tell you what changed.

The loop runs inside a larger program. ArcQubit adapts six phases from the G7 Cyber Expert Group’s PQC roadmap for the financial sector (January 2026), a public framework that carries weight with boards and regulators in any industry.

The two frames cover each other’s gaps. The phases add executive sponsorship and the migration work itself; the four questions add ownership of each individual fix, which phase 1 doesn’t. Your migration finishes when your vendors finish, so “who owns it?” often means a supplier.

Most organizations don’t know what cryptography they run, because they never treated it as an asset that changes. Discovery works on two fronts, code and traffic, and starts with tools you already own.

Feed both streams into a CBOM. Each discovery pass makes the next one faster: the flywheel Carney describes.

Put your cryptographic standard in a Git repository, so every rule has an owner, a reason and a history. Santander keeps its standard in GitHub in three layers.

The payoff is an audit trail. For any line, anyone can see who wrote it, which pull request added it, who approved it and which issue it solved. Governance, risk and compliance (GRC) teams can run git blame instead of chasing emails, and an algorithm change becomes a reviewed pull request.

The same discipline pays off beyond quantum. Cataloged, agile cryptography means certificates stop expiring unnoticed, PCI DSS and EU DORA cryptography inventories get easier, and the next broken algorithm becomes a configuration change rather than a re-architecture.

There are three paths to discovery. Whichever you pick, start with your most important systems rather than a full inventory.

PQCA also maintains Open Quantum Safe (liboqs) and the PQ Code Package, libraries for teams building PQC support into their own software.

Fix long-lived confidential data first, then roots of trust, then critical availability systems. Map each finding to business impact so crypto fixes line up with what the business cares about.

1. Long-lived confidential data and internet-facing traffic. It’s the easiest to harvest. Tunnel it through PQ-encrypted infrastructure even before every system is inventoried.
2. Roots of trust, code signing and PKI. These have the longest dependency chains, so start now: find long-lived keys and root certificates, and automate certificate provisioning.
3. Critical availability systems. Schedule them into planned refresh cycles.

Don’t run quantum as a separate program. Attach it to work that’s already funded: certificate lifecycle automation, vendor risk reviews, procurement standards and technology refresh.

Procurement is the biggest lever, because most PQC progress will come from vendors. CISA’s product categories list sorts what you can demand today:

Ask for PQC support by default, at no extra cost, with a roadmap. Define “done” carefully: a system that supports PQC but still accepts classical-only connections can be downgraded by an attacker. For key establishment, NIST recommends ML-KEM-768 by default and allows hybrid classical plus PQ implementations.

Rank each finding on two things: exposure, meaning the damage if its cryptography falls, and how hard the system is to change. Data that must stay secret for 15 years carries more exposure than a session token that expires in hours.

ArcQubit’s QuCode scores findings this way, and its Quantum Exposure Report names the software, algorithm, location, score and whether your team or a supplier must fix it. QuTrust also flags which exposures are driven by a regulatory deadline rather than technical severity. ArcQubit doesn’t publish how the score is weighted.

Only public-key cryptography needs replacing; AES stays. FIPS 203, 204 and 205 say what to use, and FIPS 140-3 says whether a product implements it correctly.

Shor’s algorithm breaks RSA, ECC and Diffie-Hellman outright. Grover’s algorithm only speeds up brute-force key search, and NIST expects it to give little or no practical advantage against AES. See PQC standards at a glance for all four FIPS standards side by side.

Illustrative This example follows one ArcQubit exposure report for a typical customer-facing application. The scan returned 53 findings after triage, 30 of them quantum-vulnerable. The report answers “where is it?”; schedules, owners and dates are planned separately.

Items that only looked like exposure were reviewed and removed first; “What triage changes” below explains them.

Grouping the 30 quantum-vulnerable findings by surface shows where to start. Key exchange and the backup key can move now; certificates depend on your CA and vendors.

The backup key matters most. Backups hold long-lived data, so they’re the clearest harvest-now, decrypt-later target in the estate. The deadlines are EO 14412’s for the most sensitive federal systems; for everyone else, they’re the benchmark auditors and customers will use.

A scanner finds strings; triage decides which ones matter. These common items look like cryptographic exposure but need manual review before they count.

Triage also reorders what’s real:

• Escalate real secrets. Raw reports often rate all classical findings low. A committed private key and a cloud access key are the most urgent items in this example, ahead of any quantum work.
• Escalate weak randomness that guards secrets. Python random generating session tokens is a real flaw; switch to the secrets module.
• Set AES-128 aside. Four of the 16 Security findings are AES-128, which NIST still allows. Flag them only if your standard requires AES-256, as CNSA 2.0 does for national security systems.
• Rank inside Migrate. Raw reports mark every Migrate finding high. Rank them by exposure and ease of change, as in the grid above, which puts the backup key first.
• Assign real owners. Findings default to the application team. Certificates belong to whoever runs your CA, JWT signing to your identity provider, and some suites to vendors.
• Confirm the Investigate pile. Settle the 10 unconfirmed findings before committing effort.

The 53 findings sort into four waves, each with an owner and a test that proves it’s done.

ArcQubit’s scan shows where your cryptography is; RogueAI turns that into a plan your teams can act on and an auditor can check. A typical engagement delivers:

The raw report answers one of the four questions. With triage, it answers all four.

Don’t panic, and don’t wait: a team starting from near zero can have post-quantum TLS on its external traffic within two years.

Good 12-month milestones to commit to: post-quantum TLS on all internet-facing traffic, PQC clauses in every new contract, or a CBOM for the top 10 crown-jewel applications.

Tools find the cryptography; people get it changed. Carney’s closing point is that migration succeeds only with champions in the right places, so the right tool reaches the right team at the right time.

• Name one accountable owner for the PQC program and brief the board.
• Recruit champions in engineering, infrastructure, GRC and procurement. Each one carries the work into budgets and refresh cycles their team already has.
• Give GRC a stake. The Git-based standard gives them traceability they value, which makes them allies rather than gatekeepers.
• Share the tooling. The CodeQL queries and cryptomon are open source; contributing back builds credibility and internal momentum.

Expect most teams to be early. An IBM and Cloud Security Alliance survey of 750 executives found an average readiness score of 25 out of 100.