NIS2 Belgium: zero trust checklist for SMEs

Belgium's NIS2 law has applied since 18 October 2024. For a company of 50 to 500 people, the hard part is turning a list of legal obligations into work an IT team can plan and a board can sign off. This article sets out who is covered, what the law asks, how the Belgian CyberFundamentals (CyFun) route works, and where zero trust practices help meet specific controls. It ends with a checklist.

This is general information, not legal advice. The only authoritative texts are those published in the Belgian Official Gazette. For your own situation, use the tools and guidance of the Centre for Cybersecurity Belgium (CCB) and, where needed, a lawyer.

The Belgian NIS2 law in brief

The law of 26 April 2024 (in Dutch, the "wet tot vaststelling van een kader voor de cyberbeveiliging van netwerk- en informatiesystemen van algemeen belang voor de openbare veiligheid") transposes Directive (EU) 2022/2555. It was published in the Belgian Official Gazette on 17 May 2024, and its article 98 sets entry into force on 18 October 2024. A royal decree of 9 June 2024 implements it and designates the CCB as the national cybersecurity authority.

Is your organisation in scope?

According to the CCB's NIS2 page on Safeonweb@Work, an organisation is in principle covered when three conditions are met. It provides a service listed in annex I or II of the law. It is at least a medium-sized enterprise under Commission Recommendation 2003/361/EC, which means at least 50 full-time equivalents, or annual turnover and balance sheet total both above EUR 10 million. And it is established in Belgium.

Annex I lists the highly critical sectors: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, B2B ICT service management, public administration and space. Annex II covers postal and courier services, waste management, chemicals, food, several manufacturing sub-sectors (medical devices, electronics, electrical equipment, machinery, vehicles and other transport equipment), digital providers and research.

Size is calculated at group level when a company has partner or linked enterprises, so a 30-person subsidiary of a larger group can be in scope even if it looks small on its own. Some entities are covered regardless of size, such as qualified trust service providers and DNS service providers. The CCB can also identify an organisation as essential or important under article 11 of the law.

Under articles 9 and 10, annex I entities above the medium-sized ceilings (in practice, large enterprises) are essential entities. Most other covered annex I and II entities are important entities. The CCB notes that the difference mainly concerns how strictly they are supervised and sanctioned.

The CCB offers a downloadable NIS2 scope test tool (an Excel file) and a quick start guide in seven steps. Start there if you are unsure.

Companies outside the scope can still be affected. NIS2 entities must manage supply chain security, and the CCB advises organisations in the supply chain of a NIS2 entity to apply at least CyFun Basic.

What the law requires

Registration

Entities register with the CCB through Safeonweb@Work. Article 13 of the law gives five months from entry into force, which put the deadline at 18 March 2025. Certain digital providers (DNS, cloud, data centre and managed service providers, among others) had until 18 December 2024. Entities identified later have five months from their identification. Changes to registered details must be reported to the CCB.

Risk-management measures

Article 30 of the Belgian law, which transposes article 21 of the directive, requires appropriate and proportionate technical, operational and organisational measures based on an all-hazards approach. The minimum list includes risk analysis policies, incident handling, business continuity and backups, supply chain security, secure acquisition and maintenance, effectiveness testing, cyber hygiene and training, cryptography, human resources security with access control and asset management, and, in article 21(2)(j), "the use of multi-factor authentication or continuous authentication solutions" where appropriate.

Incident reporting

Significant incidents go to the national CSIRT, which is the CCB. Article 35 sets the stages: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, an interim report on request, and a final report no later than one month after the incident notification. Reports are made on the CCB's notification platform, and the CCB publishes a notification guide.

Management responsibility

Under article 31, the management body approves the risk-management measures, oversees their implementation and is liable for breaches. Its members must follow training so they can identify risks and assess cybersecurity practices. The CCB lists administrative fines of up to EUR 10 million or 2% of worldwide turnover for essential entities, and up to EUR 7 million or 1.4% for important entities.

The conformity route: CyFun or ISO/IEC 27001

The CyberFundamentals framework has three assurance levels: Basic, Important and Essential. CyFun 2025 is aligned with NIST CSF 2.0, which is why its control references look like PR.AA-03.2. CyFun 2023 and CyFun 2025 are both available during a transition period, after which only the 2025 version will be accepted. The CCB states that a validated CyFun implementation gives NIS2 entities a presumption of conformity. The royal decree also accepts ISO/IEC 27001, with a scope covering all the entity's networks and information systems.

Essential entities must undergo regular conformity assessment. Important entities are in principle supervised after the fact, for example after an incident, but may opt into the same regime voluntarily. The CCB FAQ is explicit that important entities must still implement all the security measures.

Deadlines for essential entities

These dates come from article 22 of the royal decree of 9 June 2024 (18 and 30 months after entry into force, or after identification), as worded on the CCB's NIS2 timeline and NIS2 and CyFun FAQ:

