Kryptokonzept : Vom Papiertiger zum Steuerungsinstrument : Warum der „Stand der Technik“ als Kryptokonzept nicht reicht und wie sich Krypto-Kataster und -Agilität operational nutzen lassen

Die Folge ist eine trügerische Sicherheit: Während sich Systeme weiterentwickeln, neue Defaults Einzug halten und Abhängigkeiten sich verändern, bleibt das Krypto-„Konzept“ statisch – und taugt daher nicht als Arbeitsgrundlage. Das rächt sich früher oder später – meist schneller als man denkt. Denn kryptografische Empfehlungen verändern sich: Es gibt TR-Updates, Abkündigungen oder neue Prioritäten. Die TR-02102-1 vom Januar 2026 [1] fordert ausdrücklich Migrationsfristen sowie Hybridisierung und sieht eine alleinigen Nutzung klassischer asymmetrischer Verfahren nicht mehr als zukunftsfähige Option an. Diese Empfehlungen werden in der Praxis oft als klarer Zeitplan gelesen – „klassisch asymmetrisch solo“ geht dann nur noch bis Ende 2031, bei sehr hohem Schutzbedarf ist schon früher Schluss.

Unbefriedigende Praxis

Wer beispielsweise einen Webserver neu aufsetzt und dazu die Transport-Layer-Security (TLS) sauber konfigurieren muss, sollte sich eigentlich intensiv mit Protokollversionen, Cipher-Suites, Key-Exchange, Zertifikatskette, „HTTP Strict Transport Security“ (HSTS), dem Online-Certificate-Status-Protocol-(OCSP)-Stapling et cetera auseinandersetzen – das „volle Programm“ also.

Die typische Reihenfolge, in der viele Teams in der Praxis vorgehen, sieht jedoch leider anders aus: Oft besteht viel Vertrauen in die Default-Config der Software („Wird schon passen – die Maintainer werdens wissen.“), vertiefende Informationen werden gern per Suchmaschine und/oder künstlicher Intelligenz (KI) gesucht oder Konfigurationsteile als Copy-&-Paste Snippets eingebunden („Nehmen wir doch die ‚Nginx TLS best practice 2026‘ – Hauptsache, es läuft erstmal.“). Auch was bei anderen läuft, wird gern übernommen („Bei Team X funktioniert das doch auch so.“).

Das hauseigene Kryptokonzept könnte und sollte hier eine wichtige Quelle sein – falls man es schnell findet und dann mehr drinsteht als der Verweis auf den „Stand der Technik“. Die zuvor beschriebenen pragmatischen Ansätze zeugen dabei nicht von Faulheit, sondern den Anforderungen des Alltags: Entscheidungen müssen schnell und unter Zeitdruck fallen – mit möglichst wenig Risiko. Wenn ein Kryptokonzept in solchen Momenten schwer zugänglich ist oder/und nur abstrakt bleibt, wird es nicht zur Hilfe, sondern verkommt zum Papiertiger.

Vom Dokument zum Werkzeugkasten

Steuerungswirkung entsteht hingegen, wenn ein Kryptokonzept als Arbeitsgrundlage nutzbar ist – ideal ist, wenn es im Alltag schneller ist, ihm zu folgen, als es zu umgehen.

Der Kern hierfür ist die Übersetzung von Anspruch in Handhabung: Aus „Stand der Technik“ werden dann klare Leitplanken, kurze Handreichungen und verlinkbare Referenzen, die typische Entscheidungen unterstützen, ohne jedes Detail auszuerzählen. Dadurch sinkt dennoch der Interpretationsspielraum und damit das Risiko von Copy-&-Paste-Konfigurationen.

Am wirksamsten gelingt eine solche Übersetzung gemeinsam mit den umsetzenden Teams: Dann passt der Werkzeugkasten zur realen Betriebsroutine, wird akzeptiert und tatsächlich genutzt – und aus abstrakter Vorgabe wird konsistente Praxis.

Krypto-Kataster

