NIST’s PQC roadmap: work backward from two migration deadlines

01

A finalized route for migration

An algorithm standard still needs products and counterparties before its capabilities complete a business operation. Reading NIST’s final migration guidance raises a practical question: what will change, and in what order? Combining key establishment and signatures into one completion date can let an early capability conceal work that is not yet usable. Separating the two purposes makes acceleration fees and time spent waiting for counterparties easier to explain.

Covered federal systems already have a separate policy clock. Executive Order 14412, dated June 22, 2026, directed guidance for high value assets and high impact systems, excluding National Security Systems, to migrate key establishment by December 31, 2030, and digital signatures by December 31, 2031. Those two deadlines were not created on October 27. Nor does that provision impose the same dates on every private company around the world. [C3]

The practical task is to take one business operation and build two schedules around its two cryptographic purposes. A channel carrying transaction data may be ready for an upgrade while the counterparty is still preparing to accept signatures. Conversely, the ability to issue a certificate does not establish that the mechanism creating communication keys has changed. The worked example turns those differences into durations and start dates. It identifies the fields that a reader must fill from their own documents to move the comparison forward.

The article supplies a freely readable, static schedule, worked calculations and a worksheet. Readers supply their own configuration records, counterparties’ delivery dates and estimates of testing time. No device information or private key needs to be entered on this page. It performs no discovery, configuration changes or automated compliance assessment. Copy the example onto paper or into a spreadsheet and compare it with your own activities. Confirm the applicable scope and acceptance requirements with the responsible authority or contractual counterparty.

02

Two purposes within the same operation

Key establishment is the process through which communicating parties obtain shared secret keying material. NIST FIPS 203 specifies ML-KEM for that purpose; an established key can be used with symmetric cryptography to protect communications. ML-DSA in FIPS 204 instead concerns generating and verifying digital signatures, which support checks on modification and the signer’s identity. Even similarly named product features can serve different purposes. The relevant counterparties and tests depend on which purpose a feature actually serves. [C4][C6]

Consider a fictional manufacturer that sends design changes to a customer and distributes approved update files to factory equipment. The communication channel needs a way to establish keys with the intended recipient. Distribution of an update file cannot be completed unless the receiving device can verify the required signature. Even if the sender is ready on the same day for both activities, their completion dates can differ. A register with just one row for the entire business process can easily hide that difference.

Define each activity by its output and recipient before naming its product. On the communication branch, a test record showing successful key establishment under the agreed conditions becomes an input to the next activity. On the signature branch, the input identifies the devices, verifiers and file formats that were accepted. Buying both products from one vendor does not remove those handoffs. When teams agree on the deliverable passed between them, they can also identify where waiting time arises.

Separating the purposes does not remove dependencies on common infrastructure. If both branches return to one cryptographic library, procurement office or test team, they share a constraint. First separate the purposes, then reconnect the shared resources. That avoids treating one testing slot as if it were available twice merely because two budgets were approved independently. Aligning the allocation of costs with the people and facilities that can actually do the work connects the schedule with a business plan.

For the division of roles, Compare permission and cryptography roles.

03

Define the model before assigning durations

All durations below are fictional SG Group assumptions. They are not product lead times, a federal agency’s plan, or an actual company’s costs or implementation. The model uses elapsed months and does not calculate partial months. Each duration starts when that activity’s prerequisites have been met. Initially, separate staff and testing capacity are assumed to be available. A later case changes that assumption by giving the two branches a single shared testing team.

Preparations that can run in parallel wait for the slower completion. If six-month and nine-month preparations begin together and both are required, the next activity can begin after nine months, not fifteen. Activities that cannot begin until the previous test has finished must instead be added in sequence. Establishing which work is parallel and which is sequential prevents two common errors: adding every duration in a budget, or selecting only its single longest line.

Drawing parallel arrows does not make simultaneous execution possible. If two activities require the same person, additional staffing or an execution order is needed. An external partner offering only one testing window can impose the same constraint. Keep deliverable dependencies separate from competition for resources. A dependency prevents work from starting before its inputs exist; resource competition can require work to wait even when every input is already available.

