NIS2 Directive 2026: architecture implications for Mittelstand

What is the NIS2 Directive? — In brief

The NIS2 Directive (formally: Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union) is the European Union's revised cybersecurity directive. It supersedes NIS1 from 2016 — whose scope and requirements no longer match the threat landscape of 2026. The directive entered into force on 16 January 2023; member states had to transpose it into national law by 17 October 2024.

Three points carry the rest of the directive:

• Significantly expanded scope: Instead of a few hundred critical-infrastructure operators, around 29,500 entities across 18 sectors are now in scope in Germany alone (BSI estimate) — energy, transport, health, digital infrastructure, manufacturing, food, research, and more.
• Binding minimum measures: Article 21 mandates ten cyber-risk management measures — from backup management and supply-chain security through to multi-factor authentication. Technology-neutral and outcome-oriented.
• Personal management liability: Managing directors are personally accountable when risk-management obligations are breached. Penalties range up to €10 million or 2 % of global annual turnover, depending on entity classification.

In Germany, the directive was transposed via the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) — passed by the Bundestag on 13 November 2025, published in the Federal Law Gazette on 5 December 2025, entered into force on 6 December 2025. The Federal Office for Information Security (BSI) is the central supervisory authority. Companies wondering whether they fall in scope can use the BSI self-test and consult Annexes I and II of the directive.

Why NIS2 now lands in the Mittelstand

Until recently, "KRITIS" was a term reserved for energy utilities, hospitals, and telecom operators — a few thousand critical-infrastructure operators that were already heavily regulated. With the NIS2 Directive and its German implementation, that picture shifts. The German Federal Office for Information Security (BSI) estimates around 29,500 entities in scope across Germany — mechanical engineers, logistics operators, IT service providers, food producers, B2B platforms, mid-sized software houses. Most of these companies have not previously thought of themselves as critical infrastructure.

The architectural conversation has shifted accordingly. It is no longer "do we have a perimeter firewall" — it is: how do we demonstrate that we manage cyber risk across our software supply chain in a structured way? How do we log incidents so that forensic analysis is possible in hours rather than weeks? How is the personal accountability of management visible in the architecture? This article describes what the directive actually requires, what German implementation has made of it (as of May 2026), and which architecture decisions are due now.

Who is affected — and who is surprised

The NIS2 Directive (Directive (EU) 2022/2555) entered into force on 16 January 2023, with a transposition deadline for member states of 17 October 2024. The scope is wide: Annex I lists eleven sectors of high criticality — energy, transport, banking, financial market infrastructures, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space. Annex II adds seven further critical sectors — postal and courier services, waste management, chemicals, food, manufacturing, digital service providers, research. Eighteen sectors in total.

The size threshold seems clear at first: from 50 employees or €10 million annual turnover, an entity falls within scope by default. Sector-specific exceptions extend the perimeter further — certain digital services, for instance, fall in regardless of size. In practice, this means many Mittelstand companies are in scope even when their core business is not classically "critical".

The directive distinguishes two tiers. Essential entities — in the German implementation, "besonders wichtige Einrichtungen" — are typically large companies in Annex I sectors (from 250 employees or €50 million turnover and €43 million balance sheet). They face proactive supervision and higher penalties. Important entities cover medium-sized companies in Annex I as well as all in-scope companies in Annex II — they face reactive supervision. The BSI estimates the German split at approximately 8,250 essential and around 21,600 important entities.

Less discussed, but architecturally decisive: anyone supplying software to a NIS2-regulated entity becomes part of that entity's supply-chain security. Even without your own registration obligation, your customers' obligations reach you — through contracts, SBOM requests, security attestations, incident-handling SLAs. That is the second wave many software houses underestimate.

What NIS2 actually requires

Article 21 of the directive lists ten minimum measures for cyber-risk management. They are technology-neutral and outcome-oriented — the directive prescribes what must be achieved, not how:

• (a) policies on risk analysis and information system security
• (b) incident handling
• (c) business continuity, such as backup management and disaster recovery, and crisis management
• (d) supply chain security, including security-related aspects of relationships with direct suppliers and service providers
• (e) security in network and information systems acquisition, development and maintenance — including vulnerability handling and disclosure
• (f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures
• (g) basic cyber hygiene practices and cybersecurity training
• (h) policies and procedures regarding the use of cryptography and, where appropriate, encryption
• (i) human resources security, access control policies and asset management
• (j) the use of multi-factor authentication or continuous authentication, secured voice, video and text communications, and where appropriate secured emergency communications

Article 23 governs reporting obligations for significant incidents. Three staggered deadlines, mirrored in §32 BSIG (NIS2UmsuCG):

• Early warning within 24 hours of becoming aware — indicating whether the incident is suspected to be caused by unlawful or malicious acts or could have cross-border impact
• Incident notification within 72 hours — with initial assessment, severity and impact, and indicators of compromise
• Final report within one month of the incident notification — with detailed description, root-cause analysis, and remediation taken

This staging is new compared to NIS1 and acknowledges that solid forensic assessment takes time. It does, however, raise the bar for telemetry: anyone who wants to file a defensible early warning within 24 hours needs a setup that surfaces anomalies in real time — not one that discovers them during Monday-morning cleanup.

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 makes these requirements concrete for specified digital service providers — DNS providers, TLD registries, cloud providers, data centre services, content-delivery networks, managed service providers, online marketplaces, search engines, social networks, trust service providers. Its annex is structured into thirteen thematic areas and is markedly more prescriptive than the directive text itself. If you operate in one of those categories, treat it as required reading. For other sectors, ENISA's technical implementation guidance is the central reference point.

Architecture implications for software builders

The Article 21 minimum measures are architecture decisions, not compliance exercises. Six points are, in our view, the most effective levers.

Logging architecture — append-only, forensics-ready

The 24-hour early-warning deadline can only be met if you detect an incident in time. Structured logging with correlation IDs across service boundaries, a centralised log stream (Loki, Elastic, or equivalent), and append-only persistence form the foundation. "Append-only" means logs cannot be modified after they are written — forensic analysis can rely on the assumption that an attacker did not overwrite their tracks. Event logs in the platform database, recording every security-relevant action (auth attempts, configuration changes, privileged API calls) as a row, complement this. The audit trail must be tamper-evident — that is not just ISO vocabulary, but a concrete requirement when the BSI asks questions after an incident.

Identity and access — SSO and MFA as defaults, not retrofits

Article 21(2)(j) requires multi-factor authentication "where appropriate" — in practice: for privileged access without debate, for end-user access depending on the risk profile. Architecturally, this means designing MFA as part of the identity provider, not bolting it on as an extra layer in front of the login page. OIDC and SAML at the protocol level, Keycloak, Authelia, or a cloud IdP at the implementation level. Role and permission model visible in the data model — not as a downstream UI filter that can be bypassed. For Mittelstand setups that have grown historically with local logins, this is often the first major refactor. It pays off.

Network architecture — segmentation and zero-trust patterns

The classic moat-and-castle architecture — DMZ in front, trusted internal network behind — no longer reflects the state of the art. Zero-trust patterns assume the internal network is not implicitly trusted. Concretely: service-to-service communication is authenticated (mTLS, short-lived tokens), network segments are fine-grained (microsegmentation), secrets are sourced from a dedicated management system rather than from environment variables in the repo. For container-based architectures, a service mesh (Linkerd, Istio) brings the telemetry and mTLS along. For classic VM setups, clean VLAN segmentation with host-based firewalls is often enough. The choice of tooling is secondary — the discipline is primary.

Backup architecture — immutable, tested, within RPO/RTO reach

Article 21(2)(c) requires backup management and disaster recovery. The implementation is often filed under "running, fine" — until a ransomware incident reveals that the backups were encrypted along with everything else. Immutable backups — backups that cannot be altered or deleted after writing (object lock, WORM storage, backup servers in a separate trust zone) — are the central control here. Recovery objectives (Recovery Point Objective, Recovery Time Objective) must be defined per system and tested regularly. A restore that has been dry-run once a year is worth more than a backup design that has never been verified.

Software supply chain — SBOM hygiene becomes standard

Article 21(2)(d) and (e) demand supply-chain security and vulnerability handling. NIS2 does not explicitly require an SBOM — the Cyber Resilience Act does that for connected products from 2027 onwards. The connection is tight: anyone who already generates an SBOM for their own products in the CI pipeline (Syft, CycloneDX tooling, Trivy) can demonstrate supply-chain security to NIS2-regulated customers with the same artifact. Automated CVE monitoring against NVD or OSV, a quality gate that blocks critical known vulnerabilities, a documented patch-management process — these are not NIS2-specific concepts, but clean DevOps practice that NIS2 turns into a regulatory obligation.

Monitoring, alerting, and architecture documentation

Sentry for application errors, Grafana with Prometheus or equivalent for metrics, alerting that actually reaches an on-call responder — that is the operational side. The regulatory side additionally requires evidence that these measures were deliberate decisions. Architecture Decision Records (ADRs) — short, dated documents capturing an architecture decision with rationale and rejected alternatives — turn from engineering hygiene into legal hygiene. They are the proof that management has actually approved and overseen risk-management measures, as §38 NIS2UmsuCG requires them to.

Status of German implementation (as of May 2026)

Germany missed the transposition deadline of 17 October 2024. The NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) remained in process across multiple cabinet drafts, was further delayed by the collapse of the Ampel coalition at the end of 2024, and was reintroduced after federal elections and the change of government. The Bundestag eventually passed the law on 13 November 2025; the Bundesrat approved it on 20 November 2025. Promulgation in the Federal Law Gazette (BGBl. 2025 I No. 301) followed on 5 December 2025; the law entered into force on 6 December 2025. There is no transition period — the obligations apply from the date of promulgation.

