Empirical Assessment of Post-Quantum Cryptography Adoption Status in TLS

Empirical Assessment of Post-Quantum Cryptography Adoption Status in TLS Md Ariful Haque(#) , Sander Vinberg, Ben Edwards, João Cruz

arXiv:2611.09707v1 [cs.CR] 6 Nov 2026

Bitsight Technologies, Boston, MA, USA {mdariful.haque, sander.vinberg, benjamin.edwards, joao.cruz}@bitsighttech.com

Abstract—Anticipating Q-day security concerns, major CDNs and cloud providers are migrating to post-quantum cryptography (PQC). While existing literature benchmarks PQC performance, empirical research evaluating real-world adoption data remains scarce. We present an empirical assessment of PQC deployment across seven critical protocols (HTTPS, LDAPS, SMTPS, IMAPSSL, POP3-SSL, TELNETS, and RDP) using 10,000 target IP addresses per protocol. At the origin-server level, PQC algorithm support reaches 9.1% for HTTPS and 7.39% for LDAPS, while falling below 1% for all other evaluated protocols. At the entity level, PQC support is 11% for HTTPS and 5.4% for LDAPS, while the remaining protocols have less than 5% of entities supporting PQC on the hosted servers. We further correlate these adoption trends against organizational digital and financial footprint, and industry sectors, yielding a multi-dimensional empirical assessment of PQC deployment. Finally, at the domain level, we perform a comparative analysis of PQC adoption in Cloudflare-hosted domains against baseline Cloudflare datasets. Collectively, our findings provide critical insights into the current state of PQC readiness over Transport Layer Security (TLS). Index Terms—Post-Quantum Cryptography, Cybersecurity, Encryption Algorithms, TLS1.3, MLKEM, HTTPS, LDAPS, Empirical Analysis.

I. I NTRODUCTION Transport Layer Security (TLS) relies on classical publickey algorithms (such as Diffie-Hellman, Elliptic-Curve cryptography, or RSA) that will eventually be broken by sufficiently powerful quantum computers [1]. To prevent attackers from exploiting “harvest-now, decrypt-later (HNDL)”, large content delivery networks (CDNs) are already adopting PQC. In October 2025, Cloudflare claimed that “over 50% (and rising!) of human traffic is protected against store-now/decryptlater, making post-quantum key agreement the new security baseline for the Web” [2]. Also, Google has announced a 2029 timeline to secure the quantum era with post-quantum cryptography migration [3]. Thus, it is high time to conduct a data-driven empirical analysis of PQC readiness across TLS to assess PQC adoption status and trends. For the assessment of PQC readiness, we focus specifically on the TLS protocol due to its ubiquitous role in securing modern network communications and information exchange. Crucially, PQC algorithm support is exclusive to TLS version 1.3, as legacy versions (e.g., TLS 1.1 and TLS 1.2) lack the native architecture required for post-quantum key encapsulation mechanisms. In this work, we investigate the real-world PQC adoption status across seven prominent secure services running over TLS, categorized by their operational domains:

web traffic via HTTPS (port 443); directory services via LDAPS (port 636); mail delivery and retrieval infrastructure via SMTPS (port 465), IMAP-SSL (port 993), and POP3-SSL (port 995); and remote administration protocols via TELNETS (port 992) and RDP (port 3389). In the current state of the art, several studies highlight the need for PQC readiness in enterprise networks [4], [5]. In a recent study, Mallick et al. [6] surveyed nine widely deployed protocols for PQC adoption feasibility — TLS, IPsec, BGP, DNSSEC, SSH, QUIC, OpenID Connect, OpenVPN, and the Signal Protocol. For each protocol, they provided cryptographic reliance, post-quantum migration efforts to date, and the challenges that still remain. Demir et al. [7] provide a performance study of CRYSTALS-Kyber and CRYSTALSDilithium by benchmarking execution times across cryptographic operations such as key generation, encapsulation, decapsulation, signing, and verification, and assessing hardware acceleration benefits. Hanna et al. [8] analyzed the viability of Post-Quantum algorithms in TLS to power-constrained IoT devices, focusing on two widely used IoT network protocol stacks (Bluetooth Low Energy (BLE) and Wi-Fi). Additionally, Sowa et al. [9] present PQC adoption rates on TLS and SSH, but the study seems outdated, as it only presents the occurrence of the SNTRUP761 algorithm and does not present the occurrences of the MLKEM algorithm, which is the NIST standard PQC algorithm and is mostly used in TLS. These researches focus on operational challenges and performance evaluation of the PQC algorithms, but there is very limited research on the status of real-world PQC adoption. In this work, we present the PQC adoption status on seven secure protocols mentioned above at the server-level as well as entitylevel. Within the scope of this report, we looked into several research aspects: 1) PQC adoption at the level of both origin servers as well as entities for each of these protocols, 2) PQC adoption at the domain level, and 3) Variation in PQC support by organizations’ industry, revenue, employee size, and digital size (e.g., IPv4 count, etc.). To note here, we use the term ‘origin server’ or ‘host’ to represent a unique IP address that hosts the specified service, and the term ‘entity’ to represent an organization that hosts that IP address. Sometimes we use the term ‘service’ instead of ‘protocol’ interchangeably for the above seven specified protocols, as these are also considered services. The significant contributions of this work are as follows:

i) Discussion on PQC algorithms fingerprinting process on TLS, ii) Origin server-level and domain-level PQC adoption assessment, along with comparative analysis, and iii) Entity-level PQC adoption status based on several digital size and financial metrics, as well as industry sector. Thus, generating key insights on the current PQC adoption trends. We organize the rest of the paper as follows. Section II discusses the data collection and processing methods of PQC algorithm for the specified services. Section III is the hostlevel PQC adoption analysis, followed by the entity-level PQC adoption analysis in Section IV. Section V provides comparative analysis on Cloudflare-hosted IPs and domains. Finally, Section VI concludes the paper. II. DATA C OLLECTION & P ROCESSING In this section, we present the data collection and processing methodologies of PQC key exchange (KEX) algorithms pertinent to the selected protocols in TLS. We provide the details below. A. Scan Target List Bitsight has built an in-house internet scanning platform called GROMA that maintains a continuous global survey of the public-facing Internet. More details are available here [10]. We use GROMA data to create a list of 10,000 IPv4 addresses per port for the seven selected services to conduct a limited scan. We then utilize OpenSSL (v3.5) for fingerprinting the TLS handshake messages and use an in-house developed tool to perform a large-scale scan on the selected target list. We use an authorized GCP (Google Cloud Platform) instance to perform the scan. B. KEX Algorithm Extraction From TLS Handshake Several resources [11], [12] explained the TLS handshake processes in detail. Essentially, the core of the TLS handshake is the ‘ClientHello’ and ‘ServerHello’ messages, where at first the client initiates the negotiation process by sending a message to the server with its supported TLS versions, a client random number, and a list of supported cipher suites or cryptographic algorithms. The server then responds with its chosen TLS version, a server random number, a digital certificate, and the specific cipher suite it selected. The response message sent by the server includes the key exchange algorithm it selected for the specific TLS communication. We extract the negotiated algorithm from the TLS handshake message traces, incorporating custom-made RegEx expressions in our extraction logic. The extraction process looks into phrases like “Negotiated TLS1.3 group” and “NamedGroup” within the “ServerHello” message and captures the associated algorithm from the TLS handshake message traces. C. Entity Mapping and Firmographic Data Next, we map the scanned IP addresses to entities to perform entity-level analyses. The entity mapping process maps the

