up:: The Human & Organizational Side MOC

The Lead-Time Sort

The lead-time sort is the sequencing rule for starting a post-quantum migration: start the long things first, ordered by how long they take to move, never by how urgent they feel, because a lead time only starts counting the day you start it. It exists because the 4 levers an executive normally reaches for, budget, headcount, mandate, and vendor pressure, each fail against this problem for a mechanical reason, and the one lever that remains is the calendar. The sort requires no finished migration plan. It produces 3 concrete moves an organization can make this quarter, each of which starts a clock that otherwise sits at zero: a written vendor question, a procurement requirement, and a conversation about the slowest-turning hardware in the estate.

The short version:

• Most of a post-quantum migration timeline is waiting rather than working: waiting on vendor roadmaps, procurement cycles, hardware refresh, certificate rebuilds, and validation queues. Money and people compress the working half and leave the waiting half untouched.
• A lead time starts counting the day you start it, so the order you start things in matters more than the effort you apply to them.
• Sort the long-lead items by how long they take to move and start from the top. Urgency ordering feels diligent and quietly starts the shortest clocks first.
• 3 moves fit inside this quarter with no finished plan: the written vendor question, a post-quantum requirement in the next procurement, and opening the conversation on the device class with the longest replacement cycle.
• A vendor’s committed support date is where your clock starts rather than where it ends, because procurement, testing, and rollout all still belong to you.

Anyone who has cooked a holiday dinner already runs this sort. The turkey goes in the oven hours before anyone touches the salad, because the order you start dishes in is set by cook time rather than by appetite, and the only mistake that ruins the meal is starting the longest dish late. A migration kitchen works the same way: the salad-length work (a config change, a pilot on one modern service) can start any month you like, and the turkey-length work (a vendor’s roadmap, a fleet of payment terminals) has to go in first or dinner moves to next year.

Why can’t you buy your way to a faster migration?

Because the levers that speed up an ordinary program each act on effort, and most of a post-quantum timeline is spent waiting rather than working. The historical base rate makes the shape visible: retiring a single algorithm has repeatedly taken a decade or more, with SHA-1 running roughly 25 years from the first published weakness in 2005 to the 2030 federal removal date, and none of that span was short of smart people, budget, or clear instructions. Lessons from Past Crypto Migrations walks the full history; The Receipt Method shows how to measure your own version of it.

Sources: NIST, “NIST Retires SHA-1 Cryptographic Algorithm” (December 15, 2022; phase-out by December 31, 2030), nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm, for the removal date; Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, Yarik Markov, “The first collision for full SHA-1,” 2017, §1, which records that “a team led again by Wang et al. presented in 2005 the very first theoretical collision attack on SHA-1 that is faster than brute-force,” shattered.io, for the start of the span.

Against that shape, each of the 4 ordinary levers comes back empty for its own mechanical reason:

1. Budget. Money buys engineers, and engineers don’t shorten a hardware refresh cycle. You can’t pay a payment terminal into being replaceable this year, and no invoice makes a vendor’s release date arrive sooner. Budget compresses the parts of the timeline your own people work on, which is the smaller share.
2. Headcount. More people help when the constraint is work, and most of the timeline is waiting: for a vendor to ship, for a refresh cycle to come around, for an algorithm to land inside a validated module. Twice the engineers finish the working half twice as fast and change nothing about the waiting half.
3. Executive mandate. A mandate travels exactly as far as your authority does, and 2 of the 3 things that set the timeline sit outside your building: your vendors’ roadmaps and the hardware already in the field. You can compel your own teams. A supplier’s release schedule and a device that shipped in 2024 hear the mandate and continue on their own clocks.
4. Vendor pressure. Lean on a supplier and the best outcome is a date, and that date is where your clock starts rather than where it ends, because you still have to procure the release, test it, and roll it through the fleet.

Lever	What it actually moves	Where it stops
Budget	The engineering you run yourself	The refresh cycles and release dates money can’t reach
Headcount	The working half of the timeline	The waiting half, which dominates
Executive mandate	Your own teams and priorities	The vendor roadmaps and fielded hardware outside your authority
Vendor pressure	A committed date onto paper	The procurement, testing, and rollout that begin at that date

