Foundations and requirements

Summary. This page collects the laws, standards, technical guidelines, and recognized specifications that shape the requirements for WKL TrustBridge. For each framework it answers five questions. What is its purpose, and what does it require? Whom does it apply to: operators, manufacturers, customers? What does it mean for the architecture? How is it implemented, technically and organizationally? Which evidence exists, and which is missing? Legal and version status reflect the review on October 15, 2026. The requirements derived from all frameworks are listed together in Architecture derivation.

Source versus interpretation. Text under “Purpose and key requirements” restates the source. Text under “Consequences”, “Implication”, and “Implementation” is our own interpretation for this product; it is not a statement of the source.

Not legal advice. Whether an operator or customer falls under a law is for them to determine against the statutory criteria; the BSI, by its own account, makes no binding case-by-case determination. This page names criteria and primary sources, not legal opinions. It does not claim that TrustBridge is compliant with or certified against any framework.

Frameworks differ in how binding they are. This documentation uses four kinds:

Three roles need to be kept apart, because obligations fall on them differently:

• Operator – runs TrustBridge as a service for partners and customers.
• Manufacturer – places TrustBridge on the market as software, for example to run on the customer's premises.
• Customer – has its systems equipped with certificates through TrustBridge and is often a regulated entity itself.

graph TD
  subgraph G [Legal obligation]
    NIS2[NIS2 / BSIG]
    KR[KRITIS umbrella act<br/>BSI-KritisV]
    CRA[Cyber Resilience Act]
    DS[GDPR]
    DO[DORA]
  end
  subgraph E [Technical recommendation]
    TR[BSI TR-02102]
    GS[IT-Grundschutz]
    PQ[EU PQC roadmap]
  end
  subgraph F [Voluntary standard]
    ISO[ISO/IEC 27001]
    C5[BSI C5]
    ET[ETSI EN 319 411-1]
    NI[NIST FIPS 203-205]
    IE[IETF RFCs]
  end
  NIS2 -->|state of the art| TR
  NIS2 -->|evidence via| ISO
  NIS2 -->|evidence via| GS
  KR -->|supplements| NIS2
  PQ -->|algorithms| NI
  TR -->|formats| 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

Laws ask for “appropriate, proportionate, and effective” measures that reflect the state of the art, but they rarely name specific algorithms or methods. Technical guidelines (TR-02102) and standards (FIPS, RFCs) make the state of the art concrete; management systems (ISO/IEC 27001, IT-Grundschutz) and attestations (C5) provide the evidence.

Kind: Legal obligation. Status: Directive (EU) 2022/2555, transposed in Germany by the NIS2 Implementation and Cybersecurity Strengthening Act, which recasts the BSI Act (BSIG of December 2, 2025, Federal Law Gazette 2025 I No. 301), in force since December 6, 2025. The obligations of covered entities are set out in Sections 30 to 38 BSIG.

Purpose and key requirements. NIS2 aims at a uniformly high level of cybersecurity across the EU. Covered entities must implement risk management measures (Section 30 BSIG, Art. 21 NIS2), report significant incidents (Section 32 BSIG: early warning within 24 hours, notification within 72 hours, final report within one month), register with the BSI, and have management approve and oversee the implementation; management is liable for culpable breaches (Section 38 BSIG). The ten measures in Section 30(2) correspond to Art. 21(2)(a) to (j) of the Directive.

Scope.

Consequences for architecture and implementation. The ten measures determine what TrustBridge has to deliver technically and make possible organizationally:

Evidence. TrustBridge provides the architecture description with threat model and failure analysis (this documentation) and the evidence from its ledger, security audit log, and connection log. The operating organization provides the scoping assessment, registration, reporting process, risk analysis of its own operations, and the effectiveness review of the measures.

Good practice. An operator that is not covered should still be able to evidence the ten measures: its customers often are covered and must assess their service providers. The table above is the outline for that evidence.

Sources: Directive (EU) 2022/2555 – full text; Art. 21 holds the minimum measures, Annex I the sectors. · BSIG 2025 – current version (German); Section 30 risk management, Section 32 reporting, Section 38 management. · BSI: NIS2-regulated companies – BSI explanations, registration, FAQ (German). · BSI: NIS2 scoping check – questionnaire for an initial, legally non-binding assessment (German).