entity IDs corresponding to the IP addresses or domains, where each entity is a real-world organization. The mapping process relies on the use of an AI-powered asset mapping and attribution engine called ‘GIA’. More details on the entity mapping process and GIA are available here [13]. We collect firmographic data (i.e., revenue and employee count) from our service providers. We also leverage the digital metrics data (e.g., IPv4 count and distinct TLS-enabled host count known as ’SSL Active Count’) from different internal data pipelines. Next, we discuss the main analyses on the assessment of PQC adoption status on the selected protocols. We divide the discussion into two broad sections: server-level analysis III and entity-level analysis IV. III. S ERVER -L EVEL PQC R EADINESS A NALYSIS This section provides details of the server-level PQC status. We divide the analyses into several subsections: 1) PQC KEX proportions per service, and 2) Proportions of all observed KEX algorithm variants. A. PQC KEX Proportions Per Service Out of the total 70,000 scanned IPv4 targets, there are a total of 5,517 (7.89%) connections that were unsuccessful. The unsuccessful connections are mainly because of two main reasons: connection refused by the server, and connection timed out. We exclude the unsuccessful connections, and all the subsequent analyses are based on the successful connections. Table I presents the proportions of PQC and Non-PQC supported IPs during TLS1.3 handshake per service for the successful connections only. We observed that HTTPS has the highest number of PQC-supported IPs, which is 816 out of 8960, meaning 9.1% of the HTTPS target IPs were PQC supported. The same proportion of PQC-supported IPs for the other services is as follows: LDAPS (7.4%), IMAP-SSL (0.64%), POP3-SSL (0.51%), SMTPS (0.45%), TELNETS (0.15%), and RDP (0.01%). Thus, except for HTTPS and LDAPS, we see that a very few of those scanned IPs were supporting PQC, specifically for TELNETS (13 out of 8486 successful connections) and RDP (1 out of 8602 successful connections). B. Proportions of all the observed key exchange algorithms Table II presents the proportion of all the different variants of key exchange algorithms, including both PQC and nonTABLE I: Proportions of IPs supporting PQC and Non-PQC algorithm during TLS handshake.

Service HTTPS LDAPS IMAP-SSL POP3-SSL SMTPS TELNETS RDP *

PQC (%)

Non-PQC (%)

9.11 7.39 0.64 0.51 0.45 0.15 0.01

90.89 92.61 99.36 99.49 99.55 99.85 99.99

percentages are out of successful connections per port.

TABLE II: Observed Server-Level PQC KEX Algorithm Variants in TLS Handshake (All the Selected Ports Combined).

KEX Algorithm Variants

Count

Percentage (%)

ecdh_x25519 secp256r1 X25519MLKEM768 secp384r1 secp521r1 ffdhe3072 TLS1.3 Not Supported

31,807 2,465 1,674 476 204 2 27,855

49.33 3.82 2.60 0.74 0.32 0.0031 43.18

PQC variants, that we observed across all successful TLS1.3 handshake messages. The most dominant key share algorithm is the classical ecdh x25519 algorithm, appearing around 49.3% of the total successful scans. The only PQC algorithm observed is hybrid X25519MLKEM768, which appears 2.6% of the total number of successful connections (across all seven services). The other observed key share algorithms are secp256r1, secp384r1, and secp521r1, and ffdhe3072. The ffdhe3072 algorithm was found in two connections only. The remaining cases (43.2%) were returning ‘<NULL>’ in the algorithm field (means TLS1.3 not supported). IV. E NTITY-L EVEL PQC A DOPTION A NALYSIS As illustrated earlier, we perform an entity-join technique to map the scanned servers’ IP addresses to specific entities and perform a deduplication process to reduce any duplicate count on the entity-level.

TABLE III: Proportions of Entities Supporting PQC KEX on 1 or More IPs Per Service.

Service

PQC (%)

Non-PQC (%)

11.04 5.42 4.00 3.03 1.85 1.75 0.11

88.96 94.58 96.00 96.97 98.15 98.25 99.89

HTTPS LDAPS IMAP-SSL POP3-SSL SMTPS TELNETS RDP

A. Entity-Level PQC Proportions In the collected data, we have 4,636 unique entities; among them, only 308 entities support PQC in 1 or more of their TLSenabled IPs, and 4,328 entities do not support any of the PQC algorithm variants on those selected ports. The percentage of entities supporting the PQC algorithm (X25519MLKEM768) in one or more IPs per service during TLS handshake is shown in Table III. In the service level, we see HTTPS has ∼11% entities supporting PQC, whereas LDAPS has around 5.4% PQC-supported entities. For services like IMAP-SSL and POP3-SSL, the percentage of entities supporting PQC is 4% and 3%, respectively. For the other services such as SMTPS, TELNETS, and RDP, this percentage of entities supporting PQC drops to <2%. Thus, our findings show that while HTTPS has >10% entities supporting PQC in one or more IPs, this proportion drops to ∼5% or less for the rest of the selected services.

Frequency Histogram of Percentage of IPs per Entity Supporting PQC (Selected Services) https

2

2

100 5 2

10 5 2

50

5 2

100 5 2

10 5 2

1 0

100

% IPs Per Entity Supporting PQC

pop3-ssl

100

2

10 5 2

50

5 2

10 5 2

telnets

100

2

2

100 5 2

10 5 2

1 0

100

% IPs Per Entity Supporting PQC

# Entities (Log10)

2

50

5

smtps

100

% IPs Per Entity Supporting PQC

2

100

1 0

5

5

1 0

50

5

% IPs Per Entity Supporting PQC

# Entities (Log10)

# Entities (Log10)

1000

imap-ssl 1000

# Entities (Log10)

5

1 0

ldaps

1000

1000

# Entities (Log10)

# Entities (Log10)

2

50

% IPs Per Entity Supporting PQC

100

100 5 2

10 5 2

1 0

50

% IPs Per Entity Supporting PQC

Fig. 1: Frequency histogram of percentage of PQC support per entity (selected services).

100

As the number of IPs controlled by an entity may vary widely, the next research question that we explored is “what percentage of IPs per entity per service support PQC”. Figure 1 presents an analysis of the percentage of IPs per entity per service supporting PQC. This histogram provides a high-level view of how PQC adoption is distributed across different entities (i.e., organizations). For each graph, the X-axis represents the percentages of IPs per entity supporting PQC, and the Yaxis represents the number of entities on a Log10 scale. From this analysis, we see across all services, there is a huge spike at the far left with <1% of IPs per entity supporting PQC on its TLS1.3 communication. This indicates that the vast majority of entities still have near-zero PQC support currently. There is a smaller, distinct spike at 100% in almost every protocol. This suggests a group of entities (likely securityconcerned) that have converted their entire infrastructure to support PQC. Compared to legacy protocols like TELNETS or SMTPS, the HTTPS histogram shows much more activity in the middle ranges (10% - 40% of PQC support). This indicates that web traffic is seeing a more gradual, phased rollout of PQC than other services. LDAPS is the second service showing a similar growing PQC adoption pattern with some fewer numbers compared to HTTPS. Protocols like SMTPS and TELNETS show almost no partial adoption. B. Sector-Wise PQC Adoption Post entity-join, we have in total 22 sectors associated with the entities in the scanned data for the selected services. Here we provide the sector-wise analysis for HTTPS only as HTTPS have >10% of PQC support in TLS1.3 handshake messages. Figure 2 illustrates the PQC adoption in different sectors for

HTTPS (port 443) in mirrored style where it contrasts the absolute volume of PQC adoption by the entities per sector on the left with the relative maturity of each sector on the right. From the figure, we find that the Technology sector is the clear frontrunner, boasting both the highest absolute number of PQC-supporting entities and the highest adoption rate (∼17%). The Media/Entertainment, Telecommunications and Transportation sectors show higher proportional PQC adoption rates (above 10%). A significant number of sectors - including Legal, Real Estate, Healthcare, and Utilities show near-zero PQC adoption. These sectors remain almost entirely reliant on classical cryptography. Even in the leading sectors, the vast segment of the bars are non-PQC. This indicates that while PQC is entering the ‘early adopter’ phase in tech-heavy industries, the global transition to quantum-resistant HTTPS (origin-server level) is still in its infancy. C. Entity Size-Based PQC Adoption We perform entity size-based analysis to understand the relationship between entity size metrics and PQC adoption on TLS, specifically on HTTPS as HTTPS has >10% of entities supporting PQC on one or more IPs. We selected two broad classes of entity size metrics: financial metrics and digital size metrics. The financial metrics include two sub-metrics: the organization’s revenue (in USD) and the number of employees. The digital size metric includes ‘SSL ACTIVE Count’ and IPv4 address count. To give some context, ‘SSL ACTIVE Count’ is basically the number of unique SSL evidence keys (i.e., unique findings) graded over the past 60 days. An evidence key is either an ‘IP:PORT’ or ‘Hostname:Port’ information.

Sector-wise PQC Adoption on Port 443 (HTTPS) Number of Entities supporting PQC vs Non-PQC per Sector on Port 443 (HTTPS)

Percentage of Entities Supporting PQC vs Non-PQC per Sector on Port 443 (HTTPS) Technology Media/Entertainment Telecommunications Transportation Business Services Retail Education Government/Politics Finance Nonprofit/NGO Manufacturing Insurance Energy/Resources Aerospace/Defense Tourism/Hospitality Legal Real Estate Healthcare/Wellness Food Production Engineering Consumer Goods Utilities

1000

5

2

100

5

2

10

5

2

1

0

20

