NIS2 Registration in Germany: BSI Deadline 31 July

What expires on 31 July 2026

The NIS2UmsuCG completely recast the German BSI Act. Since it entered into force on 6 December 2025, any entity classified as essential or important must register with the Federal Office for Information Security no later than three months after first falling into scope (sec. 33(1) BSIG; BSI, NIS-2 obligations). For entities already in scope on the day the act took effect, that deadline ended on 6 March 2026. Registration runs in two stages: first through the public administration business account, then through the BSI portal (BSI, step-by-step guide to registration in the BSI portal).

Uptake fell well short of expectations. By the statutory deadline of 6 March 2026 around 11,500 entities had registered; by the end of May 2026 the figure had risen to roughly 18,500 (IHK zu Essen, July 2026). The Federal Office expects around 29,500 affected companies and federal institutions in Germany (BSI, FAQ on NIS-2). That leaves roughly 11,000 entities missing — a good third of the expected population. The BSI responded to that gap with a grace period and accepts late registrations until 31 July 2026 (IHK zu Essen, NIS-2 registration duty until 31 July 2026).

A second point is widely underestimated in practice: the Federal Office may register an entity on its own initiative if that entity fails to comply (sec. 33 BSIG). The real question is therefore not whether an in-scope entity ends up in the register, but whether it does so on its own terms — with contact data it maintains itself, a correctly assigned entity type and a contact point that is genuinely reachable. Registration by the authority also creates an explanatory burden towards the supervisor that timely self-registration avoids.

• Registration — submitting the details required by sec. 33 BSIG through the BSI portal, due by 31 July 2026 under the grace period (IHK zu Essen, July 2026).
• Update duty — changes to the submitted details must be reported without undue delay and no later than two weeks (BSI, NIS-2 obligations). A change of contact person or a new IP range triggers this duty.
• Risk management — the technical and organisational measures under sec. 30(2) BSIG must be implemented and documented regardless of whether registration has happened.
• Management duties — approval, supervision and training under sec. 38 BSIG apply in parallel and cannot be postponed to a later date.

Scoping: sector plus size threshold

Being in scope requires two conditions to be met together. First, the entity must fall under an entity type listed in Annex 1 or Annex 2 of the BSIG — ranging from energy, transport, finance, health and water through digital infrastructure and ICT service management to postal and courier services, waste management, chemicals, food, manufacturing and research. Second, a size threshold under sec. 28 BSIG must be reached. Directive (EU) 2022/2555 draws the same distinction in Article 3 between essential and important entities, which the BSIG implements as particularly important and important entities.

Two details often decide the classification. First, the criteria within a category are alternatives: reaching the headcount is enough — the financial figures then no longer need checking. Conversely, annual turnover and balance sheet total must both exceed the limit (sec. 28 BSIG). Second, company size is calculated using the European SME definition referenced in Article 2 of Directive (EU) 2022/2555. Linked and partner enterprises must be included — a German company that looks small on its own can be pulled into scope through group ownership.

What the BSI portal asks for

Registration is not a three-field form. Sec. 33(1) BSIG requires a data set that makes the entity addressable in legal, organisational and technical terms. Gathering the details inside the portal costs time — the technical fields in particular need lead time because in many organisations they sit somewhere between IT, marketing and an external hosting provider (project experience).

Domain names are not listed as a separate mandatory field in sec. 33 BSIG — in practice, though, they are the route to the IP address ranges. Without a reliable list of all owned domains and subdomains it is hard to derive cleanly which public address ranges actually belong to the entity. DNS service providers, top-level domain name registries and comparable registry services are additionally in scope regardless of size (sec. 28 BSIG) and therefore subject to registration irrespective of headcount and turnover.

The sticking point: your own IP and domain inventory