Kind: Legal obligation. Status: The IT security of critical facilities is governed by the BSIG; which facilities count as critical is set by the BSI Critical Infrastructure Ordinance (BSI-KritisV) through thresholds per sector. The KRITIS umbrella act (KRITIS-Dachgesetz) transposes the CER Directive (EU) 2022/2557, governs the physical protection and resilience of critical facilities, was promulgated in Federal Law Gazette 2026 I No. 66, and has applied since March 17, 2026. The supervisory authority is the Federal Office of Civil Protection and Disaster Assistance (BBK). The registration deadlines were amended after promulgation; the current version governs.

Purpose and key requirements. Operators of critical facilities face requirements beyond NIS2: measures reflecting the state of the art, attack detection systems, regular evidence to the BSI; under the umbrella act, additionally risk assessments, resilience plans, and reporting of significant disruptions.

Scope. The operator of a private PKI is, as a rule, not itself the operator of a critical facility. Its customers may be: energy, water, transport, health, and the manufacturers in their supply chains. They pass their requirements on to their service providers.

Consequences for architecture and implementation.

Evidence. The operating organization provides the operational evidence, based on the TrustBridge ledger, exercises, and default values.

Sources: BSI-KritisV – sectors, facility categories, and thresholds (German). · German Federal Government: KRITIS umbrella act – aims and content of the act (German). · BSIG 2025 – obligations of operators of critical facilities (German).

Kind: Technical recommendation; becomes authoritative through the BSIG's “state of the art” and through contracts. Status: Edition 2026-01 of all four parts: TR-02102-1 (recommendations and key lengths), TR-02102-2 (TLS), TR-02102-3 (IPsec and IKEv2), TR-02102-4 (SSH).

Purpose and key requirements. The TR sets out which cryptographic mechanisms and key lengths the BSI considers secure, and for how long. For the post-quantum transition:

• The recommendations for quantum-safe key agreement and signature schemes are in TR-02102-1. The BSI recommends using post-quantum schemes in combination with classical ones (hybrid) and lists only the parameter sets of security categories 3 and 5: ML-KEM-768 and ML-KEM-1024 (Table 2.7), ML-DSA-65 and ML-DSA-87 in the “hedged” variant (Table 5.7). It does not recommend ML-KEM-512 or ML-DSA-44.
• For TLS 1.3, TR-02102-2 announces that it will recommend the hybrid groups SecP256r1MLKEM768 and SecP384r1MLKEM1024 once the corresponding RFC is published; they are specified in RFC 10024. The BSI does not list the group X25519MLKEM768, which the same RFC also defines.
• The BSI currently advises against Classic McEliece for new developments because cryptanalysis made progress in 2026; according to the BSI, no practical attacks on the recommended parameter sets are known so far.

Scope. Operators, manufacturers, and customers alike; customers verify certificates with the algorithms that TrustBridge issues.

Consequences for the architecture. TrustBridge issues hybrid certificates: a classical signature and an ML-DSA alternative signature in the same certificate. Connections between partners use the hybrid groups recommended by TR-02102-2 and, in addition, a secret that the key agents agree on with ML-KEM and authenticate with ML-DSA. Classic McEliece is not used (see PQ key exchange for TLS).

Implementation and evidence. ML-DSA and ML-KEM are tested against the published test vectors. The parameter sets for each use follow edition 2026-01 of the TR (see Cryptography and the post-quantum transition).

Good practice. The TR is updated every year. A certificate policy should name the edition of the TR its algorithms were checked against, and a date for the next review.

Source: BSI TR-02102 – all four parts, with the BSI's current notes on hybrid TLS groups.

Kind: Technical recommendation (a roadmap among member states, not directly binding). Status: Commission Recommendation of April 2024; Coordinated Implementation Roadmap of the NIS Cooperation Group of June 2025; joint guideline of the German Federal Ministry of the Interior, the Federal Ministry for Digital Affairs and State Modernization, and the BSI.