Number of Entities (Log10) ■ PQC ■ Non-PQC

40

60

Percentage of Entities ■ PQC ■ Non-PQC

Fig. 2: Entities sector-wise PQC adoption on port 443 (HTTPS servers).

80

100

We present the analysis in a 4x2 grid view of the selected entity size metrics in Figure 3 where each row represents a metric, either financial or digital size of the entities. The row metrics are revenue in USD, employee count, SSL active count, and IPv4 count, respectively. The first column of

each row indicates the Boxplot distribution of PQC and nonPQC entities over those size metrics. The second column represents the percentage of IPs per entity with PQC adoption vs the entity size metrics. Thus, the first column compares the distribution of PQC-supported entities with that of non-PQC-

Entity Size vs PQC Deployment on Port 443 (HTTPS) Distribution by PQC Status

%PQC IPs per entity

Revenue

Non-PQC

PQC

1

1000

1M

% PQC Implementation per Entity

100

1B

80

60

40

20

0

1T

1

1000

Revenue (USD) (Log10)

1M

1B

1T

Revenue (USD) (Log10)

%PQC IPs per entity

Employee Count

100

Non-PQC

PQC

100

10k

80

60

40

20

0

1M

100

Employee Count (Log10)

10k

1M

Employee Count (Log10)

%PQC IPs per entity

SSL Active Count

100

Non-PQC

PQC

1

100

10k

80

60

40

20

0

1M

1

100

SSL Active Count (Log10)

10k

1M

SSL Active Count (Log10)

%PQC IPs per entity

100

IPv4 Count

Non-PQC

PQC

1

2

5

10

2

5

100

IPv4 Count (Log10)

2

5

1000

80

60

40

20

0

1

2

5

10

2

5

100

2

IPv4 Count (Log10)

Fig. 3: Entities financial and digital size metrics-based PQC adoption in HTTPS servers (Port 443).

5

1000

supported entities. And the second column shows the adoption depth of PQC entities with the percentage of IPs per entity supporting PQC. The X-axes are in Log10 scale because of the large range of those metrics. From the Boxplots, PQC adopters have slightly higher median revenues and employee counts, indicating that larger budgets and dedicated security teams drive early adoption. PQC adopters show a noticeably higher median IPv4 count, confirming that organizations with larger network infrastructure are leading the transition. Despite large enterprise leadership, significant overlap in active SSL counts shows that smaller entities are also adopting PQC. From the scatter plots of PQC deployment density, we find that PQC deployment is currently an “all-or-nothing” decision; most entities sit at either 0% or 100% implementation, leaving a ”hollow middle” (20% – 80%). Financial scale (revenue/employees) does not dictate deployment density; once committed, small entities are just as likely to achieve 100% PQC compliance as large ones. As IPv4 counts scale up, 100% completion rates drop slightly, suggesting that massive network footprints make full PQC migration more difficult to achieve. V. PQC A DOPTION R ATE FOR C LOUDFLARE -H OSTED D OMAINS AND IP S Cloudflare continuously updates its PQC adoption across both hosted domains (HTTPS requests) and origin servers [14]. At the time of writing this paper, the PQC adoption rate for HTTPS requests is 57.3% (human traffic) and 7.4% for originservers. We conducted a similar analysis for only Cloudflarehosted IP addresses and domains. For domains (HTTPS requests), we collect 11,979 distinct Cloudflare-hosted toplevel domains from GROMA, and specify the server name identification flag ‘-servername’ in the openssl command. We find that out of 11,979 domain scans, 9,297 times it appeared the PQC algorithm (i.e., X25519MLKEM768), 1070 times ecdh x25519, and for the remaining cases, a few other algorithms, including ‘<NULL>’. Thus, at the domainlevel, we find ∼83.6% of the Cloudflare-hosted domains (HTTPS requests) are PQC enabled, whereas 16.4% were non-PQC domains. We perform a second scan on 11048 unique Cloudflare-hosted IPs, and we find the PQC algorithm (X25519MLKEM768) in 437 target IPs , ‘<NULL>’ in 10385 IPs, and ecdh x25519 in 3 target IPs. Thus, the percentages of Cloudflare-hosted origin-server IPs supporting PQC are roughly ∼4%, and non-PQC is ∼96%. This is somewhat similar to what Cloudflare Radar is presenting [14]. VI. C ONCLUSIONS This work presents a comprehensive, multi-dimensional analysis of post-quantum cryptography (PQC) adoption over TLS across seven critical network protocols. Using a localized scanning methodology targeting 10,000 IP addresses per service, our empirical findings reveal that while HTTPS consistently exhibits an origin-server PQC adoption rate of approximately 9%, deployment across the remaining six protocols remains critically low at less than 5%. Our organizational