The waiting is structural rather than a vendor failing. Before a regulated system can turn a post-quantum algorithm on at all, the algorithm has to arrive inside a FIPS 140-3 validated module, and that validation moves through NIST’s Cryptographic Module Validation Program on the government’s schedule rather than your project plan. Parts of this you’re fully ready to run, you often can’t start until someone outside your building finishes something you have no way to hurry. ACVP and PQC Validation covers the queue in depth.

Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov/projects/cryptographic-module-validation-program. ⚠️ The CMVP overview page is a program description. It carries the mandatory-validation rule (“if cryptography is required, then it must be validated”) and the procurement framing, and it does not describe CAVP, the FIPS 140-3 security areas, or any module’s validation status. Algorithm validation: CAVP project page. Sequencing and queue rules: the CMVP FIPS 140-3 Management Manual. A module’s status: the Validated Modules search, which needs a search date to be checkable.

What is the lead-time sort?

The lead-time sort is the rule you apply once the 4 levers have failed: inventory the items whose timelines you wait on rather than work on, order them by how long they take to move, and start them from the top, longest first. The ordering key is time-to-move rather than felt urgency, visibility, or deadline proximity, because urgency ordering reliably starts the shortest clocks first and leaves the decade clocks sitting at zero.

The rule rests on one property of lead times that sounds obvious and gets ignored in practice: a lead time only starts counting the day you start it. A vendor’s roadmap moves when you ask rather than when you deploy, and a supplier who hears the question from a large customer in 2026 answers it differently than one who hears it in 2029. A hardware refresh you influence at the procurement decision costs you nothing at that moment; the same hardware bought without the question asked is a decade you just committed to, because a fielded device runs the cryptography it shipped with until its refresh replaces it.

Three properties define the sort and separate it from a migration plan:

1. It orders starts, and only starts. The sort says which clocks to start first. Which systems migrate first once movement is possible is a different question, answered by ranking risk (see The Two-Lens Rule).
2. It requires no finished plan and no complete inventory. The long-lead item classes (vendor roadmaps, procurement cycles, hardware refresh, certificate hierarchies) are knowable before discovery finishes, and the 3 this-quarter moves need none of the plan’s later decisions.
3. Its output is dated artifacts rather than milestones. A sent letter, a clause in a live RFP, a refresh conversation on a calendar. Each one is a clock that has started and a record of when.

What are the long-lead items in a post-quantum migration?

The long-lead inventory is short and consistent across estates, which is what makes the sort runnable before discovery completes. These are the item classes whose clocks run on someone else’s calendar or on a multi-year cycle of your own:

Long-lead item	What drives the lead time	When the clock starts	This-quarter move
Vendor product support	The vendor’s roadmap and release schedule, then your own upgrade and rollout	The day your dated question lands in writing	Send the written vendor question (move 1)
Procurement and contract cycles	Renewal calendars and budget cycles measured in fiscal years; leverage exists only at signature and renewal	The next RFP or renewal that carries the requirement	Put a post-quantum requirement into the next procurement (move 2)
Hardware refresh	Replacement cycles that commonly run 5 to 10 years for appliances, terminals, HSMs, and industrial equipment; a fielded device runs the cryptography it shipped with until its refresh replaces it	The procurement decision for the next generation	Open the conversation on the longest-cycle device class (move 3)
Certificate-hierarchy rebuilds	Root and issuing CA rotation, trust-store propagation, then re-issuance app by app across the estate	The day the new hierarchy is stood up and the first re-issuance begins	Date the next planned root or issuing-CA rotation and fold post-quantum readiness into its planning; see Certificate Lifecycle Management for PQC
Validated-module availability	NIST’s CMVP queue; regulated deployment waits for the algorithm inside a validated module	Outside your building; you track this one rather than start it	Fold the validated-module date into the vendor question, per ACVP and PQC Validation

Two readings of the table matter: 4 of the 5 clocks are startable by you, this quarter, at close to zero cost, and every one of them sits at zero until someone acts. The items also cluster at the top of any time-to-move ordering precisely because they’re the ones a status report never shows moving, which is why urgency ordering buries them.