The other boundary is the definition of completion. In this example, completion includes deployment on the designated business paths and the agreed acceptance. Shipment of a product, signature of a contract and availability of an algorithm are separate milestones. If testing reveals an unexpected issue, add the required rework and recalculate. The purpose is to explain which assumption has failed, rather than quietly change the meaning of the original completion date.

04

Key establishment: a nine-month prerequisite controls the path

For key establishment, assume six months to prepare the application library and nine months to prepare the gateway connecting to the counterparty. Both begin together. Once both are complete, integration takes four months, interoperability testing three months and staged deployment two months. Figure 3 measures months from the start. Its two overlapping preparations and three subsequent activities can be compared with the order of work in a reader’s own project.

The total is max(6, 9) + 4 + 3 + 2 = 18 months. Here, max selects the larger value. From the library’s completion at month six until month nine, the prerequisites for integration are incomplete. That interval need not be wasted: documentation or other preparation could be scheduled there if feasible. If integration can actually begin earlier, the project has a different dependency structure and should be redrawn accordingly.

Reducing the library preparation from six months to three leaves the total at eighteen if the gateway still takes nine. A three-month improvement in one quotation therefore need not advance business availability. If the library instead takes twelve months, it becomes the slower prerequisite and extends the total to twenty-one months. The value of acceleration and the loss from delay are not necessarily symmetric, even for the same activity. They depend on which branch currently holds up the next task.

A buyer considering an acceleration fee can ask which completion date the fee would change. An earlier library might create testing flexibility or serve another operation, even if this project still finishes at month eighteen. Booking it as a three-month advance in this deployment would count the wrong benefit. Match the promised deliverable to the activity that receives it. That makes it possible to test whether a report of on-time delivery also advances the business start date.

05

Signatures: connect the producer with the verifier

On the signature branch, assume twelve months to prepare the verifying devices and eight months for the certificate issuance and operational infrastructure. After both are ready, application changes take five months, acceptance testing with counterparties four months, and deployment across the designated device population six months. The final six months describe rollout across the device population. Device service life and the required confidentiality period are separate inputs.

The total is max(12, 8) + 5 + 4 + 6 = 27 months, nine longer than the key-establishment branch. That gap does not rank the cryptographic algorithms: the assumed handoffs and device populations differ. An early capability to generate signatures does not finish distribution if receiving devices or counterparties cannot accept them. Compare the sender’s product documentation with the recipient’s test evidence as the input and output of the same business activity.

Shortening the certificate infrastructure work from eight months to six leaves completion at month twenty-seven because the verifying devices still require twelve. If infrastructure preparation grows to fourteen months, the total becomes twenty-nine. The controlling branch can change during a project. Recalculate the next start date when assumptions change, rather than keep funding the activity identified as the bottleneck at the outset. This gives a more useful basis for considering an additional budget.

For long-lived devices, procurement must ask whether the component checking update files can itself be changed later. The final report highlights code-signing cases in which verification code is difficult to update after manufacture. If that constraint applies to the actual device population, ordering a software update does not complete the schedule. Replacement, another verification path or withdrawal from the operation must be evaluated against the supplier’s formal specifications and the actual equipment’s constraints. [C2]

For changes to long-lived equipment, Check controller settings, maintenance and support conditions.

06

Work backward from the two deadlines

To convert durations into dates, define the completion boundary. In this monthly model, completion by the end of 2030 means before January 1, 2031; completion by the end of 2031 means before January 1, 2032. Subtract the required whole months from those boundaries. Eighteen months for key establishment gives a no-buffer start boundary of July 1, 2029. Twenty-seven months for signatures gives October 1, 2029. Every activity must be completed before the relevant end boundary. Months are interval lengths between month-start boundaries; the right boundary is not an additional working day. Starting July 1, 2029, an eighteen-month allowance therefore runs through the end of December 2030.

Although the signature path takes nine months longer, its start boundary is three months later because its assumed deadline is twelve months later. This is not general advice to postpone signature work. If the actual signature path takes another six months, the ordering reverses. Sorting only by the earliest deadline, or only by the longest duration, fails to account for both inputs at once.

