{"id":17809,"date":"2026-08-05T01:50:37","date_gmt":"2026-08-05T08:50:37","guid":{"rendered":"https:\/\/www.omnitrust.com\/blog\/pki-mm-erweiterungsframework-und-vorschau-auf-pqc-readiness\/"},"modified":"2026-09-28T21:09:23","modified_gmt":"2026-09-29T04:09:23","slug":"pki-mm-erweiterungsframework-und-vorschau-auf-pqc-readiness","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/de\/blog\/pki-mm-erweiterungsframework-und-vorschau-auf-pqc-readiness\/","title":{"rendered":"PKI-MM-Erweiterungsframework und Vorschau auf PQC Readiness"},"content":{"rendered":" \n

TL;DR:<\/strong> PKI Maturity Model 2.0.0 f\u00fchrt ein Erweiterungsframework ein. Dadurch k\u00f6nnen ein Risikoprofil oder ein Branchenkontext zus\u00e4tzliche Schwerpunkte setzen, ohne das Modell zu forken. Die erste Erweiterung, PQC Readiness, ist ver\u00f6ffentlicht und ausdr\u00fccklich als in Entwicklung gekennzeichnet.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

Eine Organisation kann bei allen aktuellen Anforderungen den h\u00f6chsten Reifegrad erreichen und dennoch erhebliche kryptografische Risiken tragen. Quantenanf\u00e4llige Grundlagen tauchen im Score trotzdem nicht auf.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n \n

Jedes Reifegradmodell steht unter demselben Druck. Jemand braucht mehr Aussagen zu seinem Sektor, seiner Aufsichtsbeh\u00f6rde oder seinem besonderen Risiko. Dann w\u00e4chst das Modell entweder so lange, bis es f\u00fcr niemanden mehr passt. Oder es wird privat geforkt und ist nicht mehr vergleichbar.<\/p> \n \n

PKI Maturity Model<\/a> 2.0.0 geht einen dritten Weg. Es definiert ein Framework f\u00fcr optionale Overlays. Diese erg\u00e4nzen zus\u00e4tzliche Schwerpunkte oder Kriterien, ohne die Kerndefinition zu ver\u00e4ndern.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

So funktioniert eine Erweiterung<\/h2> \n \n

Eine Erweiterung folgt derselben Hierarchie wie das Modell selbst: Module, dann Kategorien, dann Anforderungen. Dadurch ist sie f\u00fcr jeden verst\u00e4ndlich, der das Modell bereits kennt.<\/p> \n \n

Sie kann drei Dinge tun. Sie kann erweiterungsspezifische Reifekriterien zu bestehenden Kategorien hinzuf\u00fcgen. Sie kann Gewichtungs-Overlays auf bestehende Anforderungen oder Kategorien anwenden. Und sie kann eine eigene Bewertung und Berichterstattung definieren, w\u00e4hrend weiterhin der Standardbericht erzeugt wird.<\/p> \n \n

Das Bewertungskonzept l\u00e4sst sich einfach erkl\u00e4ren. Eine Erweiterung f\u00fchrt ein zus\u00e4tzliches Reifegrad-Signal namens Relevance ein. Au\u00dferdem passt sie die Bedeutung \u00fcber Overlays an. Ihre grundlegende Reife wird dann mit diesem Signal kombiniert und entsprechend der Schwerpunktsetzung der Erweiterung gewichtet.<\/p> \n \n

\n \n \n \n \n \n \n \n \n
Designprinzip<\/th> \nWas es garantiert<\/th> \n<\/tr> \n<\/thead> \n
Nicht destruktiv<\/td> \nErweiterungen ver\u00e4ndern niemals die Definition des Basismodells<\/td> \n<\/tr> \n
Kombinierbar<\/td> \nMehrere Erweiterungen k\u00f6nnen gleichzeitig bestehen und werden jeweils unabh\u00e4ngig gegen dieselbe Basis bewertet<\/td> \n<\/tr> \n
Konsistente Bewertung<\/td> \nDie Bewertung funktioniert gleich bei einer vollst\u00e4ndigen anforderungsbasierten Bewertung und bei einer kategoriebasierten Selbsteinsch\u00e4tzung<\/td> \n<\/tr> \n
Modellnah aufgebaut<\/td> \nErweiterungen verwenden dieselbe Hierarchie aus Modulen, Kategorien und Anforderungen<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Die vier Designprinzipien des Erweiterungsframeworks.<\/figcaption> \n<\/figure> \n \n

Nicht destruktiv ist das Prinzip, das den Rest sicher macht. Eine Erweiterung kann den Kern nicht ver\u00e4ndern. Deshalb macht das Aktivieren einer Erweiterung niemals eine Basisbewertung ung\u00fcltig. Und Sie k\u00f6nnen sie wieder entfernen, ohne etwas neu berechnen zu m\u00fcssen.<\/p> \n \n

Es gibt au\u00dferdem einen maschinenlesbaren Vertrag. Das Framework ver\u00f6ffentlicht ein JSON Schema f\u00fcr Erweiterungsdefinitionen. Dadurch k\u00f6nnen Tools eine Erweiterung validieren, statt ihr einfach zu vertrauen.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Die PQC-Readiness-Erweiterung<\/h2> \n \n

Die erste ver\u00f6ffentlichte Erweiterung behandelt den \u00dcbergang zu quantensicherer Kryptografie. Ihr Argument entspricht dem Hinweis oben. Die Quantenbedrohung ver\u00e4ndert, was Reife bedeutet, weil ein Programm gut abschneiden kann, obwohl es auf anf\u00e4lligen Grundlagen aufbaut.<\/p> \n \n

Das ist ein heutiges Problem und kein zuk\u00fcnftiges. Harvest-now, decrypt-later macht langfristig vertrauliche Daten schon heute zu einem Risiko. Ihr Migrationszeitplan \u00e4ndert daran nichts.<\/p> \n \n

Die Erweiterung erg\u00e4nzt PQC-spezifische Kriterien neben den Basiskategorien. Sie wendet au\u00dferdem Gewichtungs-Overlays auf die f\u00fcr die Migration wichtigsten Anforderungen an. Die prim\u00e4re Zielgruppe sind Betreiber von Zertifizierungsstellen und Vertrauensdiensteanbietern. Ebenso geh\u00f6ren Enterprise-PKI-Architekten, Auditoren und Berater zum Anwendungsbereich.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Was fertig ist \u2013 und was nicht<\/h2> \n \n

Die Erweiterung ist als in Entwicklung gekennzeichnet, und die Arbeitsgruppe benennt genau, wo die Grenze verl\u00e4uft. Wir wiederholen das lieber deutlich, als eine Vorschau wie ein fertiges Produkt wirken zu lassen.<\/p> \n \n

\n \n \n \n \n \n \n \n
Umfang<\/th> \nStatus<\/th> \n<\/tr> \n<\/thead> \n
Governance-Modul, Kategorien 1 bis 4<\/td> \nVollst\u00e4ndig \u2014 vollst\u00e4ndige Kriterien f\u00fcr Level 1 bis 5, Leitlinien f\u00fcr Assessoren, Evidenzbeispiele und Overlay-Gewichtungen<\/td> \n<\/tr> \n
Module Management, Operations und Resources<\/td> \nNur umrissen \u2014 PQC-kritische Aspekte identifiziert, Kriterien f\u00fcr Level 1 bis 5 noch nicht entwickelt<\/td> \n<\/tr> \n
Version<\/td> \nIn Entwicklung; Wechsel zu 1.0.0, sobald alle Module vollst\u00e4ndig entwickelt sind und die Arbeitsgruppe den Inhalt best\u00e4tigt<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Aktueller Entwicklungsstand der PQC-Readiness-Erweiterung.<\/figcaption> \n<\/figure> \n \n

Eine Designfrage ist ebenfalls noch offen \u2013 und zwar eine echte. F\u00fcr die Platzierung von Overlays gibt es zwei Kandidaten. Ein Ansatz wendet governancezentrierte Multiplikatoren auf die Governance-Kategorien an. Der andere verwendet f\u00e4higkeitszentrierte Multiplikatoren f\u00fcr Crypto Agility und PQC-Schulungen. Die aktuelle Definition folgt dem governancezentrierten Design. Genau diesen Ansatz verwendet heute das Self-Assessment-Tool. Die endg\u00fcltige Entscheidung liegt bei der Arbeitsgruppe.<\/p> \n \n

Auch Abdeckungsl\u00fccken sind dokumentiert. Die Persona-Abdeckung ist f\u00fcr Organisationen, die Zertifikate konsumieren, f\u00fcr Softwareanbieter und f\u00fcr kryptografische Governance auf Ebene von KI-Systemen noch unvollst\u00e4ndig. Wichtig: Alle drei Punkte sind als bekannte L\u00fccken f\u00fcr eine sp\u00e4tere \u00dcberarbeitung festgehalten. Wer erwartet, dass die Erweiterung diese Fragen heute beantwortet, sollte daher zuerst die Statushinweise lesen.<\/p> \n \n

\n
\n

Eine Vorschau, die ihre unfertigen Teile benennt, ist n\u00fctzlicher als eine, die sie versteckt.<\/p> \n<\/blockquote> \n<\/figure> \n\r\n

\u00a0<\/div>\r\n \n

Wo die Bestandteile liegen<\/h2> \n \n

Das Framework, seine Struktur- und Bewertungsdokumentation sowie das JSON Schema liegen beim Kernmodell. Die ver\u00f6ffentlichten Erweiterungen befinden sich in einem separaten Katalog, sodass das Core-Repository keine einzelnen Erweiterungsinhalte mehr ausliefert.<\/p> \n \n

Diese Trennung hat einen praktischen Vorteil. Eine Erweiterung kann in ihrem eigenen Tempo weiterentwickelt werden und angeben, mit welchen Modellversionen sie kompatibel ist, ohne auf ein Core-Release warten zu m\u00fcssen.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Warum wir diese Form f\u00fcr richtig halten<\/h2> \n \n

OmniTrust arbeitet in der PKI-Maturity-Model-Arbeitsgruppe mit, und die Erweiterungen sind der Teil von 2.0.0, den wir am interessantesten finden.<\/p> \n \n

Ein einziges Modell kann einer Zertifizierungsstelle, einer Bank und einem Ger\u00e4tehersteller nicht gleicherma\u00dfen gerecht werden. Drei geforkte Modelle lassen sich jedoch \u00fcberhaupt nicht vergleichen. In der Praxis w\u00fcrde das den Sinn einer Reifegradmessung zunichtemachen. Overlays erhalten eine gemeinsame vergleichbare Basis und erlauben zugleich jedem Sektor, das f\u00fcr ihn Wesentliche st\u00e4rker zu gewichten.<\/p> \n \n

Das Framework ist neu und die erste Erweiterung noch nicht fertig. Deshalb ist jetzt der Zeitpunkt, an dem Feedback am einfachsten ber\u00fccksichtigt werden kann. Wenn Sie PKI-Programme bewerten, ist die offene Frage zur Overlay-Platzierung ein guter Ausgangspunkt.<\/p> \n\r\n

\u00a0<\/div>\r\n
\r\n
\u00a0<\/div>\r\n\r\n
\n

Wichtigste Erkenntnisse<\/h3> \n\r\n\r\n \n