The hardware row deserves one expansion because it quietly sets the far edge of the whole program. Refresh cycles for network appliances, payment terminals, HSMs, and industrial controllers commonly run 5 to 10 years, so a device bought in a 2027 procurement on a 10-year cycle is still in the field in 2037, running whatever cryptography it shipped with. The procurement decision is the one moment that decade is cheap to influence, which is what makes move 3 a this-quarter item rather than a someday item. HSMs and payment hardware are the worked cases.

What are the three moves you can make this quarter?

Each move starts one of the longest clocks, needs no finished plan, and produces a dated artifact. Each also has a natural owner, because a move without an owner is a suggestion.

1. Send the written vendor question. The exact words: “On what date will your product support ML-KEM, the new post-quantum key-exchange standard, inside a validated module?” ML-KEM is named because it’s the finalized NIST key-establishment standard, and the validated-module condition is named because support outside a FIPS 140-3 validated module leaves regulated deployment waiting anyway. The migration owner drafts it; the vendor relationship manager sends it through the account team, in writing, because a written question starts the vendor’s clock and creates a dated record of when you asked. You’re buying nothing today. Vendor-Controlled Crypto Surfaces explains why this surface dominates most estates.

   Source: NIST, FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard” (August 2024), csrc.nist.gov/pubs/fips/203/final.

2. Put a post-quantum requirement into the next procurement, whatever it’s for. Procurement owns the vehicle; security supplies the requirement text. The minimum viable clause asks the product to either support ML-KEM and ML-DSA in a validated module or carry a dated, contractual roadmap for doing so. The full clause set (agility requirement, notification obligation, remedy) lives in PQC Procurement and RFP Language and slots in when procurement is ready for it; the this-quarter version is getting any post-quantum requirement into the next vehicle so the cycle stops passing empty. The federal government already operates this way at scale: OMB M-26-15 tells agencies they should build post-quantum integration into their requirements for the product categories CISA identifies, which is the same move written as national policy.

   Source: OMB, “Execution of the Migration to Post-Quantum Cryptography,” M-26-15 (June 24, 2026), M-26-15 PDF, §3.C.4, Vendor and Third-Party Software.

3. Open the conversation on the device class with the longest replacement cycle in the estate. HSMs, payment terminals, or industrial controllers, whichever fleet turns over slowest for you. The owner is whoever runs that estate: the infrastructure lead, the payments lead, the controls engineering manager. The opening words: “When is the next refresh for this fleet, and what would it take for the replacement generation to ship post-quantum ready?” This is a conversation rather than a project, and it’s the one that will still be running when everything else is finished, because the device bought at the next refresh is in the field for the entire following cycle.

The tri-agency Quantum-Readiness guidance recommends exactly this posture, telling organizations to engage vendors on their post-quantum roadmaps early and to plan contract changes so new products arrive with PQC built in, and it has since August 2023, which also makes the dated artifacts from these moves part of a defensibility record.

Source: CISA, NSA, and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography” (August 21, 2023), CSI_QUANTUM_READINESS_MIGRATION_TO_PQC.PDF, “Discuss Post-Quantum Roadmaps with Technology Vendors.”

What does the sort look like on a real estate?

Here’s the sort run on a generic mid-size estate, with the urgency ordering beside it, because the failure only becomes visible in the comparison. The urgency column is what a reasonable team produces when asked “what should we do first about post-quantum”: it ranks by visibility, audit pressure, and how finished each item can look in a quarterly review.

Item in the estate	Lead-time sort position	Urgency-sort position	What the urgency sort got wrong
Payment-terminal fleet, ~8-year refresh, next procurement 2027	1st, open the refresh conversation now	Last, “no deadline touches it yet”	The 2027 procurement decides cryptography that’s in the field into the mid-2030s, and the cheap moment to influence it is now
HSM fleet under the PKI root	2nd, fold into the vendor question and the refresh conversation	5th, “vendor will handle it”	Firmware, a fresh validation, and a refresh all queue behind a question nobody has sent
SaaS and appliance vendor roadmaps	3rd, send the written question this quarter	4th, “ask when we’re ready to buy”	Asking late means the answer arrives late, and the answer is the input every plan downstream waits on
Certificate hierarchy (root rotation pending)	4th, date the rotation and fold PQ readiness in	3rd, “certificates expire, so they feel active”	Active renewal is routine churn; the long lead is the hierarchy rebuild, which nobody dated
Public web TLS configuration	5th, schedule when upstream support lands	1st, “customer-facing, the auditor asks about it”	Shortest clock in the estate; it can start almost any quarter without changing the finish date
A hybrid pilot on one modern internal service	6th, run it when convenient	2nd, “shows momentum”	Real learning value, zero effect on any long clock; the roadmaps, refresh cycles, and validation queue stay exactly where they were

