NIST released its final post-quantum cryptography transition report, IR 8547, on October 27, 2026. For teams planning work, the useful question is not simply which year appears in a headline. It is which systems you operate, how long their information must remain confidential, and what has to change before a migration can finish.
NIST’s October 27 announcement
Keep the dates attached to their scope
The report retains 2035 as the overall federal migration target. It describes earlier requirements for federal high-value assets, high-impact systems and other priority sensitive systems: post-quantum key establishment by December 31, 2030, and digital signatures by December 31, 2031. It also says migration should begin with cryptographic inventories, planning and early deployments. These are scoped federal timelines, not a single deadline automatically assigned to every business worldwide.
Final NIST IR 8547: introduction and Section 4
A planning record should therefore include the source of a requirement and the system it covers. A US supplier serving a federal customer needs to identify the relevant customer and contract requirements. A business in India should likewise establish its own applicable obligations and dependencies rather than copy a US federal date into every system’s plan.
Put data lifetime beside replacement lead time
NIST highlights the risk that attackers could collect encrypted information today for decryption after quantum technology matures. That makes long-lived confidentiality a planning concern before such a machine exists. Its announcement also emphasizes the cryptographic supply chain, not just an organization’s own components.
Consider an original fictional exercise. Service A transfers documents that must stay confidential for 15 years and relies on a vendor appliance with a two-year replacement process. Service B publishes already-public information and can be rebuilt by its owner. These facts do not calculate either service’s complete risk, but they show why a single calendar reminder is an inadequate plan.
For Service A, record the confidentiality requirement, appliance owner, vendor’s documented migration path and the time needed to test a replacement. For Service B, record the cryptographic functions that still matter, such as proving an update’s origin. Public content does not make every security requirement disappear. Keep confidentiality and signature needs in separate fields.
Build one inventory row you can act on
- System and owner: identify the service, responsible team and supported configuration.
- Cryptographic purpose: distinguish protecting confidential traffic, establishing keys and verifying signatures.
- Data lifetime: record how long confidentiality or authenticity matters, with the business reason.
- Dependencies: list the supplier, library, appliance or service that controls the migration path.
- Evidence and next action: attach a dated vendor document, identify unanswered questions and assign an owner.
This is a proposed working record, not an official NIST template. Start with one important service and trace the entire path it uses. Mark unverified algorithm or configuration fields as unknown. A product brochure mentioning post-quantum support should lead to a question about your exact deployment, rather than an automatic completed status.
Make the next milestone observable
Choose a bounded next step: obtain the vendor’s supported configuration, identify a dependency owner or test a representative connection in a separate environment. Define the evidence needed to close that step before doing it. Record compatibility failures and unresolved dependencies alongside successful observations.
Keep discovery, a successful trial and a completed production migration as distinct milestones. This article does not report a deployment test or establish your organization’s compliance. Its practical output is a better-scoped work item: the system, the reason it matters, the dependency that must move and the evidence needed next.
Check the migration plan
