Grundlagen und Anforderungen

Zusammenfassung. Diese Seite stellt die Gesetze, Normen, technischen Richtlinien und anerkannten Standards zusammen, aus denen sich die Anforderungen an WKL TrustBridge ergeben. Zu jedem Regelwerk beantwortet sie fünf Fragen: Was ist sein Zweck und was verlangt es? Für wen gilt es – Betreiber, Hersteller, Kunden? Was folgt daraus für die Architektur? Wie wird es technisch und organisatorisch umgesetzt? Welche Nachweise liegen vor, welche fehlen? Rechtsstand und Versionsstand beziehen sich auf die Prüfung am 15. Oktober 2026. Die aus allen Regelwerken abgeleiteten Anforderungen stehen gesammelt in der Architekturableitung.

Wiedergabe und Auslegung. Unter „Zweck und wesentliche Anforderungen“ steht die Wiedergabe der Quelle. Unter „Konsequenzen“, „Folgerung“ und „Umsetzung“ steht die eigene Auslegung für dieses Produkt; sie ist keine Aussage der Quelle.

Keine Rechtsberatung. Ob ein Betreiber oder Kunde unter ein Gesetz fällt, entscheidet er anhand der gesetzlichen Kriterien selbst; das BSI trifft dazu nach eigener Aussage keine verbindliche Einzelfallfeststellung. Diese Seite nennt Kriterien und Primärquellen, keine Rechtsauskunft. Es wird keine Konformität oder Zertifizierung von TrustBridge behauptet.

Regelwerke unterscheiden sich in ihrer Verbindlichkeit. Diese Dokumentation verwendet vier Arten:

Drei Rollen sind zu unterscheiden, weil Pflichten verschieden treffen:

• Betreiber – betreibt TrustBridge als Dienst für Partner und Kunden.
• Hersteller – bringt TrustBridge als Software in Verkehr, etwa zum Betrieb beim Kunden.
• Kunde – lässt seine Systeme über TrustBridge mit Zertifikaten ausstatten und ist häufig selbst eine regulierte Einrichtung.

graph TD
  subgraph G [Gesetzliche Pflicht]
    NIS2[NIS2 / BSIG]
    KR[KRITIS-Dachgesetz<br/>BSI-KritisV]
    CRA[Cyber Resilience Act]
    DS[DSGVO]
    DO[DORA]
  end
  subgraph E [Technische Empfehlung]
    TR[BSI TR-02102]
    GS[IT-Grundschutz]
    PQ[EU-Fahrplan PQC]
  end
  subgraph F [Freiwilliger Standard]
    ISO[ISO/IEC 27001]
    C5[BSI C5]
    ET[ETSI EN 319 411-1]
    NI[NIST FIPS 203-205]
    IE[IETF-RFCs]
  end
  NIS2 -->|Stand der Technik| TR
  NIS2 -->|Nachweis über| ISO
  NIS2 -->|Nachweis über| GS
  KR -->|ergänzt| NIS2
  PQ -->|Algorithmen| NI
  TR -->|Formate| IE
  classDef g fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef e fill:#fff4ce,stroke:#986f0b,color:#201f1e
  classDef f fill:#deecf9,stroke:#0078d4,color:#201f1e
  class NIS2,KR,CRA,DS,DO g
  class TR,GS,PQ e
  class ISO,C5,ET,NI,IE f
  style G fill:#ffffff,stroke:#8a8886,color:#201f1e
  style E fill:#ffffff,stroke:#8a8886,color:#201f1e
  style F fill:#ffffff,stroke:#8a8886,color:#201f1e

Gesetze verlangen „geeignete, verhältnismäßige und wirksame“ Maßnahmen nach dem Stand der Technik, nennen aber selten konkrete Verfahren. Den Stand der Technik konkretisieren technische Richtlinien (TR-02102) und Standards (FIPS, RFCs); den Nachweis führt man über Managementsysteme (ISO/IEC 27001, IT-Grundschutz) und Testate (C5).

