How to Estimate NIST PQC Migration Costs in 2026: Which Work Items to Count First

Do not budget NIST PQC migration from a generic industry price: build the estimate from your cryptographic inventory, dependency complexity, testing scope, supplier commitments, and staged deployment work. First define what the budget covers, then show confirmed work separately from assumptions and unresolved items.

This guide is for security leaders preparing a migration budget, project managers estimating schedule and staffing, and engineering leads identifying system changes and validation work. If the work is outside those roles, the sections on inventory, supplier dependencies, and testing can still help locate the right owners.

Budgeting rule: Estimate work your teams can identify; mark the rest as uncertainty instead of presenting it as a precise quote.

Set the estimate boundary before assigning effort

A budget is only useful if readers know what it includes. Decide whether the request covers migration planning, a pilot, production changes, or continuing operations. These are distinct scopes, and combining them without labels can make a small discovery exercise look like a full deployment—or make a rollout appear cheaper by leaving operational work out.

Use a cost model that records, for each work package:

• Activity and deliverable: for example, a system inventory, code change, interoperability result, or approved operating procedure.
• Responsible party: the internal team, supplier, or shared owner expected to deliver it.
• Estimate basis: an internal work estimate, historical time record, supplier statement, or valid quote.
• Assumptions: the systems, environments, interfaces, and release process included.
• Uncertainty and next action: what remains unverified, who will confirm it, and what evidence is needed.

Do not treat NIST publications as pricing benchmarks. NIST has published three finalized post-quantum cryptography standards: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA, as described in its announcement of the approved standards. Those standards establish technical specifications; they do not establish how many engineering days a particular organization needs or what a supplier will charge.

The NCCoE migration project provides migration and interoperability material that can inform planning. Treat it as input to the work definition, not as a substitute for your system inventory or internal estimate.

Price discovery and risk ranking from the asset inventory

Cryptographic asset discovery sets the denominator for the rest of the estimate. The number of systems alone is not enough: a well-documented service with a clear owner may take less investigation than a poorly documented, business-critical application with multiple interfaces and inherited dependencies.

For each candidate system, establish what is known about:

• The cryptographic functions and protocols in use, including where keys, certificates, and algorithm choices are configured.
• The application, library, appliance, or managed service that implements those functions.
• The system owner and the people authorized to approve a change.
• The environments in which the system runs, plus any external integrations that must keep working.
• The business impact of delaying or failing the change, and the evidence supporting that assessment.

Count the work of finding assets, checking dependency records, interviewing responsible teams, and resolving ownership. If discovery uses automated scanning, include the time to validate results and investigate blind spots; a scan output is not automatically a complete inventory. If the organization already maintains reliable dependency records, document which records were checked and exclude only work that is demonstrably unnecessary.

Risk ranking should inform order and depth, not become a disguised price multiplier. A system that protects long-lived sensitive information, supports a critical service, or has dependencies outside the organization's control may merit earlier investigation. Record the reason for that priority and the source of the judgment. Do not assign an unsupported percentage increase simply because a system has been labelled “high risk.”

A useful inventory record becomes a budget line only when it points to work. For example, “protocol support unknown” creates an investigation task; “supplier confirms support is planned” creates a dependency and follow-up task; “change owner and test environment identified” gives the engineering team something it can estimate. Keep these states visible so reviewers can distinguish verified effort from work that has not yet been scoped.

Allocate engineering work by application and dependency

Post-quantum migration is not a single code replacement. A system may depend on cryptographic behavior in application code, a shared library, a transport protocol, certificate handling, a service interface, or a third-party product. The estimate should identify who must act at each layer and whether that party has committed to a supported change.

For in-house software, ask the responsible team to estimate investigation, design, implementation, code review, integration, documentation, and release work separately. Include legacy components and locally maintained forks where they exist. If the team cannot yet say which libraries or protocol settings are involved, budget that uncertainty as investigation rather than assuming a standard implementation effort.

For third-party components, capture the product or service, contract scope, support statement, upgrade path, and any required supplier engagement. Use official product support information and actual contract terms as evidence. Where a supplier has not confirmed availability, mark the estimate as pending; do not invent a delivery date or treat a general roadmap statement as a binding commitment.

For certificates, endpoints, and service interfaces, identify both ends of each connection. A change can be technically available on one side but still fail if the other endpoint, intermediary, or test environment cannot interoperate. The NCCoE preliminary migration material for enterprise networks can help teams think through migration activities and system interactions. Use it to prompt questions; derive the actual work packages from the organization's own architecture and contracts.

The cost model should preserve the difference between internal labor and external spend. Internal effort can be estimated using the organization's approved loaded labor rates or recorded hours. Supplier work should use a current, verifiable quote or contract basis. If either basis is unavailable, label the amount as unpriced instead of inserting a market average.

Reserve effort for testing and release evidence

A migration is not ready for production just because a build succeeds. The project estimate should include the work required to show that expected peers, environments, and operational processes continue to function.

At minimum, teams should scope:

• Compatibility checks across the actual client, server, library, and protocol combinations in use.
• Performance measurement under representative workload and deployment conditions.
• Failure behavior, including whether a failed negotiation or configuration change is detected and handled safely.
• Cross-environment validation in the organization's development, staging, and production-like setups.
• Rollback conditions, release approvals, runbooks, and a deployment rehearsal.

Do not take another organization's test timings or performance measurements and convert them into your own labor estimate. Different code paths, traffic patterns, hardware, network conditions, and release controls can change both the test design and the work needed to interpret results. Ask the team that owns the environment to define reproducible tests, then estimate test preparation, execution, analysis, defect remediation, and retesting as separate activities.

The NCCoE preliminary migration material for TLS offers a reference for considering migration and interoperability work in TLS-related settings. It does not prove that a particular deployment is compatible. Record your own test configuration and results so the estimate can be revised using evidence from the intended systems.

Testing boundary: If no representative environment or counterpart is available, show that as a validation gap. Do not mark interoperability work as complete merely because a local component accepts a new configuration.

Decision tool: choose the estimate basis that matches the evidence

Use this comparison to decide how a work item should appear in the budget. The right treatment depends on evidence, not on pressure to make every line look final.

Build the low, central, and high scenarios

Scenario ranges are more defensible than a single false-precision total. They should be built from the work packages, not from an arbitrary contingency percentage.

• Low scenario: Include confirmed work and documented assumptions that have supporting evidence. State exclusions plainly, such as unconfirmed supplier changes or systems not yet discovered.
• Central scenario: Include the most supportable current view, with known supplier dependencies and planned validation work represented explicitly.
• High scenario: Include plausible additional work tied to named uncertainties, such as an unexpected dependency, an unavailable test counterpart, or additional remediation after compatibility testing.

For each scenario, record which assumptions change. Apply internal labor rates and external prices only when they come from the organization's own approved data, actual time records, valid quotes, or contracts. If no verified price exists, show effort without currency or mark the amount as awaiting evidence. The scenario labels are not probabilities and should not be presented as a forecast unless the organization has a defensible method for assigning probabilities.

Account for continuing operations and cryptographic agility

One-time implementation does not end the budget conversation. A new cryptographic configuration can create continuing responsibilities for key lifecycle management, approved settings, monitoring, incident response, dependency upgrades, and supplier support tracking. Identify who owns each activity and whether it changes an existing process or creates a new one.

Estimate recurring work over a stated planning period. Include the staff time needed to review configuration, respond to compatibility issues, maintain documentation, and check supplier changes. Keep recurring operations distinct from migration project costs so decision-makers can see both the initial investment and the ongoing commitment.

NIST's guidance on achieving cryptographic agility discusses considerations for systems that need to adapt cryptographic mechanisms. Use it to identify design and governance questions, such as how algorithm choices are controlled and how future changes can be managed. Do not assume that adopting an agility principle automatically removes engineering work; the estimate still needs to cover the actual interfaces, configuration controls, tests, and operating procedures being changed.

Turn the inventory into a reviewable budget

Before sending the estimate for approval, complete this review:

• [ ] Each in-scope system has a named owner, or ownership discovery is explicitly budgeted.
• [ ] Inventory entries distinguish confirmed cryptographic use from unresolved dependencies.
• [ ] Application code, libraries, certificates, protocols, interfaces, and supplier work have appropriate owners.
• [ ] Estimates include analysis, engineering, review, integration, testing, and release preparation where applicable.
• [ ] Test work includes compatibility, performance measurement, failure handling, cross-environment validation, and rollback rehearsal as relevant.
• [ ] Internal effort, supplier charges, and recurring operations are shown separately.
• [ ] Every currency amount has an auditable basis; unverified amounts are labelled rather than invented.
• [ ] Low, central, and high scenarios state the assumptions and exclusions that distinguish them.
• [ ] Each unresolved item has an owner and a next action to replace an assumption with evidence.

The inventory becomes a useful budget only when each entry leads to an accountable action, a credible estimate basis, or a named uncertainty. This approach also makes later re-estimation practical: when a supplier confirms support or a test reveals new work, the relevant line changes without obscuring the rest of the model.

Move from budget assumptions to evidence

The hardest costs to predict are usually not a standard's published specifications. They are hidden dependencies, incomplete asset records, supplier commitments, and test conditions that have not yet been reproduced. Keep those items visible in the budget, then replace assumptions with internal estimates, test results, and verified supplier information as the project advances.

A shared test setup or borrowed machine can also introduce scheduling contention, inconsistent baselines, and limited control over when a validation run is available. If a temporary Mac-based test environment is relevant to the planned work, compare those constraints with the current terms and specifications on Vuncloud's Mac mini rental page; use only the environment details and rental terms actually listed there when calculating costs. Renting through Vuncloud may suit a time-bounded test need, while an organization with continuous heavy workloads or a requirement for direct physical interfaces may be better served by an owned local system. For questions about the listed service information, consult the Vuncloud Help Center or contact Vuncloud.