Ihr Altsystem funktioniert. Aber ist es bis 2030 noch migrationsfähig?

Ausgabe 15 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Verantwortliche von Alt- und Industriesystemen: Prüfstände, Fertigungssteuerung, Fachanwendungen mit langer Laufzeit.

Die Prüfstandssoftware läuft seit 2014 ohne nennenswerten Ausfall. Ein slowenischer Dienstleister pflegt sie, zuverlässig und günstig. Sie läuft auf einem Server, dessen Betriebssystem keine Sicherheitsupdates mehr erhält, und spricht mit dem ERP-System über eine Schnittstelle, deren Bibliothek seit Jahren nicht aktualisiert wurde. „Never touch a running system“ war lange eine vernünftige Regel. Für die Post-Quanten-Umstellung ist sie keine.

In diesem Beitrag: „Funktioniert“ ist kein Kriterium · Fünf Fragen an den Lieferanten · Vier Wege · Akzeptable Ersatzmaßnahmen · Beispiel · Altsysteme beim Lieferanten · Was Sie nicht verlangen sollten · Die Frage an Ihren Lieferanten · Anhang: Entscheidungsbaum

Ein Altsystem kann fachlich einwandfrei arbeiten und kryptografisch in einer Sackgasse stecken. Das liegt selten an der Anwendung selbst, sondern an dem, worauf sie steht:

• Betriebssystem: Neue kryptografische Verfahren kommen über die Kryptografie-Schnittstellen des Betriebssystems oder über Bibliotheken, die eine aktuelle Plattform voraussetzen. Eine Version ohne Herstellersupport bekommt sie nicht.
• Laufzeitumgebung: Java erhielt Schnittstellen für ML-KEM und ML-DSA mit Version 24 (März 2025). Eine Anwendung auf Java 8 bekommt sie nicht, ohne dass die Laufzeit und meist auch die Anwendung angepasst werden.
• Bibliotheken: OpenSSL unterstützt Post-Quanten-Verfahren seit Version 3.5 (April 2025). Die Reihe 1.1.1 wird seit September 2023 nicht mehr öffentlich gepflegt.
• Protokolle und Formate: Eine Schnittstelle, die nur TLS 1.2 kann, oder ein Dateiformat mit fester Feldgröße für Signaturen lässt sich nicht durch eine Einstellung umstellen.
• Geräte: Steuerungen, Messgeräte und Terminals mit fester Firmware ändern ihre Kryptografie nur, wenn der Hersteller ein Update liefert.

Die Frage für 2030 lautet deshalb nicht „Läuft es?“, sondern: „Kann es ein neues Verfahren aufnehmen, und wenn nicht, was dann?“ Das Jahr ist nicht willkürlich: Die EU-Roadmap vom Juni 2025 empfiehlt, Anwendungsfälle mit hohem Risiko bis Ende 2030 umzustellen.

1. Plattform: Auf welchem Betriebssystem und welcher Laufzeit läuft das System, und bis wann gibt es dafür Sicherheitsupdates?
2. Kryptografie: Welche Bibliotheken und Verfahren nutzt das System für Verbindungen, Signaturen und gespeicherte Daten, und wo sind sie festgelegt (siehe Ausgabe 13)?
3. Schnittstellen und Formate: Welche Protokolle und Datenformate verwendet es nach außen, und haben sie Platz für größere Schlüssel und Signaturen?
4. Austauschbarkeit: Lässt sich die Plattform aktualisieren, ohne die Anwendung neu zu entwickeln? Wenn nicht: Was müsste geändert werden, und mit welchem Aufwand?
5. Perspektive: Gibt es eine Nachfolgeversion oder einen Plan? Was deckt der bestehende Wartungsvertrag ab?

Rechnen Sie bei Altsystemen damit, dass der Lieferant einige dieser Fragen nicht sofort beantworten kann. Das ist kein Versagen, sondern ein Befund. Die Fragen selbst sind der Anfang der Bestandsaufnahme.

