Wie lassen sich die Kosten der NIST-PQC-Migration 2026 schätzen? Welche Arbeitspakete sind zuerst zu kalkulieren?

Für die Budgetplanung zur NIST-PQC-Migration gibt es keinen belastbaren Einheitspreis: Erfassen Sie diese Woche zunächst Systeme, kryptografische Abhängigkeiten und Verantwortliche, bevor Sie Aufwand und Kosten in Szenarien schätzen. Das gilt besonders, wenn mehrere Teams, externe Anbieter oder unterschiedliche Betriebsumgebungen beteiligt sind.

Dieser Beitrag richtet sich an Sicherheitsverantwortliche, die einen Migrationsetat begründen müssen, an Projektleitungen, die Termine und Ressourcen planen, und an technische Verantwortliche, die Umbau- und Prüfaufwand aus ihren Systemen ableiten. Wer lediglich einen pauschalen Branchenpreis sucht, erhält hier bewusst keinen: Die Kalkulation soll sich aus nachvollziehbaren Arbeitspositionen, Zuständigkeiten und überprüfbaren Annahmen zusammensetzen.

Zuerst den Umfang festlegen, dann NIST-PQC-Migrationskosten schätzen

Bevor Stunden oder Angebote zusammengetragen werden, muss feststehen, was das Budget abdecken soll. Eine Planung für die Bestandsaufnahme ist nicht dasselbe wie ein Etat für einen Pilotversuch, die produktive Umstellung oder den laufenden Betrieb. Werden diese Phasen zusammengefasst, ist später oft unklar, ob eine Kostenposition einmalig anfällt oder regelmäßig wiederkehrt.

Für jedes Budget sollte daher ein klarer Umfang festgehalten werden:

• Migrationsplanung: Ermittlung kryptografischer Abhängigkeiten, Risikobewertung, Verantwortlichkeiten und Umstellungsreihenfolge.
• Pilot und technische Validierung: begrenzte Erprobung ausgewählter Komponenten, Schnittstellen und Betriebsabläufe.
• Produktive Umsetzung: Änderungen an Anwendungen, Protokollen, Konfigurationen, Zertifikatsprozessen und Lieferantenleistungen.
• Betrieb nach der Umstellung: Schlüsselverwaltung, Überwachung, Pflege der Konfigurationen sowie Prüfung neuer Abhängigkeiten.

Die Abgrenzung verhindert, dass Planungskosten mit wiederkehrendem Aufwand vermischt werden. Für eine Budgetvorlage sollte jede Position mindestens die Arbeit, das verantwortliche Team, die Kostenart, eine Annahme und den Unsicherheitsgrad enthalten. Geldbeträge und interne Stundensätze gehören nur dann hinein, wenn sie aus freigegebenen Unternehmensdaten, dokumentierten Arbeitszeiten oder tatsächlich eingeholten Angeboten stammen.

Die offizielle Grundlage ist dabei eine technische Orientierung, kein Preisverzeichnis. NIST hat die Standards für ML-KEM, ML-DSA und SLH-DSA veröffentlicht; die entsprechenden Bezeichnungen FIPS 203, FIPS 204 und FIPS 205 sind im NIST-Beitrag zu den veröffentlichten PQC-Standards dokumentiert. Daraus folgt nicht, dass jedes Unternehmen dieselbe Umstellung durchführen muss. Welche Komponenten betroffen sind, ergibt sich aus den tatsächlich verwendeten Algorithmen, Produkten und Verbindungen.

Das Kryptografieinventar in Aufwand und Prioritäten übersetzen

Wie wird das Ergebnis der Kryptografieinventur zum Budget?

Ein Kryptografieinventar ist erst dann eine brauchbare Budgetgrundlage, wenn es pro Fundstelle erkennen lässt, wo Kryptografie eingesetzt wird, wer die Komponente verantwortet und wie eine Änderung umgesetzt werden könnte. Eine bloße Liste von Bibliotheken oder Servern reicht nicht: Ein Algorithmus kann direkt im Anwendungscode stehen, über eine Laufzeitumgebung bereitgestellt oder durch einen externen Dienstleister gesteuert werden.

Für die Schätzung sollten mindestens diese Tätigkeiten berücksichtigt werden:

• System- und Schnittstelleninformationen aus Architekturunterlagen, Konfigurationen und verfügbaren Werkzeugen zusammentragen.
• Teams und Dienstleister zu nicht dokumentierten oder nur indirekt sichtbaren Abhängigkeiten befragen.
• Prüfen, ob kryptografische Funktionen aus eigenem Code, Standardbibliotheken, Betriebssystemen, Appliances oder externen Diensten stammen.
• Für jeden Eintrag eine verantwortliche Stelle und einen Status der Verifikation festhalten.
• Systeme nach Auswirkung eines Ausfalls, Schutzdauer der Daten und Änderbarkeit priorisieren.

Die Zahl der erfassten Systeme allein beschreibt den Aufwand nicht. Ein umfangreiches, gut dokumentiertes System kann einfacher zu bewerten sein als eine kleinere Anwendung mit unbekannten Abhängigkeiten, fehlenden Ansprechpartnern und mehreren Vertragsparteien. Zu den wesentlichen Kostentreibern gehören deshalb auch die Qualität der Dokumentation, die Verfügbarkeit von Testumgebungen und der Aufwand, mit dem eine Abhängigkeit eindeutig einer verantwortlichen Stelle zugeordnet werden kann.

Die NCCoE-Materialien zur Migration auf Post-Quanten-Kryptografie behandeln die Migration als planungs- und umsetzungsbezogene Aufgabe. Für die Budgetierung bedeutet das: Das Inventar sollte nicht nur Algorithmen nennen, sondern auch deren Einsatzorte, Verbindungen, Eigentümer und mögliche Änderungswege abbilden. Ergänzende technische Perspektiven enthalten die vorläufigen NCCoE-Dokumente zu TLS und Netzwerkkommunikation sowie zu Anwendungsfällen und Systemintegration. Sie helfen bei der Strukturierung technischer Prüfbereiche, liefern aber keinen unternehmensspezifischen Kostensatz.

Checkliste für eine kalkulierbare Inventur

• [ ] Sind betroffene Anwendungen, Protokolle und Dienste aus einer nachvollziehbaren Quelle erfasst?
• [ ] Sind direkte und indirekte kryptografische Abhängigkeiten gekennzeichnet?
• [ ] Gibt es für jeden Eintrag einen bestätigten technischen Verantwortlichen?
• [ ] Ist sichtbar, welche Angaben noch ungeprüft oder nur vom Anbieter bestätigt sind?
• [ ] Sind geschäftliche Auswirkung, Datenlebensdauer und mögliche Ausweichwege dokumentiert?
• [ ] Ist die Zeit für Interviews, Nachrecherche und Pflege des Inventars als eigene Position eingeplant?

Unbekannte Abhängigkeiten sollten nicht als erledigte Bestandsaufnahme verbucht werden. Kennzeichnen Sie sie als offene Arbeit mit Verantwortlichem und Klärungsweg; andernfalls wirkt das Budget präziser, als die technische Grundlage tatsächlich ist.

Anwendungscode, Protokolle und Lieferanten getrennt kalkulieren

Welche Posten gehören in das Budget für die Post-Quanten-Kryptografie-Migration?

Sobald das Inventar vorliegt, wird die Migration nach Änderungsart und Zuständigkeit aufgeteilt. Das macht sichtbar, ob ein Team selbst Code anpassen kann oder ob ein Produktwechsel, ein Herstellerupdate oder eine Vertragsklärung nötig ist. Für jede betroffene Komponente sollte die Schätzung auf einem konkreten Systemeintrag beruhen und nicht auf einer pauschalen Annahme über die gesamte IT-Landschaft.

Eigenentwickelte Anwendungen: Zu erfassen sind Codeanalyse, Anpassungen an kryptografischen Aufrufen, Konfigurationsänderungen und die Überarbeitung automatisierter Abläufe. Die Entwicklerstunden hängen unter anderem davon ab, ob Kryptografie zentral über austauschbare Schnittstellen angesprochen wird oder an vielen Stellen fest im Code verankert ist. Als Aufwandstreiber zählen außerdem Build- und Freigabeprozesse sowie die Frage, ob ältere Anwendungsteile noch von einem betreuten Team geändert werden können.

Protokolle und Schnittstellen: Für jede Verbindung ist zu prüfen, welche Komponenten miteinander sprechen, wie Algorithmen ausgehandelt werden und welche Gegenstellen berücksichtigt werden müssen. Das betrifft nicht nur interne Dienste, sondern auch Kundenverbindungen, Partner und externe Plattformen. Einseitige Änderungen können Verbindungsabbrüche erzeugen, wenn die Gegenseite die neue Konfiguration nicht unterstützt oder anders interpretiert.

