NIST’s latest guidance gives security and technology leaders a clearer basis for planning the transition to post-quantum cryptography. Its practical value will depend on what organizations do with it: identify the systems that need attention, sequence the work, and verify that changes reduce risk.
On October 27, 2026, NIST announced the final Transition to Post-Quantum Cryptography Standards report, NIST IR 8547. The report identifies quantum-vulnerable cryptographic standards, the replacements organizations will need to adopt, and the timelines that will shape migration.
At SafeLogic, we believe this transition should leave organizations better equipped to understand, change, and govern the cryptography they depend on. Progress should be judged by evidence that critical services have reduced their exposure to quantum-vulnerable cryptography. A roadmap needs to explain how teams will produce that evidence.
NIST IR 8547: Key PQC Migration Deadlines
The final report retains 2035 as the overall federal migration target while incorporating earlier requirements for specified high-value and high-impact federal systems. Those systems must adopt PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031.
NIST also plans to deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. Deprecation permits continued use subject to an assessment of the security risk; it does not extend the earlier federal migration deadlines.
Those accelerated requirements apply to specified federal systems. Other organizations need to determine how the guidance intersects with their own obligations, customer requirements, and risk. The executive order underlying the accelerated schedule excludes National Security Systems from those provisions.
For leaders, the immediate implication is practical. A platform selected today may still be in service when these milestones arrive. A multiyear contract can affect access to upgrades, and a hardware replacement may need funding well before deployment begins.
Work backward from the required outcome. Identify the decisions that must be made in the next planning cycle, including replacement budgets, supplier commitments, and engineering capacity. A distant completion date can conceal a much earlier deadline for starting the work.
Make discovery useful to the people who must act
NIST’s National Cybersecurity Center of Excellence migration project connects cryptographic discovery with risk management and prioritization. That connection deserves attention: an inventory should help an organization decide what to change and who will change it.
For each significant finding, teams should establish which business service depends on it, what information or process it protects, who owns the application, and which internal or external dependencies constrain an upgrade. They should also record how recently the finding was verified.
Consider two applications that use the same vulnerable algorithm. One has an active development team and a supported upgrade path. The other depends on a device that cannot be updated remotely. The algorithm name alone provides little help in deciding how to sequence their migrations.
Begin with a defined set of important services and build enough context to make decisions about them. Broader discovery can continue while those teams test and implement changes.
Keep that inventory connected to software delivery and operational change. When an application is updated, a supplier changes its implementation, or a new service enters production, the migration plan should reflect what changed. Otherwise, teams risk planning against an environment that no longer exists.
Prioritize around data lifetime and migration difficulty
NIST’s announcement highlights the “harvest now, decrypt later” threat: an adversary can collect encrypted information today and attempt to decrypt it when sufficiently capable quantum computers become available. Information that must remain confidential for many years deserves early attention.
This changes how leaders should evaluate timing. For a service handling information that must remain sensitive for a decade, delaying the protection of new communications adds to the period during which valuable data could be collected. A later migration cannot retroactively protect traffic already captured under vulnerable cryptography.
Prioritization should also account for the effort required to change a system. An application with a straightforward upgrade may move quickly. A critical service dependent on several suppliers, specialized hardware, or infrequent maintenance windows may need work to begin much sooner.
Consider confidentiality lifetime, business impact, and migration lead time together. This avoids a program dominated by whichever systems are easiest to update. Teams can make progress on accessible improvements while resolving the dependencies that could delay higher-priority work.
Authentication and signing also need explicit owners and plans. Their milestones should remain visible alongside confidentiality work so that a successful key-establishment pilot does not become the organization’s entire definition of PQC progress.
Turn supplier roadmaps into concrete migration inputs
The joint CISA, NSA, and NIST quantum-readiness guidance has long encouraged organizations to engage vendors as part of migration planning. The next step is to make those conversations specific enough to support decisions.
Ask suppliers to identify the product versions and operating environments that will support the required cryptography, what customers must change to use it, and which dependencies remain unresolved. Procurement and technical teams should review those answers together.
Useful questions include:
- Which capabilities are available now, and which depend on a future release?
- What upgrades, configuration changes, or hardware replacements will customers need?
- What evidence supports interoperability and performance in the environments we use?
- What validation or certification requirements remain, where applicable?
- How will we verify the cryptography actually used after deployment?
These answers should become inputs to an owned schedule. If a supplier dependency threatens a priority service, the plan should identify the decision date for an alternative, along with the person responsible for making it.
This is where executive sponsorship becomes useful. It can resolve competing priorities between security, application teams, infrastructure, and procurement before those disagreements become deployment delays.
Measure progress through verified changes in operation
We believe migration programs need explicit completion criteria for each service or use case. An upgraded component, a successful test, and an operationally protected workflow represent different stages of progress.
Consider an application whose cryptographic library supports PQC. If a priority connection still uses only a quantum-vulnerable key-establishment method, that connection retains the exposure the migration was meant to address. Teams need evidence of the actual configuration and behavior of the deployed system.
NIST’s crypto-agility guidance supports this principle, including the need for mechanisms to determine whether deployments have transitioned from old algorithms to new ones.
For a pilot, agree on the evidence required before testing begins. That might include successful operation with dependent systems, acceptable performance, confirmation of the intended algorithms in use, and a documented response when a peer cannot support the required protection.
Where policy permits a vulnerable option to remain available temporarily for compatibility, give that exception an owner, a defined scope, and a review date. Once the relevant dependencies have migrated, verify that obsolete options have been disabled or restricted as intended. Account separately for any permitted legacy use, such as processing previously protected data or verifying historical signatures, under the applicable standards and policy.
Leadership reporting should make these distinctions visible. Alongside inventory coverage, report which priority services have completed verified changes, which remain blocked, and which exceptions still carry risk. That gives leaders information they can act on.
Build crypto agility into the outcome
NIST defines crypto agility in terms of the ability to replace and adapt cryptography across systems while preserving security and ongoing operations. For a migration program, that is a useful design objective.
Test that capability directly. Ask a team to demonstrate how it would change an approved cryptographic configuration, assess the effect on dependent systems, deploy the change safely, and confirm the resulting behavior. The exercise can reveal whether future changes will require another substantial discovery effort or application redesign.
Hybrid approaches can play a role in the transition. NIST accommodates combinations of conventional and post-quantum cryptography while recognizing their added resource demands. Organizations should evaluate the relevant security properties, performance, and implementation complexity for their use cases.
Supporting a hybrid construction, however, does not by itself establish the ability to manage future change. Architecture, operating procedures, supplier support, and policy all need to make that change possible.
Build the processes for approving cryptographic choices and managing exceptions into regular operations. Reusing those processes can make the next transition easier to execute.
Give the roadmap an accountable next step
For the next planning cycle, choose a small set of priority services and assign an accountable owner to each. Establish the current dependencies, the intended outcome, and the evidence that will demonstrate progress. Bring unresolved supplier or funding issues to leadership while there is still time to act.
A successful transition should leave an organization able to explain how its critical services are protected, demonstrate that the intended cryptography is in use, and carry out the next required change through a tested process.
Contact SafeLogic to learn how we can help.