Art: Gesetzliche Pflicht. Stand: Richtlinie (EU) 2022/2555; umgesetzt durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, das das BSI-Gesetz neu fasst (BSI-Gesetz vom

2. Dezember 2025, BGBl. 2025 I Nr. 301), in Kraft seit 6. Dezember 2025. Die Pflichten der

Einrichtungen stehen in §§ 30 bis 38 BSIG.

Zweck und wesentliche Anforderungen. NIS2 soll ein einheitlich hohes Cybersicherheitsniveau in der EU herstellen. Erfasste Einrichtungen müssen Risikomanagementmaßnahmen umsetzen (§ 30 BSIG, Art. 21 NIS2), erhebliche Sicherheitsvorfälle melden (§ 32 BSIG: frühe Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussmeldung binnen eines Monats), sich beim BSI registrieren und die Umsetzung durch die Geschäftsleitung billigen und überwachen lassen, die bei schuldhafter Verletzung haftet (§ 38 BSIG). Die zehn Maßnahmen des § 30 Abs. 2 entsprechen Art. 21 Abs. 2 a bis j der Richtlinie.

Anwendungsbereich.

Konsequenzen für die Architektur und Umsetzung. Die zehn Maßnahmen bestimmen, was TrustBridge technisch leisten und organisatorisch ermöglichen muss:

Nachweise. TrustBridge liefert die Architekturbeschreibung mit Bedrohungsmodell und Ausfallanalyse (diese Dokumentation) und die Nachweise aus Register, Sicherheitsaudit und Verbindungsprotokoll. Die betreibende Organisation erbringt Betroffenheitsprüfung, Registrierung, Meldeprozess, Risikoanalyse im eigenen Betrieb und die Wirksamkeitsprüfung der Maßnahmen.

Gute Praxis. Auch ein nicht erfasster Betreiber sollte die zehn Maßnahmen nachweisen können: Seine Kunden sind häufig erfasst und müssen ihre Dienstleister bewerten. Die Tabelle oben ist die Gliederung dieses Nachweises.

Quellen: Richtlinie (EU) 2022/2555 – Volltext der Richtlinie; Art. 21 enthält die Mindestmaßnahmen, Anhang I die Sektoren. · BSIG 2025 – geltende Fassung; § 30 Risikomanagement, § 32 Meldepflichten, § 38 Geschäftsleitung. · BSI: NIS-2-regulierte Unternehmen – Erläuterungen des BSI, Registrierung, FAQ. · BSI: NIS-2-Betroffenheitsprüfung – Fragebogen zur ersten, rechtlich unverbindlichen Einschätzung.

Art: Gesetzliche Pflicht. Stand: Die IT-Sicherheit kritischer Anlagen regelt das BSIG; welche Anlagen kritisch sind, bestimmt die BSI-Kritisverordnung anhand von Schwellenwerten je Sektor. Das KRITIS-Dachgesetz setzt die CER-Richtlinie (EU) 2022/2557 um, regelt den physischen Schutz und die Resilienz kritischer Anlagen, wurde im BGBl. 2026 I Nr. 66 verkündet und gilt seit dem

17. März 2026. Aufsicht ist das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK). Die

Registrierungsfristen wurden nach der Verkündung geändert; maßgeblich ist die aktuelle Fassung.

Zweck und wesentliche Anforderungen. Betreiber kritischer Anlagen unterliegen über NIS2 hinaus erhöhten Anforderungen: Maßnahmen nach dem Stand der Technik, Systeme zur Angriffserkennung, regelmäßige Nachweise gegenüber dem BSI; nach dem KRITIS-Dachgesetz zusätzlich Risikoanalysen, Resilienzpläne und Meldung erheblicher Störungen.

Anwendungsbereich. Der Betreiber einer privaten PKI ist in aller Regel nicht selbst Betreiber einer kritischen Anlage. Seine Kunden können es sein – Energie, Wasser, Transport, Gesundheit und die Industrie in deren Lieferketten. Sie geben ihre Anforderungen an Dienstleister weiter.

Konsequenzen für die Architektur und Umsetzung.