Wer allerdings nicht weiß, wo welche Kryptografie im Einsatz ist, kann sie auch nicht gezielt austauschen, wenn sich Empfehlungen ändern oder Verwundbarkeiten von Verfahren bekannt werden. Deshalb enthält der BSIIT-Grundschutz-Baustein CON.1 „Kryptokonzept“ [2] eine wichtige Schärfung: Die Erstellung eines Krypto-Katasters ist dort als Standard-Anforderung (CON.1.A19) verankert – also für die Standard-Absicherung relevant und damit für viele Organisationen „Soll“. Für eine reine Basis-Absicherung (Testat) ist sie formal nicht zwingend, operativ aber trotzdem der entscheidende Hebel, wenn man Kryptoagilität wirklich erreichen will.

Über die formale Anforderung des BSI hinaus ist die Erstellung und kontinuierliche Pflege eines Krypto-Katasters auch eine zentrale Voraussetzung für Kryptoagilität. Kryptoagil zu sein bedeutet, kryptografische Verfahren bei Bedarf gezielt, zeitnah und kontrolliert austauschen oder anpassen zu können – etwa bei neuen Empfehlungen, praktischen Schwächungen oder sich abzeichnenden Migrationsanforderungen wie im Kontext von Post-Quanten-Kryptografie (siehe auch [3]).

Ohne eine belastbare Übersicht darüber, wo welche kryptografischen Verfahren, Bibliotheken, Protokolle und Schlüsselparameter tatsächlich eingesetzt werden, bleiben solche Anpassungen zwangsläufig reaktiv, aufwendig und risikobehaftet. Ein Krypto-Kataster schafft die notwendige Transparenz: Er macht Abhängigkeiten von konkreten kryptografischen Verfahren sichtbar, ermöglicht eine fundierte Priorisierung von Maßnahmen und ist damit die operative Grundlage, um kryptografische Migrationen planbar und beherrschbar umzusetzen. In diesem Sinne ist der Krypto-Kataster nicht nur ein Compliance-Artefakt, sondern ein wesentliches Steuerungsinstrument für die langfristige Sicherstellung kryptoagiler Systeme. Dafür darf der Kataster allerdings nicht „noch eine Liste, die niemand pflegt“ sein.

Um es nochmals zu betonen: Ohne belastbare Übersicht darüber, wo kryptografische Verfahren, Bibliotheken und Protokolle eingesetzt werden, wer sie verantwortet und wie sie konfiguriert sind, bleibt eine schnelle Reaktion auf Anpassungsbedarf nur Wunschdenken – egal ob es um TR-Updates, Abkündigungen oder neue Bedrohungen geht.

Ein guter Krypto-Kataster ist kein Wikipedia-Artikel über Kryptografie – er ist ein Steuerungsinstrument und beantwortet im Ernstfall (und auch im Alltag) schnell die Fragen „Wo ist etwas betroffen?“, „Wie kritisch ist das?“ und „Wer kann das ändern?“.

Und dabei ist es ausdrücklich okay, wenn die Aufstellung nie „allumfassend perfekt“ ist. Eine Grundprämisse der Kryptoagilitäts-Praxis lautet: Inventarisierung wird vermutlich niemals vollständig vorliegen – also muss man sie zeitlich begrenzen, pragmatisch starten und dann kontinuierlich verbessern.

Wer beim ersten Anlauf versucht, alles zu erfassen – von TLS-Cipher-Suites bis zur letzten Hardcoded-KeyKonstante in irgendeinem Skript – verliert Teams, Zeit und Motivation. Der Trick besteht darin, einen „Minimal Viable Kataster“ zu definieren, der sofort nutzbar ist.

Klein starten, schnell Nutzen erzeugen

Ein „Minimum Viable Product“ (MVP) bezeichnet die kleinstmögliche Version eines Produkts/Artefakts, mit der ein Team mit minimalem Aufwand die maximale Menge an validiertem Lernen (Feedback/Erkenntnissen) gewinnen kann.

Einträge in einem solchen MV-Kataster müssen Assets identifizieren, ihre Kryptonutzung aufzeigen und die Verantwortlichkeit benennen. Daraus ergeben sich folgende Minimum-Felder, die man wirklich braucht (und die auch im Geist der BSI-Forderung liegen):