Read the two columns against each other and the pattern is exact inversion at the extremes: the urgency sort starts the 2 shortest clocks first and leaves the 2 longest at zero. A year of diligent urgency-ordered work produces a healthy-looking deck, a finished pilot, a clean public TLS config, and a finish date that has moved by nothing, because the finish date belongs to the terminals and the HSMs, and their clocks never started. The lead-time ordering costs almost nothing in that same year, a letter, a clause, 2 conversations, and it’s the only version of the year the 2037 estate thanks you for.

Common misconceptions

1. “Sorting by urgency is diligence.” Urgency ordering feels responsible because it attacks what’s visible and audit-adjacent, and it systematically starts the shortest clocks first. Time-to-move is the ordering that protects the finish date; urgency is the ordering that protects the status report.
2. “We’ll start once the plan is finished.” The 3 moves need no plan, and the waits they start are on the critical path of any plan you eventually write. A quarter spent planning before starting the waits is a quarter added to the finish date, which makes waiting for the plan the most expensive form of waiting, because it feels like progress.
3. “The vendor’s support date is the finish line.” A committed date is the input to your own procurement, testing, and fleet rollout, so it marks where your clock starts. Booking it as “handled” converts the vendor’s milestone into years of unscheduled work.
4. “A long timeline means we have time.” Against fixed deadlines like the 2030 and 2035 marks in NIST IR 8547 (still a draft, so hold its dates as proposed), a longer migration means an earlier required start. The length is the argument for starting clocks now rather than the reassurance that you can wait.
5. “Starting the long things first means migrating the long things first.” The sort orders when clocks start. Which systems migrate first once movement is possible is a risk question, answered by shelf life and blast radius under The Two-Lens Rule. The 2 orderings run together and answer different questions.
6. “The pilot proves we’ve started.” A pilot is a short-lead item standing in for the whole program in the reporting. It builds real skill while leaving vendor roadmaps, refresh cycles, and the validation queue exactly where they were, so the long clocks read zero regardless of how well it went.

Pro tips

1. Treat the procurement clause as the zero-cost lever it is. Every contract renewal is a free shot at the requirement: the vehicle already exists, the vendor already wants the signature, and the clause costs nothing to include. Renewals arrive on their own schedule whether or not you use them, so a renewal that passes without the requirement is leverage that expired unspent. Count the renewals on next year’s calendar and you’ve counted your free shots.
2. Get the vendor’s date in writing, then diff it at renewal. The drift between this year’s answer and last year’s is the roadmap’s honesty, measured. A date that holds is a plannable input; a date that slides every cycle is itself the finding. One distinction worth keeping sharp: this question asks for a future support date, while the vendor-claims checklist pins down the date of a validation that already happened, so the 2 are adjacent questions and never the same one.
3. When the answer is evasive, ask for the quarter and the version. “We’re committed to quantum readiness” carries no date. The follow-up is “which quarter, and in which product version?” An answer that survives that question is an input; an answer that dissolves under it is an inventory entry, and a vendor surface with no dated answer belongs near the top of the worry list, per Vendor-Controlled Crypto Surfaces.
4. Record every start date in the risk register. A lead time only counts from a documented start, and the starts you date now are the receipts a future review will pull. This is the forward-looking twin of The Receipt Method: that method reads your last migration’s paper to measure your speed, and this discipline writes the paper your next measurement will need.
5. Make program reviews ask “what did we start this quarter?” A review that only scores finishes structurally favors short-lead work, which reinstalls the urgency sort through the back door no matter what the plan says. Adding a started-clocks line to the review, with dates, is the cheapest governance change that keeps the sort accurate.

Where does the lead-time sort break?

The sort earns its keep exactly where lead times spread across orders of magnitude, so it breaks honestly where they compress:

