Last week I told you to add one question to your procurement checklist before any new infrastructure purchase: “Can I change the cryptographic algorithms this product uses without replacing the hardware?”

A few of you tried it.

One wrote back: “The vendor said yes. Then I asked how. They sent me a datasheet that said ‘quantum safe architecture’ three times and answered nothing.”

That is the problem we are solving today.

“Quantum-Safe” Is Not a Standard

Let’s clear this up immediately.

There is no certification, no audit body, and no regulatory definition that qualifies a product as quantum-safe. Any vendor using that phrase on a slide deck without naming a specific NIST standard and a specific implementation timeline is telling you nothing. They are using the phrase because it tests well in prospect conversations, not because it reflects a completed engineering decision.

What you are looking for is specific. NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, backup signature method). A vendor with a credible PQC roadmap names at least one of those, tells you which product line is affected, and gives you a release timeline.

Everything else is marketing.

The Four Question Vendor Test

When a vendor claims quantum readiness, run them through this. Four questions. The answers sort the stack fast.

Question 1: Which NIST post-quantum standards are you implementing?

Acceptable answer: names ML-KEM, ML-DSA, or SLH-DSA with the associated FIPS number. Bonus if they distinguish between key encapsulation and signature algorithms and explain which applies to their product.

Unacceptable answer: “quantum resistant algorithms,” “next generation encryption,” “post-quantum ready architecture,” or any variation that does not name a specific standard.

Question 2: Which product versions will carry PQC support, and when are they generally available?

Acceptable answer: a specific release version or a date range with a named roadmap document you can reference.

Unacceptable answer: “our engineering team is actively working on this,” “we are monitoring the NIST process,” or any answer referencing NIST as ongoing when standards finalized in August 2024.

Question 3: Will you support hybrid mode during the transition?

This one matters more than most MSPs realize. Hybrid mode means the product can run classical and post-quantum encryption simultaneously. Classical for systems that have not migrated yet, post-quantum for systems that have. Without hybrid mode, migration requires a hard cutover. In a mixed client environment, that is either impossible or catastrophically disruptive.

Acceptable answer: yes, with a timeline.

Unacceptable answer: anything that suggests the client must wait for full network migration before the product can adopt PQC.

Question 4: What does migration to PQC require on our end, firmware update, software upgrade, or hardware replacement?

This is the cost question. The answer determines whether your client’s current investment survives the transition or needs to be budgeted for replacement. Hardware replacement to achieve PQC compliance on a device purchased in 2024 is a vendor problem, not a client problem. Document it as a risk now and factor it into refresh cycles.

What to Do With Vendors Who Cannot Answer

Document it. That is the whole move.

A vendor who cannot name a NIST standard, cannot give a release timeline, and cannot confirm hybrid mode support is a risk concentration point in your client’s environment. You are not necessarily ripping them out today. But you are flagging the dependency, noting the gap in writing, and factoring replacement cost into the migration roadmap.

When the cyber insurer asks your client whether their environment is aligned to NIST post-quantum standards, “our vendor hasn’t published a roadmap” is not a complete answer. “We identified the gap in July 2026, flagged it to the client, and included a replacement timeline in the migration roadmap” is.

That documentation is the work. It is also what separates a managed service from a break-fix relationship with a monthly retainer attached.

Monday Morning Move

1. Pull the vendor list for one Tier 1 client. Pick the top five security relevant products. Firewall, VPN, backup platform, identity provider, email security. Run question one against each. Name a NIST standard or flag it.
2. Any vendor with no roadmap answer gets a documented risk note in the client file this week. One line per vendor. Takes twenty minutes.
3. If a new purchase is in the approval queue right now, hold it twenty four hours and run all four questions before the PO goes out. One conversation now versus a hardware replacement conversation in three years.

The vendor landscape is sorting itself. Your job is to know which side of the line each vendor in your stack is on before your client’s insurer asks.

Stay sharp.

The Quantum Guy

The information in this post is provided for general informational purposes only and does not constitute professional, legal, technical, or security advice. Readers act on this content at their own discretion and risk; IoTSSA assumes no liability for any loss or damage arising from its use.