Nachweise. Die betrieblichen Nachweise erbringt die betreibende Organisation, gestützt auf Register, Übungen und Vorgabewerte von TrustBridge.

Quellen: BSI-KritisV – Sektoren, Anlagenkategorien und Schwellenwerte. · Bundesregierung: KRITIS-Dachgesetz – Ziele und Inhalte des Gesetzes. · BSIG 2025 – Pflichten der Betreiber kritischer Anlagen.

Art: Technische Empfehlung; wird über den „Stand der Technik“ des BSIG und über Verträge maßgeblich. Stand: Fassung 2026-01 aller vier Teile – TR-02102-1 (Empfehlungen und Schlüssellängen), TR-02102-2 (TLS), TR-02102-3 (IPsec und IKEv2), TR-02102-4 (SSH).

Zweck und wesentliche Anforderungen. Die TR legt fest, welche kryptographischen Verfahren und Schlüssellängen das BSI für welchen Zeitraum als sicher einschätzt. Für den Post-Quanten-Übergang gilt:

• Die Empfehlungen zu quantensicheren Schlüsseleinigungs- und Signaturverfahren stehen in TR-02102-1. Das BSI empfiehlt, Post-Quanten-Verfahren in Kombination mit klassischen Verfahren (hybrid) einzusetzen, und nennt nur die Parametersätze der Sicherheitskategorien 3 und 5: ML-KEM-768 und ML-KEM-1024 (Tabelle 2.7), ML-DSA-65 und ML-DSA-87 in der Variante „hedged“ (Tabelle 5.7). ML-KEM-512 und ML-DSA-44 empfiehlt es nicht.
• Für TLS 1.3 kündigt TR-02102-2 an, die hybriden Gruppen SecP256r1MLKEM768 und SecP384r1MLKEM1024 zu empfehlen, sobald der zugehörige RFC verabschiedet ist; spezifiziert sind sie in RFC 10024. Die dort ebenfalls definierte Gruppe X25519MLKEM768 nennt das BSI nicht.
• Von Classic McEliece rät das BSI für Neuentwicklungen derzeit ab, weil die Kryptoanalyse 2026 Fortschritte gemacht hat; praktische Angriffe auf die empfohlenen Parametersätze sind nach Angabe des BSI bisher nicht bekannt.

Anwendungsbereich. Betreiber, Hersteller und Kunden gleichermaßen; die Kunden prüfen Zertifikate mit den Verfahren, die TrustBridge ausstellt.

Konsequenzen für die Architektur. TrustBridge stellt hybride Zertifikate aus: klassische Signatur und ML-DSA-Alternativsignatur im selben Zertifikat. Verbindungen zwischen Partnern verwenden die von TR-02102-2 empfohlenen hybriden Gruppen und zusätzlich ein Geheimnis, das die Schlüsselagenten mit ML-KEM vereinbaren und mit ML-DSA authentisieren; Classic McEliece wird nicht verwendet (siehe PQ-Schlüsselaustausch für TLS).

Umsetzung und Nachweise. ML-DSA und ML-KEM werden gegen die veröffentlichten Prüffälle geprüft. Die Parametersätze je Einsatz folgen der Fassung 2026-01 der TR (siehe Kryptographie und Post-Quanten-Übergang).

Gute Praxis. Die TR wird jährlich fortgeschrieben. Eine Zertifizierungsrichtlinie sollte die Fassung der TR nennen, gegen die ihre Verfahren geprüft wurden, und einen Termin für die nächste Prüfung.

Quelle: BSI TR-02102 – alle vier Teile mit aktuellen Hinweisen des BSI zu hybriden TLS-Gruppen.

Art: Technische Empfehlung (Fahrplan der Mitgliedstaaten, nicht unmittelbar verbindlich). Stand: Empfehlung der Kommission vom April 2024; Coordinated Implementation Roadmap der NIS Cooperation Group vom Juni 2025; gemeinsame Leitlinie von BMI, BMDS und BSI.