Substantively, the NIS2UmsuCG is a comprehensive amendment of the BSI Act (BSIG). Core mechanics: registration obligation with the BSI, risk-management measures aligned with Article 21, staged reporting obligations aligned with Article 23, BSI supervisory powers, personal accountability of management in §38. The BSI opened its registration portal on 6 January 2026. The initial registration deadline expired on 6 March 2026. According to BSI figures, only around 38.5 % of the estimated 29,500 in-scope entities had registered by that date — late registration remains possible, but every day of delay increases the penalty risk.

In parallel, the KRITIS-Dachgesetz was finalised on 6 March 2026 (Bundestag on 29 January 2026, Bundesrat on 6 March 2026). It does not regulate IT security but the physical resilience of critical installations (transposing the EU CER Directive) and applies to roughly 2,000 operators, who must register with the German Federal Office of Civil Protection and Disaster Assistance (BBK) by 17 July 2026. NIS2UmsuCG and KRITIS-Dachgesetz are separate frameworks with partly overlapping addressees — entities affected by both face dual registration obligations and partly different supervisors.

Personal liability for management

Article 20 of the NIS2 Directive obliges the "management bodies" of essential and important entities to approve the risk-management measures under Article 21, oversee their implementation, and undergo cybersecurity training. This responsibility cannot be delegated — operational implementation can, strategic accountability cannot.

The German implementation in §38 NIS2UmsuCG goes one step beyond the directive on a specific point: a contractual or corporate-bylaws waiver of liability is statutorily excluded. Management is personally liable under company-law principles for breaches of risk-management duties. Penalties against the entity can reach €10 million or 2 % of global annual turnover (essential entities) and €7 million or 1.4 % (important entities). Architecturally, this has a concrete consequence: management needs evidence that its duties were fulfilled. Documented architecture decisions, documented risk assessments, documented control reviews — this is not "compliance theatre". It is the form in which the duty of care becomes verifiable.

What to do concretely in 2026

For a greenfield project, the answer is straightforward: build the Article 21 minimum measures into the data model, the API layer, and the CI pipeline from the start. SBOM in the build pipeline. Append-only event log per relevant business entity. SSO with MFA for privileged access. Immutable backups with documented RPO/RTO. Structured logging with correlation IDs. Monitoring with real alerting. Architecture Decision Records.

For legacy systems — the normal case in the Mittelstand — NIS2 is a refactor trigger. The law does not require you to rebuild a 15-year-old ERP. It requires you to demonstrate how you implement the minimum measures. Pragmatically: take the risk inventory as the starting point, prioritise by impact times likelihood, and tackle the top three first. In our experience, in most Mittelstand setups these are identity and access (no central SSO, MFA missing, local admin accounts without audit), logging (no central aggregation, no append-only persistence), and backup (no immutability, no restore tests). Refactor and extension beat full rebuild in almost every case.

For software suppliers serving NIS2-regulated companies, the strategic task is clear: from 2026 onwards your customers will ask, in structured form, for SBOMs, security attestations, incident-handling SLAs, and a vulnerability-disclosure process. Anyone who has prepared this — SBOM in the build pipeline, a documented vulnerability-disclosure policy, clearly defined response times — has a competitive edge over peers who have to scramble for each request.

How we approach this

We do not sell "NIS2-Compliance-as-a-Service". Compliance is not a product — it is the consequence of cleanly built architecture. What we do: we build platforms in which a tamper-evident audit trail, SSO and MFA, append-only event log, and SBOM hygiene are part of the foundation, not retrofitted layers. Refactor capability for grown systems is part of our core offering — end-to-end accountability from architecture to operations, without an enterprise apparatus in between.

The B2B-IoT project LITE BLOX is one example where this requirement profile becomes visible: connected industrial units in the field, lifecycle data model with an immutable birth snapshot per unit, append-only event log for security-relevant events, continuous telemetry via Sentry and Grafana. If you are responsible for a comparable initiative — a new platform or a refactor of a legacy system under NIS2 obligations — we are happy to talk about the architecture before the requirements document reaches the first sprint.

Resources

• EU Directive 2022/2555 (NIS2), consolidated text: eur-lex.europa.eu/eli/dir/2022/2555
• Implementing Regulation (EU) 2024/2690 for digital services: eur-lex.europa.eu/eli/reg_impl/2024/2690
• European Commission, NIS2 overview: digital-strategy.ec.europa.eu/en/policies/nis2-directive
• BSI, NIS-2 regulated companies: bsi.bund.de — NIS-2 regulated companies
• BSI press release on entry into force on 6 December 2025: bsi.bund.de — NIS-2-Umsetzungsgesetz in force
• Federal Government, decision on NIS-2 implementation: bundesregierung.de — NIS-2 Directive Germany
• BMI, legislative process NIS2UmsuCG: bmi.bund.de — NIS2UmsuCG
• Federal Law Gazette, NIS2UmsuCG (BGBl. 2025 I No. 301): recht.bund.de — BGBl. 2025 I No. 301
• ENISA, technical implementation guidance for NIS2: enisa.europa.eu — NIS2 Technical Implementation Guidance

As of May 2026. The interpretation of individual provisions may continue to evolve through implementing acts, BSI guidance, harmonised standards, and sector-specific regulations. For a legally binding assessment of your specific case, please consult qualified legal counsel.