Der BSI-Mindeststandard für TLS und die Technische Richtlinie TR-02102-2 erfüllen unterschiedliche Aufgaben: Der Mindeststandard legt Anforderungen für seinen Adressatenkreis fest, die Richtlinie beschreibt kryptografische Empfehlungen. Für eine belastbare Konfiguration müssen deshalb Dokumentfassung, Geltungsbereich und tatsächlicher Kommunikationsweg zusammenpassen. Eine Versionsnummer allein beweist noch keine sichere Verbindung.
Dieser Leitfaden berücksichtigt den am 28. September 2026 geprüften Mindeststandard Version 2.4 vom 25. Mai 2023 und die TR-02102-2, Ausgabe 2026-01 vom 27. Januar 2026. Er zeigt, wie Verantwortliche daraus ein prüfbares TLS-Profil ableiten. Die allgemeinere Einordnung der Verfahren finden Sie bei den Kryptografie-Empfehlungen der TR-02102.
Für wen sind die Anforderungen verbindlich?
Der TLS-Mindeststandard Version 2.4 wurde unter dem damaligen § 8 BSIG veröffentlicht. Die aktuelle gesetzliche Grundlage für Mindestanforderungen der Bundesverwaltung steht in § 44 BSIG. Der konkrete Adressatenkreis und die gesetzlich vorgesehenen Ausnahmen sind zu beachten. „Für alle deutschen Behörden“ wäre als pauschale Beschreibung zu weit.
Private Unternehmen werden durch diesen Mindeststandard nicht unterschiedslos zu Bundesbehörden. Verbindlichkeit kann sich in ihrem Fall aus anderen Vorschriften, konkreten Vertragsanforderungen oder einer eigenen übernommenen Sicherheitsvorgabe ergeben. Artikel 32 DSGVO verlangt risikogerechte Maßnahmen unter Berücksichtigung unter anderem von Stand der Technik, Umsetzungskosten und Verarbeitungsumständen. Daraus entsteht kein allgemeines gesetzliches Gebot, ausschließlich TLS 1.3 einzusetzen.
Der Mindeststandard selbst schreibt auch nicht vor, dass jede Transportabsicherung zwingend mit TLS erfolgen muss. Andere geeignete Verfahren bleiben möglich, sofern das angestrebte Sicherheitsniveau nicht eingeschränkt wird. Wird TLS in seinem Anwendungsbereich eingesetzt, greifen die dort formulierten Anforderungen. Zusätzlicher Schutzbedarf kann über diese Mindestanforderungen hinausgehen; die Einhaltung eines Profils ersetzt deshalb keine Betrachtung des Gesamtsystems.
Was die aktuellen Fassungen zu TLS-Versionen sagen
Die TR-02102-2, Ausgabe 2026-01 empfiehlt in Tabelle 2 TLS 1.3 bis 2032+ und TLS 1.2 bis Ende 2031. TLS 1.3 soll bevorzugt werden. Das Pluszeichen bedeutet, dass eine spätere Ausgabe den Zeitraum möglicherweise verlängert; es ist keine unbegrenzte Sicherheitszusage. Einzelne Verfahren können kürzere Verwendungszeiträume haben als die Protokollversion.
Der Mindeststandard verlangt TLS 1.2 und/oder TLS 1.3 und die Deaktivierung anderer Versionen. Bei Neubeschaffungen für den Produktivbetrieb ist auf TLS-1.3-Kompatibilität zu achten. Das unterscheidet sich von der Behauptung, jeder neue Dienst dürfe ausschließlich TLS 1.3 sprechen. Die Auswahl muss zusätzlich zu den kryptografischen Vorgaben und den dokumentierten Anforderungen des Dienstes passen.
TLS 1.0 und 1.1 sind auch nach RFC 8996 abgekündigt. Ermitteln Sie vorhandene Altverbindungen und ihre fachliche Ursache. Ein stillschweigend aktivierter Rückfall auf eine alte Version löst das Kompatibilitätsproblem nur auf Kosten des Schutzes. Im Anwendungsbereich des Mindeststandards sind Abweichungen nur nach dessen besonderen Regeln, einschließlich sachlicher Begründung und Rücksprache mit dem BSI, zu behandeln.
Für die Migration ist die Nutzungsdauer der beschafften Komponente wichtig. Ein heute eingeführtes Gateway kann noch nach 2031 betrieben werden. Fragen Sie deshalb nach Aktualisierbarkeit und Unterstützung künftiger Profile. Eine langfristige Beschaffung sollte nicht allein darauf beruhen, dass eine momentan noch empfohlene Konfiguration den ersten Abnahmetest besteht.
Cipher-Suiten nicht zwischen Protokollversionen verwechseln
Bei TLS 1.2 enthält eine Cipher-Suite Angaben zu mehreren Teilen des Verfahrens. Bei TLS 1.3 beschreibt ihr Name dagegen das Verfahren zur authentisierten Verschlüsselung und die Hashfunktion; Schlüsseleinigung und Signatur werden zusätzlich ausgewählt. RFC 8446 beschreibt dieses Protokoll. Eine Liste von TLS-1.3-Suiten ist deshalb noch kein vollständiges Sicherheitsprofil.
Tabelle 13 der BSI-Ausgabe 2026-01 nennt für TLS 1.3 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 und TLS_AES_128_CCM_SHA256. ChaCha20-Poly1305 steht in dieser Tabelle nicht. Daraus folgt weder eine BSI-Empfehlung für diese Suite noch automatisch das Urteil, jedes nicht genannte Verfahren sei unsicher. Wer eine BSI-konforme Auswahl nachweisen will, muss sich auf die tatsächlich einschlägige Liste und deren Bedingungen beziehen.
Auch die pauschale Aussage „CBC ist beim BSI ausgeschlossen“ ist falsch. Die TLS-1.2-Tabellen enthalten bestimmte CBC-Suiten, deren Verwendung nur zusammen mit der Erweiterung Encrypt-then-MAC empfohlen wird. Eine Organisation kann aus Gründen der Vereinfachung ein engeres Profil mit geeigneten AEAD-Verfahren wählen. Sie sollte diese eigene Auswahl jedoch nicht als wörtliche BSI-Vorgabe ausgeben.
Für die Umsetzung empfiehlt sich eine kleine freigegebene Kombination statt einer wahllosen Sammlung sämtlicher verfügbarer Optionen. Ordnen Sie IANA-Bezeichnungen den Konfigurationsnamen der tatsächlich eingesetzten Bibliothek zu. Prüfen Sie danach, was der Endpunkt wirklich anbietet. Eine Konfigurationsdatei kann unwirksame Namen enthalten oder durch die Voreinstellungen eines vorgeschalteten Dienstes überlagert werden.
Forward Secrecy, Schlüssel und Signaturen getrennt prüfen
Perfect Forward Secrecy schützt frühere Verbindungen gegen nachträgliche Entschlüsselung allein durch die Kenntnis langfristiger Schlüssel. Der Mindeststandard fordert diese Eigenschaft für die verwendeten kryptografischen Verfahren. Die technische Richtlinie beschreibt daneben bestimmte Sonderfälle ohne diese Eigenschaft. Solche Einträge dürfen nicht isoliert aus der Richtlinie übernommen werden, wenn zugleich das strengere Profil des Mindeststandards einzuhalten ist.
Bei TLS 1.3 lohnt ein gesonderter Blick auf Wiederaufnahmeverfahren. Die Richtlinie weist darauf hin, dass der reine PSK-Modus psk_ke keine Forward Secrecy bietet. Ebenso werden 0-RTT-Daten wegen fehlenden Schutzes gegen Wiederholungsangriffe nicht empfohlen. Eine schnellere Wiederaufnahme ist daher nicht automatisch für einen Vorgang geeignet, der eine Bestellung, Zahlung oder andere Zustandsänderung auslöst.
Tabelle 14 nennt unter anderem 3000 Bit für RSA und DH sowie 250 Bit für ECDSA und ECDH als Mindestschlüssellängen. Die zugehörigen Zeitangaben und Hinweise gehören dazu: Der alleinige Einsatz klassischer Diffie-Hellman-Verfahren wird nur bis Ende 2031 empfohlen; die dort für spätere Jahre genannten Längen beziehen sich auf einen hybriden Einsatz mit quantensicheren Verfahren. Eine nackte Schlüssellänge verschweigt diese Einschränkung.
Die Wahl einer Signatur ist eine weitere Entscheidung. Ein RSA-Schlüssel kann mit unterschiedlichen Signaturverfahren eingesetzt werden. Die Ausgabe 2026-01 grenzt insbesondere RSA mit PKCS-#1-v1.5-Padding von RSA-PSS ab. Prüfen Sie sowohl die Signatur im Handshake als auch die Zertifikatskette. Dass ein Browser die Verbindung akzeptiert, beweist noch nicht die Übereinstimmung mit dem ausgewählten BSI-Profil.
Zertifikate und Erneuerung als Betriebsaufgabe
Ein Zertifikat muss zum angesprochenen Dienst passen und über einen vertrauenswürdigen Pfad geprüft werden. Kontrollieren Sie Namen, Gültigkeit, Kette und die Anforderungen des jeweiligen Clients. Das Abschalten der Zertifikatsprüfung beseitigt Fehlermeldungen, untergräbt aber die Authentisierung. Gerade interne Anwendungen dürfen einen privaten Zertifikatsaussteller nicht mit dem Verzicht auf Prüfung verwechseln.
Für öffentlich vertrauenswürdige TLS-Serverzertifikate gelten außerdem Regeln des Browser- und Zertifikatsökosystems. Die CA/Browser-Forum Baseline Requirements, Version 2.3.0 vom 7. September 2026 begrenzen in Abschnitt 6.3.2 die Laufzeit der vom 15. März 2026 bis vor dem 15. März 2027 ausgestellten betroffenen Zertifikate auf 200 Tage. Die ältere pauschale Angabe von 398 Tagen ist dafür nicht mehr aktuell. Rein interne PKI-Systeme fallen nicht allein deshalb unter denselben Geltungsbereich.
Automatisierte Erneuerung sollte deshalb mit Überwachung verbunden sein. Prüfen Sie, ob ein neues Zertifikat auf sämtlichen Instanzen geladen wird und ob der erforderliche Neustart oder Neuladevorgang tatsächlich stattfindet. Ein erfolgreicher Bezug beim Zertifikatsaussteller reicht nicht, wenn ein einzelner Server weiterhin das alte Zertifikat ausliefert. Alarmierungen brauchen erreichbare Zuständige und einen funktionierenden Eskalationsweg.
Behandeln Sie private Schlüssel entsprechend ihrem Schutzbedarf. Begrenzen Sie Kopien und Zugriffsrechte, sichern Sie den Austausch bei einem Verdacht auf Kompromittierung und klären Sie die Verantwortlichkeit des Dienstleisters. Die allgemeine Verschlüsselung personenbezogener Daten umfasst mehr als die Auswahl eines Algorithmus: Schlüsselverwaltung und betriebliche Wiederherstellung entscheiden wesentlich über die tatsächliche Schutzwirkung.
Den vollständigen Kommunikationsweg aufnehmen
Viele Webdienste bestehen aus Browser, CDN, Load Balancer, Anwendung und weiteren Schnittstellen. TLS kann an einem vorgeschalteten System enden. Zeichnen Sie deshalb auf, an welcher Stelle Klartext verfügbar wird und wie die nächste Verbindung abgesichert ist. Eine gute Bewertung der öffentlich sichtbaren Adresse sagt noch nichts über die Verbindung vom Proxy zum Backend aus.
Die erneute Verschlüsselung zum Backend ist häufig eine sinnvolle Maßnahme. Ihre genaue Ausgestaltung folgt aus Architektur, Netzvertrauen und Schutzbedarf; eine pauschale Behauptung eines immer identischen gesetzlichen Verschlüsselungsgebots wäre zu grob. Wo TLS eingesetzt wird, muss auch dort die Gegenstelle geprüft werden. Verschlüsselung ohne belastbare Authentisierung kann das angestrebte Sicherheitsziel verfehlen.
Bei einem Cloud-Dienst fragen Sie nach dem tatsächlichen Verantwortungsanteil des Anbieters. Wer verwaltet das Zertifikat, wer bestimmt die Cipher-Auswahl und wer liefert Nachweise bei einer Änderung? Der BSI-C5-Katalog kann bei der Bewertung von Anbieterkontrollen helfen. Er ersetzt nicht die eigene Prüfung, ob der gebuchte Dienst und die gewählte Konfiguration von einem konkreten Nachweis erfasst sind.
HSTS bewusst einführen
HSTS teilt einem Browser mit, dass er den betreffenden Host während eines angegebenen Zeitraums nur über HTTPS ansprechen soll. RFC 6797 definiert dafür unter anderem max-age und die optionale Einbeziehung von Subdomains. Daraus folgt keine allgemeine gesetzliche Pflicht, jede öffentliche Website mit genau einem Jahr Laufzeit zu konfigurieren.
Prüfen Sie vor der Einbeziehung von Subdomains, ob sämtliche betroffenen Dienste zuverlässig HTTPS unterstützen. Ein übersehener Altname kann nach einer breiten Aktivierung unerreichbar werden. Beginnen Sie mit einer überprüfbaren Einführung und verlängern Sie den Zeitraum erst nach erfolgreicher Beobachtung. Für eine Aufnahme in Browser-Vorladelisten gelten zusätzliche Bedingungen und ein eigener Änderungsprozess.
HSTS schützt nicht vor einer kompromittierten Anwendung oder falsch berechtigten Benutzerkonten. Es verhindert auch nicht, dass sensible Inhalte in Serverprotokollen gespeichert werden. Ordnen Sie die Maßnahme ihrem konkreten Schutzziel zu. Diese Trennung macht es leichter, verbleibende Risiken sachlich zu erklären und zusätzliche Maßnahmen dort einzusetzen, wo sie tatsächlich benötigt werden.
Konfiguration messen und Befunde bearbeiten
Erstellen Sie zunächst eine vollständige Liste der eigenen Endpunkte einschließlich alternativer Namen, Ports, IPv4- und IPv6-Adressen. Bei mehreren Betriebsstandorten oder vorgeschalteten Diensten kann das Ergebnis je Route unterschiedlich ausfallen. Halten Sie deshalb fest, welcher Endpunkt zu welchem Zeitpunkt mit welchem Profil überprüft wurde. Ein einzelner Scan des Hauptnamens ist kein vollständiges Inventar.
Ein automatisierter TLS-Scan hilft, angebotene Versionen, Verfahren und Zertifikatsprobleme sichtbar zu machen. Bewerten Sie konkrete Befunde gegen Ihre Anforderungen, statt allein eine Gesamtnote zu verfolgen. Die Note eines öffentlichen Prüfservices kann andere Kriterien gewichten als der BSI-Mindeststandard. Vertiefende Penetrationstests untersuchen weitere Angriffsmöglichkeiten, ersetzen aber ebenfalls nicht die laufende Konfigurationskontrolle.
Eine Abweichung sollte an die fachlich und technisch zuständige Stelle gelangen. Dokumentieren Sie den betroffenen Datenfluss, das Risiko, die vorgesehene Korrektur und einen begründeten Termin. Die Risikoanalyse nach BSI 200-3 hilft, solche Entscheidungen strukturiert einzuordnen. Im verbindlichen Mindeststandard müssen zusätzlich dessen Regeln für Ausnahmen eingehalten werden; eine interne Risikoakzeptanz allein genügt dort nicht. Erforderlich sind unter anderem dokumentierte Risiken, Gegenmaßnahmen und Restrisiken sowie ein angemessener Zeit- und Maßnahmenplan zur Ablösung. Restrisikodokumentation und Ablöseplan sind der jeweiligen Leitung zur Zustimmung vorzulegen.
Beispiel: ein Portal mit altem Integrationsclient
Ein fiktives Kundenportal bietet für aktuelle Browser TLS 1.3 an. Ein angebundenes Fachverfahren unterstützt nur eine bestimmte TLS-1.2-Konfiguration. Die erste Frage lautet, ob diese Kombination im gewählten Profil tatsächlich empfohlen wird und die notwendigen Eigenschaften besitzt. „TLS 1.2“ allein ist weder ein ausreichender Freigabegrund noch automatisch ein Ablehnungsgrund.
Die Betreiber untersuchen anschließend, ob der alte Client einen separaten, eng begrenzten Zugang benötigt und wann er aktualisiert werden kann. Sie prüfen gegenseitige Authentisierung, Zertifikatswechsel und die betroffenen Informationen. Eine zeitlich befristete Lösung mit einer klaren Migrationsverantwortung ist besser steuerbar als eine unbemerkte globale Erweiterung der erlaubten Verfahren für sämtliche Benutzer des Portals.
Nach der Änderung werden erlaubte und unerwünschte Verbindungen überprüft. Zugleich kontrolliert das Team den Weg zum Backend, damit die Verbesserung nicht an der ersten TLS-Terminierung endet. Die Abnahme dokumentiert sowohl die weiterhin funktionierende fachliche Schnittstelle als auch die tatsächlich ausgeschlossenen alten Optionen. Diese Nachweise lassen sich später bei einem Versionswechsel gezielt wiederverwenden.
Übergabe zwischen Einkauf und Administration
Bei einem neuen Dienst sollten Einkauf und Betrieb dieselbe Anforderung verwenden. Eine Ausschreibung, die nur „TLS nach BSI“ verlangt, lässt offen, welche Fassung, welche Endpunkte und welcher Nachweis gemeint sind. Benennen Sie daher den maßgeblichen Mindeststandard beziehungsweise die technische Richtlinie, den eigenen Geltungsbereich und die erwarteten überprüfbaren Eigenschaften. Halten Sie zusätzlich fest, wie neue Fassungen während der Vertragslaufzeit bewertet werden.
Ein Anbieter kann beispielsweise die öffentliche Schnittstelle verwalten, während die interne Anbindung beim Kunden liegt. Für beide Teile braucht es eine eindeutige Zuständigkeit. Fragen Sie, ob Konfigurationsänderungen angekündigt werden, wie Zertifikatsprobleme eskaliert werden und welche Daten ein Prüfbericht tatsächlich umfasst. Eine allgemeine Unternehmenszertifizierung beantwortet diese konkreten Fragen nicht zwangsläufig.
Für die Abnahme sollte eine fachlich repräsentative Verbindung beobachtet werden. Ein erfolgreicher Browseraufruf reicht nicht, wenn das eigentliche Fachverfahren einen anderen Host, Port oder Vertrauensspeicher benutzt. Lassen Sie auch den Fehlerfall zeigen: Ein abgelaufenes oder für einen falschen Namen ausgestelltes Zertifikat muss entsprechend dem vorgesehenen Prüfverfahren erkannt werden. Solche kontrollierten Beobachtungen liefern mehr Aussagekraft als eine bloße Zusage, Verschlüsselung sei aktiviert.
Nach der Übergabe bleiben Änderungen ein gemeinsamer Vorgang. Wenn ein vorgeschalteter Dienst neue Standardeinstellungen erhält, kann das bisherige Profil unbemerkt abweichen. Verknüpfen Sie deshalb die technische Beobachtung mit einem verantworteten Änderungsprozess. Die dokumentierte Abnahme ist der Ausgangspunkt für den Betrieb und muss bei relevanten Änderungen aktualisiert werden.
Datenschutz, Nachweise und laufende Pflege
Die TLS-Entscheidung gehört in den Maßnahmenkatalog und in das Informationssicherheitsmanagement. Die BSI-Grundschutz-Methodik und ein Managementsystem nach ISO 27001 können Verantwortlichkeiten und Überprüfungen strukturieren. Eine Zertifizierung ersetzt jedoch weder die Prüfung eines konkreten Endpunkts noch sämtliche Anforderungen aus NIS2 in Deutschland.
Protokolle der Verbindungsprüfung sollten keine unnötigen personenbezogenen Inhalte enthalten. Ihre Speicherbegrenzung ist gesondert festzulegen. Wird eine tatsächliche Verletzung des Schutzes personenbezogener Daten festgestellt, ist die Meldung einer Datenpanne anhand von Artikel 33 DSGVO zu prüfen. Eine veraltete Konfiguration allein ist noch nicht der Nachweis eines solchen Vorfalls.
Auch DSGVO-Bußgelder folgen keiner festen TLS-Preisliste. Maßgeblich sind die rechtlichen Voraussetzungen und die konkreten Umstände. Für den Betrieb ist deshalb wichtiger, Abweichungen zu erkennen und begründet zu behandeln, als einen hypothetischen Standardbetrag zu nennen. Bewahren Sie die verwendete Richtlinienfassung zusammen mit Ihrem Profil auf und prüfen Sie bei jeder neuen Ausgabe, welche Änderungen Ihre Endpunkte tatsächlich betreffen.