By 18 April 2026, entities on the CyFun route needed at least a CyFun Basic or Important verification by an accredited conformity assessment body authorised by the CCB. Entities on the ISO/IEC 27001 route had to send the CCB their certification scope, statement of applicability and latest internal audit.
By 18 April 2027, CyFun entities must hold a CyFun Essential certification, unless a documented risk assessment justifies a lower level under article 7 of the royal decree. ISO/IEC 27001 entities must hold their certification, with a statement of applicability showing measures equivalent to the CyFun level that applies to them.
Entities that chose inspection by the CCB instead send a self-assessment (or ISO documents) by 18 April 2026 and a progress report by 18 April 2027.

On 11 August 2026 the CCB's inspection service published a communication (ref. NCCA/JK/INS/2026-002) on what happens if an essential entity cannot reach Essential by 18 April 2027. It asks such entities to submit a remediation plan, preferably with CyFun Important evidence and a description of how Essential will be reached by 18 April 2028. The communication states that it does not change the legal obligations. It also notes that the use of advanced AI raises new questions for governance, risk assessment, supply chain security, monitoring and incident response.

Where zero trust fits

Neither NIS2 nor CyFun requires "zero trust" by name. In a zero trust setup, every request is authenticated and authorised on its own, access is granted per application, and nothing is trusted because it sits on the internal network. Several of those practices line up with concrete controls. The references below come from the CCB's CyFun 2025 mapping (file dated 23 September 2026), which links each control to the directive.

Put MFA on every remote path. CyFun Basic PR.AA-03.2 requires MFA for remote network access, and the mapping links it to article 21(2)(j). A zero trust gateway can put MFA in front of each application, including old ones that cannot do MFA themselves.
Grant access per application with least privilege. PR.AA-05.3 restricts access to the systems and information needed for the task, and PR.AA-05.4 bars administrative privileges for routine work. Per-application policies are easier to review than broad VPN groups.
Segment the network. PR.IR-01.2 asks for segmentation aligned with trust boundaries and asset criticality. A VPN that places a laptop on the whole office network makes this harder. Access granted per application keeps each connection inside one boundary.
Keep management interfaces off the internet. Firewall, hypervisor and backup consoles belong behind authenticated access. This supports PR.IR-01 and, at Essential level, PR.PS-01.3, which asks organisations to disable ports and services that are not needed.
Keep an asset inventory. ID.AM-01.1 and ID.AM-02.1 require inventories of infrastructure and software. You cannot write access policies for systems you have not listed.
Log access with the 24-hour deadline in mind. PR.PS-04.1 and DE.AE-03.1 require logs to be kept and reviewed. A central access log that records who reached which system, and when, helps you decide within hours whether an incident is significant.
Control supplier access. At Important level, ID.AM-08.11 requires remote maintenance to be pre-approved and logged, and GV.SC-07.1 covers supplier risk. Time-limited vendor sessions to one host replace a standing RDP port or a shared VPN account.
Treat service accounts and AI agents as identities. PR.AA-01.1 requires identities and credentials to be managed for users, services and hardware. An AI agent that calls internal systems is a service identity and needs an owner, scoped permissions and an audit trail.

A checklist for Belgian SMEs

Run the CCB scope test and record the result, including group-level size and every service you provide (law, articles 9 and 10).
Confirm your Safeonweb@Work registration and that the contact details are current (article 13).
Choose your framework (CyFun or ISO/IEC 27001) and, for CyFun, a target level based on a documented risk assessment (royal decree, articles 5 and 7).
Put the risk-management measures to the board for approval and schedule management training (article 31).
Build or update the hardware, software and cloud inventory (ID.AM-01.1, ID.AM-02.1).
Enforce MFA on all remote access, starting with email, admin portals and remote desktop (PR.AA-03.2, directive article 21(2)(j)).
Remove standing admin rights from daily accounts and review access rights on a fixed cycle (PR.AA-05.1, PR.AA-05.4).
Replace network-wide VPN access with per-application access where possible, and segment critical systems (PR.IR-01.2).
Check that no management interface is reachable from the internet, and close ports you do not need (PR.IR-01, PR.PS-01.3).
List every supplier with remote access, move them to named, time-limited, logged sessions and document the risk (ID.AM-08.11, GV.SC-07.1, directive article 21(2)(d)).
List service accounts, API keys and AI agents, give each an owner, and limit what each can reach (PR.AA-01.1, PR.AA-05.3).
Centralise access and security logs, set a retention period and review them (PR.PS-04.1, DE.AE-03.1).
Write an incident response plan that names who files the 24-hour early warning and the 72-hour notification on the CCB platform (RS.MA-01.1, law article 35).
Test backups and a recovery run (PR.DS-11.1, RC.RP-01.1).
If you are an essential entity, check your status against the 18 April 2027 deadline and the CCB's August 2026 communication before planning the next audit.

About Flowplane

At Flowplane we are building a European zero trust gateway for people and AI agents. Nothing is available yet, and there are no customers or certifications today. Once it launches, it will aim to cover the per-application access, MFA and access logging described above.

NIS2 and zero trust: a practical checklist for Belgian SMEs