In advisory practice the IP address range field is the single most common reason a registration stalls (project experience). The cause is rarely reluctance — it is grown structure: the main domain sits with the hosting provider, the campaign landing page with an agency, the customer portal in a cloud environment, the old shop on a subdomain nobody has opened in years. All four are reachable from outside, and all four belong in the assessment.

• Forgotten subdomains and legacy systems — test, staging and campaign environments often keep running for years. They appear in no inventory yet remain reachable and are attributed to the entity. How to track down exposed artefacts systematically is covered in the article on exposed files such as .git directories, .env files and backups.
• Orphaned DNS records — records pointing at decommissioned services are a well-known takeover risk and simultaneously distort the IP inventory. The corresponding DNS hygiene including signature validation is described in the article on DNSSEC validation and DNS security.
• Provider-operated segments — where parts of the infrastructure are run externally, their public address ranges still belong in the submission if they fall under the entity's responsibility. Requirements for provider relationships are covered in the article on service provider evidence under NIS2.
• Dynamic addresses — what gets reported are static, publicly reachable ranges. Where addresses change, a documented allocation logic is needed instead of a snapshot, so the two-week update duty stays workable.

Continuous uptime and availability monitoring helps twice here: it keeps the list of endpoints actually in operation current, and it produces the time series that later serves as evidence. An endpoint that is monitored shows up in the inventory; an endpoint nobody monitors tends to drop out of the registration as well.

Management duties under sec. 38 BSIG

The real break with the previous legal position is not in the registration rules but in sec. 38 BSIG. Management bodies of essential and important entities are obliged to implement the risk management measures required under sec. 30 and to supervise their implementation (sec. 38(1) BSIG). Directive (EU) 2022/2555 phrases the same requirement in Article 20 as a governance duty of management bodies. Cybersecurity is thus explicitly a management task and not something that can be shifted wholesale into the IT department.

Management bodies that breach their duties under paragraph 1 are liable to their entity for damage caused culpably, in accordance with the company law rules applicable to the entity's legal form.

— Sec. 38(2) BSIG as amended by the NIS2UmsuCG (translation)

The liability consequence in sec. 38(2) BSIG points to the applicable company law — for a GmbH the duties of care of the managing directors, for a stock corporation those of the management board. In practice this shifts the evidential position: it is not for the Federal Office to prove that nothing was done, but for management to show that it approved, supervised and trained. Seen from there, registration with the BSI is the cheapest and simplest part of the chain of obligations — and the most visible one. A missing registration is immediately apparent from outside and reads as an indication that the remaining management duties were not addressed either.

Responsibility: delegate yes, hand over no

Operational tasks may be delegated to the IT department, to a security team or to external providers. Ultimate responsibility for approval, supervision and evidence remains with management under sec. 38 BSIG. For registration that means: the contact point may be a specialist department, but the decision on classification and data quality is not. A clear three-way split works well in practice.

1. Management — decides on the classification, approves the measures, owns the registration and documents both. It also sets the rhythm in which it wants to be briefed on implementation status.
2. NIS-2 contact point — receives communication from the Federal Office, maintains the registration data and triggers updates within two weeks whenever something changes (BSI, NIS-2 obligations).
3. Technical operations — keeps the inventory of publicly reachable systems current, runs the monitoring and supplies the timestamped evidence on which approval and supervision rest.

Technical evidence for the Article 21 measures

The part that creates lasting work begins after registration. Sec. 30(2) BSIG requires appropriate, proportionate and effective technical and organisational measures and names ten minimum areas for them — from risk analysis through incident handling and effectiveness assessment to cryptography, access control and multi-factor authentication (BSI, NIS-2 obligations). Article 21(2) of Directive (EU) 2022/2555 contains the same catalogue. The decisive word is effective: a measure whose effect nobody measures can neither be assessed nor evidenced.

For website operators, the publicly reachable part of the infrastructure is where effectiveness is easiest to objectify. It is measurable from outside, independently verifiable and can be logged with few gaps. The mapping below shows which data trail fits which area of measures.

