PQC for MSSPs and Consultancies: Opportunity and Risk

By September 2025, the UK’s National Cyber Security Centre had admitted eight firms to a pilot that assures consultancies for post-quantum cryptography work: Arqit, Avella, Cambridge Consultants, Capgemini, CGI, Frazer-Nash, IBM and PQShield. Under the NCSC’s PQC pilot, every firm is assured to support cryptographic discovery and initial migration planning, and some are also assured to give direct advice on using PQC. The pilot is expected to run until 31 March 2027.

For anyone who sells security services, that list is an early look at how buyers will choose providers for the largest cryptographic change most of us will see in our careers. Buyers in the UK can now see which consultancies the NCSC has assessed for this work, and I expect large buyers elsewhere to build their own filters. A five-year managed security contract signed this quarter will still be running on 31 December 2030, the date by which the White House expects US high-value federal systems to use post-quantum key establishment and the EU expects member states to have migrated their high-risk use cases. A three-year contract will come up for renewal the year before. Either way, every managed security proposal written today is already a PQC proposal, whether it mentions quantum or not.

PQC migration will give consultancies, integrators and managed security providers a decade of paid work. In my view it will be the largest cryptographic services market any of us has seen. I expect most of that money to go to the hard, slow parts: PKI, signatures, legacy applications, operational technology, vendor management and multi-year program work. Generic scans and readiness scorecards will earn little of it. Clients will also ask a question that gets far less attention in vendor marketing. Before they buy PQC services from a provider, they will check its own cryptography, because it terminates their TLS, carries their logs, runs their VPNs and often manages their certificates. Providers that can’t answer risk losing deals they never knew were PQC deals.

I’ve looked at this market from three seats. As a CISO I bought managed security and consulting services. Later I held global and regional leadership roles at IBM, Accenture, PwC and KPMG, leading cybersecurity and quantum consulting practices. Today Applied Quantum, the firm I founded, sells PQC migration services to enterprises and helps consultancies and MSPs build their own PQC practices, so it competes with some of the providers this article is written for and works for others. Read what follows with that interest in mind.

The PQC Deadlines Now Run Past Today’s Contracts

For years, security providers could treat quantum as a conference topic, because nobody had put a date in a contract. Between 2024 and 2026, regulators, standards bodies and the US government set dates, and an ordinary managed services agreement signed this year will still be in force when they arrive.

Every date in the table applies whether or not a cryptographically relevant quantum computer exists by then. I’ve argued before that the Q-Day debate has stopped driving decisions: regulators, insurers, investors and large clients have set their own deadlines, and boards fund obligations, not threats. A client’s CFO will approve a PQC program to meet a supervisor’s date long before approving one to beat a physicist’s forecast. I count 14 deadlines and milestones between 2026 and 2030 alone, and more will follow as national programs diverge from each other.

Organizations are far behind those dates. A GAO report released in October 2026 examined how 24 US federal agencies had prepared for PQC. The agencies had until May 2023 to inventory quantum-vulnerable cryptography, and only one had fully addressed the requirements for that prioritized inventory. The Hong Kong Monetary Authority’s initial, survey-based Quantum Preparedness Index scored its banking sector 2.3 out of 10. DigiCert’s 2026 survey found that 87% of organizations are planning, testing or implementing PQC, but only 7% have deployed quantum-safe or hybrid cryptography across most of their digital certificates. To close those gaps, most of these organizations will need people and skills they don’t employ.

Why Most Organizations Will Need Outside Help

The first reason is scale. A PQC migration touches every system that uses public-key cryptography, and that covers almost everything an enterprise runs: web and API endpoints, internal TLS between services, VPNs, identity providers, code signing, databases, payment systems, HSMs and the products of hundreds of vendors. One of the telecom and financial-sector programs behind my PQC Migration Framework ran to more than 120,000 tasks on its own. Few organizations have the program staff to absorb that on top of their normal work.

The second reason is skills. Cryptographic engineers are scarce, and most security teams have never had to replace an algorithm across an estate. The skills a PQC program needs are spread across PKI administrators, network engineers, application architects, procurement and risk. In many organizations several of those functions are already outsourced, often to the same MSSPs and MSPs that will be asked to help with the migration.