1. Everything-short-lead estates. A cloud-native organization with no field hardware, annual SaaS contracts, and fully managed cryptography has lead times that all cluster around the contract year. Sorting by time-to-move stops separating anything, urgency ordering returns as the reasonable ordering, and sequencing hands off to the risk ranking: shelf life and blast radius under The Two-Lens Rule. One long clock usually survives even here, the providers’ own roadmaps, so the written question remains the move even when the rest of the sort has nothing to do.
2. Estates where every long clock has already started. In a mature program with the letters sent, the clause in force, and the refresh conversations dated, the sort has done its job and degrades into maintenance: diff the vendor dates at each renewal and keep the started clocks documented.
3. Budget allocation. The sort orders starts and says nothing about how much to spend where. Funding decisions need the risk ranking and the estate’s own numbers, which is work the sort deliberately leaves to the tools built for it.

How do you use the lead-time sort in the boardroom?

One level up, the sort converts into a single question a director or an executive sponsor can ask any migration program: “Which of our long-lead clocks have started, and on what date did each one start?” A percent-complete number is dominated by short-lead work, so a program can report healthy progress for years while every long clock reads zero. The started-clocks question reads the true state in about 5 lines: the vendor letters and their send dates, the procurement clause and which contracts carry it, the refresh conversations and their calendar entries, the certificate-rotation date, the validated-module dates being tracked.

The same artifacts work in the other direction, as the budget defense. The first post-quantum ask that reaches a board is stronger as “we’re starting clocks, and most of this quarter’s moves cost nothing” than as a large migration figure with no record behind it, because the zero-cost moves produce the dated evidence the larger asks later stand on. And the record protects the leader who built it: an organization holding dated vendor letters and procurement clauses from this year has an answer to the eventual “when did you act?” question, and the tri-agency guidance has defined acting early as the reasonable posture since 2023. When the board wants the whole story, Brief Your Board carries it.

Questions people ask

What’s the exact vendor question to send? “On what date will your product support ML-KEM, the new post-quantum key-exchange standard, inside a validated module?” Send it in writing through the account team, keep the dated copy, and log the answer, or the absence of one, against the renewal calendar.

Do we need a complete cryptographic inventory before running the sort? No. The long-lead item classes are knowable without one, and the 3 moves touch none of the inventory’s detail. Discovery and the CBOM run underneath while the clocks start, and the 2 workstreams meet when sequencing begins.

Who owns the lead-time sort? The migration owner runs the sort and holds the started-clocks record; the individual moves execute through procurement, the vendor relationship manager, and the estate owners. An organization without a named owner has a prior problem, covered in Cryptographic Ownership.

Isn’t it premature to put post-quantum requirements into procurement before we have a strategy? The requirement is a dated-roadmap clause and it forecloses nothing: it obligates the vendor to a schedule, and every path your eventual strategy could take needs that schedule as an input. The full clause language is in PQC Procurement and RFP Language.

Does budget really do nothing? Budget does real work on the working half: discovery, engineering, testing, and rollout all fund normally. It fails only against the waiting half, and the waiting half dominates the calendar. Fund the work, and start the waits, and know which half a given dollar is aimed at.

How does this relate to Mosca’s theorem? Mosca’s inequality tells you whether the total timeline overruns the deadline; the lead-time sort tells you which clocks to start first given that most of the timeline is waiting. The sort is what shortens the calendar side of the inequality, because starting a wait earlier ends it earlier.

What if a vendor never answers the question? The silence is a finding. A vendor-controlled surface with no dated roadmap answer is unplannable by definition, which moves it up the inventory’s priority list and onto the renewal-leverage agenda, where the question gets asked again with a signature attached.

How do we know a year later that the sort worked? By the receipts: dated vendor letters with logged answers, a requirement clause live in at least one contract, a refresh conversation on the calendar for the slowest fleet, a dated certificate-rotation plan, and a started-clocks line in the program review. Movement on the long clocks is the measure; the short-lead work was never in danger of being skipped.

---

Everything here is the map, given freely. When your team needs its own long-lead inventory mapped across vendors, contracts, and fielded hardware, with a start date on every clock and the record built to defend the timeline, that’s the work I do.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.