Wenn ein Altsystem nicht direkt umgestellt werden kann, bleiben vier Wege:

• Migrieren: Plattform, Laufzeit oder Bibliothek aktualisieren, Anwendung anpassen. Der sauberste Weg, wenn Aufwand und Risiko tragbar sind.
• Kapseln: Das System bleibt, wie es ist, wird aber abgeschirmt. Ein vorgeschalteter Knoten übernimmt die Verbindung nach außen mit aktuellen Verfahren; das Altsystem spricht klassisch nur noch über ein kurzes, kontrolliertes Netzsegment. Der Schutz der Daten im Altsystem selbst ändert sich dadurch nicht.
• Ersetzen: Das System wird durch ein neues abgelöst. Oft ohnehin geplant; dann gehört die Post-Quanten-Fähigkeit in die Anforderungen des Nachfolgers.
• Befristet abweichen: Das Risiko wird bewusst getragen, dokumentiert, mit Verantwortlichem und Ablaufdatum. Keine Dauerlösung, aber eine ehrliche Zwischenlösung.

Welcher Weg passt, hängt von Schutzdauer und Schaden (Ausgabe 12) und vom geplanten Lebensende des Systems ab. Ob es fachlich abgelöst werden sollte, ist eine eigene Entscheidung, in die die Kryptografie nur als ein Faktor eingeht. Ein System, das 2028 abgelöst wird, braucht keine aufwendige Migration; ein System, das 2040 noch läuft, schon.

Kapseln und befristetes Abweichen sind Ersatzmaßnahmen. Damit sie mehr sind als eine Ausrede, sollten sie vier Bedingungen erfüllen:

• Bezug: Sie verringern das konkrete Risiko an der konkreten Stelle. Eine Firewall-Regel schützt nicht vor dem Mitschneiden einer Verbindung über das Internet; ein vorgeschaltetes Gateway mit hybridem Schlüsselaustausch auf dem Internetabschnitt schon.
• Verantwortung: Jemand ist benannt, der die Maßnahme betreibt und überprüft.
• Befristung: Sie hat ein Ablaufdatum, das mit dem Lebensende des Systems oder einem Migrationstermin verbunden ist.
• Nachweis: Ihre Wirksamkeit ist geprüft, nicht angenommen, etwa durch eine Messung des ausgehandelten Verfahrens am Gateway (Ausgabe 11).

Eine Maßnahme, die keine dieser Bedingungen erfüllt, ist keine Ersatzmaßnahme, sondern ein Vermerk.

Denken Sie an einen Getriebehersteller in Niederbayern. Er betreibt drei Prüfstände mit einer Software, die ein slowenischer Dienstleister 2014 entwickelt hat und pflegt. Die Prüfprotokolle gehen per SFTP an das ERP-System und werden auf Verlangen an Kunden der Automobilindustrie weitergegeben; sie müssen fünfzehn Jahre aufbewahrt und als echt nachweisbar sein.

Die Antworten des Dienstleisters auf die fünf Fragen:

Die Entscheidung: Migrieren, aber in zwei Stufen. Zuerst Plattform und Laufzeit aktualisieren und die Prüfprotokolle signieren, mit einem Verfahren, das sich später austauschen lässt. Bis dahin wird die SFTP-Verbindung über einen bestehenden, aktualisierten Dateitransfer-Server geführt (Kapseln, befristet bis zum Abschluss der Migration).

Der interessanteste Befund hatte mit Quantenrechnern nichts zu tun: Die Prüfprotokolle waren nie signiert. Die Post-Quanten-Frage hat ein Problem sichtbar gemacht, das schon heute besteht.

Nicht jedes Altsystem, das Ihre Daten verarbeitet, steht bei Ihnen. Beim Lieferanten laufen oft ebenso alte Anwendungen: der Export, der Ihnen Lieferscheine schickt, die Software, die Ihre Zeichnungen empfängt, die Steuerung, die Ihre Bauteile prüft. Sie sehen davon nur die Schnittstelle.