• Asset/Service (Name, System, Umgebung, Owner)
• Einsatzzweck (z.B. „TLS inbound“, „DB at rest“, „Signaturen“, „VPN“)
• Kryptobaustein (z.B. Protokoll, Library, PKI, HSM, Managed Service)
• Verfahren und Parameter (z.B. TLS-Version, KeyExchange, Signatur, Schlüssellängen)
• Implementierung (Produkt/Komponente/Library, Version, Config-Location)
• Zuständigkeit (Wer kann ändern? Wer entscheidet?)
• Schutzbedarf/Kritikalität (für die Priorisierung – für den MVP genügt eine grobe Einstufung)
• Review-Datum und Ablöse-/Migrationshinweis (falls nötig)

Als MVP-Merksatz kann gelten: Wenn ein Feld nicht hilft, eine Entscheidung zu treffen oder eine Änderung auszulösen, ist es wahrscheinlich nur „Deko“.

Kataster-Aufbau in sechs Schritten

Die im Folgenden beschriebene Vorgehensweise skizziert den schrittweisen Weg zu einem Kataster, den man wirklich pflegt.

Schritt 1: Scope festziehen – sonst wirds ein Fass ohne Boden

Zunächst ist der Geltungsbereich so zu definieren, dass er zum ISMS-Scope der eigenen Organisation passt und operativ machbar bleibt. Typische Start-Scopes sind: „alle extern erreichbaren Services“, „alle Systeme mit hohem Schutzbedarf“ oder „alles, was Zertifikate aus unserer PKI nutzt“.

Wichtig: Der Scope umfasst nicht nur „welche Systeme“, sondern auch „welche Kryptoarten“! In der Kryptoagilitäts-Praxis haben sich vier Blickrichtungen bewährt:

• Netzwerk-Kryptografie (TLS, VPN etc.),
• Software-Kryptografie (Libraries, Abhängigkeiten etc.),
• operative Kryptografie (PKI, Schlüssel, Certificate-Lifecycle etc.) und
• managed/hardware-basierte Kryptografie (HSM, KMS etc.).

Schritt 2: Datenmodell festlegen – statt „einfach mal Excel“ zu nutzen

Natürlich kann man auch mit Excel-Tabellen starten. Entscheidend ist nicht das Werkzeug, sondern dass vorher klar ist, wie ein gültiger Kataster-Eintrag aussieht. Fehlt dieses gemeinsame Verständnis, entsteht schnell eine lose Sammlung individueller Beschreibungen: inkonsistent, schlecht auswertbar und ohne echte Steuerungswirkung.

Daher ist es wesentlich, schon vor der Befüllung festzulegen, welche Informationen pro Eintrag verpflichtend sind und wie man sie zu interpretieren hat. Dabei kann man sich an den Mindestangaben orientieren, die der BSI-Grundschutz für einen Krypto-Kataster erwartet: Einsatzzweck, Zuständige, eingesetztes kryptografisches Verfahren, Hard-/Software mit kryptografischen Funktionen sowie sicherheitsrelevante Parameter (z.B. Schlüssellängen).

Struktur ist dort zu erzwingen, wo Vergleichbarkeit unabdingbar ist (z.B. Use-Case-Typen, Algorithmusnamen, Schlüssellängen, Produkt/Komponente) – Freitext sollte man nur dort zulassen, wo Kontext unvermeidbar ist (z.B. Sonderfälle, Ausnahmen, technische Randbedingungen).

Bei all dem empfiehlt es sich, gedanklich in Richtung „Cryptography Bill of Materials“ (CBOM, vgl. [4]) zu denken: Einsatzzweck, Verfahren, Parameter und Implementierung gehören zusammen und sollten als Einheit erfasst werden. Das erhöht die Konsistenz und macht spätere Änderungen deutlich einfacher.

Ein gutes Datenmodell ist erreicht, wenn ein einzelner Eintrag ohne Rückfragen beantwortet:

• Was wird kryptografisch eingesetzt?
• Wofür wird es eingesetzt?
• Wo ist es konfiguriert/implementiert?
• Wer kann es ändern?

