Germany Software Supply Chain and AI Security Rules: A 90-Day Plan

If your organisation builds, buys or runs software in Germany, four sets of rules now decide what you must prove about it: the BSI Act as rewritten by the NIS2 implementation law, the new KRITIS umbrella law for critical facilities, the EU Cyber Resilience Act for anything you sell with digital elements, and DORA for financial firms supervised by BaFin. The AI Act adds a fifth line, now supervised nationally by the Bundesnetzagentur. The practical answer is the same for all of them: a living inventory of your software components, supplier evidence you can show on request, clocks for incident and vulnerability reporting, and a record that management signed off.

This guide is for the CISO, the head of AppSec or product security, the engineering lead, the information security officer and GRC team, procurement and vendor risk, and the data protection officer in German organisations, and for foreign software makers selling into Germany. The first two thirds work with whatever tools you already have. Safeguard enters at "How Safeguard does this".

This is not legal or regulatory advice. Where the post describes a rule, it describes the primary text as published on 25 October 2026. Your supervisor, auditor and counsel decide how it applies to you.

Key takeaways

• The BSI Act (BSI-Gesetz, BSIG) in its NIS2 version is in force. Section 30 lists ten minimum measures, including supply chain security (no. 4) and security in acquisition, development and maintenance, including vulnerability management and disclosure (no. 5). Section 32 sets a 24 hour early report, a 72 hour report and a final report one month later.
• The BSI says the registration deadline under section 33 BSIG has passed; unregistered entities should register now.
• The KRITIS umbrella law (KRITIS-Dachgesetz) is in force for physical resilience of critical facilities, with a 24 hour incident report (section 18).
• BSI TR-03183 is the BSI's non-binding guide to the CRA; Part 2 (version 2.1.0) sets SBOM requirements.
• The EU Cyber Resilience Act reporting duties for actively exploited vulnerabilities apply from 11 September 2026; the main obligations apply from 11 December 2027.
• BaFin repealed VAIT, KAIT and ZAIT at the end of 16 January 2025 and will fully repeal BAIT at the end of 31 December 2026, because DORA covers more institutions from 1 January 2027.
• Germany's AI Act law (KI-MIG) makes the Bundesnetzagentur the default AI market surveillance authority, with BaFin for regulated financial activity.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV, reachability analysis, CSAF and VEX upload, policies and gates, license compliance, attestation and signing, TPRM (Third-Party Risk Manager), Trust Center, Portal (the SBOM publish and share product), the compliance and GRC suite, autonomous remediation (GA, ships switched off), AI-BOM discovery, the CLI and local runner, and private VPC, on-prem, air-gapped and Zero AI deployment.

Who this applies to in Germany

Germany's rules sort organisations by what they are and what they sell, not by whether they write code. Most software teams fall into at least one of these groups.

Foreign suppliers rarely sit inside the BSIG themselves, but their German customers do, and section 30(2) no. 4 makes those customers answer for supplier security. The CRA, by contrast, applies to you directly if you place a product with digital elements on the EU market.

The rules, regulator by regulator

The BSI Act after NIS2 (BSIG and NIS2UmsuCG)

Germany transposed the NIS2 Directive through the NIS2 Implementation and Cybersecurity Strengthening Act (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, NIS2UmsuCG), which replaced the old BSI Act with a new one. The consolidated text is published on the federal law portal as the BSIG. It came into force in December 2025, with no general transition period for the security measures.

The sections that matter most for software teams:

• Section 28 defines particularly important entities (besonders wichtige Einrichtungen) and important entities (wichtige Einrichtungen). Size thresholds and the sector lists in Annexes 1 and 2 decide which you are.
• Section 30(1) requires appropriate, proportionate and effective technical and organisational measures to avoid disruptions to the availability, integrity and confidentiality of the IT systems, components and processes used to deliver services. The last sentence of 30(1) requires entities to document that they comply. That documentation duty is where software evidence lives.
• Section 30(2) lists ten minimum measures. Numbers 4 and 5 are the software supply chain duties: supply chain security, including the security aspects of relationships with direct suppliers or service providers, and security measures in the acquisition, development and maintenance of IT systems, components and processes, including the management and disclosure of vulnerabilities. Measures should follow the state of the art (Stand der Technik) and consider relevant European and international standards.
• Section 31 adds stricter requirements for operators of critical facilities, and section 39 requires them to prove implementation through security audits, examinations or certifications, every three years.
• Section 32 sets the reporting clock: an early report without undue delay and at the latest within 24 hours of becoming aware of a significant security incident; a notification within 72 hours with a first assessment of severity and impact and, where available, indicators of compromise; interim reports on request; and a final report no later than one month after the 72 hour notification, or a progress report if the incident is still running.
• Section 33 requires registration within three months of first qualifying, and changes within two weeks.
• Section 38 places implementation, monitoring and training duties on the management body (Geschäftsleitung) of particularly important and important entities.
• Section 65 sets fines. For breaches of the measures, documentation or reporting duties, particularly important entities face up to 10 million euros, or up to 2 percent of worldwide turnover where turnover exceeds 500 million euros. Important entities face up to 7 million euros, or 1.4 percent above the same turnover threshold.