The third reason is money, and the numbers are starting to appear in budgets. In July 2024, the White House’s Office of the National Cyber Director estimated the cost of migrating prioritized US federal information systems, excluding national security systems, at about $7.1 billion in 2024 dollars between 2025 and 2035. The report calls the figure a rough order of magnitude with a high level of uncertainty, and it covers one government’s priority systems, before a single bank, utility or hospital. In its 2026 security predictions, Forrester said that “quantum security spending will exceed 5% of the overall IT security budget.” That’s a forecast, not a measurement. Still, it is the kind of line item that gets put out to tender. Nobody can tell a client exactly what its migration will cost, but the services share of that spending will be large. The work is labor-intensive and specific to each estate.

The fourth reason is the one I’ve been warning about for years: the inventory. Organizations, and many of the regulators that require inventories, underestimate how large and complex a comprehensive cryptographic inventory is. When operators realize it, they produce checkbox inventories, and supervisors often lack the means to tell a good inventory from a bad one. The GAO’s finding that only one agency in 24 had fully addressed its inventory requirements is that problem measured. In my PQC Migration Framework, I proposed a minimum viable inventory, scoped to the decisions it has to support, as an alternative to years of trying to build a complete inventory that goes stale hours after it is finished. Clients will need help with exactly this judgment: which systems to cover first, to what depth, and how to prioritize when a full inventory isn’t possible.

What Browsers, CDNs and Cloud Platforms Already Do for Free

Before planning a PQC practice, a provider has to understand which parts of the migration the large platforms are already doing for its clients without a separate PQC charge.

Hybrid post-quantum key exchange is already deployed at large scale on the public web. The major browsers offer hybrid ML-KEM key exchange by default, Apple’s operating systems have advertised it automatically in TLS 1.3 connections since the version 26 releases, and Cloudflare reported in October 2025 that more than half of human traffic through its network was protected by it. By June 2026, Cloudflare’s Sharon Goldberg and Vincent Voci wrote that “over two-thirds of browser traffic to Cloudflare’s network is protected with post-quantum encryption”, and that the company aims to be fully post-quantum secure, including authentication, by 2029. On the administration side, OpenSSH 10.1, released in October 2025, added a warning when a connection “negotiates a non-post quantum key agreement algorithm,” with a new WarnWeakCrypto option that is on by default. Administrators will see that warning whether or not anybody sells them a service.

For providers, a service that consists of enabling hybrid key exchange on a client’s public website competes with a setting in the client’s CDN console. And an external scan of a client’s internet-facing estate will show its post-quantum score improving every quarter as vendors change their defaults. A scorecard that improves because Chrome and Cloudflare upgraded is a pleasant report to deliver and a hard one to bill for.

Platform defaults leave most of a client’s estate untouched, and adoption at the network edge says nothing about the client’s authentication, origin servers, inspection paths or applications:

• Authentication and signatures. Post-quantum certificates for the public web are not settled. Chrome is testing Merkle Tree Certificates as an alternative to putting ML-DSA into today’s X.509 chains, and the first external operators applied to its test program in July 2026. Internal PKI is a separate migration, and so are code, firmware and document signing. So is identity: SAML assertions and OAuth and JWT tokens are signed with RSA or ECDSA keys, and FIDO2 passkeys use elliptic-curve keys, usually on P-256. Any signing root trusted for years faces the Trust Now, Forge Later risk.
• Internal traffic. Large parts of most estates still run TLS 1.2, and the hybrid ML-KEM groups in use today are defined for TLS 1.3. Netskope’s documentation, discussed below, says plainly that “TLS 1.2 sessions continue to use classical algorithms.”
• Legacy and embedded systems. Mainframe integrations, payment HSMs, industrial controllers and medical devices change on hardware cycles measured in decades. Operational technology is its own problem.
• Vendors. A typical enterprise depends on hundreds of products whose cryptography it doesn’t control. Someone has to collect roadmaps, write contract clauses and chase the laggards. I covered the governance side in PQC vendor and supply chain governance.
• Decisions. What to migrate first, how to fund it, what to accept as a dated exception and how to report progress to a board are judgments, and no platform default makes them.

That list is where the services revenue is.

Providers Are Part of Their Clients’ Attack Surface

Managed security providers terminate, inspect or relay their clients’ most sensitive traffic, which makes their own cryptography a client problem. When a provider is compromised, every client it manages is exposed with it. This is the disadvantage side of PQC for providers, and most of the commentary aimed at MSSPs skips it.

Telemetry Pipelines, Remote Access and Harvest Now, Decrypt Later

Attackers have used managed service providers to reach their clients for at least a decade. In December 2018, the US Department of Justice charged two members of the Chinese APT10 group and said that “the APT10 Group targeted MSPs in order to leverage the MSPs’ networks to gain unauthorized access” to client data around the world. In May 2022, the Five Eyes cyber agencies issued a joint advisory on threats to MSPs and their customers, because the pattern had continued.

The quantum version of that risk is quieter. An MSSP’s links to its clients carry logs with usernames, internal hostnames and IP plans, EDR telemetry, vulnerability scan results, incident reports and remote administration sessions. Part of that data loses its value in weeks. Network maps, architecture details, unpatched weaknesses in systems that will run for another decade and the contents of incident investigations keep their value for years. If those links use classical key exchange, an adversary who records them today could decrypt them later, once a quantum computer can break the key exchange. That is harvest now, decrypt later applied to the provider’s own pipes: log forwarding, agent-to-cloud channels, site-to-site VPNs into client networks, jump hosts and remote monitoring tools.

MSPs that run IT operations as well as security have two more exposures. Their remote monitoring and management (RMM) and professional services automation (PSA) platforms reach into every client through agents, API tokens and stored credentials, and the tool vendor chooses the cryptography, not the MSP. Their backup services usually encrypt archives with AES-256, which quantum computers aren’t expected to break, but they often wrap or exchange the archive keys with RSA or elliptic-curve cryptography. An adversary who obtains an archive together with its wrapped key could recover the data once those algorithms fall. With retention periods of seven years or more, archives written today may still exist when that becomes possible.

A provider controls fewer, more standardized components than most of its clients, which helps. Shared infrastructure also means a larger blast radius, tenants with different compatibility needs and coordinated maintenance windows, so a provider has to pilot its own migration and plan a rollback like anyone else. The provider also has to be able to show the work when a client’s third-party risk team asks.

That migration costs money before any client pays for it: lab and interoperability testing, appliance and HSM replacement, license upgrades, staff time, and exposure on fixed-price contracts if a milestone slips. Many providers will have to fund that work before their clients accept a separate PQC charge.

TLS Inspection Can Remove Post-Quantum Protection

TLS inspection is the most immediate example, because it can undo protection that clients already have. An inspecting proxy terminates the client’s TLS session and opens a second one to the destination server. Each leg negotiates its key exchange separately. If the proxy doesn’t offer hybrid ML-KEM on the client-facing leg, the browser falls back to a classical group such as X25519 when it talks to the proxy. Traffic on that leg is then exposed to harvest-now, decrypt-later collection even if the other leg uses hybrid ML-KEM. Even with hybrid key exchange on both legs, the proxy remains a point where the plaintext exists.

Vendor documentation shows how uneven support still is:

• As of October 2026, Netskope’s documentation describes PQC support as “available as a beta feature starting in Next Generation Secure Web Gateway (NG-SWG) Release 137,” enabled per tenant by Netskope Support, with a separate flag for each leg. When PQC isn’t supported, “the handshake falls back to a classical algorithm such as X25519 or P-256,” and “no sessions are dropped and no traffic is blocked due to a PQC mismatch.”
• Skyhigh Security’s documentation says its cloud gateway has negotiated PQC with origin servers by default since SSE 6.8.2 in June 2025. The page doesn’t describe the client-facing leg.
• Palo Alto Networks’ decryption cipher list for PAN-OS 12.1 includes X25519MLKEM768 and SecP256r1MLKEM768 for firewalls in normal operating mode. Firewalls in FIPS-CC mode follow a separate list, and estates on earlier releases have to be checked one release at a time.

Silent fallback is a reasonable default for availability. It also means nobody gets an error when the protection disappears, and for flows that must resist harvest-now, decrypt-later collection, the client may want the connection to fail instead. Any provider that runs inspection for clients should be able to say, for each tenant, which release is running, which legs negotiate hybrid ML-KEM, which operating mode the appliances are in and which flags are set. A provider that can’t answer that may be the reason a client’s traffic is classical.

Palo Alto also describes a “cipher translation” proxy in PAN-OS 12.1 that terminates TLS sessions from legacy applications and re-establishes them with a hybrid post-quantum key exchange, without changes to the client or the server. For applications nobody can modify in time, that is a reasonable interim measure. The segment between the application and the proxy stays classical, though, so it belongs in the client’s plan as a dated exception with an owner, not as a finished migration.

Rules That Apply to Providers Directly

In the EU, some of this is already a legal obligation for the providers themselves. Commission Implementing Regulation (EU) 2024/2690, which sets the NIS2 technical requirements for digital infrastructure and ICT service providers, lists MSPs and MSSPs among the entities it covers. Section 9 of its annex requires a cryptography policy that sets the approved protocols, algorithms and cipher strengths, “following, where appropriate, a cryptographic agility approach,” and requires entities to review that policy at planned intervals, “taking into account the state of the art in cryptography.” The regulation doesn’t name ML-KEM or set a PQC deadline, though in 2026 the state of the art includes NIST’s post-quantum standards. In my view, an in-scope EU MSSP whose cryptography policy says nothing about PQC will struggle to explain that to a supervisor or to a client’s auditor.

In the US, EO 14412 directs a proposed rule under the Federal Acquisition Regulation, due by 19 December 2026, that would require covered contractors to comply by 31 December 2030 with NIST’s FIPS, “including all applicable FIPS incorporating PQC compliant algorithms.” No such rule is in force yet, but providers that serve federal agencies should read it as a contract clause on its way. Providers that sell into national security systems face CNSA 2.0’s 1 January 2027 procurement gate.

In financial services, the obligations reach providers through their clients. Banks in Saudi Arabia, Hong Kong and Singapore are under supervisory pressure on quantum readiness. The Monetary Authority of Singapore has said it aims for financial institutions to achieve quantum resilience before the end of the decade, with supervisory expectations to follow. A bank can’t meet those expectations if the provider running its SOC, its managed firewalls or its certificate lifecycle can’t produce a roadmap. SAMA’s circular, for example, asks institutions to identify their dependencies on third parties when they assess the cryptographic resilience of their priority assets. That question will reach providers through due diligence questionnaires and renewal negotiations, often before anyone calls it a PQC question.

Questions Clients Will Ask Their Providers

Based on how clients have handled earlier supplier risks, these are the questions I expect a capable client to ask a managed security provider in the next 12 to 24 months:

1. Which of your services terminate, inspect or proxy our TLS traffic, and do they negotiate hybrid ML-KEM on both legs today?
2. What key exchange protects our log forwarding, your agents’ connections to your cloud, your remote access into our network and the VPN tunnels between us?
3. Where do you hold our keys, certificates or secrets, and which HSMs or key management services protect them? What are those vendors’ PQC roadmaps?
4. How do you sign the agents and updates you push into our environment, and when will that signing move to ML-DSA or another post-quantum scheme?
5. Can you produce a cryptographic bill of materials for the services you run for us, and in what format?
6. What is your own PQC roadmap, with dates, and which of our regulatory deadlines does it meet?
7. Who pays when an appliance or HSM you manage for us has to be replaced to support PQC?

The first provider in a sector to answer these in writing, unprompted, will set the standard its competitors are measured against.

A provider can’t answer several of those questions until its own vendors answer theirs. I’d put five questions to every RMM, remote access, backup and security platform vendor in the provider’s estate:

• Is there a published PQC roadmap, with dates?
• Does the current release support hybrid ML-KEM in TLS 1.3?
• Can the product be configured to reject quantum-vulnerable key exchange instead of falling back to it?
• Will the vendor supply cryptographic inventory data, ideally a CBOM, for the product?
• What happens to keys and encrypted data if the vendor is acquired or leaves the market?

The answers go into a vendor dependency register that the provider keeps current, since its own roadmap dates depend on them.

Where the Services Revenue Is

Some vendors are already telling their channel partners where the money is. When Keyfactor expanded its partner program in July 2026, its Louise McEvoy told ChannelE2E that “the strongest MSP/MSSP opportunity is not a one-time quantum assessment” and that the goal is for providers to stay on as the client’s continuous manager of machine identities and cryptography. Keyfactor sells the platform for that continuous work, so its view isn’t neutral. It is still right.

What Y2K Did for Indian IT Services Firms

The closest economic parallel I know is Y2K. In the late 1990s, a large share of the code remediation work moved to Indian IT firms, and it changed their business. Cognizant’s R. Chandrasekaran told Business Today in 2009 that “Y2K was a defining moment. It was an inflection point for the Indian IT industry.” The same article credits Y2K with moving those firms beyond supplying staff to fill client skill shortages, with opening relationships across industries that grew into application services and outsourcing, and with laying the foundation for offshoring. By the magazine’s count, India’s IT exports grew twelvefold, to $47 billion, over the following decade, and Infosys, Wipro, TCS and Cognizant became global players. Y2K didn’t cause all of that growth, but the remediation work gave those firms the client relationships and delivery credibility that the later work grew from.

The comparison has limits, and I’ve written about where Y2Q differs from Y2K. Y2K had one conspicuous common deadline, 1 January 2000. PQC has a dozen regulatory dates and a threat date nobody can fix, and no moment when the work is finished. The goal is crypto-agility, with PQC migration as its first test. Those differences strengthen the services case. A remediation project that becomes a permanent capability is worth more to a provider than one that ends at midnight.

Consultancies and Systems Integrators

For consultancies and integrators, the work that stays valuable is the work that needs judgment and engineering:

• Discovery beyond the network scan. Cryptography appears in source code, binaries, configuration files, libraries, HSMs, cloud key management services and vendor products. A network scan sees the part that answers on a port. Clients need help choosing discovery tools and methods, combining their output and deciding when the inventory is good enough for the decisions it has to support.
• Prioritization. Ranking systems by data lifetime, exposure, dependency on long-term signatures and regulatory deadlines is consulting work that clients will pay for if it produces a defensible order of migration.
• Regulatory mapping across jurisdictions. A bank that operates in the EU, the UK, the US and Singapore faces different dates, definitions and evidence expectations for the same systems, and the national programs are diverging. Turning them into one plan with one set of evidence is advisory work that clients already buy for other regulation.
• Program design and management. A migration with tens of thousands of tasks needs a program office, a funding model and board reporting. My articles on who should lead the migration and on board oversight cover what clients will expect.
• PKI and signing redesign. Internal certificate authorities, code-signing services and device identity schemes will need redesign, not just new algorithms.
• Application and infrastructure remediation. Replacing cryptographic libraries, retiring TLS 1.2 dependencies and fixing infrastructure that can’t take larger keys and handshakes is engineering work that integrators already know how to staff and price.

Assessments are turning into standard catalog items. Kyndryl launched a Quantum Safe Assessment in December 2025 that produces a cryptographic bill of materials and a roadmap, and it is aimed at enterprises and at the MSSPs and MSPs that support them. The NCSC’s pilot list puts global integrators (Capgemini, CGI, IBM) next to specialists (Arqit, PQShield). The premium for advice is highest while clients are still deciding whether, when and how to act. Once supervisors fix the requirements, assessments become procurement line items and competition moves to price. Smaller consultancies will be squeezed from both directions if they compete on assessments alone. I’d price the assessment as the entry to a program and build the practice on engineering depth in PKI, protocols and application cryptography, which is much harder for competitors to copy. A consultancy has to fund that depth before it earns anything from it: a senior core, methods, a lab and training, approved by partners who will ask when the first program will arrive.

MSSPs and MDR Providers

MSSPs already collect much of the data a PQC program needs and run several of the systems it has to change:

• Continuous cryptographic posture management. Network metadata, certificate inventories, vulnerability scans and asset records together show which key exchange groups, protocol versions, certificate algorithms and key sizes each service uses. Tracked over time, that becomes a posture report a client’s risk committee can use. The next section explains what such monitoring can and can’t show.
• Managed certificate lifecycle. Public certificate lifetimes fall from 200 days today to 100 days in March 2027 and 47 days in March 2029. Manual renewal stops working well before 2029. The automation clients need for that schedule is the same automation they need to change algorithms later, so a provider that manages certificates is building crypto-agility whether or not it sells it under that name.
• Crypto-agility as a managed service. Algorithms and implementations will keep changing after the first migration, as NIST adds backup schemes and researchers find flaws in implementations. A provider that tracks those events across its clients’ estates and rolls out the change when one arrives has a service that continues after the migration ends.
• Managed network and SASE upgrades. Post-quantum IPsec, hybrid key exchange on both legs of inspection and the retirement of VPN concentrators and appliances that will never support PQC are upgrade projects inside existing managed contracts.
• Evidence for supervisors and auditors. PCI DSS 12.3.3 already requires an annual review of cipher suites and protocols. NIS2, banking supervisors and EO 14412’s inventory requirements add more. A provider that produces the evidence as part of its service saves its clients an annual scramble. For a bank, though, a provider’s evidence about its own work isn’t independent assurance, so supervisors will still expect testing by someone else.
• Vendor tracking across clients. One provider that tracks the PQC roadmaps of 300 products can share that research across 50 clients, although deployed versions, configurations and contract terms stay client-specific. Few clients can match that efficiency internally.

MSPs Serving Smaller Organizations

For a 40-person accounting firm or a regional medical practice, most of PQC will arrive in software updates: operating systems, browsers, Microsoft 365 or Google Workspace, cloud services and firewall firmware. The MSP’s job is to keep those systems on supported versions, replace end-of-life VPN and firewall appliances, automate certificates, choose vendors with published roadmaps and keep a simple record of where cryptography is used. Selling a bespoke quantum audit to a small client is poor value for the client and poor positioning for the MSP. The exception is a small client whose sensitive data has a long shelf life, such as a law firm with merger files or a clinic with patient records, which deserves a short harvest-now, decrypt-later review of how its files move between offices, cloud services and backup providers, and of how their encryption keys are exchanged.

Summary by Provider Type

What a SOC Can and Cannot Monitor

A security operations center can’t reliably recognize the quantum threat itself. Harvesting is passive and usually happens on network paths the client doesn’t control. Decryption happens years later, offline, on the attacker’s hardware. A signature forged with a future quantum computer passes cryptographic verification, so the SOC would see only what the attacker does with it. The SOC can still detect the compromises and misuse around those events, such as unauthorized traffic capture or exfiltration. A product that claims to “detect quantum attacks” should say exactly which observable behavior it detects, and the ones that can’t belong in my quantum snake oil dictionary.

Downgrade attacks need a careful explanation, because they are easy to misdescribe in PQC service proposals. In TLS 1.3, the server signs the handshake transcript in its CertificateVerify message and both sides confirm it in their Finished messages (RFC 8446). An attacker in the network path who strips the ML-KEM share from a client’s offer breaks the handshake instead of downgrading it, as long as the attacker can’t forge that signature. Once an attacker can forge the classical signatures a client still accepts, a downgrade becomes unnecessary, because the attacker can impersonate the server outright. Migrating key exchange doesn’t finish the job without migrating authentication. Cloudflare’s guidance on EO 14412 also recommends defining “transition” to include disabling classical-only fallback. Turning fallback off stops sessions from negotiating quantum-vulnerable key exchange once both ends support something better. It is a policy change, made for one service at a time when the client population allows it. The SOC’s job is to measure how close each service is to that point.

Here is what a SOC can usefully monitor today:

• Negotiated key exchange groups per service and per client population, for example X25519MLKEM768 against X25519, so the client can see which services still negotiate classical key exchange and why.
• TLS version mix. TLS 1.2 connections can’t use the hybrid groups standardized for TLS 1.3, so they mark services that need upgrades before they can migrate.
• Certificate signature algorithms, key sizes, lifetimes and issuing CAs, collected from certificate managers, endpoints and active scans, because TLS 1.3 encrypts certificates in transit and a passive sensor can’t read them. This data feeds the certificate automation work and, later, the move to post-quantum signatures.
• SSH key exchange. OpenSSH 10.1’s client warning makes classical SSH sessions visible to the people who open them. The current OpenSSH source also logs a server-side warning for connections that don’t use a post-quantum key exchange, while the negotiated algorithm name itself appears only in debug-level logs.
• IPsec and IKE proposals on managed VPNs.
• Regressions. A firmware update, a failover to an older cluster or a new vendor appliance can quietly reintroduce classical key exchange on a service that had moved.

Getting that data is engineering work. Offered, configured, negotiated and required are different states, and a dashboard shouldn’t let one stand in for another. Sensors and proxies have to log the group the server selected, not just the groups the client offered, and some don’t yet. In July 2026, users of F5’s BIG-IP were still asking for the load balancer to log the negotiated post-quantum key exchange. The workaround offered in that discussion “guesses” the result from the client’s offer and is reliable only “assuming your cipher group lists it and no HelloRetryRequest occurred.” The same reply points to aggregate PQC counters, so the gap is per-connection logging, not all visibility. Every provider should audit its own telemetry sources the same way before promising a client a post-quantum dashboard.

Routine coverage figures belong in migration and risk reporting. An unexpected regression on a flow that is required to use post-quantum protection should follow the client’s normal incident and change thresholds, like any other loss of a required control.

Selling PQC Without Q-FUD

The quickest way for a provider to lose credibility on PQC is to repeat timeline claims without checking what they say and how certain they are. In April 2026, Palo Alto Networks published a sponsored piece on MSSP Alert, The 2026 MSSP Blueprint: Navigating the Quantum Countdown, written by Tyler Murphy, director of its MSSP program. Much of its advice is sensible: start with discovery, build a cryptographic bill of materials, enforce policy continuously. It also says that “Gartner projects that quantum computing will render current encryption obsolete by 2029.” The Gartner research note it links to, published in February 2025, says that quantum computing “continues to advance with expectations that it will break public key cryptographic algorithms by 2029.” That is already a more aggressive date than the forecast I wrote about in October 2024, when Gartner said traditional cryptography would be “unsafe” by 2029 and fully breakable by 2034. Neither public summary shows the analysis behind the dates. On its way into the blueprint, an analyst’s expectation about public-key algorithms became a statement about “current encryption,” which also covers the symmetric encryption that quantum computers aren’t expected to break at today’s key sizes. A client CISO who follows the link will notice the difference and start checking everything else in the deck.

That’s the quantum panic industry at the scale of a single sales slide, and it fails twice. Clients who believe it buy the wrong things in a hurry. Clients who don’t believe it stop listening to the provider on everything else. The opposite error is just as expensive. A provider that tells clients quantum computing is decades away, or that “our clients aren’t asking,” will find out at a renewal that a competitor answered the client questions listed earlier in this article.

The position I’d take with clients is the one I take on this site. A cryptographically relevant quantum computer is a serious, long-term threat to today’s public-key cryptography. Its arrival date is uncertain. Published obligations and targets already set the planning dates. Harvest-now, decrypt-later collection is a present risk for data with a long shelf life, and migration takes years. A provider can sell honestly on four things:

1. The client’s obligations, with dates, from the table at the top of this article.
2. The lifetime of the client’s data, which decides how much harvest-now, decrypt-later exposure it has today.
3. The client’s dependencies on vendors and providers, including the provider making the pitch.
4. The provider’s own readiness, shown in writing.

Two more rules help. Don’t call a product or service “quantum-safe” because it negotiates hybrid key exchange; authentication, fallback and key storage decide whether a system is protected. And don’t make quantum key distribution a default managed-service upsell. QKD has a place in national programs and research networks, and I support continued investment in it. But I wouldn’t trust a client’s critical systems to it today.

Building the Capability

People. Most providers won’t be able to hire enough cryptographers, so they will have to build the practice from people they already employ. PKI administrators, network engineers who run VPNs and inspection, application security staff and GRC consultants all hold part of the skill set. The work spans cryptography, protocol engineering, enterprise architecture, regulation and large-scale program delivery, and no single hire covers all of it. A provider needs a small core of people who understand the algorithms and protocols in depth, and a much larger group trained to find, change and test cryptography in the systems they already manage. The third group is external: specialists the provider can call in for algorithm evaluation, threat timeline questions and the hardest client situations, without paying for them full time.