Mit diesem Fundament bleibt der Kataster toolunabhängig nutzbar – ohne diese Anforderungen es wird auch „einfach Excel“ schnell zum nächsten (E-)Papiertiger. Auf der skizzierten Basis bleibt der Kataster nicht nur ein Nachweis, sondern liefert eine verlässliche Entscheidungsgrundlage für Reviews und Änderungen – er bietet also genau das, was Kryptografie-Vorgaben unter anderem in Grundschutz-Kontexten operational macht.

Schritt 3: Quellen kombinieren – statt Default-Configs anzunehmen

Man benötigt keine perfekte Vollständigkeit, wohl aber belastbare Erkenntnisse. Deshalb sollte man sich nicht auf eine einzelne Sicht verlassen, sondern mehrere Quellen (Discoverys) kombinieren, um ein realistisches Bild der tatsächlich eingesetzten Kryptografie zu erhalten.

Wichtig: Eine Default-Konfiguration ist kein Nachweis, sondern höchstens ein Startpunkt für eine Hypothese („so könnte es sein“)! Defaults unterscheiden sich je nach Produkt, Version, Distribution und Betriebsmodus – und sie werden in der Praxis häufig durch Templates, Policies, Infrastructure as Code (IaC) oder nachträgliche Hotfixes überschrieben. Entscheidend ist, was wirklich aktiv ist, nicht was theoretisch voreingestellt wäre.

Daher sollten unbedingt mehrere Quellen parallel ausgewertet und miteinander abgeglichen werden:

• Interviews/Workshops mit Admins und Entwicklern: Das ist der schnellste Weg zu „Was läuft wirklich?“ – inklusive Wissen über Sonderfälle, Workarounds und historische Entscheidungen.
• Dokumentensichtung (Architektur, Konfigurationen, Betriebshandbücher etc.) liefert Kontext: Wo wird Krypto erwartet, welche Komponenten sind beteiligt, wo liegen Konfigurationsartefakte?
• Scans und Automatisierung liefern, wo sie möglich sind (z.B. TLS-Scanner, SBOM/CBOM-Ansätze) messbare Beobachtungen – wo Automatisierung nicht funktioniert, arbeite man händisch oder halbautomatisch, markiere aber solche Stellen explizit.
• Bestehendes Asset-Management und/oder ConfigurationManagement-Database (CMDB) erweitern statt neu zu erfinden: Vorhandene Bestände sollte man als Ankerpunkte nutzen (etwa für Systeme, Owner, Umgebungen etc.) und kryptorelevante Informationen dort ergänzen, wo es sinnvoll ist.

Wichtig ist bei alldem Ehrlichkeit: Wenn man etwas nicht zuverlässig erfassen kann (z.B. Legacy-Systeme, Vendor-Blackboxes etc.), sollte diese Unsicherheit sichtbar sein. Anstatt Annahmen zu treffen oder Dinge zu verschweigen, ist dann „unbekannt/nicht prüfbar“ zu dokumentieren. So entstehen keine Scheingenauigkeiten und die Organisation sieht, wo echte „Blind Spots“ liegen.

Schritt 4: Zeitlimit setzen und mit Leuchttürmen starten

Für die initiale Befüllung sollte man ein klares Zeitlimit ansetzen (z.B. 2–4 Wochen). Das Ziel ist ja keine Vollständigkeit, sondern ein nutzbares Kataster-MVP, das schnell die Steuerungsfähigkeit verbessert und das eingesetzte Datenmodell in der Praxis testet.

Dafür sollte man mit wenigen, aber repräsentativen „Leuchtturm“-Systemgruppen oder Services starten – zum Beispiel:

• externe Web-Frontends/- APIs (TLS, Zertifikate, Reverse-Proxys etc.)
• VPN/Remote-Access
• PKI-nahe Systeme (Issuing CA/RA, Zertifikatsautomation, HSM/KMS etc.)

Pro Leuchtturm reicht dann zunächst ein Eintrag, der die schon angesprochenen BSI-Mindestinhalte zuverlässig abdeckt: Einsatzzweck, Zuständigkeit, eingesetzte Verfahren, Hard-/Software mit Kryptofunktionen sowie relevante Parameter (z.B. Schlüssellängen).

