TLS 1.3 ist nicht mehr die nächste Generation, sondern der Standard
Es dauert Jahre, bis ein Protokoll zur operativen Baseline wird. Die IETF veröffentlichte TLS 1.3 mit RFC 8446 im Jahr 2018. Seitdem hat sich das Protokoll in Browsern ausgebreitet, in Bibliotheken etabliert und Eingang in Audit-Frameworks gefunden. Bis 2026 wurde eine Schwelle überschritten: Ältere Protokolle zu unterstützen ist nun teurer, als sie aufzugeben.
Die Clients, die TLS 1.2 benötigen, wurden entweder aktualisiert, irrelevant oder sind auf eine Population geschrumpft, die die Kosten eines kontinuierlichen Betriebs nicht mehr rechtfertigt. Kunden, die TLS 1.3 verlangen — aus Compliance-, Performance- oder Modernisierungsgründen — lesen die Aussage „unterstützt standardmäßig immer noch TLS 1.2" zunehmend als Red Flag bei der Beschaffung.
Dieser Trend ist nicht neu. Browser haben TLS 1.0 und 1.1 im Jahr 2020 ausgemustert. PCI-DSS 4.0 (in Kraft getreten 2024–2025) verlangt „starke Kryptografie", die der Rat als TLS 1.2 oder höher interpretiert; die zukunftsgerichtete Erwartung ist eindeutig TLS 1.3. FIPS 140-3 setzt zunehmend TLS 1.3 als Baseline voraus. Was sich 2026 ändert, ist, dass die Long-Tail-TLS-1.2-Clients ausreichend ausgedünnt sind: Die Entscheidung „einfach 1.2 abschalten" ist für die meisten Unternehmens-Deployments nun operativ umsetzbar, nicht mehr nur theoretisch.
Dieser Beitrag deckt drei Dinge ab: was die Unterstützung von TLS 1.2 Sie 2026 tatsächlich kostet, die Compliance- und Performance-Argumente für ausschließlich TLS 1.3 und wie die Hardware-SSL-Beschleunigung die Migrationsmathematik verändert. Er ist nicht für Kryptografen geschrieben, sondern für die Teams, die die operative Entscheidung treffen; Protokolldetails sind zusammengefasst, nicht erschöpfend.
Was die Unterstützung von TLS 1.2 Sie 2026 wirklich kostet
Die Kosten der Unterstützung von TLS 1.2 neben TLS 1.3 sind einzeln betrachtet nicht katastrophal; aber sie summieren sich im großen Maßstab, und keine davon entsteht ausschließlich mit dem Alten. Keine wirkt für sich allein groß — doch wenn sie alle gleichzeitig vorhanden sind, wird die Unterstützung des alten Protokolls teurer, als es aufzugeben.
Langsamere Handshakes
TLS 1.2 benötigt für einen frischen Handshake zwei Roundtrips; TLS 1.3 einen. Für Clients mit hoher Latenz — mobil, international — ist der Unterschied spürbar: 100–300 ms Ersparnis pro frischer Verbindung. Über Millionen von Verbindungen multipliziert, werden die Auswirkungen auf Nutzererfahrung und Conversion messbar.
Breitere Cipher-Suite-Fläche
TLS 1.2 zu unterstützen bedeutet, eine breitere Cipher-Liste zu akzeptieren — einschließlich älterer Konstruktionen mit bekannten Schwachstellen oder schwachen Forward-Secrecy-Eigenschaften. Selbst sorgfältig konfiguriert ist die Angriffsfläche größer; das Risiko einer Konfigurationsabweichung ist höher.
Alter Code im kritischen Pfad
Jede TLS-Bibliothek im Verbindungspfad enthält eine TLS-1.2-Implementierung. Dieser Code ist selten der Fokus neuer Sicherheitsforschung; war aber historisch eine Quelle von Schwachstellen (BEAST, Lucky13, ROBOT). Das Entfernen von 1.2 entfernt auch diese Fläche im kritischen Pfad.
Forward-Secrecy-Inkonsistenz
TLS 1.3 macht Forward Secrecy verpflichtend — jede Sitzung hat flüchtige Schlüssel. TLS 1.2 lässt sie optional und von der Cipher-Wahl abhängig. Gemischte Deployments bedeuten, dass einige Sitzungen forward-sicher sind und andere nicht — was die Risikobewertung für langfristige Vertraulichkeit verkompliziert.
Audit-Druck
In den Jahren 2025–2026 verweisen PCI-DSS-4.0-Audits zunehmend auf TLS 1.3 als Best Practice, selbst wenn 1.2 technisch konform ist. FIPS 140-3 setzt 1.3 voraus. SOC-2-Berichte vermerken den Versionsmix als Kontrollbedenken. Der Compliance-Druck ist einseitig und nimmt zu.
Operative Komplexität
Zwei Protokollfamilien bedeuten zwei Cipher-Suite-Policies, zwei Debug-Code-Pfade, zwei Überwachungsansichten und zwei Fehlermodi. Jede zusätzliche Dimension vervielfacht die operativen Kosten. Das Aufgeben von 1.2 vereinfacht diese Dimension.
TLS 1.3 in Zahlen (mit Hardware-Beschleunigung)
TLS 1.3 — gegenüber 2 RTT bei TLS 1.2. Gewinn bei jeder frischen Verbindung.
IETF RFC 8446Bei Wiederverbindungen können Anwendungsdaten im ersten Paket gesendet werden; keine Handshake-Latenz.
IETF RFC 8446Reduktionsrate der Hardware-Beschleunigung von TR7 gegenüber der reinen Software-Baseline; die CPU-Kosten pro Handshake brechen ein.
TR7 SSL-BeschleunigungJede TLS-1.3-Sitzung hat flüchtige Schlüssel; die rückwirkende Entschlüsselung langlebiger Geheimnisse wird unmöglich.
IETF RFC 8446Das Compliance-Bild: Der Druck ist einseitig
Sechs verschiedene Frameworks weisen — wenn auch in unterschiedlicher Sprache — in dieselbe Richtung, hin zu TLS 1.3. Keines sagt „kehren Sie zu 1.2 zurück"; alle verweisen entweder direkt oder indirekt auf 1.3. Die gemeinsame Botschaft: TLS 1.3 wird vom Best Practice zum Standard.
PCI-DSS 4.0
In Kraft getreten im März 2024, vollständiger Übergang im März 2025 abgeschlossen. Verlangt „starke Kryptografie" für Karteninhaberdaten; TLS 1.0/1.1 sind ausdrücklich verboten, TLS 1.2 ist zulässig und zukunftsgerichtet wird TLS 1.3 erwartet. Über 2025–2026 weist das Audit-Feedback 1.3 zunehmend als Best Practice aus.
FIPS 140-3
Standard für die Validierung kryptografischer Module. Die Validierungslabore in den Jahren 2025–2026 setzen TLS 1.3 als Deployment-Kontext voraus. Module, die nur für TLS 1.2 validiert sind, werden in regulierten Branchen zunehmend schwer für Neuanschaffungen zu positionieren.
SOC 2 und ISO 27001
Beide erwarten „branchenübliche Kryptografie". Die Prüferinterpretation 2026 behandelt die Verbreitung von TLS 1.3 als Nachweis aktueller Praxis; ein reines TLS-1.2-Deployment zieht zunehmend Audit-Hinweise auf sich, selbst wenn es technisch konform ist.
DORA (EU-Finanzresilienz)
Führt Anforderungen an die operative Resilienz für EU-Finanzinstitute ein. Kryptografische Agilität — die Fähigkeit, Protokolle schnell zu aktualisieren — ist Teil des operativen Risikobilds. Die Verbreitung von TLS 1.3 ist ein positives Signal; ein TLS-1.2-Lock-in ist negativ.
CNSA 2.0 / PQC-Pfad
Als kryptografische Suite der US-Sicherheitsbehörden bewegt sie sich bis 2030 in Richtung PQC. Sie setzt TLS 1.3 als zugrunde liegendes Protokoll der PQC-Migration voraus — der hybride ML-KEM-Schlüsselaustausch ist für TLS 1.3 definiert, nicht für 1.2. TLS 1.3 zu überspringen, hinterlässt eine schwierigere PQC-Migration.
Browser-Vorgaben
Chrome, Firefox, Safari, Edge — alle unterstützen TLS 1.3 standardmäßig und haben Zeitpläne für die Ausmusterung von TLS 1.2. Die Indikatoren für eine herabgestufte Verbindung in den Browser-DevTools beginnen zunehmend, TLS 1.2 in nutzerseitigen Tests zu markieren.
Wie migriert man, ohne etwas Wichtiges zu zerbrechen?
Inventarisieren Sie den TLS-1.2-Verkehr
Aktivieren Sie auf Ihrem ADC die Protokollierung der TLS-Version pro Verbindung. Aggregieren Sie nach User-Agent, Quell-IP-Bereich und Endpoint. Ergebnis: die Client-Population, die den Zugang verliert, wenn Sie TLS 1.2 abschalten. Die meisten Organisationen finden die Population kleiner als befürchtet.
Klassifizieren Sie die TLS-1.2-Population
Gruppieren Sie das Inventar nach Kategorie: kundenseitige Browser (2026 sollte nahe null sein), Partner-API-Integrationen, interne Services, eingebettete Geräte. Jede Kategorie hat einen anderen Sanierungspfad.
Legen Sie eine Policy pro Endpoint fest
Nur TLS 1.3 ist kein Alles-oder-nichts. Konfigurieren Sie pro Endpoint: öffentlich zugängliche Kunden-Endpoints erhalten nur TLS 1.3; interne Services mit dokumentiertem 1.2-Bedarf behalten es vorübergehend; Partner-Integrationen erhalten einen Ausmusterungspfad mit dokumentierter Frist.
Kommunizieren Sie mit Partnern
Senden Sie für B2B-Integrationen, die TLS 1.2 benötigen, dem Partner einen dokumentierten Ausmusterungsplan mit einer echten Frist. Die meisten Partner aktualisieren auf Anfrage schneller als bei einer „TLS-1.2-Versenkung"; viele warten womöglich auf eine erzwingende Funktion.
Erzwingen Sie standardmäßig TLS 1.3
Stellen Sie den Standard für neue Endpoints auf nur TLS 1.3 um. Bestehende Endpoints mit dokumentiertem 1.2-Bedarf erhalten ein Override; alles wird standardmäßig auf die moderne Baseline gesetzt. Das stoppt die Anhäufung neuer technischer Schulden.
Planen Sie hier auch gleich PQC
Wenn Sie ohnehin an der TLS-Konfiguration arbeiten, aktivieren Sie den hybriden ML-KEM-Schlüsselaustausch in TLS 1.3. Die Änderung ist konservativ (der Hybridmodus fällt auf klassische Sicherheit zurück) und beginnt, den Verkehr gegen „jetzt sammeln, später entschlüsseln" zu schützen. PQC- und TLS-1.3-Migrationen sind dasselbe Projekt; sie werden im selben Konfigurationsdurchgang durchgeführt.
Wo setzt die Hardware-SSL-Beschleunigung an?
Die Performance-Vorteile von TLS 1.3 zeigen sich am stärksten, wenn die kryptografischen Operationen kein Engpass sind. Bei hohem Volumen übt rein softwarebasiertes TLS spürbaren CPU-Druck auf Allzweck-Kerne aus; in der Spitze können allein TLS-Handshakes auf stark ausgelasteten Load Balancern 20–30 Prozent der verfügbaren CPU verbrauchen. Hardware-SSL-Beschleunigung lagert diese Operationen auf dedizierte Krypto-Einheiten aus und reduziert die CPU-Kosten pro Verbindung dramatisch.
Die Hardware-SSL-Beschleunigung von TR7 reduziert die SSL-Verarbeitungslast gegenüber reiner Software um etwa 95 Prozent. Die praktische Auswirkung: Dieselbe Hardware verarbeitet deutlich mehr gleichzeitige TLS-Sitzungen, die Latenz wird konsistenter (dedizierte Hardware konkurriert nicht um die CPU) und die Kosten pro Handshake fallen unter die Schwelle, an der die Wahl des TLS-Protokolls eine messbare Auswirkung auf die Anwendung hätte.
Für den PQC-Pfad ist die Hardware-Beschleunigung von ML-KEM und AEAD-Ciphern der Weg zu einer PQC-Verbreitung mit hohem Volumen. Die Handshake-Größe wächst (ML-KEM etwa 1,1 KB gegenüber etwa 100 Byte bei X25519); aber die CPU-Kosten pro Operation können mit RSA-2048 konkurrieren. Hardware, die PQC-Primitive enthält, hält die Kosten pro Handshake konstant, während die Migration fortschreitet. Die Roadmap von TR7 richtet die Hardware-Beschleunigung am PQC-Migrationszeitplan aus; für die Migration muss keine Hardware ausgetauscht werden.
Der Kerngedanke kehrt an diesem Punkt noch einmal zurück: Die TLS-1.3-Migration und die PQC-Migration für 2030 sind derselbe Konfigurationspfad. Die Hardware-Beschleunigung ist die Komponente, die die Kosten beider operativ unsichtbar macht.
Referenzen und Quellen
Die Protokollspezifikation mit dem 1-RTT-Handshake-Design, 0-RTT-Daten, verpflichtender Forward Secrecy und entfernten alten Cipher Suites. https://datatracker.ietf.org/doc/html/rfc8446
Die aktuelle Version des Payment Card Industry Data Security Standard. Der vollständige Übergang wurde im März 2025 abgeschlossen. https://www.pcisecuritystandards.org/document_library/
Der Federal Information Processing Standard für die Validierung kryptografischer Module. https://csrc.nist.gov/projects/cryptographic-module-validation-program
Regulation (EU) 2022/2554, die Anforderungen an die operative Resilienz für Finanzinstitute einführt, einschließlich kryptografischer Agilität. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Commercial National Security Algorithm Suite 2.0 — TLS 1.3 als Standardprotokoll unter dem PQC-Migrationszeitplan. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
Modernes TLS, moderne Hardware
Die hardwarebeschleunigte SSL-Verarbeitung von TR7 trägt TLS 1.3 mit 0-RTT, hybridem ML-KEM-Schlüsselaustausch und etwa 95 Prozent CPU-Auslagerung gegenüber reiner Software. Die TLS-1.3-Migration und die PQC-Story für 2030 sind derselbe Konfigurationspfad.
TR7 SSL-Beschleunigung entdecken