Bibliotheken und Plattformen: Für jede verwendete Bibliothek, Laufzeit, Appliance und verwaltete Plattform gehören unterstützte Versionen, Updatepfade, Vertragsgrenzen und Abhängigkeiten in die Kalkulation. Die dafür nötigen Informationen sollten aus tatsächlichen Produktunterlagen, Supportauskünften und Vertragstexten stammen. Wo Angaben fehlen, wird nicht geschätzt, als sei Unterstützung bestätigt: Der Posten bleibt offen und erhält eine konkrete Anfrage an den Anbieter.

Zertifikate und Dienste: Die Kostenplanung muss berücksichtigen, welche Zertifikatsstellen, Ausstellungsabläufe, Identitätsdienste und technischen Schnittstellen betroffen sind. Der Aufwand kann bei der Umstellung von Konfigurationen entstehen, aber auch in der Abstimmung von Richtlinien und Betriebsprozessen. Deshalb sollte die technische Änderung von der organisatorischen Freigabe getrennt ausgewiesen werden.

Für jede Kategorie sind vier Angaben hilfreich: verantwortliches Team, geschätzte interne Arbeitszeit, mögliche externe Leistung und Abhängigkeit von Dritten. Ergänzen Sie außerdem, auf welcher Grundlage eine Schätzung beruht: überprüfter Quellcode, dokumentierter Architekturstand, schriftliche Herstellerbestätigung oder bislang nur eine Annahme. So wird ersichtlich, welche Positionen sich bereits auf Fakten stützen und wo die Kalkulation noch von einer Rückmeldung abhängt.

Tests, Interoperabilität und Freigabe als eigene Arbeitsphase ansetzen

Eine Änderung ist nicht abgeschlossen, sobald sie sich kompilieren lässt oder eine Verbindung in einer Entwicklungsumgebung zustande kommt. Bei einer Post-Quanten-Kryptografie-Migration müssen Unternehmen unter ihren eigenen Betriebsbedingungen prüfen, ob beteiligte Systeme kompatibel sind, ob die Konfigurationen stabil funktionieren und wie ein Fehler erkannt und behoben wird. Deshalb sollte Testaufwand nicht als pauschaler Zuschlag im Umbau verschwinden.

Für die Planung sind getrennte Positionen sinnvoll:

• Kompatibilität: Zusammenarbeit zwischen Anwendung, Bibliothek, Betriebssystem, Gegenstelle und gegebenenfalls externem Dienst.
• Leistungsmessung: Messungen in der eigenen Umgebung mit dokumentiertem Lastprofil und reproduzierbaren Bedingungen. Werte anderer Organisationen ersetzen diese Messungen nicht.
• Fehler- und Rückfallverhalten: Prüfung, wie Verbindungsfehler erkannt werden, welche Wiederherstellungswege bestehen und wer sie im Betrieb auslösen darf.
• Umgebungsabdeckung: Validierung in den tatsächlich relevanten Entwicklungs-, Test- und Produktionsnähe-Umgebungen.
• Freigabe und Rollout: Abstimmung von Änderungsfenstern, Genehmigungen, Beobachtung und Abbruchkriterien.

NCCoE behandelt Migration und Interoperabilität in seinen Materialien zur PQC-Umstellung. Für die eigene Schätzung zählen jedoch ausschließlich Ergebnisse, die das Unternehmen in einem reproduzierbaren Testablauf selbst erreicht hat. Ein Leistungstest sollte daher Umgebung, Softwarestand, verwendete Konfiguration, Lastprofil und beobachtete Fehler festhalten. Nur damit lässt sich einschätzen, ob weitere Tests, zusätzliche Kapazitäten oder Änderungen am Rollout nötig sind.

Ein häufiger Planungsfehler liegt darin, die Zahl der Testläufe zu schätzen, bevor die Testziele feststehen. Besser ist es, jede Prüfung mit einem konkreten Risiko zu verknüpfen: Welche Komponente kann inkompatibel sein? Welche Verbindung muss mit einer Gegenstelle geprüft werden? Welcher Fehler erfordert einen Rückfall? Daraus entsteht ein begründeter Testumfang; die nötige Zeit wird anschließend mit den realen Kapazitäten des jeweiligen Teams kalkuliert.

Schlüsselverwaltung und Pflege nach der Umstellung berücksichtigen