Der Mehrwert dieser Phase liegt darin, frühzeitig Muster, Lücken und Reibungspunkte (z.B. fehlende Owner oder unklare Config-Locations) zu erkennen, Pflichtfelder sowie Begriffe zu schärfen und danach einen belastbaren „Bauplan“ vorliegen zu haben, mit dem sich der Kataster in den beiden letzten Schritten konsistent skalieren lässt.

Schritt 5: Qualität sichern – statt nur „Mutmaßungen“ zu erfassen

Ein Kataster ist nur so gut wie seine Konsistenz. Daher sollte man unbedingt einfache Checks einbauen wie:

• Sind alle Pflichtfelder vorhanden?
• Sind Verfahren und Parameter plausibel (z.B. TLS-Versionen, Schlüssellängen)?
• Ist die Zuständigkeit klar dokumentiert? „Team X“ ist dabei kein Owner, sondern nur ein Hinweis!
• Ist die Config-Location angegeben (Repository, Policy, DeviceTemplate, IaC-Modul etc.)?

Optional, aber hilfreich ist ein kurzer „Konsistenz-Review“ durch jemanden, der das System nicht selbst betreibt – ein frischer Blick findet häufig leichter Lücken.

Schritt 6: Vom Kataster zum Prozess wechseln – statt die Ergebnisse nach dem Audit „sterben“ zu lassen

Ein Krypto-Kataster entfaltet nur dann Steuerungswirkung, wenn daraus ein wiederkehrender und ereignisgetriebener Prozess hervorgeht. Genau das erwartet der Grundschutz auch inhaltlich: Mindestens jährlich soll anhand des Katasters geprüft werden, ob Verfahren und Parameter noch ausreichend sicher sind. Außerdem soll ein definierter Ablauf existieren, wie man bei Schwächungen reagiert und wie ein Verfahren gegebenenfalls zu sichern oder abzulösen ist.

Damit das im Alltag funktioniert, braucht es drei Dinge:

• Klare Verantwortlichkeiten und Verbindlichkeit: Es ist festzulegen, wer bewertet (fachlich), wer entscheidet (Risiko/Abweichungen) und wer umsetzt (Betrieb/Teams). Darüber hinaus muss man das Kryptokonzept beziehungsweise den Kataster als bindend verankern – Abweichungen sind zwingend mit dem Verantwortlichen für die Informationssicherheit abzustimmen und zu dokumentieren.
• Taktung und Trigger: Als Regeltermin sollte mindestens ein jährliches Review erfolgen – beispielsweise als „Krypto-Review“ mit Ergebnisliste, Maßnahmen und Fristen. Darüber hinaus sind Ereignisse zu definieren, die zusätzliche Arbeiten auslösen – etwa beim Vorliegen neuer Erkenntnisse zu Schwächungen, geänderten Empfehlungen oder Parametern sowie das Bekanntwerden von Schwachstellen und betroffenen Implementierungen. Für solche Fälle soll im Kryptokonzept zudem ein Prozess definiert sein.
• Workflow, der in das Change- und Release-Management hineinragt: Ein praktikabler Minimal-Workflow, der leicht auditierbar, aber vor allem operativ nützlich ist, startet mit einem Ereignis/ReviewFund (z.B. „Parameter/Verfahren nicht mehr empfohlen“ oder „Implementierung betroffen“), auf den ein Impact-Check im Kataster folgt (Welche Systemgruppen/Services nutzen das konkret? Wie lauten Einsatzzweck, Verfahren, Parameter und zuständiges Team?). Anschließend sind notwendige Arbeiten nach Schutzbedarf, Exponierung sowie Abhängigkeiten zu priorisieren (für MVP reicht das grob, muss aber nachvollziehbar sein). Es folgen konkrete Maßnahmenpakete (Absichern oder Ablösen/Migrieren inkl. Zielzustand und Frist), sowie deren Umsetzung und Nachweis (Change-Ticket, Config-Snapshot als Belegkette etc.). Abschließend ist der Kataster zu aktualisieren (neuer Stand nebst Review-Datum), um ein „Abdriften“ von der Realität zu verhindern.