The BSI's NIS2 page says the statutory registration deadline has passed and unregistered entities should register immediately, in the BSI portal, using an ELSTER organisation certificate from the "Mein Unternehmenskonto" service.

The KRITIS umbrella law (KRITIS-Dachgesetz)

The KRITIS-Dachgesetz, formally the act to strengthen the physical resilience of critical facilities (Dachgesetz zur Stärkung der physischen Resilienz kritischer Anlagen, KRITISDachG), implements the EU Critical Entities Resilience Directive. It is in force and published on the federal law portal. It is about physical resilience, not IT security, which stays in the BSIG. But it shares infrastructure with the BSIG and touches software teams in two places:

• Section 8 requires operators of critical facilities to register with the BBK within three months of a facility qualifying, through the registration facility run jointly with the BSI. Section 33(2) BSIG points to this section for registering critical facilities, so one registration feeds both regimes.
• Section 18 requires operators to report incidents to the BBK without undue delay and at the latest 24 hours after becoming aware, through the joint BSI and BBK reporting office, followed by a detailed report within one month.

Section 13 requires a resilience plan and section 20 places duties on management. If your software runs part of a critical facility, expect that plan to assume you can be restored and patched on a known schedule.

BSI TR-03183: the BSI's guide to the CRA

Technical Guideline BSI TR-03183, "Cyber Resilience Requirements for Manufacturers and Products", is the BSI's interpretation of what the CRA will ask of manufacturers. The BSI states plainly that it is a guide, not binding or mandatory, and that it cannot be used as a presumption of conformity. It will be replaced by harmonised European standards as they become available. The current parts are:

• Part 1, General requirements, revised after a comment period, with a risk-based approach to selecting security measures and an initial set of generic measures in machine-processable OSCAL format.
• Part 2, Software Bill of Materials (SBOM), version 2.1.0. It sets formal and technical requirements for SBOMs. Version 2.1.0 added a recommended mapping between its data fields and the SPDX and CycloneDX formats, revised the licence section and introduced virtual and referenced components. The BSI has registered its own CycloneDX namespace to help.
• Part 3, Vulnerability Reports and Notifications, version 1.0.0, on handling incoming vulnerability reports.
• Part H, version 1.1.0, on CRA conformity through full quality assurance (Module H) built on an ISO/IEC 27001 compliant ISMS such as IT-Grundschutz.

On 29 July 2026 the BSI announced a revised "Minimum Elements for a Software Bill of Materials" published by CISA with the BSI and other agencies.

BSI C5 for cloud services

The Cloud Computing Compliance Criteria Catalogue (C5) sets minimum requirements for secure cloud computing. There is no C5 certificate: a provider engages an auditor, who examines whether the criteria are met and writes a detailed report. The BSI advises cloud customers to request and analyse the C5 report as part of their own risk assessment, and to repeat that yearly.

The BSI published C5:2026 on 7 April 2026, adding container management, post-quantum cryptography and confidential computing, sharpening supply chain management, and offering a machine-readable format for the first time. Many current reports are still written against C5:2020, so check the BSI's transition guidance for your next audit period.

BSI IT-Grundschutz

IT-Grundschutz is the BSI's ISMS method: BSI Standards 200-1, 200-2 and 200-3 plus the IT-Grundschutz Compendium. For software teams the key modules are CON.8 (software development), APP.6 (general software), OPS.1.1.3 (patch and change management) and the outsourcing modules.