analysis uncovers a nuanced relationship between entity scale and PQC readiness: while larger enterprises leverage expansive budgets and dedicated engineering teams to initiate deployment, the inherent complexity of massive network infrastructures introduces significant friction to achieving a 100% PQC rollout. Consequently, our analysis captures an active, gradual rollout phase wherein organizations systematically deploy PQC across isolated, highly specific subsets of their total IP space rather than executing immediate enterprise-wide migrations. Finally, by cross-validating our domain-level data against public Cloudflare Radar telemetry, we confirm the baseline consistency and representativeness of our findings. Ultimately, this study provides a vital empirical benchmark for early-stage PQC readiness in TLS, highlighting both infrastructure constraints and organizational hurdles that must be cleared before realizing a fully post-quantum-secure internet. R EFERENCES [1] P. W. Shor, “Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer,” SIAM review, vol. 41, no. 2, pp. 303–332, 1999. [2] Bas Westerbaan, “State of the post-quantum Internet in 2025,” The Cloudflare Blog, Oct. 2025, accessed: 2026-05-04. [Online]. Available: https://blog.cloudflare.com/pq-2025/ [3] H. Adkins and S. Schmieg, “Quantum frontiers may be closer than they appear,” The Keyword (Google Blog), Mar. 2026, accessed: 2026-05-04. [Online]. Available: https://blog.google/innovation-and-ai/ technology/safety-security/cryptography-migration-timeline/ [4] A. Qureshi, “Risk-adaptive framework for enterprise post-quantum cryptography readiness and transition,” Available at SSRN 6045163, 2026. [5] A. Kundu and R. Kompella, “Quantum-resistant security: Pqc readiness and research challenges,” in 2025 62nd ACM/IEEE Design Automation Conference (DAC). IEEE, 2025, pp. 1–4. [6] T. Mallick, A. Kundu, and R. Kompella, “Study of post quantum status of widely used protocols,” 2026. [Online]. Available: https: //arxiv.org/abs/2603.28728 [7] E. D. Demir, B. Bilgin, and M. C. Onbasli, “Performance analysis and industry deployment of post-quantum cryptography algorithms,” arXiv preprint arXiv:2503.12952, 2025. [8] Y. Hanna, J. Bozhko, S. Tonyali, R. Harrilal-Parchment, M. Cebe, and K. Akkaya, “A comprehensive and realistic performance evaluation of post-quantum security for consumer iot devices,” Internet of Things, vol. 33, p. 101650, 2025. [9] J. Sowa, B. Hoang, A. Yeluru, S. Qie, A. Nikolich, R. Iyer, and P. Cao, “Post-quantum cryptography (pqc) network instrument: Measuring pqc adoption rates and identifying migration pathways,” in 2024 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 1. IEEE, 2024, pp. 1835–1846. [10] Arzu Ozbek Akay, “Bitsight Groma: The Next Generation of Internet Scanning,” https://www.bitsight.com/blog/bitsight-groma-nextgeneration-internet-scanning, 2024, accessed: 2026-05-13. [11] P. Morrissey, N. P. Smart, and B. Warinschi, “A modular security analysis of the tls handshake protocol,” in International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2008, pp. 55–73. [12] Cloudflare. (2026) What happens in a TLS handshake? — TLS handshake explained. Cloudflare. Accessed: May 28, 2026. [Online]. Available: https://www.cloudflare.com/learning/ssl/what-happens-in-atls-handshake/ [13] Francisco Ferreira, “Bitsight GIA: AI-powered Asset Mapping and Attribution,” https://www.bitsight.com/blog/bitsight-gia-ai-powered-assetmapping-and-attribution, Oct. 2024, accessed: 2026-05-13. [14] Cloudflare. (2026) Post-quantum encryption worldwide — Cloudflare Radar. Cloudflare, Inc. Accessed: May 29, 2026. [Online]. Available: https://radar.cloudflare.com/post-quantum?dateRange=52w