This mapping is not a complete rendering of the catalogue — personnel security, access control, training and crisis management cannot be measured from outside. What it does show is which part of the obligations can be evidenced without extra manual effort, and experience suggests that is the part audits reach for first, precisely because it is externally verifiable.

From raw data to a verifiable evidence pack

Raw data is not yet evidence. An evidence pack only emerges when measurements, timing, responsibility and decisions come together. Six steps have proven useful and can be set up within a few weeks (project experience).

1. Define the scope — which domains, subdomains and endpoints belong to the entity? That list is simultaneously the basis for the IP details under sec. 33(1) BSIG and the later audit perimeter.
2. Measure continuously — check availability, response time, TLS state, DNS records and content integrity at fixed intervals from more than one network location, so isolated network faults stay distinguishable from genuine outages.
3. Record events with timestamps — every switch from available to disrupted and back needs a point in time. Without timestamps, neither detection nor response duration can be evidenced later.
4. Define thresholds and owners — at which value is an alert raised, who is informed, who decides? That definition is itself part of the documentation under sec. 30(2) BSIG.
5. Report regularly — monthly or quarterly reports with availability rate, deviations and processing status. They are the material with which management evidences its supervisory duty under sec. 38(1) BSIG.
6. Document approval — the report goes to a management body and the decision is minuted. Only this step closes the chain from measurement to responsibility.

The fine range: what EUR 500,000 actually covers

The BSIG fine framework is tiered, and the tiers are frequently mixed up in discussion. For breaches of the registration and submission duties — details not submitted, or submitted incorrectly, incompletely or late — the act provides a separate range of up to EUR 500,000 (sec. 65(2) no. 6 in conjunction with sec. 65(5) BSIG). The far higher ranges of up to EUR 10m or 2 per cent of worldwide annual turnover for essential entities and up to EUR 7m or 1.4 per cent for important entities attach to different breaches, in particular to the risk management and reporting duties (sec. 65 BSIG).

• Missed registration — up to EUR 500,000, regardless of how well everything else runs (sec. 65(5) BSIG). It is the breach that takes the least effort to avoid.
• Incorrect or incomplete details — the same range applies where the submitted data is wrong (sec. 65(2) no. 6 BSIG). An outdated IP range is therefore not a cosmetic flaw.
• Missing updates — late notification of changes is also subject to fines (sec. 65(2) no. 8 BSIG). The two-week deadline is therefore an operational process, not a project step.
• Personal level — independently of any fine against the entity, management is liable to its entity for culpably caused damage under the applicable company law rules (sec. 38(2) BSIG).

The ratio of effort to risk is striking. Registration itself takes a manageable amount of time once the details are available. The fine range attached to it is nevertheless substantial at EUR 500,000, because it concerns the formal basis of the entire supervisory regime: without a register the authority does not know who is in scope. Anyone familiar with comparable notification logic in other frameworks — such as the vulnerability reporting duty under the Cyber Resilience Act or the transparency duty for website chatbots under the AI Act — will recognise the same pattern: the formal duty is cheap to fulfil and expensive to ignore.

Complete the registration, keep the evidence running

Until 31 July 2026, registration remains a task of a few working days provided the scoping assessment, the IP inventory and the contact point are settled. After that the emphasis shifts to the lasting part: implement the measures under sec. 30(2) BSIG, assess their effectiveness, present the results to management and document the approval. The difference between an entity that can produce this evidence and one that cannot rarely lies in the technology — it lies in whether someone collects and retains the data continuously.

For the externally measurable part, getting started is straightforward: availability, response time, TLS state, DNS records and content integrity can be set up for all public endpoints in one pass. Anyone who wants to see what such an evidence trail looks like in operation will find the mapping to the areas of measures in the NIS2 readiness overview, the full data set without signing up in the demo environment, and the classification by scope in the pricing overview. Registration is the start of the chain of obligations, not its conclusion.