Purpose and key requirements. A sufficiently powerful quantum computer would break RSA and elliptic-curve cryptography. Data encrypted and recorded in transit today could be decrypted later (“harvest now, decrypt later”), and long-lived signatures could be forged later. The roadmap therefore sets deadlines:

The German guideline confirms this timeline and names crypto agility as a core principle.

Consequences for the architecture. A PKI is a high-risk use case in its own right and at the same time a prerequisite for its customers' migration. Root and CA keys generated classically today and meant to last twenty years would outlive the timeline. Hence: hybrid CAs from the start, a new CA generation instead of re-keying later, and relying parties that can evaluate both signatures.

Evidence from the operating organization. The operator's cryptographic inventory; a migration plan for customers' existing anchors.

Sources: EU: Coordinated Implementation Roadmap – deadlines and risk-based prioritization. · EU: Commission Recommendation – mandate to the member states. · BSI: Quantum technologies and post-quantum cryptography – the BSI's assessment, with a pointer to the recommendations in TR-02102-1.

Kind: Voluntary standard (mandatory for US federal agencies); IR 8547 is a draft. Status: FIPS 203, 204, and 205 of August 2024; IR 8547 initial public draft of November 2024.

Purpose and content. FIPS 203 standardizes ML-KEM, a lattice-based key encapsulation mechanism; FIPS 204 standardizes ML-DSA, a lattice-based signature scheme; FIPS 205 standardizes SLH-DSA, a hash-based signature scheme with more conservative assumptions and larger signatures. The IR 8547 draft proposes deprecating RSA and elliptic-curve schemes after 2030 and disallowing them after 2035.

Scope. Authoritative worldwide for the algorithms themselves; not binding on European operators, relevant for customers doing business in the US.

Consequences and implementation. TrustBridge uses ML-DSA for signatures and ML-KEM for key encapsulation. The implementation is tested against the published test vectors. FIPS 204 provides for a context string of up to 255 bytes; it is carried and is part of the tests.

Sources: FIPS 203 · FIPS 204 · FIPS 205 · NIST IR 8547 (draft) – proposed timeline for retiring classical algorithms.

Kind: Voluntary standard; binding through interoperability, because a certificate the counterpart cannot parse is worthless.

Kind: Technical recommendation; a method for an information security management system. Status: IT-Grundschutz Compendium Edition 2023 with BSI Standards 200-1 to 200-4. Grundschutz++ is meant to replace the Compendium; according to the BSI the methodology is in its introduction and trial phase, and the existing IT-Grundschutz remains usable during a transition period of several years. The BSI states that both are compatible with ISO/IEC 27001.

Purpose. IT-Grundschutz describes how an organization builds up information security systematically, and provides modules with concrete requirements.

Scope. Operators.

Consequences and implementation. The following modules apply directly to TrustBridge:

Evidence from the operating organization. The operator's Grundschutz check, modeling, and security concept.

Sources: IT-Grundschutz Compendium – modules and requirements (German). · Grundschutz++ – successor methodology with machine-readable requirements (German).

Kind: Voluntary standard, certifiable. Status: 2022 edition with Amendment 1:2024 (climate action changes).

Purpose. Requirements for an information security management system: context, leadership, planning, operation, performance evaluation, improvement; Annex A with 93 controls.

Scope. Operators; customers often ask for it as baseline evidence.

Consequences and implementation. Directly relevant controls: 5.15 access control, 5.23 information security for use of cloud services, 5.30 ICT readiness for business continuity, 8.5 secure authentication, 8.15 logging, 8.24 use of cryptography, 8.28 secure coding. The architecture supplies the technical rationale; the management system itself is the operator's responsibility.

Evidence from the operating organization. Management system, statement of applicability, certification.

Source: ISO/IEC 27001:2022 – standard description (the text itself is sold by ISO).

Kind: Voluntary standard; the basis for an attestation by auditors. Status: C5:2020. The BSI recommends C5:2026 (version 1.0.1, published April 2026) for audit periods ending on or after June 1,

