What NIS 2 actually asks of your network devices
The NIS 2 directive (EU 2022/2555) replaced the original NIS directive and widened the set of entities in scope considerably. Its Article 21 requires "proportionate" risk-management measures, written as outcomes rather than as products. For a network team, that open wording is the real work: translating legal obligations into technical evidence.
This article describes what those obligations mean in practice for an estate of switches, routers and firewalls. It does not replace the guidance of your national authority.
Five obligations that land on the network
1. Know your estate
No security measure can be demonstrated on a device you do not know about. Inventory is not listed as a measure of its own, but every other one depends on it: risk analysis, vulnerability handling, access control. A usable inventory identifies vendor, model, firmware version, location and owner for each device — and it updates itself, otherwise it is wrong within weeks.
2. Handle vulnerabilities
Article 21 explicitly names vulnerability handling and disclosure. On the network side, that means being able to answer one simple question when an advisory is published: which devices are affected, on which version, and where are they? If answering takes a week of manual collection, the obligation is not met.
3. Control privileged access
The text requires access control policies and stronger authentication for privileged access. On a network, the usual weak point is the shared local account: an enable password the whole team knows, never rotated after someone leaves, never logged. What is expected is named identities, multi-factor authentication on administrative access, and a record of who did what.
4. Keep operations recoverable
Backup management and disaster recovery are among the measures. For a network, the useful backup is not the monitoring server: it is the configuration of every device, versioned, with the ability to return to the state before a change. A backup whose restore has never been tested is not evidence.
5. Report incidents within the deadlines
Article 23 sets an early warning within 24 hours, a notification within 72 hours and a final report within one month. Those deadlines are only workable if the history exists before the incident: knowing which configuration was in place, what changed and when, is what lets you qualify an event in hours instead of days.
The difference between a policy and evidence
The most common mistake is documenting an intention. A binder stating that "configurations are backed up daily" is worth nothing to an auditor if nobody can produce yesterday's backup for a device picked at random. What an audit asks for is verifiable material:
- the list of devices, with their software version, at a given date;
- the history of configuration changes, with their author;
- the result of a compliance check, and the residual gap you accept;
- the record of administrative access, replayable if needed;
- the timeline of a past incident, reconstructed from data rather than memory.
These five items are produced by running the network, not by a separate compliance project. That is the point of continuous collection: the evidence is a by-product of normal operation.
Where to start from zero
In this order, because each step makes the next one possible: automatic inventory, then versioned configuration backup, then a compliance check that measures the gap against your policy, then control of administrative access. Incident reporting comes last, because it consumes everything above.
Our NIS 2 compliance page maps these requirements to the platform modules, and the compliance audit page shows how the gap is measured after each collection.
One useful caveat
NIS 2 is a directive: it is transposed into national law, with variations. The exact scope of entities, thresholds and reporting channels depend on your country and sector. The technical building blocks described here are needed in every case, but this is not legal advice: have your situation qualified by your national authority.