Die einmalige Umsetzung deckt nicht alle Kosten ab. Nach der Migration müssen Teams kryptografische Konfigurationen pflegen, Schlüsselprozesse überwachen, Abhängigkeiten aktualisieren und neue oder geänderte Produkte erneut bewerten. Dieser laufende Aufwand sollte als eigener Kostenblock mit einem klaren Betrachtungszeitraum ausgewiesen werden, statt ihn in der initialen Projektsumme zu verstecken.

Zur Betriebsplanung gehören mindestens folgende Aufgaben: Zuständigkeiten für Schlüsselgeneration, Speicherung, Rotation und Stilllegung festlegen; Protokollierung und Überwachung anpassen; Konfigurationsänderungen dokumentieren; Software- und Lieferantenmeldungen auf relevante Änderungen prüfen; sowie festlegen, wann das Kryptografieinventar erneut validiert wird. Die tatsächliche Häufigkeit dieser Tätigkeiten muss aus den internen Betriebsregeln und dem Risikoprofil abgeleitet werden. Ein allgemeingültiger Wartungsaufwand lässt sich daraus nicht seriös ableiten.

Kryptoagilität ist für die Planung relevant, weil Änderungen an kryptografischen Verfahren in Architektur und Betrieb berücksichtigt werden müssen. Die NIST-Leitlinie zu Überlegungen für Kryptoagilität bietet dafür eine offizielle Orientierung. Für den Etat folgt daraus keine vorgegebene Zahl an Betriebsstunden. Zu kalkulieren sind vielmehr die konkreten Prozesse, die in der jeweiligen Organisation gepflegt und personell verantwortet werden müssen.

Halten Sie für jede wiederkehrende Position fest, ob sie bereits durch bestehende Betriebsaufgaben abgedeckt ist oder zusätzliche Kapazität erfordert. Bestehende Arbeit darf nicht automatisch als kostenfrei gelten: Wird ein Team dadurch stärker belastet, kann das zu Verschiebungen bei anderen Vorhaben führen. Umgekehrt sollte ein bereits vertraglich abgedeckter Service nicht nochmals als neue externe Leistung angesetzt werden, sofern Umfang und Verantwortung tatsächlich übereinstimmen.

Unsicherheit mit Szenarien statt Scheingenauigkeit abbilden

Eine Kostenschätzung wird nicht belastbarer, wenn viele offene Annahmen in eine einzelne Summe gepresst werden. Kennzeichnen Sie stattdessen bestätigte Arbeit, ausstehende Lieferanteninformationen und besonders unsichere Abhängigkeiten getrennt. Erstellen Sie daraus niedrige, mittlere und hohe Szenarien, ohne einen der Werte als Branchenstandard oder NIST-Vorgabe zu bezeichnen.

Diese Szenarien dürfen nicht durch erfundene Prozentsätze auseinandergezogen werden. Ihre Unterschiede müssen aus benannten Bedingungen entstehen: etwa einer noch nicht bestätigten Produktunterstützung, fehlendem Zugang zu Quellcode oder einer ungeklärten Gegenstelle. Sobald ein Lieferant ein belastbares Angebot vorlegt oder ein Team Messergebnisse dokumentiert, wird die betreffende Annahme aktualisiert und das Szenario neu bewertet.

Die folgende Gegenüberstellung hilft dabei, die Kalkulationsart passend zum Reifegrad der Informationen zu wählen:

Die Budgetvorlage vor der Freigabe prüfbar machen

Vor der Einreichung sollte das Team nachvollziehen können, wie jeder Betrag zustande kommt und welche Entscheidung er ermöglicht. Dafür lässt sich der Prozess in konkrete Schritte überführen:

1. Budgetgrenze beschließen. Legen Sie fest, ob die Vorlage Planung, Pilot, produktive Umsetzung, Betrieb oder mehrere dieser Phasen umfasst. Halten Sie den Betrachtungszeitraum fest.
2. Inventar als Ausgangsbasis einfrieren. Erfassen Sie den Datenstand, kennzeichnen Sie ungeprüfte Einträge und benennen Sie eine zuständige Person für die Nachpflege.
3. Arbeit pro Szenario zuordnen. Verknüpfen Sie jedes betroffene System mit Inventarisierung, Umbau, Test, Freigabe und Betrieb, soweit diese Tätigkeiten tatsächlich anfallen.
4. Aufwand mit Unternehmensdaten belegen. Nutzen Sie interne Kapazitäts- und Kostendaten, dokumentierte Arbeitszeiten oder konkrete Angebote. Erfinden Sie weder Stundensätze noch Marktpreise, um eine Lücke zu schließen.
5. Offene Punkte als Bedingungen formulieren. Schreiben Sie zum Beispiel auf, welche Herstellerbestätigung noch fehlt und welche Änderung erst nach deren Eingang kalkuliert werden kann.
6. Einmalige und wiederkehrende Kosten trennen. Kennzeichnen Sie, ob ein Posten für Umsetzung, laufenden Betrieb oder beides anfällt, und vermeiden Sie doppelte Ansätze.
7. Freigabe und Aktualisierung festlegen. Benennen Sie, wer Annahmen bestätigt, wann neue Informationen eingearbeitet werden und welche Änderungen eine erneute Budgetentscheidung auslösen.

Eine kompakte Vorlage sollte für jede Position Arbeitspaket, Systembezug, Zuständigkeit, interne oder externe Leistung, Kostenquelle, Annahme, Unsicherheitsgrad und Aktualisierungsbedarf enthalten. Damit kann die Projektleitung prüfen, welche Kosten durch die technische Bestandsaufnahme gestützt sind und welche noch von offenen Entscheidungen abhängen. Für die weitere Betriebsplanung können die Angaben zu Aufgaben, Zugängen und Zuständigkeiten mit den Informationen im Vuncloud-Hilfebereich abgeglichen werden; daraus dürfen jedoch keine Kosten oder Leistungen abgeleitet werden, die dort nicht ausdrücklich ausgewiesen sind.

Eine passende Testumgebung nur bei tatsächlichem Bedarf einplanen

Eine vorübergehende Remote-Mac-Umgebung ist kein allgemeiner Ersatz für die Unternehmensinfrastruktur und löst weder eine unvollständige Bestandsaufnahme noch offene Lieferantenfragen. Sie kann allenfalls dann in den Testplan passen, wenn macOS-Clients, Apple-spezifische Anwendungen oder entsprechende Build- und Freigabeabläufe Teil der zu prüfenden Migration sind. Für serverseitige Kryptografie-, Netzwerk- oder Hardwaretests ist zunächst zu klären, ob eine solche Umgebung überhaupt die relevante Zielplattform abbildet.

Wer heute mit einem gemeinsam genutzten Entwicklerrechner, einer allgemeinen Cloud-VM oder einer dauerhaft belegten lokalen Testmaschine arbeitet, sollte die jeweiligen Nachteile konkret benennen: Zugriffsrechte und Datenfreigaben können Abstimmung erfordern, Betriebssystem- und Konfigurationsstände können von der Zielumgebung abweichen, und eine dauerhaft gebundene Maschine lässt sich für kurzzeitige Prüfungen möglicherweise nicht wirtschaftlich auslasten. Eine gemietete Mac-Umgebung kann für klar abgegrenzte, zeitlich befristete Apple-spezifische Tests bequemer sein; Datenschutz, Zugriffsschutz, Testdaten und die benötigte Laufzeit müssen trotzdem vorab geprüft werden.

Für den Budgetvergleich zählen ausschließlich die aktuell ausgewiesenen Konditionen und Leistungsangaben. Prüfen Sie diese auf der Vuncloud-Seite zu Mac mini, bevor eine Mietposition angesetzt wird. Wenn dort keine passende Umgebung oder Laufzeit beschrieben ist, sollte der Posten nicht als verfügbar kalkuliert werden. Bei einer ungeklärten Anforderung kann eine Rückfrage über die Vuncloud-Kontaktseite klären, welche Informationen für einen belastbaren Kostenvergleich vorliegen müssen.

Der verlässlichste nächste Schritt ist daher, das Kryptografieinventar mit technischen Verantwortlichen zu vervollständigen und für jede offene Position einen Nachweis, eine Zuständigkeit und einen Klärungstermin einzutragen. Erst danach lassen sich Umbau, Testumfang und Betrieb mit den tatsächlichen Unternehmensdaten zu einem prüfbaren Budget verbinden. Eine Mac-Miete gehört nur dann in diesen Vergleich, wenn ein konkreter macOS-Testbedarf besteht; für kurzzeitige, Apple-spezifische Validierung kann sie gegenüber einer dauerhaft gebundenen lokalen Testmaschine die passendere Variante sein.