Post-Quantum Roadmap by October: Where to Start, and the Questions to Ask First

The post-quantum migration plan is due in October, and if you have not started, you are in good company. Many have not. The mandate is public: agencies are executing their migration under OMB M-26-15, with prioritized plans due to OMB in October 2026, and CNSA 2.0 sets the National Security Systems dates the supply chain inherits. The first move is to find out what cryptography you already run, before any algorithm choice. That inventory is the technical starting point; the migration also turns on who owns it and the people who carry it, which is where a plan really begins.

At a recent lunch-and-learn on the October deadline, these were the questions that came up, and they are the ones that decide where you start.

Start with an inventory, before an algorithm

You start with an inventory, before you touch an algorithm. The October plan is asking for exactly this first step, and if you have not built one yet, that is the normal place to begin this work.

The inventory is the foundation for a cryptographic bill of materials, which is the picture of the cryptography you run and the cryptography you inherit from others. You cannot prioritize or sequence what you cannot see, so the plan starts here. From there the work runs in three passes: discovery and prioritization, the public-facing edge, and coordination with the third parties who run cryptography on your behalf.

One thing that takes the pressure off: even the federal template is still settling. Guidance gives NIST and CISA until around March 2027 to publish the minimum elements of a cryptographic bill of materials, so the plan is due before the taxonomy is final. Start now with what you can see, and refine as the standard firms up.

What your scanners reach, and what they miss

They find part of it, and it helps to know which part. The vulnerability scanners already in your environment have some software-scanning reach, and your public-facing systems can be checked for the cryptography they negotiate. That coverage is worth having, and a fair place to begin.

What those tools tend to miss is the hardware. Encryption appliances, the key-management modules, routers, and switches often hold cryptography that a software scan never sees. For those you read the technical specifications, look at the cipher suites the devices negotiate, and use tooling built to collect that detail. The split is worth stating plainly:

Hardware you buy now should assume post-quantum

Yes, put post-quantum readiness into the market research now. One team was doing procurement for a hardware refresh in the next fiscal year and asked whether quantum readiness belonged in it yet. It does: fold post-quantum considerations into all planned procurements, because the alternative is buying gear today that you have to replace again to meet the same mandate.

Hardware is where a small agency feels this most, since you cannot swap everything at once. The encryption appliances, the key-management modules, and the network gear that carry cryptography will need assessment, and some will need replacement. The practical move is to identify end-of-life devices first, so what you buy next is forward-looking and can negotiate modern cipher suites, and so the refreshes you have to stage line up against real dates rather than a scramble.

When a vendor cannot migrate in time

A gap you cannot close yet belongs in the roadmap as a finding, and the plan keeps moving around it. A team running workloads on a major cloud platform raised that some providers may not support post-quantum algorithms until 2030. That is a real constraint, and the answer is to document it in the roadmap as a known limitation, with the date the provider gave you, so your plan reflects the true state of your estate.

Two things follow from that. First, hold the provider accountable through the contract: define timelines, name the algorithms you expect, and if a provider will not move when a solution exists, that becomes a documented finding. Second, keep the framing accurate. You are aiming for post-quantum resistance and crypto-agility, the ability to change again as modules and validated toolchains catch up. There is no single moment where you are finished and safe, and a roadmap that records where you cannot yet negotiate post-quantum algorithms is doing exactly what it should.

Inherited cryptography is still yours to account for

For the mandate, the inherited cryptography is still yours to account for. A team asked whether a cryptographic bill of materials needs to cover cloud-hosted systems and the firewalls and switches a vendor provides. It does. All components, including cloud services, are expected to meet the mandate as part of the agency's compliance package, so the cryptography you inherit belongs in your inventory alongside the cryptography you run yourself.

In practice that means requesting post-quantum roadmaps from the providers who run those systems, and recording what they tell you. Where they support it, you note it. Where they do not, it joins the list of documented gaps with a date attached. The point is that nothing quietly falls outside the picture because someone else operates it.

The supplier dimension has a maturity model

Your roadmap can only move as fast as the products underneath it. You can inventory your cryptography, fund the migration, and set a date, and you still depend on vendors to update the products that run your work. Supplier portals and cloud services use cryptography you do not control, software platforms carry embedded libraries and protocols, and hardware and firmware can stay deployed for years. A roadmap is credible only when the products it leans on can support it, so the supplier boundary is where a plan is most likely to stall.

The usual way to check a supplier is a custom questionnaire, which costs more and reveals less. The language varies, so answers are hard to compare. The scope is vague, so a company-level claim may not cover the exact product you are buying. The evidence is inconsistent, so confidence rides on the reviewer. The PKI Consortium's Post-Quantum Cryptography Maturity Model (PQCMM) replaces that with one free, open scale: product-specific, down to the version and deployment model; based on evidence rather than marketing language; and algorithm-neutral, so it stays useful as the standards move.

The model runs on six cumulative levels, from 0 to 5. Level 0 is a baseline worth having on its own: even if every supplier sits there, you now know where you stand and where to start. A supplier climbs as post-quantum becomes a recognized requirement, a named team takes ownership of the migration, a dated roadmap appears, and finally as evidence backs a shipped, verifiable capability. You set the level you require by how much you depend on the supplier.

From there the model becomes an operating loop across the supplier lifecycle: set the required level by risk, evaluate the supplier's report against a few gates (the right product and version, the level achieved, the assurance method, and whether the report can be verified), write the commitment into the contract with milestones and reassessment triggers, and monitor it so any in-scope supplier keeps a current record. Start with a small pilot of a few representative vendors, then make it the question you ask by default.

The fastest way to put a first data point on the board is to scan your public-facing edge. Enter a public hostname below to see the key exchange algorithm and certificate it negotiates today, and the next migration step. It runs right here, and it only needs a public hostname.

What the free scan covers, and where it stops

There is no catch, and the scoping call it mentions is optional. A question that comes up about the results is what the "scoping call" is for, and whether it is required. It is not. The scan stands on its own, and you are welcome to take the output and use it in your inventory without ever talking to us.

The call is there for the teams who want more than a data point: a larger consulting or engineering engagement to build the inventory across the private estate, sequence the roadmap, and do the cryptographic work. It is an option, offered plainly, for when the scope runs past what a free edge scan can give you.

You do not have to carry it alone

The through-line across every question was the same: this is bounded, ordered work, and no team has to invent it from scratch. Take the inventory, prioritize by how long the data has to stay secret and how far a failure would spread, put key establishment first, and document the gaps you cannot close yet. Some of what you run, including FIPS-validated systems, cannot negotiate the new algorithms yet, and that trade-off gets written into the roadmap with a date attached. That is a roadmap you can hand to a program office and defend.

The free scan shows your public edge, which is the fastest first data point. Your private estate, the hardware modules, and the cryptography you inherit are where the bulk of the inventory work sits, and where a partner earns their place. FEDLIN holds its own infrastructure to the same bar, with a written post-quantum standard, an inventory of the cryptography we operate, and a logged trade-off where a validated platform and the newest post-quantum key exchange could not both hold, made the way I would want a client's decision made and recorded.

If you need a partner to own the roadmap end to end, that is the work we do, inside your own boundary and alongside your people, whether you are an agency taking it on directly or a contractor carrying the requirement into a teaming arrangement.

Common questions

Sources: OMB M-26-15 (federal PQC migration execution); CNSA 2.0 (National Security Systems timeline); NIST FIPS 203 / 204 / 205; PKI Consortium PQC Maturity Model (PQCMM); and Addie LaMarr, The Post-Quantum Field Guide.