The BSI is rebuilding IT-Grundschutz as a process-oriented digital rule set in JSON that software can evaluate. The current version stays applicable during a multi-year transition.

TISAX for automotive

TISAX (Trusted Information Security Assessment Exchange) is the automotive industry's shared assessment and exchange mechanism, governed by the ENX Association. Assessments are based on the Information Security Assessment (ISA) catalogue, maintained by ENX and published by the German Association of the Automotive Industry (VDA). ENX lists VDA ISA2027 as published on 1 July 2026, with the German version ISA2027.1 available from 1 October 2026. TISAX labels are valid for three years.

The EU Cyber Resilience Act as it lands in Germany

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission, reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. That means German manufacturers are already inside the reporting window.

The provisions that shape software work:

• Article 13 sets manufacturer obligations, including due diligence when integrating third-party components, open source included, so that those components do not compromise the product's security.
• Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents through the single reporting platform to the CSIRT designated as coordinator and to ENISA: an early warning within 24 hours, a notification within 72 hours, and a final report, which for an actively exploited vulnerability is due within 14 days after a corrective measure is available and for a severe incident within one month.
• Annex I Part II sets vulnerability handling requirements, starting with point (1): identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
• Article 31 and Annex VII require technical documentation, which includes the SBOM where the market surveillance authority asks for it.

Germany has not yet named its CRA market surveillance authority. The KI-MIG text refers to the authority "to be designated" under Article 52(2) CRA and, in section 10(4), gives the BSI the related coordination tasks until then. Watch for the national CRA implementation law.

DORA and the end of BAIT, VAIT, KAIT and ZAIT

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. It covers ICT risk management (Articles 5 to 16), major ICT incident reporting (Article 19) and ICT third-party risk (Articles 28 to 30), including a register of information on ICT third-party arrangements.

BaFin has withdrawn its national IT circulars to avoid double regulation. It repealed the insurance (VAIT), capital management (KAIT) and payment institution (ZAIT) IT requirements at the end of 16 January 2025. For the banking requirements (BAIT), BaFin removed institutions that must apply DORA ICT risk management from 17 January 2025 and deleted BAIT chapter 11. Because the Financial Market Digitalisation Act (FinmadiG) brings further institutions under DORA from 1 January 2027, BaFin will repeal BAIT completely at the end of 31 December 2026.

The EU AI Act and Germany's KI-MIG

The AI Act, Regulation (EU) 2024/1689, is applying in stages. Germany's implementation law, the act on market surveillance and innovation promotion for artificial intelligence (KI-Marktüberwachungs- und Innovationsförderungsgesetz, KI-MIG), is in force and published on the federal law portal. Section 2(1) makes the Bundesnetzagentur the competent market surveillance authority unless the law says otherwise. Section 2(2) leaves AI in products covered by Annex I Section A harmonisation legislation with the existing product authorities. Section 2(3) makes BaFin the authority for AI systems directly connected to regulated financial activity of the institutions it supervises.

For security teams, Article 15 (accuracy, robustness and cybersecurity of high-risk AI) is where AI meets the supply chain: models and agent tools are components. The EU has been revising the high-risk application dates, so confirm the current dates on EUR-Lex before you plan around them.

What the rules ask of software and open source

Read side by side, the German regimes ask for the same small set of artefacts. The table maps each requirement to the evidence a supervisor, auditor or customer usually asks for.

One SBOM with the TR-03183-2 fields can serve the BSIG documentation duty, the CRA technical file and a customer's TISAX or C5 questions. The reporting clocks also overlap, so write one runbook that branches, not four.

Real public incidents in or affecting Germany

These examples come from BSI publications. They are chosen because they show the gap the rules target: software that is known to be vulnerable, still running, and hard to inventory.

Thousands of exposed mail servers vulnerable, March 2024

On 26 March 2024 the BSI reported that at least 17,000 on-premises Exchange mail server instances in Germany were vulnerable to one or more critical vulnerabilities. Of about 45,000 servers reachable from the internet, roughly 12 percent ran versions too old for security updates and about 25 percent had outdated patch levels. For another 48 percent the BSI could make no clear statement about CVE-2024-21410; only the operators could tell.

End of support, October 2025

On 28 October 2025 the BSI reported that, after vendor support for Exchange Server 2016 and 2019 ended in mid October 2025, more than 30,000 servers in Germany were still running those or older versions with web access reachable from the internet. No further security updates exist for them.

The 2025 state of IT security report

The BSI's report on the state of IT security in Germany 2025 says an average of 119 new vulnerabilities were reported every day in the reporting period, an increase of around 24 percent on the previous year. The BSI points to insufficiently protected attack surfaces as a main reason the situation remains tense.

The common thread is that organisations could not quickly say which versions they ran and who was responsible for updating them, the question section 30(2) no. 5 BSIG and Annex I Part II of the CRA require you to answer.

The personas who own the problem

CISO

Needs a board-ready view of exposure and a defensible position under section 38 BSIG. The trigger is a supervisory request, an incident or the annual management report. What helps: one page showing SBOM coverage, open known-exploited vulnerabilities, supplier coverage and the last runbook test.

Head of AppSec or product security (PSIRT lead)

Owns CRA Article 14 for products and BSIG section 30(2) no. 5 for internal systems; the 24 hour early warning now applies. Needs: an SBOM per release, advisory matching, a VEX process and a working disclosure contact.

VP or Director of Engineering

Wants one process instead of four: pipeline gates that do not stop every release, fix pull requests instead of tickets, and SBOMs as a build step.

Information security officer and GRC lead

Owns the section 30(1) BSIG documentation duty, section 39 audits for critical facilities, the IT-Grundschutz or ISO 27001 mapping and, in finance, the DORA ICT risk framework. Needs: dated evidence per clause, with owners.

Procurement and vendor risk owner

Owns supplier security under section 30(2) no. 4 BSIG and, in finance, the DORA register and Article 28 contract terms. Needs: suppliers ranked by criticality, evidence requests with deadlines and monitoring between renewals.

Data protection officer

Is pulled in when software or AI tooling sends personal data or source code outside the organisation or the EU. Needs: the deployment model, where data is processed and the subprocessors.

Foreign software makers selling into Germany

Expect C5 report requests for cloud services, TISAX questions in automotive, CRA questions and SBOM requests aligned to TR-03183-2.

A practical 30/60/90-day plan

This plan works with or without Safeguard. Adjust the order to the trigger in front of you.

Days 1 to 30: scope, registration and inventory

1. Confirm your status under the BSIG with the BSI's NIS2 applicability check, and under the KRITISDachG if you operate a critical facility. If you qualify and have not registered, register now; the BSI says the deadline has passed.
2. Confirm whether you are a CRA manufacturer, importer or distributor for each product line, and whether BAIT still applies to you until 31 December 2026.
3. Name owners: incident reporting (BSIG s. 32, CRA Art. 14), supplier security, vulnerability handling, AI inventory.
4. Generate SBOMs for every product and every internet-facing system you build, in SPDX or CycloneDX, and check them against the TR-03183-2 fields: creator, timestamp, component name and version, hash, licence and dependency relationships.
5. List your suppliers and service providers, and mark the ones whose software runs in production or touches customer data.
6. List AI systems in use and in products, including agent tools.

Days 31 to 60: evidence and triage rules

1. Request SBOMs, or at minimum a component list and a vulnerability handling statement, from critical suppliers. Set deadlines.
2. Write triage rules: which severity, exploitation status (CISA KEV, EPSS) and reachability combinations require a fix within which time.
3. Set up VEX: when you decide a vulnerability does not affect a product, record it in CSAF or CycloneDX VEX.
4. Draft the incident runbook with the BSIG section 32 and CRA Article 14 clocks side by side, and run a tabletop: a critical CVE in a widely used open source library on a Friday afternoon.
5. Map evidence to the controls you are audited against.

Days 61 to 90: gates, monitoring and the evidence pack

1. Turn on pipeline gates: start with Warn, then move the clearest rules (for example, known-exploited vulnerabilities in new code) to Block.
2. Monitor suppliers continuously for new vulnerabilities in their declared components.
3. Publish what customers keep asking for: a security page, a disclosure contact, and SBOM sharing on request.
4. Assemble the evidence pack: SBOMs, policies, triage records, supplier evidence, runbook test results, management approval and training records.
5. Present the result to management and record their approval (section 38 BSIG).

Template: supplier software evidence request

Use this text, adapted, when you ask a supplier for evidence.

We are subject to section 30(2) no. 4 of the German BSI Act and need evidence of the security of the software you provide. Please send, by [date]: (1) an SBOM for [product, version] in SPDX or CycloneDX, including component versions, hashes, licences and dependency relationships, aligned where possible to BSI TR-03183-2; (2) your vulnerability handling and disclosure policy, with a contact address; (3) VEX statements for any known vulnerabilities you consider not exploitable in this product; (4) how and when you will notify us of actively exploited vulnerabilities and incidents affecting our service.

Decision table: one vulnerability, which clock?

Illustrative scenario: a Friday advisory

Illustrative scenario, with round invented numbers. A software maker with 40 products learns on a Friday that a library it uses is under active exploitation. With SBOMs per release, it finds the library in 6 products within an hour, 2 with the vulnerable path reachable. It weighs a CRA early warning for those 2 within 24 hours and records VEX "not affected" for the other 4. Without SBOMs, the 24 hour clock runs out before anyone knows the scope.

How Safeguard does this

Everything below is described from Safeguard's offering documentation and docs.safeguard.sh as of 25 October 2026. Every capability named is GA. Commands are shown as the docs show them; we did not run them for this post. Safeguard helps a team produce and keep the evidence these regimes ask for.

Step 1: Build the inventory with SBOM generation (GA)

1. In the Safeguard web app, open Integrations from the sidebar. The docs show filters for Source Code (SCM), Container Image, AI Model and Upload.
2. Connect the repositories and registries for the software you build. Safeguard generates SBOMs (GA) in SPDX and CycloneDX and runs software composition analysis with deep transitive dependency scanning (GA).
3. Where you cannot or will not connect a repository, the Safeguard CLI and local runner (GA) scan on your own machine. The CLI docs show:

# Sign in (OAuth device-code flow)
safeguard login

# Scan a local directory
safeguard scan --dir .

# Scan an SBOM you already have (SPDX or CycloneDX)
safeguard scan --sbom sbom.json

The docs say that when you scan from the interactive terminal while signed in, the runner uploads the SBOM and findings, never your source.

4. Check SBOMs you receive or produce before you rely on them:

safeguard validate sbom.json --strict -o report.json

The docs say validate checks CycloneDX, SPDX and VEX documents against their specifications, and --strict treats warnings as errors.

Step 2: Map scans to German and EU frameworks with the compliance and GRC suite (GA)

The compliance and GRC suite (GA) includes framework pages for the regimes in this post. Each is on unless you switch it off in Compliance › Manage.

• BSI TR-03183-2: each scan of a product checks its SBOM for a machine-readable format, document metadata with a timestamp, a recorded creator, component versions, integrity hashes, licence information and dependency relationships.
• BSI IT-Grundschutz: scan requirements tied to the structure analysis inventory, risk analysis target objects, OPS.1.1.3 patch and change management, CON.8 sourcing, APP.6 software documentation and supplier oversight.
• EU NIS2 Directive: scan requirements mapped to Article 21(2)(a), (d) and (e) and to incident reporting readiness under Article 23, which the BSIG transposes in sections 30 and 32.
• EU Cyber Resilience Act: scan requirements tied to the Annex I Part II SBOM and remediation duties, a coordinated disclosure contact, integrity, third-party due diligence and technical documentation identity.
• TISAX: scan requirements for asset inventory, technical vulnerability management, patch level awareness, supplier relationships, software integrity and assessment evidence.

Each page also lists catalog controls and policy templates; you evidence non-scan controls with automated tests, uploaded evidence, policies or an attestation. For a law with no framework page, such as the KRITISDachG, map evidence to your own controls.

Step 3: Prioritise with vulnerability management and reachability analysis (GA)

1. Vulnerability management (GA) enriches findings with EPSS and CISA KEV status.
2. Reachability analysis (GA) ranks findings by whether the vulnerable code path is actually called, so the work starts with what is reachable and exploited.
3. Use these signals to run your triage table.

Step 4: Record "not affected" decisions with CSAF and VEX upload (GA)

In Integrations, filter by Upload and choose Upload CSAF/VEX, so supplier advisories and your own "not affected" decisions sit next to the findings they explain.

Step 5: Enforce rules with policies and gates (GA)

1. Go to Settings → Policies and click Create Policy.
2. Set each policy's action. The docs define three: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent).
3. Approvals run through exceptions: a developer clicks Request Exception with a justification, approvers decide, and the exception history is kept.
4. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

The docs say this fails the CI job when the gate fails, and that a plain safeguard scan does not fail on findings.

5. License compliance (GA) runs in the same pipeline, which feeds the TR-03183-2 licence field and CRA technical documentation.

Step 6: Request and monitor supplier evidence with TPRM (GA)

1. In TPRM (Third-Party Risk Manager), click Request SBOM, choose a request template and set a deadline. Bulk Request sends to several vendors at once, and custom templates live in Settings → Request Templates, where you can add the evidence request text above.
2. TPRM monitoring watches supplier SBOMs for new risk. Alerts are configured in Settings → Monitoring, with types the docs name: Critical Vuln, Exploited (CVE added to CISA KEV), Risk Change and SBOM Expiry. Critical vendors can be re-checked daily.

Step 7: Fix what you own with autonomous remediation (GA, ships off)

For repositories you connect, autonomous remediation opens fix pull requests. It ships switched off, with every category set to Manual, so your team decides what runs on its own.

Step 8: Share evidence with Trust Center and Portal (GA)

1. Trust Center (GA) publishes a public page on Compliance › Trust Center with your frameworks, monitored controls, policies, subprocessors and documents, plus a security contact for vulnerability reports. Publishing is always an explicit action.
2. Portal (the SBOM publish and share product, GA) shares SBOMs with customers who ask for them, which German buyers increasingly do.

Step 9: Provenance and AI inventory (GA)

1. Attestation and signing (GA) records build provenance (SLSA provenance and in-toto) with SCAL and LCAL scores for software you build.
2. AI-BOM discovery (GA) inventories AI assets, which is the starting point for AI Act classification. Agent identity (GA) records which agent holds what access.

Step 10: Choose a deployment that matches your residency rules (GA)

Safeguard's SaaS runs in US, EU and Gov regions; the EU region is hosted in Frankfurt, Germany. For teams that need data to stay under their own control, the offering lists these GA options:

• Private VPC or dedicated tenancy, single-tenant and not locked to one cloud provider.
• Full on-prem, the whole platform in your own data centre.
• Fully air-gapped, including the AI models running inside your environment. The docs describe signed snapshot bundles delivered through a one-way diode, manual media, a scheduled DMZ sync or a pull replica, with no component inside the perimeter calling outbound.
• The local runner, where the CLI pulls the repository on your machine, scans there and sends only encrypted results; source code never leaves your environment.
• Zero AI mode, where the platform runs deterministically with no language model in the loop, or bring your own approved model.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It is not a supervisor, auditor or assessment body. Safeguard does not register you with the BSI or BBK, issue C5 attestations, award TISAX labels, or decide whether you meet the BSIG, CRA, DORA or AI Act.
• It does not file your reports. BSIG section 32, KRITISDachG section 18, CRA Article 14 and DORA reports are yours to write, sign and submit. Safeguard helps you scope the affected products quickly.
• It holds no German or EU certification. Safeguard is not on any government framework or catalog, and has no BSI, C5 or TISAX attestation of its own. It helps you produce the evidence those regimes ask for.
• Frankfurt hosting is not the same as full control. SaaS regions are US, EU (hosted in Frankfurt, Germany) and Gov. If you need control over where data sits beyond that, use private VPC, on-prem, air-gapped deployment, the local runner or Zero AI mode.
• It does not cover physical resilience. The KRITISDachG resilience plan is outside its scope.
• It does not fix software you do not build. When the vulnerable code sits in a vendor appliance, a hosted service or a closed-source product, the fix has to come from that vendor. Safeguard helps you track it.
• It does not classify your AI systems. AI-BOM discovery gives you the inventory; whether a system is high-risk under the AI Act is a legal judgment for you and counsel.

Common mistakes

• Treating TR-03183 as optional because it is not binding. It is not law, but it is the BSI's stated reading of the CRA, and German buyers already ask for SBOMs that match Part 2.
• Waiting for the national CRA authority. The CRA reporting duties already apply from 11 September 2026, whether or not Germany has named its market surveillance authority.
• Running two inventories. One SBOM process for the CRA and another for BSIG documentation doubles the work and the drift.
• Assuming BAIT still covers you in 2027. It is fully repealed at the end of 31 December 2026.
• Letting management approval slip. Section 38 BSIG puts the duty on the management body. A security team's plan without a recorded board approval is incomplete.
• Blocking everything on day one. Start gates on Warn, fix the backlog, then move the clearest rules to Block.

FAQ

Is the German NIS2 law in force?

Yes. The NIS2 Implementation and Cybersecurity Strengthening Act rewrote the BSI Act, and the consolidated BSIG is published on the federal law portal. It came into force in December 2025. The BSI says the statutory registration deadline has passed.

What are the NIS2 reporting deadlines in Germany?

Section 32 BSIG requires an early report within 24 hours of becoming aware of a significant security incident, a notification within 72 hours, and a final report one month after the notification, or a progress report if the incident is ongoing.

What does the KRITIS-Dachgesetz require of software teams?

It covers physical resilience of critical facilities, not IT security. But it shares registration with the BSIG (section 8) and requires a 24 hour incident report to the BBK (section 18). If your software runs a critical facility, expect your customer's resilience plan to depend on your patch and recovery timelines.

Is BSI TR-03183 mandatory?

No. The BSI says it is a guide, not binding, and cannot be used as a presumption of CRA conformity. Part 2 (version 2.1.0) sets the SBOM fields many German buyers now request.

When do CRA duties apply to German manufacturers?

The CRA entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and the main obligations from 11 December 2027.

Does BAIT still apply after DORA?

Only to institutions not yet in DORA scope, and only until the end of 31 December 2026, when BaFin fully repeals it. VAIT, KAIT and ZAIT were repealed at the end of 16 January 2025.

Who supervises the AI Act in Germany?

Under the KI-MIG, the Bundesnetzagentur is the default market surveillance authority. BaFin supervises AI systems tied to regulated financial activity, and existing product authorities keep AI in products under Annex I Section A legislation.

Is there a C5 certificate?

No. C5 compliance is shown through an auditor's examination report. The BSI published C5:2026 on 7 April 2026.

Germany's rules all come back to one question: when a component turns out to be vulnerable, how fast can you find it and fix it? The block below describes the three ways Safeguard closes that gap for the open source you build and ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner. You set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a German team whose source code must stay on its own systems, this is the flow that produces SBOMs and findings without handing over the repository.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow is how a product team works through the "remediate without delay" duty in Annex I Part II of the CRA.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. GRC and security teams can then ask questions of their SBOM and findings data from an assistant they already use, with access limited to the tools they approved.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• BSIG, consolidated text (gesetze-im-internet.de)
• BSIG section 30: risk management measures
• BSIG section 32: reporting duties
• BSIG section 33: registration duty
• BSIG section 39: evidence duties for critical facility operators
• BSIG section 65: fines
• BSI: NIS-2 regulated entities and registration
• KRITIS-Dachgesetz, consolidated text
• KRITIS-Dachgesetz section 8: registration
• KRITIS-Dachgesetz section 18: incident reporting
• KI-MIG, consolidated text
• KI-MIG section 2: market surveillance authorities
• KI-MIG section 10: cooperation with the CRA market surveillance authority
• BSI: Technical Guideline TR-03183
• BSI: TR-03183 updated, 17 October 2025
• BSI: Minimum Elements for SBOM updated, 29 July 2026
• BSI: C5 criteria catalogue
• BSI: C5:2026 published, 7 April 2026
• BSI: IT-Grundschutz
• ENX Association: TISAX
• European Commission: Cyber Resilience Act
• BaFin: DORA and changes to the IT supervisory requirements, January 2025
• BSI: thousands of mail servers vulnerable, 26 March 2024
• BSI: end of support puts tens of thousands of servers at risk, 28 October 2025
• BSI: The State of IT Security in Germany 2025, summary
• Safeguard docs: BSI TR-03183-2
• Safeguard docs: BSI IT-Grundschutz
• Safeguard docs: EU NIS2 Directive
• Safeguard docs: EU Cyber Resilience Act
• Safeguard docs: TISAX
• Safeguard docs: CLI usage
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Generate SBOM
• Safeguard docs: Trust Center setup
• Safeguard docs: Air-Gapped Deployment

Related reading: Germany's NIS2 BSI Act of December 2025, BSI TR-03183 SBOM guidance explained, BSI C5 and when a German buyer asks for it, answering C5 security questionnaires from German customers, Germany and France sovereign cloud and AI rules and TISAX: what it is and who needs it.

Try it yourself: download Safeguard or read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.