Bis Ende 2026 sollen alle EU-Mitgliedstaaten mit dem Übergang zur Post-Quanten-Kryptografie beginnen, Anwendungen mit hohem Risiko sollen bis spätestens Ende 2030 umgestellt sein. Das empfiehlt der Fahrplan der NIS-Kooperationsgruppe, den die Europäische Kommission am 23. Juni 2025 veröffentlicht hat. Als ersten Schritt für jede Organisation nennt er ein Inventar der Stellen, an denen Kryptografie arbeitet.
Auf Mobilgeräten ist ein Teil der Arbeit schon erledigt, und zwar vom Hersteller. iPhones und iPads bieten seit iOS 26 beim Verbindungsaufbau über TLS 1.3 von sich aus einen hybriden, quantensicheren Schlüsselaustausch an. Ob er zustande kommt, entscheidet der Server auf der anderen Seite.
Der Fahrplan setzt drei Meilensteine, jeweils zum 31. Dezember. Er richtet sich an die Mitgliedstaaten und ist eine Empfehlung, die sie in nationale Übergangspläne übersetzen sollen (Roadmap, Version 1.1, S. 7).
Was „hohes Risiko“ heißt, bemisst der Fahrplan an der Schutzdauer der Daten. Schützt ein Public-Key-Verfahren Informationen, deren Offenlegung nach zehn oder mehr Jahren noch erheblichen Schaden anrichten würde, gilt der Anwendungsfall als Hochrisiko. Der Grund: Verschlüsselter Verkehr lässt sich heute mitschneiden und später entschlüsseln, sobald ein ausreichend großer Quantencomputer existiert. Für diese Fälle sollen klassische Public-Key-Verfahren nach Ende 2030 nicht mehr allein eingesetzt werden, empfohlen sind standardisierte und getestete hybride Lösungen.
Die Pressemitteilung der Kommission spricht an dieser Stelle von kritischen Infrastrukturen. Für die eigene Planung ist das Kriterium aus dem Fahrplan das brauchbarere. Es lässt sich an den eigenen Daten prüfen, unabhängig von der Branche.
Das iPhone ja, beim Schlüsselaustausch in TLS 1.3. Seit iOS 26, iPadOS 26, macOS Tahoe 26 und visionOS 26 bieten TLS-geschützte Verbindungen automatisch das hybride Verfahren X25519MLKEM768 an (Apple, 18.06.2026). Es kombiniert das klassische X25519 mit dem Post-Quanten-Verfahren ML-KEM (RFC 10024). Unterstützt der Server das Verfahren nicht, wählt er eine andere angebotene Gruppe, und die Verbindung kommt klassisch zustande.
Bei Android 17 betrifft der Post-Quanten-Eintrag in der Entwicklerdokumentation die App-Signatur. Ein neues hybrides Signaturschema koppelt einen klassischen RSA- oder EC-Schlüssel mit ML-DSA (Android Developers). Das schützt die Identität einer App gegen künftige Fälschung, nicht die Verbindung, über die sie Daten austauscht.
Die App-Signatur ist nicht die einzige Stelle. Im ISEC7-Webcast zu Android 17 vom 11. Juni 2026 haben Oliver Schiemann und Magnus Wonschik auch den Bootprozess und die Remote Attestation genannt, mit der das Gerät dem UEM bestätigt, dass es nicht manipuliert wurde. Google beschreibt beides im Security-Blog vom 25. März 2026: Android Verified Boot bekommt ML-DSA, und die Remote Attestation beginnt den Übergang zu quantenresistenten Zertifikatsketten. Auch das sichert das Gerät, nicht den Datenverkehr. Für Administratoren sahen die beiden zunächst keinen Handlungsbedarf.
Ob der Schutz im Datenverkehr greift, entscheidet damit der Server.
Zwei Dinge: ob die Server das Verfahren aushandeln, und ob sie mit der größeren ersten Nachricht zurechtkommen. Ein ClientHello mit ML-KEM-Schlüsselanteil passt nicht mehr in ein einzelnes Paket. Apple weist darauf hin, dass Geräte mit iOS 26 an manchen älteren Servern scheitern können, deren TLS-Implementierung große ClientHello-Nachrichten nicht korrekt liest. Nach der Beschreibung auf tldr.fail, auf die Apple verweist, betrifft das neben Servern auch Middleboxes, die TLS-Verbindungen annehmen.
Prüfen lässt sich beides vom Mac. Ab macOS Tahoe 26 zeigt der Befehl nscurl --tls-diagnostics mit der Adresse eines HTTPS-Servers, welche Gruppe ausgehandelt wurde. Steht dort X25519MLKEM768, unterstützt der Server das Verfahren. Sinnvoll ist der Test an den Endpunkten, die Mobilgeräte täglich ansprechen: Mail, UEM, Intranet, Reverse Proxy.
Das BSI empfiehlt klassische Schlüsseleinigungsverfahren allein nur noch bis Ende 2031. Für Anwendungen mit sehr hohem Schutzbedarf sollte die Umstellung bis Ende 2030 erfolgen, quantensichere Verfahren sollten hybrid eingesetzt werden (TR-02102-1, Version 2026-01). Teil 2 der Richtlinie empfiehlt TLS 1.2 nur noch bis Ende 2031, weil für TLS 1.2 nach derzeitigem Stand keine quantensicheren Schlüsseleinigungsverfahren standardisiert werden (TR-02102-2, Version 2026-01).
Für Apple-Geräte kommt eine Grenze nach unten dazu. Ab iOS 27 können sie Verbindungen zu Servern mit veralteter TLS-Konfiguration ablehnen, unter anderem bei MDM, App-Installation und Software-Updates. Die Server müssen mindestens TLS 1.2 unterstützen, Apple empfiehlt, wo möglich TLS 1.3 auszuhandeln (Apple, 09.06.2026). Darauf haben Oliver Schiemann und Magnus Wonschik im ISEC7-Webcast zu iOS 27 vom 14. Juli 2026 hingewiesen. Zwischen UEM und Gerät ist TLS 1.2 damit das Mindeste, was Apple zulässt, und nach der TR ein Verfahren mit Ablaufdatum.
Eine Einzelheit zählt für alle, die ihre Server nach der TR einstellen. Teil 2 kündigt an, die hybriden Verfahren SecP256r1MLKEM768 und SecP384r1MLKEM1024 zu empfehlen, sobald der zugehörige RFC verabschiedet ist. Das ist mit RFC 10024 im August 2026 geschehen. Derselbe RFC definiert auch X25519MLKEM768, das Verfahren, das Apple nennt. X25519 steht in der TLS-1.3-Tabelle der TR in der Fassung 2026-01 nicht. Wer streng nach dieser Tabelle konfiguriert, sollte deshalb nachsehen, was mit Apple-Geräten tatsächlich ausgehandelt wird.
Ein Kryptoinventar listet, wo in der eigenen Umgebung Kryptografie arbeitet und welche Daten sie schützt. Der EU-Fahrplan nennt es einen Schritt, der sich in jedem Fall lohnt, weil er auch Schwachstellen- und Vorfallsmanagement unterstützt. Als Format empfiehlt er die Cryptographic Bill of Materials (CBOM), eine Erweiterung der SBOM. Dazu kommen eine Karte der Abhängigkeiten und das Gespräch mit Lieferanten über deren eigene PQC-Planung.
Für den mobilen Teil der Umgebung helfen vier Fragen:
Bei Frage 3 setzt ISEC7 SPHERE an: Es überwacht die eingesetzten Zertifikate und liefert Reports mit ihren Parametern. Beratung und Implementierung für Post-Quantum-sichere Kommunikation gehören zu ISEC7 Endpoint Security, die Produkte dafür kommen von strategischen Partnern. Warum heutige Schlüsselaustausche überhaupt angreifbar werden, erklärt unser englischer Grundlagenbeitrag Demystifying Cybersecurity: Post-Quantum Security, Part 1. Teil 2 derselben Reihe ordnet Post-Quanten-Kryptografie neben Verfahren wie Quantum Key Distribution ein. Die Aufzeichnungen der beiden genannten Webcasts erhalten Sie kostenfrei nach Registrierung, kommende Termine stehen in der Webcast-Übersicht.
Drei Meilensteine. Bis 31. Dezember 2026 sollen die Mitgliedstaaten erste Schritte umgesetzt, nationale Fahrpläne aufgestellt und Pilotprojekte begonnen haben. Bis Ende 2030 soll der Übergang für Anwendungen mit hohem Risiko abgeschlossen sein, bis Ende 2035 für mittleres Risiko. Der Fahrplan stammt von der NIS-Kooperationsgruppe und wurde am 23. Juni 2025 veröffentlicht.
Ja, beim Verbindungsaufbau über TLS 1.3. Seit iOS 26 bieten iPhones automatisch den hybriden Schlüsselaustausch X25519MLKEM768 an, der das klassische X25519 mit ML-KEM kombiniert. Zustande kommt er nur, wenn der Server das Verfahren unterstützt. Sonst wählt der Server eine andere angebotene Gruppe, und die Verbindung läuft klassisch.
Nein, er ist eine Empfehlung an die Mitgliedstaaten, die sie in nationale Übergangspläne übersetzen sollen. Der Fahrplan verweist aber darauf, dass NIS2 und DORA Risikomaßnahmen einschließlich Kryptografie nach dem Stand der Technik verlangen. In Deutschland beschreibt das BSI in der TR-02102 die Fristen für den Wechsel auf quantensichere Verfahren.
Eine laufend gepflegte Liste, wo in der eigenen Umgebung Kryptografie arbeitet, mit welchen Verfahren, Schlüsseln und Zertifikaten und welche Daten sie schützt. Der EU-Fahrplan nennt sie den ersten Schritt für jede Organisation und empfiehlt ein standardisiertes Format wie die Cryptographic Bill of Materials (CBOM), eine Erweiterung der SBOM.