Kryptoagilität: Können Ihre Dienstleister Algorithmen austauschen, ohne Geschäftsprozesse umzubauen?

Ausgabe 13 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für technische Leitung und IT-Beschaffung, die Software und Dienstleistungen einkaufen.

In der Ausschreibung steht: „Die Lösung muss kryptoagil sein.“ Alle fünf Bieter kreuzen „erfüllt“ an. Zwei Jahre später soll die Signatur der Rechnungsdokumente auf ein neues Verfahren umgestellt werden. Der Dienstleister schätzt vier Monate Entwicklung, weil das Verfahren an vierzehn Stellen im Code steht und das Dokumentformat keinen Platz für eine zweite Signatur hat. Gelogen hat niemand. Die Anforderung hat nur nicht gesagt, was sie meint.

In diesem Beitrag: Was Kryptoagilität ist · Sechs beobachtbare Eigenschaften · Ergebnis verlangen, nicht Bauweise · Beispiel · Prüfen in Beschaffung und Abnahme · Ausweichende Antworten · Die Grenzen der Agilität · Die Frage an Ihren Lieferanten · Anhang: Referenzmuster

Kryptoagilität ist die Fähigkeit einer Lösung, kryptografische Verfahren, Parameter und Schlüssel auszutauschen, ohne ihre fachliche Funktion umzubauen. Die EU-Roadmap zur Post-Quanten-Kryptografie vom Juni 2025 nennt sie als einen der nächsten Schritte und empfiehlt, sie in der öffentlichen Beschaffung zu berücksichtigen.

Drei Gleichsetzungen führen in die Irre:

• Kryptoagil ist nicht quantensicher. Agilität beschreibt, wie leicht ein Wechsel ist, nicht, welches Verfahren läuft. Eine kryptoagile Lösung kann heute ausschließlich RSA verwenden; sie kann es nur leichter ersetzen.
• Kryptoagil ist nicht konfigurierbar. Eine Auswahlliste mit drei Verfahren in der Oberfläche hilft nicht, wenn das vierte, das Sie brauchen, nicht darin steht und nur durch eine neue Version kommt.
• Kryptoagil ist nicht kostenlos. Ein Wechsel bleibt ein Änderungsvorhaben mit Tests, Abstimmung mit Gegenstellen und Betrieb. Agilität macht ihn planbar, nicht trivial.

Der Nutzen liegt woanders: Wenn ein Verfahren geschwächt wird, eine Empfehlung sich ändert oder eine Gegenstelle umstellt, entscheidet die Agilität einer Lösung, ob die Reaktion Wochen oder Jahre dauert.

Sie müssen nicht wissen, wie der Dienstleister seinen Code strukturiert. Sie können aber beobachten, wie sich die Lösung verhält. Sechs Eigenschaften lassen sich von außen erfragen und nachweisen:

1. Ort der Auswahl: Wird das Verfahren an einer Stelle festgelegt (Konfiguration, Richtlinie, zentraler Dienst) oder an vielen Stellen im Code?
2. Parallelbetrieb: Kann die Lösung während eines Übergangs altes und neues Verfahren gleichzeitig verarbeiten, etwa alte Signaturen prüfen und neue erzeugen?
3. Kennzeichnung in Daten: Tragen gespeicherte und übertragene Daten eine Angabe, mit welchem Verfahren sie geschützt sind? Ohne diese Angabe lassen sich alte und neue Daten nicht unterscheiden.
4. Größenreserve: Verkraften Datenformate, Datenbankfelder und Protokolle größere Schlüssel und Signaturen? Post-Quanten-Signaturen sind um ein Vielfaches größer als heutige.
5. Testbarkeit: Gibt es automatisierte Tests, die mit einem anderen Verfahren laufen, oder wird ein Wechsel zum ersten Mal in Produktion ausprobiert?
6. Abhängigkeiten: Welche Bibliotheken, Module und Gegenstellen müssen ein neues Verfahren unterstützen, damit die Lösung es nutzen kann?

Jede dieser Fragen hat eine überprüfbare Antwort. „Wir sind kryptoagil“ hat keine.

Die Versuchung ist groß, die Architektur vorzuschreiben: „Kryptografie ist über eine Abstraktionsschicht zu kapseln.“ Das ist gut gemeint und schlecht als Anforderung. Sie können nicht prüfen, ob eine Schicht ihren Zweck erfüllt, und Sie übernehmen eine Mitverantwortung für eine Bauweise, die Sie nicht verantworten können.

Besser ist es, das gewünschte Ergebnis zu beschreiben:

• „Der Wechsel des Signaturverfahrens für Dokumente erfordert keine Änderung der fachlichen Abläufe und keinen Datenumzug.“
• „Während eines Übergangszeitraums von mindestens zwölf Monaten werden mit dem bisherigen Verfahren signierte Dokumente weiterhin geprüft.“
• „Der Lieferant weist die Austauschbarkeit durch einen Test mit einem zweiten, von ihm gewählten Verfahren nach.“

Wie der Dienstleister das erreicht, bleibt seine Sache, und damit auch seine Verantwortung. Ihre Aufgabe ist es, das Ergebnis klar zu benennen und abzunehmen.

Eine Vergabe, wie sie im Mittelstand täglich vorkommt: Ein Logistikunternehmen in Nordrhein-Westfalen schreibt ein Portal für den Austausch signierter Frachtdokumente mit Partnern aus, darunter zwei slowenische Speditionen. Zwei Angebote kommen in die engere Wahl. Statt „kryptoagil ja/nein“ stellt der Einkauf die sechs Fragen:

Beide Bieter hätten „kryptoagil“ angekreuzt. Angebot B ist nicht schlecht; es ist für einen Wechsel nur deutlich teurer. Mit den Antworten kann der Einkauf diesen Unterschied bewerten und, wenn B aus anderen Gründen gewinnt, die fehlenden Punkte als Bedingung in den Vertrag schreiben.

In der Ausschreibung gehören die sechs Fragen in den Kriterienkatalog, mit der Bitte um Nachweis statt Selbsteinschätzung: Architekturbeschreibung des Kryptografieteils, Liste der Abhängigkeiten, Beschreibung des Wechselverfahrens.

In der Abnahme lässt sich Agilität vorführen: Der Dienstleister stellt in einer Testumgebung auf ein zweites Verfahren um und zeigt, dass alte und neue Daten verarbeitet werden. Das muss kein Post-Quanten-Verfahren sein; ein Wechsel zwischen zwei klassischen Verfahren beweist dieselbe Fähigkeit.

Im Betrieb gehört die Fähigkeit in die Wartungsvereinbarung: Wer stellt um, in welcher Frist, nach welcher Ankündigung, und was gilt als Wartung, was als Änderung (siehe Ausgabe 12)?

Nicht jede Antwort auf die sechs Fragen ist gleich viel wert. Einige Muster deuten darauf hin, dass die Fähigkeit eher behauptet als vorhanden ist:

• „Das Verfahren ist konfigurierbar.“ Fragen Sie nach: Welche Verfahren stehen zur Auswahl, und wie kommt ein neues hinzu? Wenn die Antwort „mit dem nächsten Release“ lautet, ist das eine Produktabhängigkeit, keine Konfiguration.
• „Wir nutzen eine Standardbibliothek.“ Das sagt, wer die Verfahren implementiert, nicht, wie die Lösung sie auswählt. Die Bibliothek kann agil sein und der Code darüber nicht.
• „Das ist bei uns kein Problem.“ Ohne Angabe, wann und wie die letzte Umstellung stattfand, ist das eine Selbsteinschätzung.
• „Wir stellen um, sobald Sie es verlangen.“ Bereitschaft ist keine Fähigkeit. Fragen Sie nach Dauer und Aufwand.

Eine gute Antwort ist meist unspektakulär: Sie nennt Orte, Versionen, Grenzen und einen Termin für die Vorführung.

Agilität hat einen Preis, den eine seriöse Anforderung berücksichtigt:

• Aushandlung kann angegriffen werden. Wenn zwei Seiten das Verfahren aushandeln, muss die Aushandlung selbst geschützt sein, sonst kann ein Angreifer beide auf das schwächste Verfahren herunterhandeln. Etablierte Protokolle wie TLS 1.3 berücksichtigen das; bei Eigenentwicklungen gehört es zu den Fragen an den Dienstleister.
• Mehr Optionen sind mehr Fläche. Jedes zusätzlich unterstützte Verfahren muss gepflegt und getestet werden. Agilität heißt, wechseln zu können, nicht, alles gleichzeitig anzubieten.
• Nicht alles muss agil sein. Ein System, das in drei Jahren abgelöst wird, braucht keine aufwendige Austauschbarkeit. Ein System, das zwanzig Jahre läuft, schon.

„Wie lange hat die letzte Umstellung eines kryptografischen Verfahrens in Ihrer Lösung gedauert, was musste dabei geändert werden, und können Sie uns einen Wechsel in einer Testumgebung vorführen?“

Die Frage zielt auf Erfahrung statt auf Absicht. Ein Dienstleister, der schon einmal etwa von SHA-1 auf SHA-256 umgestellt hat, kann darüber konkret berichten. Wer ausweicht, hat diese Erfahrung vermutlich nicht.

Die slowenische Ausgabe richtet sich an Entwicklungsarchitekten beim Lieferanten: »Če je vaš kriptografski algoritem del poslovne logike, imate problem.« (auf Slowenisch). Vorherige Ausgabe: PQC-Migration: Welche Systeme zuerst – und wer bezahlt?

Referenzmuster (vereinfacht). Es beschreibt Verantwortungen, keine bestimmte Technologie. Als Auftraggeber verwenden Sie es als Gesprächsgrundlage, nicht als Vorgabe. In der slowenischen Ausgabe inhaltlich gleich.

 +-----------------------------------------------------------+
 |  Fachlogik           "Dokument signieren", "Daten senden" |
 |                      kennt KEIN Verfahren                  |
 +-----------------------------+-----------------------------+
                               | Zweck (signieren, schützen)
 +-----------------------------v-----------------------------+
 |  Kryptodienst        wählt Verfahren nach Richtlinie       |
 |  + Richtlinie        schreibt Verfahrenskennung in Daten   |
 |    (Konfiguration)   prüft alte und neue Verfahren         |
 +-----------------------------+-----------------------------+
                               | Verfahren, Schlüsselreferenz
 +-----------------------------v-----------------------------+
 |  Anbieter            Bibliothek, HSM, Betriebssystem       |
 +-----------------------------+-----------------------------+
                               |
 +-----------------------------v-----------------------------+
 |  Schlüsselverwaltung Erzeugung, Speicherung, Wechsel       |
 +-----------------------------------------------------------+

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

Nächste Ausgabe (3. 8. 2026): „Hybride Kryptografie: Was passiert, wenn Ihr Lieferant den neuen Standard noch nicht unterstützt?“

Quellen (Stand 6. 7. 2026): NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025), Next Steps „Cryptographic agility“; AIVD, CWI und TNO, „The PQC Migration Handbook“, 2. Auflage (Dezember 2024); NIST FIPS 204 (August 2024).

Wenn „kryptoagil“ in Ihrer Ausschreibung steht und Sie wissen wollen, was die Antworten wert sind: Schreiben Sie uns.