Adding a fictional three-month contingency to each path increases the planning allowance to twenty-one months for key establishment and thirty for signatures. The corresponding start boundaries move to April 1 and July 1, 2029. Three months is an explanatory assumption, not a NIST recommendation or a safety guarantee. Assigning contingency to approval, incident handling or retesting explains what could consume it more clearly than adding an arbitrary percentage to every activity.

For a private-sector project, first replace the dates with those in the actual contract or implementation plan. Supplying the federal government does not by itself establish the asset classification or applicable contract clause. Keep procurement requirements, product availability and customer acceptance as separate milestones, each with a document and owner. Where working days, holidays or change freezes matter, expand the monthly result into the actual calendar rather than treat it as an exact committed date.

07

One testing team creates a queue

Now increase only the key-establishment gateway preparation from nine months to thirteen. After four months of integration, that branch is ready for testing at month seventeen. The signature branch also reaches testing at month seventeen after twelve months of preparation and five of application changes. With separate teams, key establishment finishes in 17 + 3 + 2 = 22 months, while signatures finish in 17 + 4 + 6 = 27. Only the former completion date changes.

If one team works on only one branch at a time and signatures go first, signature testing occupies months seventeen through twenty-one. The three-month key-establishment test follows, then its two-month rollout starts at month twenty-four. Key establishment finishes at month twenty-six. Those additional four months reflect a wait for test capacity, not slower cryptographic processing. This is the difference between a diagram of dependencies and a schedule with actual resources assigned.

If key establishment goes first, its test runs from month seventeen to twenty, and rollout finishes at month twenty-two. Signature testing moves to months twenty through twenty-four, with six months of deployment taking completion to month thirty. The team still performs seven months of testing in either order, but the pair of completion dates changes. Departments cannot resolve the trade-off simply by each declaring their own project the highest priority. Both deadlines and the operational exposure while waiting must be considered.

A second testing team removes the queue in this example. More internal staff would not achieve that result if the counterparty still provides only one environment or approving authority. Two teams might compete for the same facility, or inconsistent methods could create retesting. An outsourcing estimate should therefore identify the waiting time removed, the six-month rollout that remains, and the work needed to maintain comparable quality. The price of acceleration can be assessed only after identifying which part of the schedule the spending changes.

08

Use separate evidence for TLS support and operational acceptance

The final report identifies January 2, 2030, as the federal deadline for supporting TLS 1.3. That is a different milestone from PQC migration for key establishment or signatures. The TLS 1.3 specification itself separates key exchange and authentication mechanisms. A statement that a product supports TLS 1.3 therefore does not establish that a connection uses a particular post-quantum mechanism or that its operational acceptance test with a counterparty has finished. [C2][C7]

At an acceptance gate, separate a list of supported mechanisms from a record of the mechanism actually negotiated. The first describes possible capabilities; the second describes the combination achieved in that test. A different peer or route can change the outcome even with the same product. Assume the example’s three-month test includes important exception paths as well as the usual peer. Reducing the test population to keep a date changes the scope of completion; put the remaining paths back into the schedule rather than book an equivalent acceleration.

For signatures, pair the test of generation with verification on the designated devices. Acceptance may also address rejection of files modified within the agreed test scope and handling of validity or revocation states. Responsible specialists must design the actual work in a safe test environment. The article’s comparison is not a procedure to run against production equipment. A completion record needs a deliverable that makes the tested population and conditions intelligible.

The NCCoE migration project includes work on discovering cryptographic use and work on interoperability. Mapping those roles onto the schedule clarifies what a new finding changes: discovery may expand the test population, while an interoperability problem may extend integration or counterparty preparation. A high discovery count is not deployment progress, and numerous successful tests do not eliminate unknown assets. Recording which document changes which input makes a progress report more useful. [C5]

09

Confidentiality has a different clock

Encrypted traffic may be collected for future decryption. Signatures involve a different clock: whether equipment still in service in the future can accept a legitimate update. Aligning the completion dates of the two migration branches does not measure these two exposure periods. The useful life of information and of equipment belongs in separate fields. [C1]