Zweck und wesentliche Anforderungen. Ein ausreichend leistungsfähiger Quantencomputer würde RSA und elliptische Kurven brechen. Daten, die heute verschlüsselt übertragen und aufgezeichnet werden, könnten später entschlüsselt werden („harvest now, decrypt later“); Signaturen mit langer Gültigkeit könnten später gefälscht werden. Der Fahrplan legt deshalb Fristen fest:

Die deutsche Leitlinie bestätigt diesen Zeitrahmen und nennt Kryptoagilität als Grundprinzip.

Konsequenzen für die Architektur. Eine PKI ist selbst eine Hochrisiko-Anwendung und zugleich Voraussetzung für die Umstellung ihrer Kunden. Wurzel- und CA-Schlüssel, die heute klassisch erzeugt werden und zwanzig Jahre gelten sollen, überdauern den Zeitrahmen. Daraus folgt: hybride CAs von Anfang an, eine neue CA-Generation statt späterer Umschlüsselung, und Prüfer, die beide Signaturen auswerten können.

Nachweise der betreibenden Organisation. Kryptoinventar des Betreibers; Migrationsplan für bestehende Anker der Kunden.

Quellen: EU: Coordinated Implementation Roadmap – Fristen und Priorisierung nach Risiko. · EU: Empfehlung der Kommission – Auftrag an die Mitgliedstaaten. · BSI: Quantentechnologien und Post-Quanten-Kryptografie – Einschätzung des BSI und Verweis auf die Empfehlungen der TR-02102-1.

Art: Freiwilliger Standard (für US-Bundesbehörden verbindlich); IR 8547 ist ein Entwurf. Stand: FIPS 203, 204 und 205 vom August 2024; IR 8547 als Entwurf vom November 2024.

Zweck und Inhalt. FIPS 203 standardisiert ML-KEM, ein gitterbasiertes Verfahren zur Schlüsselkapselung; FIPS 204 ML-DSA, ein gitterbasiertes Signaturverfahren; FIPS 205 SLH-DSA, ein hashbasiertes Signaturverfahren mit konservativeren Annahmen und größeren Signaturen. Der Entwurf IR 8547 schlägt vor, RSA und Verfahren auf elliptischen Kurven nach 2030 abzukündigen und nach 2035 nicht mehr zuzulassen.

Anwendungsbereich. Weltweit maßgeblich für die Algorithmen selbst; für europäische Betreiber nicht verbindlich, für Kunden mit US-Geschäft relevant.

Konsequenzen und Umsetzung. TrustBridge verwendet ML-DSA für Signaturen und ML-KEM für Schlüsselkapselung. Die Implementierung wird gegen die veröffentlichten Prüffälle geprüft. FIPS 204 sieht eine Kontextzeichenkette von höchstens 255 Byte vor; sie wird geführt und ist Teil der Prüfung.

Quellen: FIPS 203 · FIPS 204 · FIPS 205 · NIST IR 8547 (Entwurf) – vorgeschlagener Zeitplan zur Abkündigung klassischer Verfahren.

Art: Freiwilliger Standard; verbindlich durch Interoperabilität – ein Zertifikat, das eine Gegenstelle nicht lesen kann, ist wertlos.

Art: Technische Empfehlung; Methode für ein Informationssicherheits-Managementsystem. Stand: IT-Grundschutz-Kompendium Edition 2023 mit den BSI-Standards 200-1 bis 200-4. Grundschutz++ soll das Kompendium ablösen; laut BSI befindet sich die Methodik in der Einführungs- und Erprobungsphase, der bisherige IT-Grundschutz bleibt in einer mehrjährigen Übergangszeit anwendbar. Beide sind nach Angabe des BSI mit ISO/IEC 27001 vereinbar.

Zweck. Der IT-Grundschutz beschreibt, wie eine Organisation Informationssicherheit systematisch aufbaut, und liefert Bausteine mit konkreten Anforderungen.

Anwendungsbereich. Betreiber.

Konsequenzen und Umsetzung. Folgende Bausteine betreffen TrustBridge unmittelbar:

Nachweise der betreibenden Organisation. Grundschutz-Check, Modellierung, Sicherheitskonzept des Betreibers.

Quellen: IT-Grundschutz-Kompendium – Bausteine und Anforderungen. · Grundschutz++ – Nachfolgemethodik mit maschinenlesbaren Anforderungen.

Art: Freiwilliger Standard, zertifizierbar. Stand: Ausgabe 2022 mit Änderung 1:2024 (Klimaschutz).

Zweck. Anforderungen an ein Informationssicherheits-Managementsystem: Kontext, Führung, Planung, Betrieb, Bewertung, Verbesserung; Anhang A mit 93 Kontrollen.

Anwendungsbereich. Betreiber; häufig von Kunden als Mindestnachweis verlangt.

Konsequenzen und Umsetzung. Kontrollen mit unmittelbarem Bezug: 5.15 Zugangssteuerung, 5.23 Informationssicherheit bei der Nutzung von Cloud-Diensten, 5.30 IKT-Bereitschaft für die Betriebskontinuität, 8.5 sichere Authentisierung, 8.15 Protokollierung, 8.24 Verwendung von Kryptographie, 8.28 sichere Programmierung. Die Architektur liefert die technische Begründung; das Managementsystem selbst ist Sache des Betreibers.

Nachweise der betreibenden Organisation. Managementsystem, Erklärung zur Anwendbarkeit, Zertifizierung.

Quelle: ISO/IEC 27001:2022 – Normbeschreibung (Normtext kostenpflichtig).

Art: Freiwilliger Standard; Grundlage eines Testats durch Wirtschaftsprüfer. Stand: C5:2020; C5:2026 (Fassung 1.0.1, veröffentlicht im April 2026) empfiehlt das BSI für Prüfzeiträume, die am oder nach dem 1. Juni 2027 enden.

Zweck. Mindestanforderungen an die Informationssicherheit von Cloud-Diensten. C5:2026 vertieft unter anderem Lieferkette, Mandantentrennung und Schwachstellenmanagement.

Anwendungsbereich. Betreiber, wenn TrustBridge als Cloud-Dienst angeboten wird. Im Gesundheitswesen ist ein C5-Testat für die Cloud-Verarbeitung von Patientendaten gesetzlich vorgeschrieben (§ 393 SGB V).

Konsequenzen. Mandantentrennung in Datenbank und CA-Hierarchie, nachweisbare Protokollierung, Schwachstellenbehandlung.

Nachweise der betreibenden Organisation. Testat.

Quelle: BSI: C5 – aktuelle Version – Kriterienkatalog, Querverweise zu ISO/IEC 27001, maschinenlesbare Fassung.

Art: Freiwilliger Standard. Stand: EN 319 401 V3.1.1 (Juni 2024, an NIS2 angeglichen); EN 319 411-1 in der Fassung von 2023, eine Überarbeitung ist angekündigt.

Zweck. Anforderungen an Vertrauensdiensteanbieter, die Zertifikate ausstellen: Organisation, Rollentrennung, Schlüsselzeremonien mit Zeugen, Schutz der Schlüssel, Protokollierung, Beendigung des Dienstes. EN 319 411-1 folgt dem Gliederungsrahmen von RFC 3647.

Anwendungsbereich. Für eine private PKI nicht verpflichtend, aber die gängige Messlatte eines ordnungsgemäßen CA-Betriebs, an der Prüfer sich orientieren.

Konsequenzen und Umsetzung. Zeremonien mit Rollen und Zeugen, Schlüssellebenszyklus, manipulationserkennbare Protokollierung sind Teil von TrustBridge (PKI und Zertifikatslebenszyklus).

Nachweise. Zertifizierungsrichtlinie (CP) und Erklärung zum Zertifizierungsbetrieb (CPS) erstellt die betreibende Organisation; TrustBridge liefert eine Vorlage nach RFC 3647, die die Festlegungen dieser Dokumentation enthält.

Quellen: ETSI EN 319 401 · ETSI EN 319 411-1 – frei abrufbar beim ETSI.

