# PQC migration does not start by replacing an algorithm > Source: > Published: 2026-08-03 01:25:49+00:00 In [part one](https://www.vvitovec.com/en/blog/quantum-problem-starts-before-quantum-computer), I explained why the quantum problem starts before a sufficiently powerful quantum computer arrives. Data lives for years, and large cryptographic changes take years too. Now for the more practical question: **what should a company actually do first?** The obvious answer is usually “deploy a post-quantum algorithm.” But that is a little like starting a move by ordering a new sofa. You may need one, but it helps to know where you are moving, what you already own, and whether it fits through the door. PQC migration does not start by replacing an algorithm. It starts with an inventory. NIST has already standardized ML-KEM, ML-DSA, and SLH-DSA. The hardest part is not inventing our own cryptography. I would strongly recommend not doing that. The hard part is putting the change into a real product without breaking compatibility, performance, or trust between systems. Classical public-key cryptography may live in: Some things can be changed through configuration. Others will need new hardware, firmware, a certificate authority, a protocol change, or a vendor commitment. Some will need to run in a hybrid mode for a long time because an entire ecosystem will not switch on the same day. That is why blind algorithm search-and-replace is a bad start. Without context, you do not know whether you fixed the biggest risk or only the easiest line of code. An inventory is not a spreadsheet with two columns called `RSA` and `yes/no` . To support decisions, it needs to connect technical evidence with context. For every important item, I would want to know at least: [NIST NCCoE now describes cryptographic visibility and risk management](https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/) as one of the core PQC migration workstreams. Its current guidance starts with discovery and inventory because an organization cannot effectively prioritize cryptography it has not found. I am building [PQC Radar](https://pqc-radar.com/en) around this logic. Not as a button that produces a “quantum safety” percentage after one scan, but as a controlled process from uncertainty to a decision. A sensible first pass looks like this to me: Do not try to map the whole company on day one. Choose one important product, service, or trust chain with a clear owner and business reason. The scope may include two representative repositories, approved TLS endpoints, a certificate export, and one signing or update flow. That is enough to build a useful picture, but still small enough to avoid turning the work into an endless audit. PQC Radar inspects repositories, certificates, and explicitly authorized network targets. It looks for classical public-key algorithms, TLS configuration, cryptographic libraries, certificate files, signing scripts, and other signals. The result is not only a list of strings found by a regular expression. Each finding includes evidence, a confidence level, an explanation of its quantum relevance, a recommendation, and notes about possible false positives. Sensitive values are redacted; private keys and tokens do not belong in the output. This is the part no scanner can do alone. Code may contain RSA because of an old test. A certificate may protect a public marketing page with no long-lived sensitive data. A library may be a dependency but never be used. At the same time, the most critical signing process may live inside an HSM or a vendor product and leave almost no trace in the repository. Automated discovery makes the work faster. People provide the context. The algorithm alone does not determine priority. The same use of RSA may be a low priority in a temporary internal tool and a high priority in a long-lived product protecting sensitive data or signing firmware. It therefore makes sense to consider data lifetime, business criticality, external exposure, ownership, and migration difficulty. The goal is not to produce as many red findings as possible. The goal is to know what to fund and fix first. For some items in the inventory, the next step will not be “change the code.” It will be “ask the vendor.” Does the product support ML-KEM or ML-DSA? What is its migration plan? Will it support hybrid deployment? Does the change require new hardware? What happens to old signatures, archives, and devices already in the field? A good first output is therefore more than a technical backlog. It should include owners, validation steps, vendor questions, and a 30/60/90-day plan. There is another reason I like this work. Even if estimates for when a powerful quantum computer might arrive keep changing, a good cryptographic inventory and the ability to replace algorithms are not wasted effort. Cryptography changes without quantum computers too. Vulnerabilities appear, parameters weaken, standards evolve, regulations change, and vendors end support. [NIST calls the ability to manage these changes crypto agility](https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final): replacing and adapting cryptographic algorithms across applications, protocols, hardware, and infrastructure while preserving security and operations. PQC is a large test of that ability. If a company cannot say where cryptography is used today, every future transition will be more expensive and slower than it needs to be. I want to be precise about this. One readiness sprint is not a complete cryptographic audit of an entire organization. A scanner cannot see everything. Heuristic findings require manual validation. And the result is not a certificate that a product is quantum safe. PQC Radar is meant to deliver something more practical: I think that is the right first step. Not because it completes the entire migration in two weeks, but because it replaces the worst state — uncertainty — with a concrete list of decisions. Post-quantum migration does not begin when someone adds a new algorithm to the backlog. It begins when an organization can say: **we know what protects our data, we know who owns it, and we know what should change first.** That is exactly what [PQC Radar](https://pqc-radar.com/en) is meant to help with.