Suppose fictional design information created at the start of 2027 must remain confidential through the end of 2034. Finishing a channel migration in mid-2029 does not retroactively protect copies of earlier traffic that may already exist outside the organization. The schedule cannot establish whether such copies exist or when future decryption becomes possible. What it can compare is the period of new communications covered by the change against the required confidentiality period.

Assigning a particular year to the arrival of a capable quantum computer would not establish a safe last start date. Even with that arrival uncertain, the estimated eighteen-month migration and the required confidentiality period can be investigated. A shorter estimate is not automatically reassuring: it may reflect fewer covered assets rather than faster dependencies. Operational improvement and elimination of a threat should not be treated as the same measure.

Retiring equipment earlier can sometimes reduce the population needing replacement, but it also changes production capacity and investment needs. Changing information retention likewise depends on business requirements and applicable rules. This is not a reason to delete necessary original records. Match dates to their actual purpose across protection of sensitive information, equipment service and record retention, even when the same year appears in all three plans.

For questions that remain in stored information, Examine original records and transfer boundaries.

10

Does spending reach the activity that moves completion?

The international business transmission is not a single step from a published standard to higher revenue. Equipment and infrastructure suppliers have development and validation work; users have procurement and operational testing. Contracts, available versions and counterparties’ readiness sit between them. The guidance strengthens the case for examining that sequence. Without the population of covered systems, it cannot be converted into a global demand figure or a particular supplier’s profit.

For the buyer, separating ordinary contract renewal from additional migration work exposes the cost boundary. Access to a new version may already be included while replacement equipment and joint testing still require separate orders. Conversely, an added feature may include integration or operational support. Before ranking quotes by total price, map each to the example’s activities. This reveals duplicated work and handoffs for which no party has accepted responsibility.

Supplier comparisons also separate early shipment from early acceptance. A company preparing a component, supplying a verifier or coordinating interoperability can accelerate different branches. A supplier shortening the six-month activity in Figure 3 may have value, but it cannot be credited with the same completion advance as one shortening the nine-month branch. Anyone examining orders or development spending should also check the documented condition under which delivery or customer acceptance gives rise to payment.

A cost-saving alternative is to use shared services rather than have every company build independently. That can be valuable where the scope is common and provider and user responsibilities are agreed. Yet several customers waiting for one testing slot or release can create a shared bottleneck. An international business must also examine counterparties, contracts and maintenance windows across locations. Compare the benefits of sharing with the waiting time created by concentration in the same schedule.

11

SG Group View: the branch that changes completion

SG Group finds it more useful to read the final guidance through the dependencies that move business completion than through the amount spent on cryptographic products. The examples show that shortening an already shorter parallel branch does not advance completion, while delays in the controlling branch or testing queues change the total. Completion remains unchanged if the slower prerequisite does not move, and priorities change when another branch becomes controlling. Budget utilization or the number of supported features cannot explain that distinction.

A strong objection is that real teams may overlap preparation and integration. If part of integration can safely proceed in a test environment before the gateway is complete, Figure 3’s fully sequential assumption is too restrictive. Split that work from activities requiring the finished product and redraw the dependencies. Evidence of what can now start earlier, rather than a blanket reduction in the estimate, changes the eighteen-month result.

Evidence can also move the result in the other direction. A newly identified external identity service or maintenance connection may expand testing beyond the original four- or three-month allowance. Do not mechanically convert a discovery count into months of delay. Identify the new deliverable and when work on it can begin. Dozens of assets may fit one test, while a single specialized device may require a lengthy replacement.

A shared service can also change the assessment by taking responsibility for several dependencies. If the provider completes them and includes the user’s acceptance, the internal schedule may become shorter. The evidence must identify the assets and versions accepted, rather than rely on a short contract description. Less internal development and a shorter supplier queue are different outcomes. The schedule should remain traceable when responsibility for work changes hands.

12

Map one operation into eight fields

Begin an actual comparison by selecting one operation and its completion condition, rather than listing every device in the company at once. In Figure 7’s first field, record the sender, recipient, infrastructure and covered versions or device population. Then make separate rows for key establishment and signatures, each with a deliverable. A shared product name is not sufficient reason to merge departmental rows. Different purposes or accepting counterparties can require different endpoints.

For each dependency, record the preceding activity number and required deliverable. Durations alone cannot tell the reader whether six and nine months must be added or the larger selected. Map staff, facilities and the counterparty’s test windows, then check whether activities can overlap. If ownership is unresolved, leave the resource field unresolved instead of silently assuming unlimited staffing. That preserves the provisional nature of the calculation.

A deadline field needs the governing document and covered scope as well as the date. In the final field, pair evidence of completion with the condition requiring rework. Acceptance of an interoperability result for a designated version differs from requiring completed distribution across a device population. A quotation, counterparty notice and test report may carry different dates. Identify which of them actually releases the next activity.

Once inputs are available, calculate elapsed months first and map them to dates afterward. Include the maximum parallel preparation, the sum of sequential work and resource waiting time once each. Compare separate shorter and longer cases for an uncertain duration rather than compress it into a single committed value. A range is not evidence for a probability distribution or success rate. The useful result is identifying which input changes the start boundary.

13

Connect cutover failure with remaining work and continuity

The two- and six-month rollout durations mean different things depending on whether they cover only deployment or also reversal and retesting for affected groups. The baseline assumes acceptance without rework. A failure plan should identify which deliverable is no longer accepted and the activity to which work returns. Restarting the entire project and repeating one counterparty’s test require very different allowances.

Suppose an additional three-month interoperability test is required at the baseline key-establishment project’s month-eighteen completion gate. If no other work is reversed and dedicated testing capacity is immediately available, the total becomes twenty-one months, consuming the entire three-month contingency. If another project occupies the facility, adding only three months is insufficient. The revised estimate needs both the failed condition and the date on which rework can actually begin.

A continuity path needs agreed conditions and an approving authority before use. The ability to return to an old mechanism does not establish that confidentiality needs or applicable system requirements are satisfied. If no alternative is permitted, plan the operation to stop, the parties to notify and the evidence required for resumption. Neither choice follows automatically from a news example. Record responsibility for exceptions and the resulting exposure separately from acceleration of the completion date.

Preservation of originals and approval records should be considered alongside reversal. Keeping only the latest test result can obscure which assets failed and why the original completion date changed. Matching old and new configurations to acceptance records may justify a narrower retest. Recordkeeping is therefore an input to deciding whether the entire project must be repeated, rather than merely an administrative cost. Storage and access controls must reflect the actual sensitivity of those records.

For continuity and handoffs, Trace continuity arrangements and operational handoffs.

14

Ask which activity the next document changes

Choose the next document from the unresolved fields in the schedule. Technical specifications supply features and versions; supplier plans supply deliverables and dates; counterparty notices supply testing windows and acceptance conditions. Policy documents require matching scope, purpose and date. Publication of a final report does not establish that a particular product or operation has migrated. Where preparation is already underway, keep the existing plan and replace only the conditions changed by the new document.

NIST IR 8547 also anticipates updates to more detailed application-specific guidance. There is no need to predict their publication dates. When an applicable standard or product version changes, map it to the two schedules: a new capability may affect a preparation branch, a format change may affect integration and peer testing, and a scope change may affect deployment and acceptance populations. That mapping prevents a document update from being mistaken for progress across the entire plan. [C2]

Between global suppliers and users, a common standard name is not enough: the activities leading to acceptance must line up. A more answerable opening question than whether an entire company is ready is which deliverable will be provided for the designated operation, when, and to whom for acceptance. If delay emerges, examine the controlling branch and shared resources before reducing the discussion to a discount or an extra fee. Evidence of what moves the schedule gives procurement and development a common completion condition.

A reader who already knows the report’s conclusion can still insert their own durations into Figures 3 and 4, then replace Figure 5’s dates with those in the document governing their project. Together, they show how deadlines and long dependencies determine the start. Figure 7 identifies unresolved counterparties, resources and acceptance evidence that could change the answer. The result is a traceable input and the activity it changes under the reader’s own conditions, rather than a single badge declaring the system safe.