--- title: "PQProbe Vendor Analysis: Where 100 Cybersecurity Vendors Actually Stand on Post-Quantum TLS" description: "PQProbe v3.7.5 Enterprise Edition measured 100 cybersecurity vendors. 67 apexes negotiate post-quantum key exchange, but 79.8% of that lives behind third-party edges while only 23.5% lives on first-party infrastructure. A census of the Cyber 100." pubDatetime: 2026-09-17T10:00:00Z author: hrbrmstr tags: ["post-quantum", "tls", "cybersecurity", "pqprobe", "research"] --- > Original: [PQProbe Vendor Analysis: Where 100 Cybersecurity Vendors Actually Stand on Post-Quantum TLS](https://ai.rud.is/posts/2026-09-17-pqprobe-vendor-analysis-where-100-cybersecurity-vendors-actually-stand-on-post-quantum-tls) > Original: [What 100 security vendors' TLS endpoints say about post-quantum readiness: the edge is ready, the origin is not](https://ai.rud.is/posts/2026-09-16-cyber100-pqprobe) Hotter-ish on the heels of the [TLS and DNS census](https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec) and the [llms.txt census](https://ai.rud.is/posts/2026-09-04-cyber100-llms-txt-census), we're running the same 100 vendors through a different instrument. This time it's a vastly improved [PQProbe](https://pqprobe.com/) (v3.7.5 Enterprise Edition specifically), a multi-protocol scanner that grades TLS endpoints A through F, checks them against eight compliance profiles, and tells you whether an endpoint is genuinely ready for post-quantum cryptography or just performing readiness. The tool's author is [Davi Ottenheimer](https://www.flyingpenguin.com/about/), whose background is in binary analysis and virtualization security – which is a woeful understatement of his range; [he's written for The Atlantic](https://www.theatlantic.com/technology/archive/2023/09/robot-safety-standards-regulation-human-fatalities/675231/), after all. Davi provided an evaluation copy for this census, and the grading thesis and compliance verdicts below are faithfully his. If you run infrastructure and care about PQC, PQProbe is worth a serious look. It does considerably more than the single-profile prober from last week's census (which was a different tool, written by a completely different person). Davi's PQProbe uses a matrix of client offers, records what each address accepts, grades the result, and checks it against multiple compliance frameworks. ## TL;DR 67 of 100 vendor apexes negotiate a hybrid post-quantum group. But 79.8% of port-443 endpoints behind third-party edges (CDNs, cloud front doors) negotiate PQC, against only 23.5% of endpoints on the vendors' own infrastructure. The vendors are renting post-quantum readiness from their edge providers, not deploying it themselves. 78 vendors graded D or F still negotiate a hybrid group somewhere in their footprint. Only five vendors' worst apex grade is A or B, and four apexes still accept TLS 1.0 and 1.1. The post-quantum future apparently lives at the edge, while the origin is still catching up _(which is not an endorsement of centralizing internet infrastructure at morally questionable companies, please)_. ## What are we actually checking for? [**Post-quantum key exchange.**](https://en.wikipedia.org/wiki/Post-quantum_cryptography) An attacker recording TLS traffic today can derive the session key later once a capable quantum computer exists. The fix is a hybrid key exchange group that mixes a classical curve with [ML-KEM](https://en.wikipedia.org/wiki/ML-KEM), so breaking one session requires breaking both algorithms simultaneously. PQProbe dials each host with multiple client profiles and records what the server accepts – not just one group, the whole negotiation matrix. It also grades each endpoint A through F against its own scoring model, where fatal conditions rightfully zero the score. The grade measures post-quantum readiness, not classical TLS hygiene. Please don't conflate the two. The tool checks against eight compliance profiles: BSI, FIPS, NIST, PCI DSS, HIPAA, GDPR/ENISA, Google, and Mozilla. Each profile has its own rules about TLS versions, cipher suites, certificate properties, and post-quantum support. A single scan can pass one profile and fail another – which is why the compliance matrix runs 3,008 verdicts deep. ## Test harness The targets are the same 100 domains as the two earlier censuses (censae?), the University of San Diego's Cyber 100 list – which, by the way, (again) really needs to drop `threatstack.com` since it stopped resolving after the F5 acquisition. PQProbe ran on a dedicated scanner host on 2026-09-16. The collection driver was serialized so only one invocation held the SQLite database at a time; concurrent opens cause silent WAL fallback and lost scans (and I wasn't in a hurry, so didn't waste time parallelizing the runs). Two commands per target: ```bash pqprobe --db pqprobe.db probe --sensitivity 0 --output json pqprobe --db pqprobe.db scan www. --sensitivity 0 --output json ``` The `probe` command covers the apex at port 443 and follows MX records to measure mail exchangers at port 25. The `scan` command covers the `www` name where the list has one. 376 completed scans across 312 distinct hosts. Raw output, analysis SQL, the frozen claims table, and driver scripts are at [rud.is/git/cyber100-pqprobe](https://rud.is/git/cyber100-pqprobe) – data under CC BY 4.0, scripts under MIT. ## Results | Post-quantum coverage | Count | Examples | |---|---:|---| | Every endpoint negotiates hybrid | 18 | cloudflare.com, boozallen.com, bugcrowd.com, hackerone.com, imperva.com, knowbe4.com, lockheedmartin.com, rapid7.com | | Mixed across endpoints | 67 | the large CDN-fronted household names | | No endpoint negotiates hybrid | 14 | cofense.com, f5.com, forcepoint.com, fortinet.com, deepinstinct.com, guidancesoftware.com | | Nothing to measure | 1 | threatstack.com | | Grade (worst apex) | Count | Examples (names from the OG list) | |---|---:|---| | A | 2 | northropgrumman.com, www2.deloitte.com | | B | 3 | boozallen.com, cybersecurity.att.com, lockheedmartin.com | | C | 3 | (three vendors) | | D | 52 | (the majority) | | F | 39 | cisco.com, cloudflare.com, cofense.com, splunk.com | | Control: prior TLS census vs PQProbe | Count | |---|---:| | Agree on hybrid | 67 | | Agree on classical | 31 | | Disagree | 0 | | No prior measurement (due to acquisitions) | 2 | About two-thirds of the apexes negotiate a hybrid group. Across every endpoint the census touched – apexes, `www` names, mail exchangers – 217 of the 376 scans negotiated one. Eighteen vendors negotiate post-quantum key exchange on every endpoint they own or rent, apex and mail included. Sixty-seven are mixed: the front door is hybrid but the mail exchanger isn't, or the apex is and the `www` name trails. Fourteen show no post-quantum group anywhere. The mixed bucket is mostly household names whose public-facing properties sit on large CDNs, but whose mail – terminated by Google Workspace, Microsoft 365, or Proofpoint – negotiates only classical groups. Post-quantum readiness at a given cybersecurity vendor is, as of this census's date, a property of which providers the vendor buys/rents from, not anything the vendor deliberately configured. ## The control The negotiated group at each apex was cross-checked against the independent measurement from the earlier TLS census, which used a different tool from a different author. They agree on 98 apexes (two are problematic due to acquisitions) and disagree on none: 67 both call hybrid, 31 both call classical. This verification pass also spot-checked protocol claims at the apexes with nmap – a third, separate implementation – and all 14 sampled checks agreed. ## Grade ≠ hygiene PQProbe grades post-quantum readiness, not classical TLS hygiene, and a single fatal condition zeroes the score. A good grade isn't required for at least the appearance of post-quantum capability. 78 vendors whose worst grade is D or F still negotiate a hybrid group somewhere in their footprint. Cloudflare's own front door is the canonical example: `cloudflare.com:443` accepts TLS 1.0 and TLS 1.1 (verified with nmap), which zeros the grade to F. In the same session, the same endpoint negotiated a hybrid ML-KEM group. Readiness and hygiene are on separate tracks, and the industry is ahead on one and embarrassingly behind on the other. I'll let you guess (or review the data to see) which is which. ## Edge versus origin The census terminates each host to a network operator by walking the CNAME chain, resolving addresses, and looking up each address's operator in `whois`. Classification is first-party when the terminating operator contains the vendor's own registrable label – `cisco` in Cisco's `aer-mx-01.cisco.com`, `akamai` in Akamai's own front door – and third-party otherwise. Nothing landed in an undetermined bucket; all 376 endpoints resolved to an operator. Of those 376 endpoints, 340 terminated on third-party infrastructure and 36 on the vendor's own. Post-quantum follows the edge almost entirely. Of 217 hybrid-negotiating endpoints, 209 sit behind third-party operators and 8 on first-party infrastructure. Holding port constant at 443, where the classification is cleanest: 142 of 178 third-party-terminated endpoints negotiated a hybrid group (79.8%), against 4 of 17 first-party endpoints (23.5%). Seventeen is a thin denominator – most vendors' front doors terminate on CDNs or cloud front-ends, so 23.5% is a direction, not a precise rate. Mail reinforces the direction. Of 181 mail-exchanger endpoints, 71 (39.2%) negotiated a hybrid group, and mail exchangers are almost by definition third-party provider infrastructure. That's why the edge-versus-origin comparison above holds port constant rather than pooling everything together. So, edge providers shipped post-quantum by default across their fleets, and the vendors inherited it the day their traffic started riding through them. The vendors' own origins – the machines they actually operate – mostly didn't. ## Certificates and compliance Observed leaf certificates span 36 distinct issuers. The compliance module grades each scan against eight profiles and records a verdict per endpoint. These are PQProbe's opinions about the observed endpoints on 2026-09-16, with the profile named and the tool version attached – not the census's judgments, and certainly not an audited assessment. In total: 3,008 verdicts across 376 scans, and 52 apex scans carried at least one Not Ready verdict at port 443. The full matrix is in the published data, profile by profile, endpoint by endpoint. ## What this singular pass can't show A single pass on a single day can't show trajectory. This census says what 100 vendors' endpoints looked like on 2026-09-16 – it says nothing about whether any of them are moving, because movement requires repeat scans. None of the numbers above carry a trend claim. Other bounds: probes were issued from one vantage point, so geography-sensitive answers and anycast skew are out of scope. Each name was observed once. Multi-address targets were scored fully on 459 addresses and probed briefly on 694, per the tool's multi-address handling, so an endpoint behind a large rotating pool carries less weight than its single-address neighbor. And the census can't see Encrypted Client Hello at all – the tool doesn't observe it. ECH coverage remains what the earlier census measured; nothing here updates it. ## Vendor configurations that need work Each item below is checkable from fresh probes: - **cisco.com caps at TLS 1.2.** Both addresses answer a TLS 1.3 ClientHello with a TLS 1.2 server hello, putting hybrid ML-KEM out of reach at a network security vendor. Grade: F. The zone is also unsigned – no DS, no DNSKEY. One out of three isn't great. (`www.cisco.com` does support TLS 1.3.). I [loaded this up in the PQ Dashboard](https://pqprobe.com/app?scan=336a6043-d032-45d9-9dce-d64a59ba6883) earlier today. - **trendmicro.com accepts only P-384.** Every profile gets a handshake failure alert. Per-group apex dials show P-384 completing while X25519, P-256, P-521, and all hybrid groups are declined. - **cloudflare.com accepts TLS 1.0 and 1.1.** Grade: F. The same endpoint negotiates hybrid ML-KEM in the same session. `o_o` - **splunk.com accepts TLS 1.0 and 1.1, and caps at TLS 1.2 on some paths.** Grade: F, no hybrid group at the apex. - **11 names cap at TLS 1.2.** Accenture, Cisco, Guidance Software, McAfee, Nexusguard, One Identity, Ping Identity, Splunk, Thycotic, and VMware. One well-known network security vendor on that list answers a TLS 1.3 ClientHello with a TLS 1.2 server hello on both of its addresses. - **14 vendors show no post-quantum group on any endpoint.** Cofense, F5, Forcepoint, Fortinet, Deep Instinct, Digital Defense, Guidance Software, Mimecast, Mitre, Radware, RiskIQ (an acq.), Telos, Thycotic, and Kaspersky's US site. Some are TLS 1.2 caps, some are classical-only groups, some just don't offer the hybrid. ## What true "security" vendors should actually do 1. **Offer hybrid groups on your own 443s.** The CDN is doing the work for you at the edge. Your origin servers aren't. X25519MLKEM768 is the group to add first. 2. **Retire TLS 1.2.** Eleven names on this list still cap there, and post-quantum key exchange requires TLS 1.3. A TLS 1.2 endpoint can't reach hybrid ML-KEM. Full stop. 3. **Retire TLS 1.0 and 1.1.** Four apexes still accept them. That's a fatal condition in PQProbe's scoring model, deprecated by RFC 8996, and a PCI DSS violation. 4. **Ask your mailbox provider for their ML-KEM timeline.** 39.2% of mail endpoints in this census already negotiate a hybrid group. If your provider is in the 60.8% that doesn't, that's a procurement conversation worth having. 5. **Run PQProbe against your own endpoints.** Davi built something that measures what actually happens at the wire, not what your config file says should happen. The compliance profiles alone are worth the price of admission. [pqprobe.com](https://pqprobe.com/) *Source data and scripts: [rud.is/git/cyber100-pqprobe](https://rud.is/git/cyber100-pqprobe)* ```json [ { "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://ai.rud.is/posts/2026-09-17-pqprobe-vendor-analysis-where-100-cybersecurity-vendors-actually-stand-on-post-quantum-tls", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://ai.rud.is/posts/2026-09-17-pqprobe-vendor-analysis-where-100-cybersecurity-vendors-actually-stand-on-post-quantum-tls" }, "headline": "PQProbe Vendor Analysis: Where 100 Cybersecurity Vendors Actually Stand on Post-Quantum TLS", "datePublished": "2026-09-17T10:00:00Z", "description": "PQProbe v3.7.5 Enterprise Edition measured 100 cybersecurity vendors. 67 apexes negotiate post-quantum key exchange, but 79.8% of that lives behind third-party edges while only 23.5% lives on first-party infrastructure. A census of the Cyber 100.", "url": "https://ai.rud.is/posts/2026-09-17-pqprobe-vendor-analysis-where-100-cybersecurity-vendors-actually-stand-on-post-quantum-tls", "keywords": [ "post-quantum", "tls", "cybersecurity", "pqprobe", "research" ], "author": [ { "@type": "Person", "name": "hrbrmstr", "url": "https://rud.is" } ], "publisher": { "@type": "Organization", "name": "hrbrmstr", "url": "https://ai.rud.is/", "sameAs": [ "https://mastodon.social/@hrbrmstr", "https://bsky.app/profile/hrbrmstr.bsky.social", "https://github.com/hrbrmstr", "https://sr.ht/~hrbrmstr" ] } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "item": { "@id": "https://ai.rud.is/", "name": "ai.rud.is" } }, { "@type": "ListItem", "position": 2, "item": { "@id": "https://ai.rud.is/posts/2026-09-17-pqprobe-vendor-analysis-where-100-cybersecurity-vendors-actually-stand-on-post-quantum-tls", "name": "PQProbe Vendor Analysis: Where 100 Cybersecurity Vendors Actually Stand on Post-Quantum TLS" } } ] } ] ```