After the NIS2 deadline: what network segmentation has to prove

On 31 July 2026 the grace period the BSI had granted for registration under § 33 BSIG expired. The date was never a new statutory deadline — the duty existed before it — but a signal of leniency in enforcement. For engineering work that changes little. Registration is a form. The obligations under § 30 BSIG are a network.

Where the deadline leaves you — and what it does not settle

The German NIS2 implementation act was proclaimed on 5 December 2025 and entered into force on 6 December 2025, with no transition period. The BSI expects roughly 29,500 regulated entities, up from about 4,500 before. Around 11,500 had registered by the statutory date of 6 March 2026, and roughly 18,500 by the end of May 2026. The BSI's enforcement grace period until the end of July 2026 followed.

Registration is the most visible and the smallest part of this. It tells the regulator you exist. It says nothing about whether your network meets the requirements. That gap is why the second wave of work starts now — and why it happens in the network.

Why segmentation is the most verifiable field in § 30

§ 30 BSIG lists ten fields of risk management measures — from risk analysis through backup management and supply chain security to cryptography and multi-factor authentication. Nine of them can be evidenced with concepts, policies and process descriptions. One cannot.

Segmentation is a measurable state. An auditor, a penetration tester and an attacker all ask the same question: can this system reach that one? The answer is binary, reproducible and independent of what the security concept claims. That is why segmentation is where a security programme first shows whether it has substance.

What “state of the art” means here in practice

The law names no products and no VLAN counts. It requires measures that reflect the state of the art and are proportionate to the risk. Translated into network engineering: zones follow protection requirements, not historical cabling. Every transition between two zones is a deliberate, documented point. And the rule at that point is tighter than “everything except what caused an incident last year”.

From a flat network to a defensible zone

The most common mistake is jumping to the tool: buying a segmentation platform before anyone knows what actually needs to talk to what. The order that works in real projects is the reverse.

1. 01

   Inventory

   What is on the network, who owns it, what protection does it need? Without an inventory every zone is a guess. The source may be a database, but it has to be a single one.

2. 02

   Communication matrix

   Which relationships are functionally necessary? Captured from real traffic — NetFlow, firewall logs, a span port — not from memory. This is where the uncomfortable findings appear: the remote maintenance link nobody remembered.

3. 03

   Zone cut

   Systems with the same protection requirement and the same trust level form a zone. Clients, servers, management, production, guests, third-party access: that is the beginning, not the target state.

4. 04

   Enforcement point

   Every zone transition gets a place where the rule actually bites — a firewall, a routing instance, a policy in the switch. A zone without an enforcement point is a label.

5. 05

   Controlled rollout

   Observe first, then enforce. Rules run in logging mode, deviations are clarified with the business, and only then does the bolt drop. That is how segmentation avoids becoming a production outage.

6. 06

   Proof

   The state is verified repeatably: defined test cases showing that a forbidden relationship really fails. A dated test report is the evidence — not a screenshot of a rule list.

Where the rule bites: four enforcement models

There is no single correct approach. There are four common ones that differ sharply in granularity, operational effort and how well they can be evidenced. Most durable architectures combine two of them.

The decisive difference is not the technology but what the rule depends on. An IP-based rule ties security to topology: move the system and the statement collapses. A group-based rule ties it to a role assigned at authentication — it survives the move, but demands an identity layer that actually works. Mixing both without cause produces two truths about the same traffic.

What actually holds up under audit

Regulators and auditors rarely ask about individual rules. They ask about the chain: how do you know what exists — how did you decide — how is it enforced — how do you know it still holds? Five artefacts answer that chain:

• A versioned zone model naming every zone with its protection requirement and owner.
• The communication matrix as a maintained document rather than a one-off survey — carrying the date of its last verification.
• The rule sets as configuration in a repository, with a traceable history: who changed what, when and why?
• A set of test cases that actively probe the forbidden relationships and log the result.
• An exception register with expiry dates — any permanent exception without one is a silent withdrawal of the architecture.

These five artefacts are exactly the ones that carry operations without NIS2 as well. That is no coincidence: what the legislator asks for is the traceability a well-run network already has. How we produce it is described under network security and enterprise networks.

The reporting chain needs network data, not just process

§ 32 BSIG stages the reporting of a significant incident: early warning within 24 hours, report within 72 hours, final report after one month. The first stage is the hard one. Twenty-four hours after becoming aware, you must be able to say whether the incident may have cross-border effects — which means knowing how far it could reach.

This is where segmentation pays a second time. In a flat network the honest answer about reach is “everywhere”. In a zone architecture with logged transitions it is a list. That difference decides whether the 24-hour notification states a finding or a suspicion.

Why this is not settled inside IT alone

§ 38 BSIG moves responsibility explicitly upwards: management must approve the risk management measures, monitor their implementation and attend training regularly, and can be held personally liable for breaches. For network work this has a practical consequence that is easy to miss — signing off a zone model is no longer an internal IT act but a management decision that has to be documented.

In practice that means the zone model needs a version a managing director can read and sign. Not the rule list, but the statement behind it: which areas are separated, which risk that bounds, which exceptions deliberately remain.

The first 90 days if nothing has happened yet

If you are only starting now, the backlog is real but manageable. What can genuinely be achieved in that window:

• Register late. Late beats never — it documents a response to the regulator.
• Establish visibility. Four to six weeks of traffic capture at the suspected boundaries produce the factual basis no workshop can replace.
• Take the two most dangerous transitions first. Usually third-party and remote access, and the boundary between the office world and production or server estate.
• Time-box exceptions. Every existing any-any rule gets an expiry date and a name attached.
• Build the proof from day one. A test that runs after every change costs little in week one and cannot be retrofitted in month twelve.

The rest is craft and time. What matters is that the chain stays closed: what is not inventoried cannot be zoned. What is not zoned cannot be enforced. What is not tested is not evidence.