Praxistipp, damit hieraus keine „Listenpflege“ wird: Kataster-Updates sollten ein verpflichtender Teil für das „Done“ bei relevanten Changes sein – so behält man den Kataster als ein lebendes Steuerungsinstrument, statt ein Audit-Artefakt zu erschaffen.

Fazit

Ein Krypto-Kataster ist dann wertvoll, wenn er im Alltag als Entscheidungshilfe funktioniert – nicht, wenn er theoretisch „vollständig“ ist. Deshalb gilt: lieber klein, konsistent und belastbar starten als groß, unübersichtlich und schnell veraltet implementieren. Der Minimum-Viable-Product-(MVP)-Gedanke verhindert, dass ein Kataster zur „Meinung mit Spalten“ verkommt und sorgt dafür, dass er tatsächlich nutzbar bleibt – er enthält dann nur Felder, die Entscheidungen unterstützen.

Wichtig ist außerdem eine saubere GovernanceHaltung: Kryptografische Vorgaben müssen so verständlich und zugänglich sein, dass Teams sie unter Zeitdruck lieber anwenden als umgehen. Wo Abweichungen nötig sind, sollten sie transparent gemacht und mit den zuständigen Stellen abgestimmt werden – das ist keine Bürokratie, sondern ermöglicht Risikosteuerung und Nachvollziehbarkeit!

Akzeptanz entsteht bei alldem nicht durch Perfektion, sondern durch spürbaren Nutzen. Wenn der Kataster bei typischen Fragen („Wo nutzen wir X?“, „Wer kann das ändern?“, „Welche Parameter sind aktiv?“) schnell Antworten liefert, wird er automatisch Teil der Arbeitsroutine. Genau dann wird aus einem „Kryptokonzept als Dokument“ (aka Paperware) ein Werkzeugkasten, der seine Organisation handlungsfähig macht – auch wenn sich Empfehlungen, Technologie oder Rahmenbedingungen ändern. Umgekehrt wird ein Kryptokonzept sogar gefährlich, wenn es nur „Stand der Technik“ einfordert und im Alltag niemandem hilft, unter Zeitdruck die richtigen Entscheidungen zu treffen.

Genau deshalb ist der Krypto-Kataster der eigentliche Gamechanger: Er macht Kryptografie auffindbar, zuordenbar und änderbar – also auch steuerbar. Mit Scope, MVP-Ansatz, konsistenten Feldern, Leuchtturm-Systemen und einem klaren Trigger-/Workflow-Prozess wird aus „Wir reviewen das jährlich.“ endlich „Wir können handeln!“.

Und wenn Post-Quantum-Cryptography (PQC) nicht mehr Buzzword, sondern Anforderung ist, startet man nicht bei Null, sondern klickt im Idealfall nur auf „Migration“, um den vorbereiteten Prozess zu starten, weil man längst weißt, wo es Probleme gibt, wer zuständig ist und wie man seine Systeme sauber umstellt.

Der Papiertiger „Kryptokonzept“ ist dann nicht nur gezähmt, sondern ersetzt worden: durch einen nützlichen Werkzeugkasten.

Holger von Rhein ist Expert bei HiSolutions.

Literatur

_{[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), Kryptografische Verfahren: Empfehlungen und Schlüssellängen, Technische Richtlinie BSI TR-02102, Januar 2026, www.bsi.bund.de/dok/TR-02102}  

_{[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), Kryptokonzept, IT-GrundschutzBaustein CON.1, Edition 2023, Februar 2023, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_1_Kryptokonzept_Edition_2023.pdf}

_{[3] Leonie Wolf, Krypto-Agilität, Leitfaden für langfristige Sicherheit, Fraunhofer SIT, 2024, https://sit.fraunhofer.de/de/kryptoagilitaet}

_{[4] OWASP Foundation, Authoritative Guide to CBOM, Implement Cryptography Bill of Materials for Post-Quantum Systems and Applications, Oktober 2025, https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-CBOM-en.pdf}