Purpose. Minimum information security requirements for cloud services. Among other things, C5:2026 goes deeper on the supply chain, tenant separation, and vulnerability management.

Scope. Operators, when TrustBridge is offered as a cloud service. In German healthcare, a C5 attestation is required by law for processing patient data in the cloud (Section 393 SGB V).

Consequences. Tenant separation in the database and the CA hierarchy, verifiable logging, vulnerability handling.

Evidence from the operating organization. Attestation.

Source: BSI: C5 – current version – criteria catalog, cross-references to ISO/IEC 27001, machine-readable version.

Kind: Voluntary standard. Status: EN 319 401 V3.1.1 (June 2024, aligned with NIS2); EN 319 411-1 in its 2023 version, with a revision announced.

Purpose. Requirements for trust service providers that issue certificates: organization, separation of roles, key ceremonies with witnesses, protection of keys, logging, termination of the service. EN 319 411-1 follows the outline of RFC 3647.

Scope. Not mandatory for a private PKI, but the common yardstick for running a CA properly, and the one auditors look to.

Consequences and implementation. Ceremonies with roles and witnesses, the key lifecycle, and tamper-evident logging are part of TrustBridge (PKI and certificate lifecycle).

Evidence. The operating organization writes the certificate policy (CP) and certification practice statement (CPS); TrustBridge provides an RFC 3647 template that contains the rules defined in this documentation.

Sources: ETSI EN 319 401 · ETSI EN 319 411-1 – free of charge from ETSI.

Kind: Legal obligation (EU regulation). Status: Regulation (EU) 2024/2847; reporting obligations for actively exploited vulnerabilities and severe incidents since September 11, 2026, all other obligations from December 11, 2027.

Purpose. Security of products with digital elements across their lifecycle: essential security requirements, vulnerability handling, conformity assessment, CE marking, technical documentation.

Scope. Manufacturers, when TrustBridge is placed on the market as software and run at the customer's site. An offering run exclusively as a service falls primarily under NIS2.

Consequences. Vulnerability handling, software bill of materials (SBOM), secure default configuration, updatability. TrustBridge is placed on the market as software; the manufacturer obligations rest with WKL.

Evidence. An SBOM per release, the manufacturer's vulnerability handling and reporting channel.

Source: Regulation (EU) 2024/2847.

Kind: Legal obligation. Status: Regulation (EU) 2016/679, applicable since May 25, 2018.

Purpose and requirements. Protection of personal data; data minimization (Art. 5), security of processing (Art. 32).

Scope. Operators and customers, insofar as certificates, requests, or logs contain personal data such as names, email addresses, or IP addresses.

Consequences and implementation. A system is identified by exactly one DNS name; email addresses only if personal certificates are explicitly introduced; TrustBridge sets the organization field from the tenant. Retention periods must be defined for the security audit log and the operations log. An issued certificate cannot be changed; an erasure request applies to the inventory and the logs, not to the certificate.

Evidence from the operating organization. Records of processing activities, deletion concept.

Source: Regulation (EU) 2016/679.

Kind: Legal obligation for financial entities. Status: Regulation (EU) 2022/2554, applicable since January 17, 2025.

Purpose and requirements. Digital operational resilience of the financial sector, including the management of ICT third-party service providers: register of information, minimum contractual content, exit strategies.

Scope. Customers in the financial sector; indirectly the operator as their service provider.

Consequences. Contract annexes on audit rights, incident reporting, and exit, in particular the hand-over of CA certificates, the last revocation list, and the ledger when the contract ends.

Source: Regulation (EU) 2022/2554.

The frameworks lead to six areas of requirements, which Architecture derivation lists one by one with their origin: authenticity of identities across partner boundaries, protection and lifecycle of keys, availability of status information, verifiable authorization of every issuance, tenant separation and data protection, and a planned transition to post-quantum algorithms.

• No legal advice. Restatements of sources and our own interpretation are marked separately; whether a framework applies to a particular operator or customer has to be assessed case by case.
• No conformity assessment. Which evidence exists and which is missing is stated per framework; no claim of fulfillment is made.
• No guarantee of being up to date. Legal and version status reflect the review on October 15, 2026.