<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1732033&amp;fmt=gif">
Skip to content
All posts

Post-Quanten-Kryptografie auf Mobilgeräten: der EU-Fahrplan ab Ende 2026

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.

Was der EU-Fahrplan für Post-Quanten-Kryptografie vorsieht

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).

  • Bis Ende 2026: Die ersten Schritte sind umgesetzt, jeder Mitgliedstaat hat einen nationalen Fahrplan, Planung und Pilotprojekte für Anwendungen mit hohem und mittlerem Risiko haben begonnen.
  • Bis Ende 2030: Der Übergang für Anwendungen mit hohem Risiko ist abgeschlossen. Quantensichere Software- und Firmware-Updates sind standardmäßig aktiviert.
  • Bis Ende 2035: Der Übergang für mittleres Risiko ist abgeschlossen, für niedriges Risiko so weit wie möglich.

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.

Unterstützen iPhone und Android schon quantensichere Verfahren?

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.

Was am Netz zu prüfen ist, wenn Clients hybride Schlüsselaustausche anbieten

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.

Was das BSI in der TR-02102 empfiehlt

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.

Was ist ein Kryptoinventar, und womit fängt man an?

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:

  1. Welche Verbindungen der Geräte laufen über TLS 1.3, welche noch über TLS 1.2?
  2. Welche Daten auf diesen Wegen müssen zehn Jahre oder länger vertraulich bleiben?
  3. Welche Zertifikate und Schlüssel sind im Einsatz, mit welchem Verfahren und welchem Ablaufdatum?
  4. Welche Hersteller im Pfad, etwa für UEM, Mail oder Gateway, haben Post-Quanten-Verfahren in ihrer Planung?

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.

Häufige Fragen

Was sieht der EU-Fahrplan für Post-Quanten-Kryptografie vor?

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.

Unterstützt das iPhone schon Post-Quanten-Verschlüsselung?

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.

Ist der EU-Fahrplan zur Post-Quanten-Kryptografie verbindlich?

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.

Was ist ein Kryptoinventar?

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.

Quellen

  • NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Part 1, Version 1.1, 11.06.2025, veröffentlicht am 23.06.2025: digital-strategy.ec.europa.eu · PDF
  • Europäische Kommission, „EU reinforces its cybersecurity with post-quantum cryptography“, 23.06.2025: digital-strategy.ec.europa.eu
  • Apple, „Prepare your network for quantum-secure encryption in TLS“, 18.06.2026: support.apple.com
  • IETF, RFC 10024 „Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3“, August 2026: rfc-editor.org
  • tldr.fail, Beschreibung des ClientHello-Fehlers bei Post-Quanten-Schlüsselaustausch: tldr.fail
  • Android Developers, „Android 17 features and APIs“, PQC APK Signing, Stand 16.09.2026: developer.android.com
  • Google, Eric Lynch und Dom Elliott, „Security for the Quantum Era: Implementing Post-Quantum Cryptography in Android“, 25.03.2026: blog.google
  • Apple, „Prepare your network environment for stricter security requirements“, 09.06.2026: support.apple.com
  • BSI, TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, Version 2026-01, Stand 23.01.2026: bsi.bund.de
  • BSI, TR-02102-2 „Verwendung von Transport Layer Security (TLS)“, Version 2026-01, 27.01.2026: bsi.bund.de

ISEC7-Ressourcen

  • ISEC7-Webcast „What’s new in Android 17 for Enterprise?“ mit Oliver Schiemann und Magnus Wonschik, 11.06.2026: isec7.com
  • ISEC7-Webcast „Apple und iOS 27: was für Unternehmen wichtig ist“ mit Oliver Schiemann und Magnus Wonschik, 14.07.2026: isec7.com
  • ISEC7 Blog, „Demystifying Cybersecurity: Post-Quantum Security“, Part 1 und Part 2
  • ISEC7 Endpoint Security: isec7.com · ISEC7 SPHERE: isec7.com