TLS 1.3はもはや次世代ではなく、デフォルト
あるプロトコルが運用上のベースラインになるには何年もかかります。IETFはRFC 8446でTLS 1.3を2018年に公開しました。その日以来、プロトコルはブラウザに広がり、ライブラリに定着し、監査フレームワークに入り込みました。2026年に至り、ある閾値が越えられました：古いプロトコルをサポートし続けることが、もはやそれを手放すことよりも高くつくのです。
TLS 1.2を必要とするクライアントは、更新されたか、関連性を失ったか、あるいは継続的なサービスのコストを正当化できない母集団へと縮小しました。TLS 1.3を要求する顧客は — コンプライアンス、パフォーマンス、近代化を理由に — 「依然としてデフォルトでTLS 1.2をサポートしている」という表現を、次第に調達上のレッドフラグとして読むようになっています。
このトレンドは新しいものではありません。ブラウザは2020年にTLS 1.0と1.1を引退させました。PCI-DSS 4.0（2024〜2025年に発効）は、評議会がTLS 1.2以上と解釈する「強力な暗号化」を要求しており、将来に向けた期待は明確にTLS 1.3です。FIPS 140-3は次第にTLS 1.3をベースラインとして前提とします。2026年に変わったのは、ロングテールのTLS 1.2クライアントが十分に薄くなったことです：「1.2を単に切る」という決定が、ほとんどのエンタープライズ展開にとってもはや運用上実行可能であり、理論上だけのものではなくなりました。
この記事は3つのことを扱います：TLS 1.2をサポートすることが2026年に実際にどれだけのコストになるか、TLS 1.3のみとするコンプライアンスとパフォーマンスの論拠、そしてハードウェアSSLアクセラレーションが移行の計算をどう変えるか。暗号研究者のためではなく、運用上の決定を下すチームのために書かれています。プロトコルの詳細は要約されており、網羅的ではありません。
2026年にTLS 1.2をサポートする本当のコスト
TLS 1.3とともにTLS 1.2をサポートするコストは、一つ一つは致命的ではありません。しかしスケールでは積み重なり、いずれも古いものと一緒にしか付いてきません。どれも単独では大きく見えません — しかしすべてが同時に存在するとき、古いプロトコルをサポートすることは手放すことよりも高くつきます。
より遅いハンドシェイク
TLS 1.2は新しいハンドシェイクに2回のラウンドトリップを必要とします。TLS 1.3は1回です。高遅延クライアント — モバイル、国際間 — では差が知覚可能です：新しい接続あたり100〜300 msの節約。数百万の接続にわたって乗算されると、ユーザー体験とコンバージョンへの影響が測定可能になります。
より広いcipher suiteサーフェス
TLS 1.2をサポートするとは、より広いcipherリストを受け入れることを意味します — 既知の脆弱性や弱いforward secrecy特性を持つ古い構成を含みます。慎重に設定されていても、サーフェス領域はより大きく、設定ドリフトのリスクはより高くなります。
クリティカルパス上の古いコード
接続経路上のすべてのTLSライブラリがTLS 1.2の実装を含みます。このコードが新しいセキュリティ研究の焦点になることは稀です。しかし歴史的に脆弱性の発生源でした（BEAST、Lucky13、ROBOT）。1.2を取り除くことは、このクリティカルパスのサーフェスも取り除きます。
forward secrecyの不整合
TLS 1.3はforward secrecyを必須とします — 各セッションが一時鍵を持ちます。TLS 1.2はそれを任意とし、cipher選択に依存させます。混在展開は、一部のセッションがforward secureで一部がそうでないことを意味します — 長期的な機密性のためのリスク評価を複雑にします。
監査からの圧力
2025〜2026年に、PCI-DSS 4.0の監査は、1.2が技術的に準拠していてもTLS 1.3を次第にbest practiceとして言及しています。FIPS 140-3は1.3を前提とします。SOC 2レポートはバージョン混在を統制上の懸念として記録します。コンプライアンスの圧力は一方向であり、増しています。
運用上の複雑さ
2つのプロトコルファミリーは、2つのcipher suiteポリシー、2つのデバッグコード経路、2つの監視ビュー、2つのエラーモードを意味します。追加される次元のそれぞれが運用コストを乗算します。1.2を手放すことは、この次元を簡素化します。
数字で見るTLS 1.3（ハードウェアアクセラレーションあり）
TR7ハードウェアアクセラレーションのソフトウェアのみのベースラインに対する削減率。ハンドシェイクあたりのCPUコストが崩落する。
TR7 SSL Accelerationコンプライアンスの全体像：圧力は一方向
6つの異なるフレームワークが、それぞれ異なる言葉であっても同じ方向 — TLS 1.3 — を指しています。どれも「1.2に戻れ」とは言っていません。すべてが1.3を直接または間接に指しています。共通のメッセージ：TLS 1.3はbest practiceではなく、デフォルトになりつつあります。
PCI-DSS 4.0
2024年3月に発効し、2025年3月に完全移行が完了しました。カード会員データに「強力な暗号化」を要求します。TLS 1.0/1.1は明確に禁止、TLS 1.2は許容され、将来に向けてTLS 1.3が期待されます。2025〜2026年を通じて、監査フィードバックは1.3を次第にbest practiceとして示しています。
FIPS 140-3
暗号モジュール検証の標準です。2025〜2026年の検証ラボは、展開コンテキストとしてTLS 1.3を前提とします。TLS 1.2のみで検証されたモジュールは、規制された業界での新規調達では次第に位置づけが難しくなっています。
SOC 2およびISO 27001
いずれも「業界標準の暗号化」を期待します。2026年の監査人の見解は、TLS 1.3の展開を現行プラクティスの証拠として扱います。TLS 1.2のみの展開は、技術的に準拠していても次第に監査上の指摘を招きます。
DORA（EU金融レジリエンス）
EUの金融機関に対する運用レジリエンス要件を導入します。暗号アジリティ — プロトコルを迅速に更新できる能力 — は運用リスクの全体像の一部です。TLS 1.3の展開はポジティブなシグナルであり、TLS 1.2のロックインはネガティブです。
CNSA 2.0 / PQCの道
米国の国家安全保障暗号スイートとして、2030年に向けてPQCへ進んでいます。PQC移行の基盤プロトコルとしてTLS 1.3を前提とします — ML-KEMのハイブリッド鍵交換はTLS 1.3向けに定義され、1.2向けには定義されていません。TLS 1.3をスキップすることは、後により困難なPQC移行を残します。
ブラウザの強制
Chrome、Firefox、Safari、Edge — すべてがデフォルトでTLS 1.3をサポートし、TLS 1.2の引退タイムラインを持っています。ブラウザDevToolsの接続ダウングレード表示は、ユーザー向けのテストでTLS 1.2を次第に目立たせ始めています。
重要なものを壊さずにどう移行するか？
TLS 1.2トラフィックを棚卸しする
ADCでTLSバージョンの接続ごとのロギングを有効にします。user-agent、ソースIP範囲、エンドポイントごとに集計します。結果：TLS 1.2を切るとアクセスを失うクライアント母集団。ほとんどの組織は、その母集団が恐れていたよりも小さいことに気づきます。
TLS 1.2母集団を分類する
棚卸しをカテゴリでグループ化します：顧客向けブラウザ（2026年にはゼロに近いはず）、パートナーAPI統合、内部サービス、組み込み機器。各カテゴリには異なる改善経路があります。
エンドポイントごとにポリシーを定める
TLS 1.3のみは、全か無かではありません。エンドポイントごとに設定します：公開された顧客向けエンドポイントはTLS 1.3のみを受け付ける；1.2が必要であることが文書化された内部サービスは一時的に維持する；パートナー統合は期限が文書化された引退経路を受け取る。
パートナーとコミュニケーションをとる
TLS 1.2を必要とするB2B統合には、実際の期限を伴う文書化された引退計画をパートナーへ送ります。ほとんどのパートナーは、求められれば「TLS 1.2の沈没」より速く更新します。多くは強制力のある契機を待っているかもしれません。
デフォルトでTLS 1.3を強制する
新しいエンドポイントのデフォルトをTLS 1.3のみに切り替えます。文書化された1.2の必要性を持つ既存のエンドポイントはオーバーライドを受け取り、それ以外はすべてモダンなベースラインがデフォルトになります。これにより新たな技術的負債の蓄積が止まります。
ここにいるうちにPQCも計画する
すでにTLS設定に触れているなら、TLS 1.3でハイブリッドML-KEM鍵交換を有効にします。変更は保守的（ハイブリッドモードは古典的なセキュリティにフォールバックする）であり、「今収集して後で復号する」に対してトラフィックを保護し始めます。PQCとTLS 1.3の移行は同じプロジェクトであり、同じ設定移行で実行されます。
ハードウェアSSLアクセラレーションはどこに位置するか？
TLS 1.3のパフォーマンス上の利点は、暗号化処理がボトルネックでないときに最もよく現れます。大量のソフトウェアのみのTLSは、汎用コアに顕著なCPU圧力をかけます。ピーク時にはTLSハンドシェイクだけが、高負荷のロードバランサーで利用可能なCPUの20〜30%を消費し得ます。ハードウェアSSLアクセラレーションは、これらの処理を専用の暗号ユニットへオフロードし、接続あたりのCPUコストを劇的に削減します。
TR7のハードウェアSSLアクセラレーションは、SSL処理負荷をソフトウェアのみに比べて約95%削減します。実際の効果：同じハードウェアがはるかに多くの同時TLSセッションを処理し、遅延がより一貫し（専用ハードウェアはCPUを奪い合わない）、ハンドシェイクあたりのコストが、TLSプロトコル選択が測定可能なアプリケーション影響を持つ閾値の下に落ちます。
PQCの道においては、ML-KEMとAEAD cipherのハードウェアアクセラレーションが、大量のPQC展開への道筋です。ハンドシェイクのサイズは大きくなります（ML-KEMはX25519の約100バイトに対して約1.1 KB）。しかし操作あたりのCPUコストはRSA-2048に匹敵し得ます。PQCプリミティブを含むハードウェアは、移行が進む間もハンドシェイクあたりのコストを一定に保ちます。TR7のロードマップはハードウェアアクセラレーションをPQC移行のタイムラインと整合させます。移行のためにハードウェアを交換する必要はありません。
中心的な考えがここで再び戻ってきます：TLS 1.3移行と2030年に向けたPQC移行は、同じ設定の道です。ハードウェアアクセラレーションは、両者のコストを運用上見えなくする構成要素です。
参考文献と情報源
1-RTTハンドシェイク設計、0-RTTデータ、必須のforward secrecy、削除された古いcipher suiteを含むプロトコル仕様。https://datatracker.ietf.org/doc/html/rfc8446
Payment Card Industry Data Security Standardの現行バージョン。完全移行は2025年3月に完了。https://www.pcisecuritystandards.org/document_library/
暗号モジュール検証のためのFederal Information Processing Standard。https://csrc.nist.gov/projects/cryptographic-module-validation-program
金融機関に対し、暗号アジリティを含む運用レジリエンス要件を導入するRegulation (EU) 2022/2554。https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Commercial National Security Algorithm Suite 2.0 — PQC移行タイムラインの下でデフォルトプロトコルとしてのTLS 1.3。https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
モダンなTLS、モダンなハードウェア
TR7のハードウェアアクセラレーション付きSSL処理は、0-RTT、ハイブリッドML-KEM鍵交換、そしてソフトウェアのみに比べて約95%のCPUオフロードでTLS 1.3を運びます。TLS 1.3移行と2030年に向けたPQCのストーリーは、同じ設定の道です。
TR7 SSLアクセラレーションを見る