Cloudflare Oneが全プラットフォームで現代的な耐量子暗号を備えた初のSASEサービスに
Cloudflare Oneが最新のIETF草案を実装し、全主要な接続経路で耐量子暗号をサポート。
キーポイント
Cloudflare Oneが業界初の完全プラットフォーム対応ポスト量子暗号化SASEを提供
ML-KEM（モジュール格子ベース鍵カプセル化機構）をSWG、Zero Trust、WANユースケースで実装
Cloudflare IPsecとCloudflare One Applianceにポスト量子暗号化サポートを追加
量子脅威は「次の10年」の問題ではなく、現在の優先課題として位置付け
影響分析・編集コメントを表示
影響分析
この発表は、量子コンピューティング時代に向けたセキュリティ基盤の重要な進展を示しており、企業ネットワーク全体の将来の安全性を確保するための業界標準を設定する可能性がある。Cloudflareが完全なSASEプラットフォームでポスト量子暗号化を実装したことで、他のセキュリティプロバイダーも同様の対応を迫られる競争環境が生まれる。
編集コメント
量子コンピューティングの脅威が現実化する中、セキュリティ業界のリーダーが具体的な対策を発表したことは、業界全体の方向性を示す重要なマイルストーンと言える。
Cloudflare Oneは、フルプラットフォームで最新の耐量子暗号を提供する初のSASEです
Sharon Goldberg
Amos Paul
David Gauch
セキュリティウィーク2025において、当社は業界初のクラウドネイティブな耐量子セキュアWebゲートウェイ（SWG）およびゼロトラストソリューションを発表しました。これは、エンドユーザーデバイスからパブリックおよびプライベートネットワークに送信される企業ネットワークトラフィックを保護するための大きな一歩です。
しかし、これは方程式の一部に過ぎません。企業ネットワークの未来を真に保護するためには、完全なSecure Access Service Edge（SASE）が必要です。
本日、当社はその方程式を完成させます：Cloudflare Oneは、セキュアWebゲートウェイ、およびゼロトラストと広域ネットワーク（WAN）のユースケース全体において、最新の標準準拠の耐量子（PQ）暗号化をサポートする初のSASEプラットフォームです。より具体的には、Cloudflare Oneは現在、すべての主要なオンレンプとオフランプにおいて、耐量子ハイブリッドML-KEM（Module-Lattice-based Key-Encapsulation Mechanism）を提供しています。
方程式を完成させるため、当社はCloudflare IPsec（クラウドネイティブなWAN-as-a-Service）およびCloudflare One Appliance（Cloudflare IPsec接続を確立する物理的または仮想的なWANアプライアンス）に耐量子暗号化のサポートを追加しました。Cloudflare IPsecはIPsecプロトコルを使用して、顧客のネットワークからCloudflareのグローバルネットワークへの暗号化トンネルを確立し、IP Anycastを使用してそのトンネルを最寄りのCloudflareデータセンターに自動的にルーティングします。Cloudflare IPsecは設定を簡素化し、高可用性を提供します。特定のデータセンターが利用できなくなった場合、トラフィックは自動的に最寄りの正常なデータセンターに再ルーティングされます。Cloudflare IPsecは当社のグローバルネットワークの規模で動作し、WANを介したサイト間接続およびインターネットへのアウトバウンド接続をサポートします。
Cloudflare One Applianceのアップグレードは、アプライアンスバージョン2026.2.0より一般提供されています。Cloudflare IPsecのアップグレードはクローズドベータ段階にあり、クローズドベータリストに名前を追加することでアクセスをリクエストできます。
耐量子暗号は今重要なのです
量子脅威は「次の10年」の問題ではありません。当社の顧客が今日、耐量子暗号（PQC）を優先している理由は以下の通りです：
期限が迫っています。2024年末、米国国立標準技術研究所（NIST）は（他の機関も同調した）明確なシグナルを送りました：古典的な公開鍵暗号の時代は終わりを迎えつつあります。NISTは、RSAおよび楕円曲線暗号（ECC）を廃止し、強力な量子コンピュータによって破られないPQCへの移行について、2030年という期限を設定しました。移行を開始していない組織は、期限が近づくにつれてコンプライアンス違反のリスクにさらされ、脆弱になる危険性があります。
アップグレードは歴史的に困難でした。2030年は遠いように思えるかもしれませんが、暗号アルゴリズムのアップグレードは非常に困難であることで知られています。歴史は、暗号の廃止には数十年を要することを示しています：MD5が廃止されてから20年後に問題を引き起こした例が見つかっています。この暗号機敏性（暗号アルゴリズムを容易に交換する能力）の欠如は、大きなボトルネックです。当社のSASEプラットフォームであるCloudflare OneにPQ暗号化を直接統合することで、当社は組み込みの暗号機敏性を提供し、組織がリモートアクセスとサイト間接続性を提供する方法を簡素化します。
データはすでに危険にさらされている可能性があります。最後に、「今収穫し、後で解読する（Harvest Now, Decrypt Later）」は現在進行形の持続的な脅威であり、攻撃者が今日機密性の高いネットワークトラフィックを収集し、量子コンピュータがそれを解読できるほど強力になるまで保存します。データの保存期間が数年を超える場合（例：金融情報、医療データ、国家機密）、PQ暗号化で保護されていない限り、すでに危険にさらされています。
量子安全性への道における2つの移行：鍵合意とデジタル署名
ネットワークトラフィックを耐量子暗号（PQC）に移行するには、2つの暗号プリミティブ、すなわち鍵合意とデジタル署名の全面的な見直しが必要です。
移行1：鍵確立。鍵合意により、2者は安全でないチャネル上で共有秘密を確立できます。この共有秘密はその後、ネットワークトラフィックの暗号化に使用され、耐量子暗号化が実現します。業界は、標準的なPQ鍵合意プロトコルとしてML-KEM（Module-Lattice-based Key-Encapsulation Mechanism）にほぼ収束しています。
ML-KEMはTLSでの使用のために広く採用されており、通常は古典的な楕円曲線ディフィー・ヘルマン（ECDHE）と併用して導入されます。この場合、ネットワークトラフィックの暗号化に使用される鍵は、ML-KEMとECDHEの鍵合意の出力を混合して導出されます（これは「ハイブリッドML-KEM」とも呼ばれます）。Cloudflareのネットワークへの人間が生成するTLSトラフィックの実に60％以上が、現在ハイブリッドML-KEMによって保護されています。ハイブリッドML-KEMへの移行が成功している理由は、それが以下を行うからです：
「今収穫し、後で解読する」攻撃を阻止する
量子鍵配送（QKD）のようなアプローチとは異なり、クライアントとサーバー間の専用ハードウェアや専用の物理的接続性を必要としない
短命のTLS接続であっても、パフォーマンスへの影響がほとんどない
ML-KEMは古典的なECDHEと並行して実行されるため、古典的なECDHEアプローチと比較して、セキュリティとコンプライアンスが低下することはありません。
移行2：デジタル署名。一方、デジタル署名と証明書は真正性を保護し、能動的な攻撃者がサーバーになりすましてクライアントに接続することを阻止します。残念ながら、PQ署名は現在、古典的なECCアルゴリズムよりもサイズが大きいため、その採用は遅れています。幸いなことに、PQ署名への移行はそれほど緊急ではありません。なぜなら、PQ署名は強力な量子コンピュータを備えた能動的な攻撃者を阻止するように設計されており、そのようなコンピュータはまだ存在が知られていないからです。したがって、CloudflareはPQデジタル署名の標準化と展開に積極的に貢献していますが、現在のCloudflare IPsecのアップグレードは、鍵確立をハイブリッドML-KEMにアップグレードすることに焦点を当てています。
米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、2026年1月に発表した「耐量子暗号標準を使用する技術の製品カテゴリ」において、これら2つの移行の性質を認識しました。
IPsecで新境地を開く
耐量子暗号化で完全に保護されたSASEを実現するため、当社はCloudflare IPsec製品をアップグレードし、IPsecプロトコルでハイブリッドML-KEMをサポートするようにしました。
IPsecコミュニティの耐量子暗号への道のりは、TLSのそれとは大きく異なっています。TLSは、レイヤー4でパブリックインターネットトラフィック（例：ブラウザからコンテンツデリバリーネットワーク（CDN）へ）を暗号化する事実上の標準であるため、セキュリティとベンダー間の相互運用性がその設計の最前線にあります。一方、IPsecはレイヤー3プロトコルであり、通常は同じベンダーによって構築されたデバイス（例：2台のルーター）を接続するため、相互運用性は歴史的にはそれほど懸念されてきませんでした。このことを念頭に置いて、IPsecの量子未来への旅を見てみましょう。
事前共有鍵？量子鍵配送？
2020年5月に公開されたRFC 8784は、IPsecネットワークトラフィックの暗号化に使用される対称鍵を確立するために使用されるIPsecインターネット鍵交換v2（IKEv2）の耐量子アップデートとなることを意図していました。RFC 8784は、長寿命の事前共有鍵（PSK）または量子鍵配送（QKD）のいずれかの使用を暗示しています。これらのアプローチはいずれもあまり好ましいものではありません。
RFC 8784は、PSKをディフィー・ヘルマン交換から導出された鍵と混合することを提案しています。
原文を表示
Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform
Sharon Goldberg
Amos Paul
David Gauch
During Security Week 2025, we launched the industry’s first cloud-native post-quantum Secure Web Gateway (SWG) and Zero Trust solution, a major step towards securing enterprise network traffic sent from end user devices to public and private networks.
But this is only part of the equation. To truly secure the future of enterprise networking, you need a complete Secure Access Service Edge (SASE).
Today, we complete the equation: Cloudflare One is the first SASE platform to support modern standards-compliant post-quantum (PQ) encryption in our Secure Web Gateway, and across Zero Trust and Wide Area Network (WAN) use cases. More specifically, Cloudflare One now offers post-quantum hybrid ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) across all major on-ramps and off-ramps.
To complete the equation, we added support for post-quantum encryption to our Cloudflare IPsec (our cloud-native WAN-as-a-Service) and Cloudflare One Appliance (our physical or virtual WAN appliance that establish Cloudflare IPsec connections). Cloudflare IPsec uses the IPsec protocol to establish encrypted tunnels from a customer’s network to Cloudflare’s global network, while IP Anycast is used to automatically route that tunnel to the nearest Cloudflare data center. Cloudflare IPsec simplifies configuration and provides high availability; if a specific data center becomes unavailable, traffic is automatically rerouted to the closest healthy data center. Cloudflare IPsec runs at the scale of our global network, and supports site-to-site across a WAN as well as outbound connections to the Internet.
The Cloudflare One Appliance upgrade is generally available as of appliance version 2026.2.0. The Cloudflare IPsec upgrade is in closed beta, and you can request access by adding your name to our closed beta list.
Post-quantum cryptography matters now
Quantum threats are not a "next decade" problem. Here is why our customers are prioritizing post-quantum cryptography (PQC) today:
The deadline is approaching. At the end of 2024, the National Institute of Standards and Technology (NIST) sent a clear signal (that has been echoed by other agencies): the era of classical public-key cryptography is coming to an end. NIST set a 2030 deadline for depreciating RSA and Elliptic Curve Cryptography (ECC) and transitioning to PQC that cannot be broken by powerful quantum computers. Organizations that haven't begun their migration risk being out of compliance and vulnerable as the deadline nears.
Upgrades have historically been tricky. While 2030 might seem far away, upgrading cryptographic algorithms is notoriously difficult. History has shown us that depreciating cryptography can take decades: we found examples of MD5 causing problems 20 years after it was deprecated. This lack of crypto agility — the ability to easily swap out cryptographic algorithms — is a major bottleneck. By integrating PQ encryption directly into Cloudflare One, our SASE platform, we provide built-in crypto agility, simplifying how organizations offer remote access and site-to-site connectivity.
Data may already be at risk. Finally, "Harvest Now, Decrypt Later" is a present and persistent threat, where attackers harvest sensitive network traffic today and then store it until quantum computers become powerful enough to decrypt it. If your data has a shelf life of more than a few years (e.g. financial information, health data, state secrets) it is already at risk unless it is protected by PQ encryption.
The two migrations on the road to quantum safety: key agreement and digital signatures
Transitioning network traffic to post-quantum cryptography (PQC) requires an overhaul of two cryptographic primitives: key agreement and digital signatures.
Migration 1: Key establishment. Key agreement allows two parties to establish a shared secret over an insecure channel; the shared secret is then used to encrypt network traffic, resulting in post-quantum encryption. The industry has largely converged on ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) as the standard PQ key agreement protocol.
ML-KEM has been widely adopted for use in TLS, usually deployed alongside classical Elliptic Curve Diffie Hellman (ECDHE), where the key used to encrypt network traffic is derived by mixing the outputs of the ML-KEM and ECDHE key agreements. (This is also known as “hybrid ML-KEM”). Well over 60% of human-generated TLS traffic to Cloudflare’s network is currently protected with hybrid ML-KEM. The transition to hybrid ML-KEM has been successful because it:
stops "harvest-now, decrypt-later" attacks
does not require specialized hardware or specialized physical connectivity between client and server, unlike approaches like Quantum Key Distribution (QKD)
has little impact on performance, even for short-lived TLS connections
Because ML-KEM runs in parallel with classical ECDHE, there is no reduction in security and compliance as compared to the classical ECDHE approach.
Migration 2: Digital signatures. Meanwhile, digital signatures and certificates protect authenticity, stopping active adversaries from impersonating the server to the client. Unfortunately, PQ signatures are currently larger in size than classical ECC algorithms, which has slowed their adoption. Fortunately, the migration to PQ signatures is less urgent, because PQ signatures are designed to stop active adversaries armed with powerful quantum computers, which are not known to exist yet. Thus, while Cloudflare is actively contributing to the standardization and rollout of PQ digital signatures, the current Cloudflare IPsec upgrade focuses on upgrading key establishment to hybrid ML-KEM.
The U.S. Cybersecurity & Infrastructure Security Agency (CISA) recognized the nature of these two migrations in its January 2026 publication, “Product Categories for Technologies That Use Post-Quantum Cryptography Standards.”
Breaking new ground with IPsec
To achieve a SASE fully protected with post-quantum encryption, we’ve upgraded our Cloudflare IPsec products to support hybrid ML-KEM in the IPsec protocol.
The IPsec community’s journey toward post-quantum cryptography has been very different from that of TLS. TLS is the de facto standard for encrypting public Internet traffic at Layer 4 — e.g. from a browser to a content delivery network (CDN) — so security and vendor interoperability are at the forefront of its design. Meanwhile, IPsec is a Layer 3 protocol that commonly connects devices built by the same vendor (e.g. two routers), so interoperability has historically been less of a concern. With this in mind, let’s take a look at IPsec’s journey into the quantum future.
Pre-Shared Keys? Quantum key distribution?
RFC 8784, published in May 2020, was intended to be the post-quantum update to IPsec Internet Key Exchange v2 (IKEv2), which is used to establish the symmetric keys used to encrypt IPsec network traffic. RFC 8784 implies the use of either long-lived pre-shared keys (PSK) or quantum key distribution (QKD). Neither of these approaches are very palatable.
RFC 8784 proposes mixing a PSK with a key derived from Diffie Hellman Exchange (DHE), essentially running PSK in hybrid with DHE. This approach protects against harvest-now-decrypt-later attackers, but does not offer forward secrecy against quantum adversaries.
Forward secrecy is a standard desideratum of key agreement protocols. It ensures that a system is secure even if the long-lived key is leaked. The PSK approach in RFC 8784 is vulnerable to an harvest-now-decrypt-later adversary that also obtains a copy of a long-lived PSK, and can then decrypt traffic in the future (by breaking the DHE key agreement) once powerful quantum computers become available.
To solve this forward secrecy issue, RFC 8784 can instead be used to mix the key from the classical DHE with a freshly generated key derived from a QKD protocol.
QKD uses quantum mechanics to establish a shared, secret cryptographic key between two parties. Importantly, for QKD to work, the parties must have specialized hardware or be connected by a dedicated physical connection. This is a significant limitation, rendering QKD useless for common Internet use cases like connecting a laptop to a distant server over Wi-Fi. These limitations are also why we never invested in deploying QKD for Cloudflare IPsec. The U.S. National Security Agency (NSA), Germany’s BSI and the UK National Cyber Security Centre have also warned against relying solely on QKD.
But what about interoperability?
RFC 9370 landed in May 2023, specifying the use of hybrid key agreement rather than PSK or QKD. But unlike TLS, which only supports using post-quantum ML-KEM in parallel with classical DHE, this IPsec standard allows using up to seven different key agreements to run at the same time in parallel with classical Diffie Helman. Moreover, it doesn't specify details about what these key agreements should be, leaving it up to the vendors to choose their algorithms and implementations. Palo Alto Networks, for example, took this seriously and built support for over seven different PQC ciphersuites into its next generation firewall (NGFW), most of which do not interoperate with other vendors and some of which have not yet been standardized by NIST.
Over the years, TLS has gone in the opposite direction, reducing the number of registered ciphersuites from hundreds in TLS 1.2, down to around five in TLS 1.3. This philosophy of reducing “ciphersuite bloat” is also in line with NIST’s SP 800 52 from 2019. The rationale for reducing “ciphersuite bloat” includes:
Improved interoperability across vendors and regions
Lower risk of attacks that exploit downgrades to weak ciphersuites
Lower risk of security problems due to misconfiguration
Lower risk of implementation flaws by reducing the size of the codebase
This is why we didn’t initially build support for RFC 9370.
Standards that are finally on the right track
It’s also why we were excited when the IPsec community put forth draft-ietf-ipsecme-ikev2-mlkem. This Internet-Draft standardizes PQ exchange for IPsec in the same way PQ key exchange has been widely deployed for TLS: hybrid ML-KEM. The new draft fills in the gaps in RFC 9370, by specifying how to run the ML-KEM as the additional key exchange in parallel with classical Diffie Hellman in IKEv2.
Now that this specification is available, we’ve moved forward with supporting post-quantum IPsec in our Cloudflare IPsec products.
Cloudflare IPsec goes post-quantum
Cloudflare IPsec is a WAN Network-as-a-Service solution that replaces legacy private network architectures by connecting data centers, branch offices, and cloud VPCs to Cloudflare’s global IP Anycast network.
With Cloudflare IPsec, Cloudflare’s network acts as the IKEv2 Responder, awaiting connection requests from an IPsec initiator, which is a branch connector device in the customer’s network. Cloudflare IPsec supports IPsec sessions initiated by branch connectors that include our own Cloudflare One Appliance, along with branch connectors from a diverse set of vendors, including Cisco, Juniper, Palo Alto Netw
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み