Method. Providers don’t need to invent a methodology. The NCSC’s guidance, NIST’s transition documents and open frameworks are available. My PQC Migration Framework is published under a Creative Commons license, and providers can use it or adapt it, with the minimum viable inventory as the starting point. Whichever method a provider picks, it should be written down and repeatable, because clients and assessors will ask for it.

Tooling. The discovery tool market is crowded and consolidating, and each tool sees a different part of an estate. A provider that builds its service on one tool inherits that tool’s blind spots and its vendor’s roadmap. The output format will also matter. EO 14412 requires CISA to publish the minimum elements of a cryptographic bill of materials by March 2027, and I expect clients to want providers’ discovery work to be compatible with them. A product CBOM that lists the algorithms a product can use won’t show what a running service negotiates, where plaintext exists or which configuration a tenant runs, so a provider’s inventory has to cover both. In the interest of disclosure, Applied Quantum has published a CBOM profile at cbomprofile.org, open for public comment until 31 October 2026.

Assurance. Where a government scheme is accepting applications, apply. The NCSC pilot has closed expressions of interest and is expected to run until 31 March 2027, and the NCSC says pilot firms aren’t guaranteed full membership of the scheme afterwards. Providers outside it can prepare against the standard the NCSC published for the pilot and watch for its successor. Assurance of consulting services doesn’t certify a provider’s products or show that its own estate has migrated. I expect other national cyber agencies and some financial supervisors to create similar lists, because the organizations they oversee will need a way to choose providers for this work.

Contracts. Managed services agreements written in 2026 should cover cryptography explicitly. That means the provider’s obligation to support named algorithms by fixed dates, notice periods for algorithm changes, delivery of a CBOM for the managed services, responsibility for the cost of replacing appliances and HSMs, reporting on post-quantum status, and the handling of keys and certificates at exit. A promise to “support ML-KEM” is weak on its own. For each managed service, the contract should say what is supported, what is enabled, what has been observed in use and what is enforced. It should also say which release, operating mode, client population and connection segments the evidence covers, and which of those states counts as delivery. Clients’ lawyers will start asking for these clauses. Providers that draft them first get to set reasonable terms.

A Twelve-Month Plan for a Security Provider

For a provider starting in the last quarter of 2026, the order I’d follow is:

1. Inventory your own services first. List every place where you terminate, inspect, sign, store or transmit client data or keys: inspection proxies, VPNs, log pipelines, agents, remote access, certificate services and HSMs. Record the key exchange and signature algorithms each one uses today.
2. Fix or document TLS inspection and VPNs. For every tenant, record the release, the legs that negotiate hybrid ML-KEM, the operating mode and the flags. Upgrade where you can and write down the exceptions with dates.
3. Publish your own PQC roadmap. Give dates for key exchange, signatures on agents and updates, and HSM and key management changes, and map them to your clients’ deadlines in the US, the EU, the UK and their sectors. Send it to clients before their questionnaires arrive.
4. Update your contract templates with the cryptography clauses described above.
5. Build posture telemetry from data you already collect. Make sure your sensors log negotiated groups, then report trends per client and alert on regressions.
6. Package discovery as the start of a program. Sell a minimum viable inventory with prioritization and a funded plan, not a scorecard.
7. Train the people you have. Start with PKI, network and application security staff. Give them a lab where they can break and fix hybrid deployments.
8. Choose tool partners deliberately. Test vendors’ claims against primary sources, avoid single-tool dependence and make sure you can export the data in an open format.
9. Pursue assurance where a scheme is open and prepare against the NCSC’s published standard where it isn’t. Keep the evidence of your own migration ready for clients’ auditors.

A provider can take all of these steps before a quantum computer exists, and each of them improves its position in renewals that will happen before 2030.

Which Providers Clients Will Trust With Cryptography

The NCSC’s pilot is expected to end on 31 March 2027, and I think other buyers will draw up their own lists over the same period. By 2030, I expect most large clients to have chosen a small number of providers to trust with their cryptography, the way they chose cloud providers in the 2010s. The firms on those lists will be the ones that inventoried and fixed their own services first and did the PKI, signing and legacy work that platforms don’t do for free. They will also have sold to their clients’ obligations instead of their fears. The contracts that decide those lists are being negotiated now.

From the author