Fragen Sie deshalb nicht nur nach den Systemen, die der Lieferant für Sie betreibt oder pflegt, sondern auch nach denen, die Ihre Daten bei ihm verarbeiten. Die fünf Fragen gelten sinngemäß. Erwarten Sie dabei keine vollständige Offenlegung seiner Infrastruktur; erwarten Sie eine Antwort für die Systeme, die Ihre Daten berühren, mit Plattform, Perspektive und Ansprechpartner. Ein Lieferant, der seine eigenen Altsysteme kennt und einen Plan dafür hat, ist ein geringeres Risiko als einer, der modern wirkt und keine Übersicht hat.

• Keine Zusage für die Plattform anderer. Ein Dienstleister, der eine Anwendung pflegt, kann nicht zusagen, dass der Hersteller des Betriebssystems neue Verfahren nachliefert.
• Keine Umstellung im Rahmen der Fehlerbehebung. Eine Plattformerneuerung ist eine Änderung, auch wenn sie der Sicherheit dient (Ausgabe 12).
• Keine pauschale Ablösung. Ein Altsystem, das gekapselt und befristet betrieben wird, kann die wirtschaftlich richtige Lösung sein.

„Wenn wir die Plattform Ihres Systems bis 2028 erneuern wollten: Was müsste an der Anwendung geändert werden, mit welchem Aufwand, und welche Teile könnten Sie nicht selbst beeinflussen?“

Die Frage gibt einen Zeitrahmen vor, fragt nach Aufwand statt nach Bereitschaft und lässt Raum für die ehrliche Antwort, dass manches nicht beim Dienstleister liegt.

Die slowenische Ausgabe richtet sich an interne IT und Wartungsdienstleister beim Lieferanten: »Deset let stara aplikacija in postkvantna prihodnost: kaj sploh lahko spremenimo?« (auf Slowenisch). Vorherige Ausgabe: Hybride Kryptografie: Was passiert, wenn Ihr Lieferant den neuen Standard noch nicht unterstützt?

Entscheidungsbaum für ein Altsystem (je System einmal durchlaufen). In der slowenischen Ausgabe inhaltlich gleich.

 Schützt das System Daten oder Signaturen mit hoher Schutzdauer
 oder hohem Schaden (Ausgabe 02, 12)?
 ├─ nein ──> befristet abweichen; bei nächster Erneuerung mitnehmen
 └─ ja
     Ist das Lebensende des Systems vor Ende 2030 geplant?
     ├─ ja ───> Nachfolger mit PQC-Anforderung beschaffen (ersetzen);
     │          bis dahin kapseln, wenn möglich
     └─ nein
         Lässt sich die Plattform aktualisieren und das Verfahren
         austauschen, mit vertretbarem Aufwand?
         ├─ ja ───> migrieren
         └─ nein
             Lässt sich die Verbindung nach außen über einen
             aktuellen Knoten führen?
             ├─ ja ───> kapseln (befristet, mit Nachweis)
             │          und Ablösung planen
             └─ nein ──> ersetzen; bis dahin befristet abweichen
                         mit Verantwortlichem und Ablaufdatum

Erfassung je Entscheidung:

Alle erschienenen Ausgaben der Reihe: Übersicht „Post-Quanten-Sicherheit in der Lieferkette“

Nächste Ausgabe (5. 10. 2026): „Die deutsche PQC-Roadmap kommt. Was bedeutet sie für Ihre slowenischen Lieferanten?“

Quellen (Stand 7. 9. 2026): NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025); JEP 496 und 497 (JDK 24, März 2025); OpenSSL 3.5 Release Notes (April 2025); OpenSSL, Ende der öffentlichen Pflege der Reihe 1.1.1 (11. 9. 2023).

Wenn Ihr wichtigstes System auch Ihr ältestes ist: Schreiben Sie uns.