Art: Gesetzliche Pflicht (EU-Verordnung). Stand: Verordnung (EU) 2024/2847; Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle seit 11. September 2026, die übrigen Pflichten ab 11. Dezember 2027.

Zweck. Sicherheit von Produkten mit digitalen Elementen über ihren Lebenszyklus: grundlegende Sicherheitsanforderungen, Schwachstellenbehandlung, Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation.

Anwendungsbereich. Hersteller, wenn TrustBridge als Software in Verkehr gebracht und beim Kunden betrieben wird. Ein ausschließlich als Dienst betriebenes Angebot steht vor allem unter NIS2.

Konsequenzen. Schwachstellenbehandlung, Stückliste der Software (SBOM), sichere Standardkonfiguration, Aktualisierbarkeit. TrustBridge wird als Software in Verkehr gebracht; die Herstellerpflichten liegen bei WKL.

Nachweise. Stückliste der Software je Fassung, Schwachstellenbehandlung und Meldeweg des Herstellers.

Quelle: Verordnung (EU) 2024/2847.

Art: Gesetzliche Pflicht. Stand: Verordnung (EU) 2016/679, geltend seit 25. Mai 2018.

Zweck und Anforderungen. Schutz personenbezogener Daten; Datenminimierung (Art. 5), Sicherheit der Verarbeitung (Art. 32).

Anwendungsbereich. Betreiber und Kunden, soweit Zertifikate, Anträge oder Protokolle personenbezogene Daten enthalten – Namen, E-Mail-Adressen, IP-Adressen.

Konsequenzen und Umsetzung. Ein System wird über genau einen DNS-Namen identifiziert; E-Mail-Adressen nur bei ausdrücklicher Einführung von Personenzertifikaten; das Organisationsfeld setzt TrustBridge aus dem Mandanten. Für Sicherheitsaudit und Betriebsprotokoll sind Aufbewahrungsfristen festzulegen. Ein ausgestelltes Zertifikat ist unveränderlich; ein Löschbegehren betrifft Inventar und Protokolle, nicht das Zertifikat.

Nachweise der betreibenden Organisation. Verarbeitungsverzeichnis, Löschkonzept.

Quelle: Verordnung (EU) 2016/679.

Art: Gesetzliche Pflicht für Finanzunternehmen. Stand: Verordnung (EU) 2022/2554, geltend seit

17. Januar 2025.

Zweck und Anforderungen. Digitale operationale Resilienz des Finanzsektors, einschließlich der Steuerung von IKT-Drittdienstleistern: Informationsregister, vertragliche Mindestinhalte, Ausstiegsstrategien.

Anwendungsbereich. Kunden aus dem Finanzsektor; mittelbar der Betreiber als deren Dienstleister.

Konsequenzen. Vertragsanhänge zu Prüfrechten, Vorfallsmeldung und Ausstieg – insbesondere die Übergabe von CA-Zertifikaten, letzter Sperrliste und Register bei Beendigung.

Quelle: Verordnung (EU) 2022/2554.

Aus den Regelwerken ergeben sich sechs Anforderungsbereiche, die die Architekturableitung einzeln mit Herkunft auflistet: Echtheit der Identitäten über Partnergrenzen, Schutz und Lebenszyklus der Schlüssel, Verfügbarkeit der Statusauskunft, nachweisbare Autorisierung jeder Ausstellung, Mandantentrennung und Datenschutz, geplanter Übergang zu Post-Quanten-Verfahren.

• Keine Rechtsberatung. Die Wiedergabe der Quellen und die eigene Auslegung sind getrennt gekennzeichnet; ob ein Regelwerk für einen bestimmten Betreiber oder Kunden gilt, ist im Einzelfall zu prüfen.
• Keine Konformitätsbewertung. Welche Nachweise vorliegen und welche fehlen, steht je Regelwerk; eine Erfüllung wird nicht behauptet.
• Kein laufend aktueller Stand. Rechts- und Versionsstand beziehen sich auf die Prüfung am
  15. Oktober 2026.