The final NIST IR 8547 says RSA and ECC will be deprecated after 2030 and disallowed after 2035. This article separates who is bound and explains a one-page cryptography inventory a systems team can build itself, without buying a new product.
An auditor from a large customer sends one question in the annual security questionnaire. It asks which encryption algorithms the system you delivered uses, and whether you have a plan for moving to cryptography that resists quantum computers. The IT team reads it and goes quiet for a moment. Not because they have never heard of the topic, but because nobody knows what cryptography the whole system uses, or where.
This article is written from the viewpoint of a team that designs and delivers systems, not cryptography specialists. We describe what the latest NIST document actually states, say what it binds and whom, and explain work you can do today without buying a new product: an inventory of which public-key cryptography your systems use, where it sits, and who holds the keys.
What the document states
NIST published the final NIST IR 8547, Transition to Post-Quantum Cryptography Standards, in October 2026. NIST's page gives the final date as 27 October 2026 and lists an earlier draft dated 12 November 2024 (see NIST's page for the document). We opened and read the PDF itself (DOI of the document). The relevant content is as follows.
NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and will disallow its use under NIST standards and guidelines after 2035.
Tables in the document list the affected groups, such as the digital signature schemes ECDSA, EdDSA and RSA, and the key-establishment schemes Finite Field DH, Elliptic Curve DH and MQV.
For US federal agencies, the document cites OMB Memorandum M-26-15, which requires systems with highly sensitive data to use quantum-resistant cryptography for key establishment by 31 December 2030 and for digital signatures by 31 December 2031.
Federal agencies must support TLS 1.3 no later than 2 January 2030, according to the same document.
The overall target for the migration to quantum-resistant cryptography is 2035, which the document attributes to National Security Memorandum 10.
The document also notes that previous cryptographic transitions took 10 to 20 years, and that the schedule leaves little slack. We kept that sentence because it is the reason a systems team should know what it uses before the day it has to change.
Whom the document binds, and whom it does not
This needs to be said clearly, because many news items read as if every organization has a 2030 deadline.
NIST IR 8547 is a document from a US standards body. It sets the direction of NIST's own standards and guidelines and cites directives that bind US federal agencies. It is not Thai law and does not bind Thai organizations directly. We did not find anything in the document that obliges private-sector organizations outside the United States.
What Thai organizations should care about is therefore the indirect effect, in three ways. First, NIST standards are used as references in security questionnaires, procurement requirements, and the products vendors will gradually update. Second, foreign customers or organizations that work with the US government may pass these requirements down the supply chain. Third, the document discusses a threat called harvest now, decrypt later: an attacker stores encrypted data today to decrypt it once a capable machine exists. That means data that must stay confidential for years carries a risk that starts the day it is transmitted, not the day a quantum computer becomes available.
We do not know which Thai organization will face an actual deadline, and we do not know when a cryptographically relevant quantum computer will exist. NIST's document does not predict that date either. Our conclusion is limited: knowing what you use is preparation that is not wasted whichever way the future goes.
What a cryptography inventory is
A cryptography inventory is a table that answers where, across all the systems an organization uses, public-key cryptography appears, which algorithm it uses, who owns it, and how hard it is to change. By public-key cryptography we mean the group the NIST document identifies as vulnerable to quantum computers, such as RSA and ECC, not every kind of encryption.
For each place it is used, we suggest recording the following.
Where it is. For example certificates for websites and APIs, VPN connections, token signing for single sign-on, code or installer signing, email encryption, database connections.
The algorithm and key size actually in use, read from configuration or the certificate, not from someone's memory.
Who holds the key and where it is kept, for example on a server, in a cloud provider's key management service, or on one person's machine.
Whether it is embedded in our code or inside someone else's product. If it is in someone else's product, changing it means waiting for the vendor.
How long the protected data must stay confidential. Data that loses value within days differs from data that must stay secret for years.
Whether it is easy or hard to change. A certificate that renews automatically every few months is easy. A signature embedded in the firmware of an installed device is hard.
The last column matters most for planning, because it separates work that fits in a normal renewal from work that needs a project.
Where cryptography hides
When we go through an organization's systems one by one, cryptography is usually in places the team does not think of when first asked.
Certificates used internally for services not exposed outside are often issued by the same tool years ago and nobody looks at them. A single sign-on system uses a key to sign tokens, and that key may be an RSA key set on installation day. An old system whose original developer is gone may connect to others over a protocol pinned to a fixed version. Network devices and printers with web administration pages have their own certificates. A function that signs contract files or electronic receipts uses a key stored on one administrator's machine.
On administrators who hold keys, we wrote about handing over access when a team changes in our article on who holds the keys to your cloud accounts. The same principle applies to cryptographic keys: if only one person knows where a key is, you already have a risk that has nothing to do with quantum computing.
Questions you can ask vendors and developers now
What you cannot change yourself, you must ask the vendor about. We suggest three short questions, to put in a vendor questionnaire or in the next round of procurement requirements.
Where does this product or service use public-key cryptography, and which algorithms?
Does the vendor have a published plan or timeline for supporting quantum-resistant cryptography and, if so, will the update fall under the existing maintenance contract?
If an algorithm must change, does the system need downtime, and who does the work?
We suggest asking for the answers in writing. A vendor without a plan can simply say so, which is also information a buyer needs. The idea is consistent with the requirements that belong in a terms of reference for a maintainable system, which we wrote about in our article on conditions in a TOR.
What not to do now
In our view, three things should not be done just because you read this news.
The first is buying an entire product line advertised as quantum-ready before you know what cryptography your own systems use. A product that solves an unidentified problem rarely solves the real one. The second is changing algorithms on a live system outside the normal change process. Changing cryptography affects every connection point and should be tested like any other system change, which we wrote about in our article on release management in production. The third is assuming symmetric encryption or hashing is always safe. NIST's own document notes that some symmetric security levels will be disallowed in 2030, and that the SHA-1 hash function will be disallowed for FIPS-validated modules after 2030. A good inventory should therefore cover these older algorithms too, not only RSA and ECC.
Limits we should state plainly
If your system has a service life under five years, holds no data that must stay confidential for long, and is not delivered to customers with US-government requirements, a full cryptography inventory may be more than you need. One page listing certificates, login points and signing keys is a reasonable start.
Also, we can confirm only what NIST's document states. We did not verify the OMB schedule or the presidential directive the document cites against their originals, and we did not verify the technical details of the post-quantum standards NIST selected. If you need a real technical plan, consult a cryptography specialist who reads the full document and assesses your systems.
Finally, an inventory does not make a system more secure by itself. It tells you what exists and where. Deciding what to change first, and when, is the next step and depends on the risk of each kind of data.
Objections we often hear
A common objection is that a quantum computer able to break the encryption does not exist yet, so why prepare now. That is correct, and we do not claim when one will arrive. But NIST sets its schedule on the assumption that migration takes a long time, and data stored today for later decryption is a risk that does not wait for the machine. For data that does not need to stay secret long, the risk is low. For data that must stay confidential for years, the organization has to decide how much risk it accepts.
Another is that this is a job for the security team, not the development team. The security team can set policy, but the people who know which services the system calls and where keys are embedded are the ones who write and maintain it. The inventory has to come from both sides together.
Where to start
List every certificate the organization holds, both external and internal. Record expiry date, algorithm and owner.
Check the signing keys of the login system and APIs: where they are, who can reach them, and when they were last rotated.
Ask each main vendor the three questions and record the answers with the date.
Separate data that must stay confidential for long from ordinary data, then see what protects the first group.
Keep the inventory with the system documentation and set a review date, for example at each renewal of the maintenance contract, so the next person can read it.
Summary
The final NIST IR 8547 says quantum-vulnerable public-key cryptography will be deprecated after 2030 and disallowed after 2035 under NIST standards, with stricter deadlines tied to US federal agencies, not Thai organizations. If you take one thing from this article, build a one-page table showing where your systems use RSA or ECC, who holds the keys, and how hard each is to change. That table answers customer questionnaires, supports planning with vendors, and helps whoever takes over the system.
If you would like to talk through the details of a project, you can reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok. For organizations still drafting a scope of work, we are glad to arrange a conversation to understand the problem first, without needing complete documents. And if we find that the problem is not yet at the point of needing a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting another quarter.
FAQ: Frequently Asked Questions about This Article
A collection of questions and answers to help you better understand the content of this article.
Tags: