Germany’s NIS2 Competent Authority (BSI): Three Supervision Tiers That Determine Your Audit Risk

Every EU member state designates a competent authority to implement NIS2 — the national body that registers entities, audits their cybersecurity controls, and issues fines. In Germany, that body is the Bundesamt für Sicherheit in der Informationstechnik (BSI).

What most guides don’t explain is that Germany’s supervision model is a three-tier system, not the two-tier framework the NIS2 Directive establishes. Whether the BSI can audit your organisation proactively — or only after something goes wrong — depends on which tier you fall into. So do the penalties, the registration requirements, and the obligations around critical ICT components under Section 41 of the BSIG.

This guide explains what the BSI oversees, how the three tiers work, what the BSI portal registration process looks like step by step, and when your organisation must notify the BSI of a security incident.

Germany’s NIS2 Competent Authority: What BSI Oversees

Germany transposed the NIS2 Directive through the NIS2-Umsetzungs- und Cybersicherheitssstärkungsgesetz (NIS2UmsuCG), which entered into force on 6 December 2025 and fundamentally overhauled the Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG). Under Article 8 of NIS2 Directive 2022/2555, member states must designate competent authorities; Germany designates the BSI as the primary authority for registration, supervision, enforcement, and incident response coordination across the vast majority of regulated entities.

The scale of what BSI now oversees is significant. Under the previous IT-Sicherheitsgesetz 2.0, approximately 4,500 entities were regulated. The NIS2UmsuCG expands that to an estimated 29,500 organisations across 18 sectors [9] — roughly six times the previous coverage [9]. Manufacturing, waste management, food production, and postal services all became regulated sectors for the first time. Notably, there is no transition period: all obligations applied from 6 December 2025.

For registration and incident reporting, the BSI established a joint point of contact with the Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) — the Federal Office for Civil Protection and Disaster Assistance [8]. This joint structure matters most for operators of critical facilities (KRITIS), who must register with both bodies independently.

BSI’s supervisory toolkit under §§61–62 BSIG includes registration review, proactive audits for the highest tier, reactive inspections for lower tiers, binding orders, public disclosure of infringements, and administrative fines up to €10 million for the most serious breaches.

Germany’s Three-Tier Model: Why It Adds a Layer the NIS2 Directive Doesn’t Require

The NIS2 Directive creates two entity categories: essential entities and important entities. Germany’s BSIG adds a third — operators of critical facilities (Betreiber kritischer Anlagen), the KRITIS tier — sitting above the NIS2 essential category in terms of regulatory burden. The tier you fall into determines audit frequency, registration process, and penalty exposure.

Category	German Term	Qualifying Threshold	Supervision Type
Critical Facility Operators	Betreiber kritischer Anlagen (KRITIS)	Infrastructure-specific (e.g. ≥500,000 persons served in energy, water, health)	Mandatory evidence every 3 years (§39 BSIG) + dual registration BSI & BBK
Particularly Important Entities	Besonders wichtige Einrichtungen	≥250 employees OR turnover >€50M AND balance sheet >€43M; some sectors size-independent	Ex ante — BSI audits proactively without requiring a trigger
Important Entities	Wichtige Einrichtungen	≥50 employees OR turnover >€10M AND balance sheet >€10M	Ex post — BSI acts only on evidence of non-compliance

Operators of critical facilities (KRITIS) run infrastructure whose disruption would have a major societal or economic impact: energy grids, drinking water systems, financial market infrastructure, and hospitals above certain capacity thresholds. KRITIS thresholds are infrastructure-based — typically calibrated around the number of persons served or supplied, not company headcount. Sector-specific thresholds are set by ordinance [4]. KRITIS operators are automatically classified as particularly important entities under NIS2 but carry additional obligations specific to their tier.

Particularly important entities (equivalent to essential entities under the NIS2 Directive) qualify if the organisation has at least 250 employees, or if annual turnover exceeds €50 million and the balance sheet total exceeds €43 million [4]. Some entities qualify regardless of size — providers of qualified trust services, top-level domain registries, and public electronic communications providers, among others.

Important entities (equivalent to important entities under the NIS2 Directive) qualify when an organisation has at least 50 employees, or when both annual turnover and balance sheet total each exceed €10 million [4].

The negligible activity carve-out: If a company’s regulated activities are negligible relative to its overall business, those activities may be excluded when calculating whether the size threshold is met [9]. YPOG notes this provision (§28 III BSIG) creates practical challenges — the vagueness makes self-assessment risky. When in doubt, assume you’re in scope rather than relying on this carve-out without legal advice.

For a full comparison of the obligations that differ between the particularly important and important classifications, see essential vs important entities.

What Each Tier Means for Your BSI Audit Exposure

The tier classification is not an administrative label. It determines whether the BSI is already authorised to examine your cybersecurity controls — or whether it needs a reason to start.

KRITIS operators face the highest continuous scrutiny. Under §39(1) BSIG, operators of critical facilities must proactively submit evidence of their security measures to the BSI every three years [4]. This mandatory evidential cycle does not require the BSI to detect a problem first — it runs on a fixed schedule. The first submissions under the revised BSIG framework will fall due approximately in 2028. KRITIS operators must additionally register with the BBK and disclose the types of critical components they deploy — including version numbers — at registration under §8(1) Nr. 7 BSIG [5].

Particularly important entities are subject to ex ante supervision under Article 32 of the NIS2 Directive, implemented through §61(1)(3)(5) BSIG [1]. Ex ante means the BSI can initiate an audit without a specific trigger: it does not need to have received a complaint or detected an incident. Under this framework, the BSI may conduct on-site and off-site inspections, commission independent security audits based on risk assessments, run security scans, or initiate ad hoc audits where a risk assessment or prior incident warrants one [1]. The practical consequence: particularly important entities should maintain always-ready audit documentation and expect periodic BSI contact even in the absence of any incident.

Important entities face ex post supervision under Article 33 of the NIS2 Directive, implemented through §61 BSIG [2]. Ex post means the BSI acts when there is evidence of non-compliance — it does not routinely audit these entities. The BSI considers the extent of the entity’s risk exposure, its size, and the likelihood and severity of potential incidents when deciding whether to open supervision [2]. Sampling-based checks are permitted. The lower continuous burden does not mean supervision is a remote risk: a significant incident or a third-party complaint can trigger full BSI scrutiny regardless of tier.

Penalty exposure by tier under §65 BSIG [6]:

Category	Maximum Administrative Fine
Particularly important entities (including KRITIS)	€10 million or 2% of global annual turnover, whichever is higher
Important entities	€7 million or 1.4% of global annual turnover, whichever is higher
Registration or notification failure (all tiers)	Up to €500,000
KRITIS critical component reporting failure	Up to €5 million

These figures represent the statutory ceiling. Actual fines are proportionate to the severity and duration of the violation. For a complete breakdown of the conditions that trigger NIS2 fines, see NIS2 penalties and enforcement.

Section 41 BSIG: Germany’s ICT Component Prohibition Mechanism

Section 41 of the BSIG gives the Federal Ministry of the Interior (Bundesministerium des Innern, BMI) — not the BSI — the authority to prohibit KRITIS operators from using specific ICT components supplied by specific manufacturers. This power sits outside the BSI’s supervisory remit but is directly triggered by what operators disclose during BSI registration.

A component enters the Section 41 framework if it meets all three of the following criteria [7]:

1. It is an ICT product used in a critical facility
2. It performs a critical function within that facility
3. A malfunction of the component could significantly impair the functionality of the critical facility or public safety

Sector-specific lists of critical components are published by statutory ordinance for each sector, with each ordinance proposed by the relevant sectorial ministry and signed by the BMI. When a component is designated, the BMI may issue a prohibition notice if its continued use “is likely to endanger public order or national security” [7]. The prohibition can extend beyond the original operator to other entities using the same component types.

What changed from the previous framework: Under the IT-Sicherheitsgesetz 2.0, operators had to notify the BMI before their first use of a listed component, wait two months for a potential objection, and obtain a manufacturer guarantee statement. That advance-notification procedure has been eliminated [7]. Operators now disclose the types of critical components they deploy — including version numbers — when registering with the BSI under §8(1) Nr. 7 BSIG [5]. The BMI retains the authority to prohibit use after reviewing those disclosures, with compliance and replacement deadlines set in the prohibition notice [8].

The removal of the advance-notification buffer makes component inventory management more operationally significant, not less. Compliance officers at KRITIS operators need a maintained, up-to-date list of critical ICT components in scope for their sector, with current version information, ready for both initial registration disclosure and any subsequent BMI inquiry. Under §33(5) BSIG, changes to registered component information must be reported to the BSI within two weeks [3].

How to Register: The BSI Portal and MUK-ELSTER Process

All three categories must register with the BSI. The initial registration deadline under §33 BSIG was 6 March 2026 — three months after the law entered into force on 6 December 2025. Entities that became in-scope after that date have three months from when they first meet the qualifying threshold to register [6]. Late registration falls within the €500,000 fine ceiling [9].

Why ELSTER? The BSI portal uses Germany’s cross-agency company authentication infrastructure. Mein Unternehmenskonto (MUK) is the identity provider, and it relies on the ELSTER organisational certificate your company uses for tax filings. Without this certificate, registration at portal.bsi.bund.de is not possible.

Step 1 — Obtain the ELSTER organisational certificate

Check whether your tax department or external tax adviser already holds an ELSTER organisational certificate. If one exists, obtain the certificate file and its password. If not, apply immediately at mein-unternehmenskonto.de — processing typically takes several days to several weeks. Any discrepancy between the ELSTER certificate data and the commercial register must be corrected in Mein ELSTER before proceeding; corrections are pulled into the BSI portal automatically [3].

Step 2 — Set up your MUK account

At mein-unternehmenskonto.de, authenticate using the ELSTER certificate. Company data — name, legal form, registered address, trade register number — imports automatically from the certificate. Allow 15–30 minutes. The initial account holder becomes the administrator and manages access for other users.

Step 3 — Register at portal.bsi.bund.de

Navigate to portal.bsi.bund.de and select “Mit MUK anmelden.” After authentication, navigate to the NIS-2 area and click “Zur NIS-2-Registrierung.” You will need to supply [3]:

• Company size: employee count, annual turnover, balance sheet total
• Sector and sub-sector classification
• Facility type
• EU member states where you provide regulated services
• NIS-2 contact point: name, organisational unit, two phone numbers in international format, and a functional mailbox address — not a personal email
• Public IP address ranges in CIDR notation (IPv4 and IPv6); if none, declare that explicitly
• KRITIS Institution-ID, if your organisation was registered under the IT-Sicherheitsgesetz 2.0

The system automatically assigns your tier classification (particularly important or important) based on the submitted data. You can override the auto-assignment if it is incorrect. Under §33(5) BSIG, any subsequent changes to your registration data must be reported “immediately, but no later than within two weeks” [3].

KRITIS operators — dual registration requirement

Operators of critical facilities carry a second registration obligation. Under §8(1) BSIG, KRITIS operators must also register with the BBK separately from the BSI portal registration [5]. The BBK registration covers facility-specific details: critical component types with version numbers, supply coverage level, geographic location of the critical facility, and a 24/7 accessible contact point for the authorities. This is a distinct process and must be completed independently.

For a full overview of the registration obligation — including what happens when you become in-scope after the initial deadline — see entity registration requirements.

Who to Notify and When: BSI Incident Reporting Timelines

All three categories must report significant incidents to the BSI using the three-stage cascade under §32 BSIG, which implements Article 23 of the NIS2 Directive:

• 24 hours — Early warning: Notify the BSI that a significant incident has occurred or is ongoing. Indicate whether the incident is suspected to involve malicious intent. This is an alert, not a full technical report.
• 72 hours — Detailed assessment: Provide an updated report with the incident’s nature and scope, an initial impact assessment, and whether malicious cause has been confirmed or remains suspected.
• 30 days — Final report: Submit a comprehensive account of the incident — root cause or threat type, full impact, mitigation measures taken, and any cross-border implications.

A significant incident, for the purposes of §32 BSIG, is one that has caused or is capable of causing severe operational disruption or material financial loss, or that has affected or is capable of affecting other persons with considerable material or non-material damage. Incidents with potential cross-border impact should be reported regardless of the scale to your own organisation.

Management liability under §38 BSIG: Germany’s implementation goes beyond the NIS2 Directive’s general oversight requirement. Management bodies carry three non-delegable duties under §38 BSIG [6]: formal approval of the organisation’s cybersecurity risk management measures; active oversight of their implementation (passive awareness is insufficient); and personal participation in cybersecurity training at least every three years. These duties cannot be passed to the CISO or compliance officer — they sit with the board.

For the full incident notification procedure — including what constitutes a reportable incident and how multi-jurisdictional cases are handled — see NIS2 incident reporting.

Key Takeaways

Germany’s NIS2 implementation adds a tier that the Directive itself doesn’t create. The three-tier structure — KRITIS, particularly important, important — produces meaningfully different regulatory burdens. KRITIS operators face dual registration (BSI and BBK), a three-year mandatory evidence cycle under §39(1) BSIG, and critical component disclosure requirements under Section 41 BSIG. Particularly important entities face proactive ex ante BSI scrutiny under Article 32 NIS2 — audits without a trigger. Important entities face reactive ex post supervision under Article 33 NIS2, triggered only by evidence of non-compliance.

The BSI portal registration process via MUK-ELSTER is procedurally specific: without the ELSTER organisational certificate, registration cannot proceed, and obtaining the certificate takes time. The March 2026 registration deadline has passed, but the obligation remains active for all entities that meet the thresholds — including those that become regulated after the initial window.

The supervision tier you’re in is not a formality. It determines whether the BSI is already authorised to examine your controls — or waiting for a reason to start.

For a broader view of Germany’s NIS2 compliance landscape, visit Germany NIS2 overview.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive Article 32 — Supervisory measures for essential entities
2. NIS2 Directive Article 33 — Supervisory measures for important entities
3. BSI Step-by-Step Registration Guide — bsi.bund.de
4. NIS2 Implementation in Germany — OpenKRITIS
5. Registration under NIS2 and KRITIS — OpenKRITIS
6. NIS2 in Germany 2026: Deadlines, Fines & BSIG Guide — nisd2.eu
7. Germany Implements NIS2 — What You Need to Know Now — Freshfields
8. Flipping the NIS2 Switch: What Germany’s Implementation Means for 2026 Compliance — Morrison Foerster
9. Germany’s NIS2 Implementation Act — YPOG