NIS2 changed the conversation for any organization that qualifies as an “essential” or “important” entity, and one of the most concrete places that shows up is in how exposed network services get managed. If a port is open to the internet and something is listening on it, that service now falls inside the scope of risk management measures the directive requires under Article 21 – regardless of whether it’s a web app, a database left open during a migration, or a forgotten RDP endpoint from three years ago.
What NIS2 actually says about exposed services
NIS2 (Directive (EU) 2022/2555) doesn’t mention “port scanning” or “open ports” by name. It talks about risk management measures in Article 21(2), which lists things like network and information systems security, incident handling, business continuity, supply chain security, and vulnerability handling and disclosure. Member states had until 17 October 2024 to transpose it into national law, and by mid-2026 most EU countries have enforcement mechanisms active, with fines up to €10 million or 2% of global annual turnover for essential entities.
The practical translation: if you can’t produce an inventory of what’s reachable from the internet on your servers, you can’t demonstrate the “appropriate and proportionate technical, operational and organisational measures” the directive demands. Auditors and national CSIRTs increasingly ask for evidence of continuous monitoring, not a one-time pentest report from two years ago.
Who falls under scope
NIS2 expanded coverage far beyond the original 2016 NIS Directive. Essential entities include energy, transport, banking, health, water, and digital infrastructure providers. Important entities cover manufacturing, postal services, waste management, chemicals, and digital providers like cloud services and data centers with more than 50 employees or €10 million in annual turnover.
A mid-sized manufacturing company with 80 employees that would have been ignored under NIS1 is now squarely in scope as an “important entity.” That’s a meaningful shift – a lot of IT teams that never had to think about regulatory port hygiene now do, often without the headcount that a bank’s security team has.
Why open ports are a recurring audit finding
Exposed network services keep showing up as findings for a few consistent reasons. Firewall rule changes made during an incident get left in place after the incident closes. A contractor opens port 3389 for a one-off remote session and forgets to close it. A load balancer health check port ends up reachable from 0.0.0.0/0 instead of the internal subnet it was meant for.
None of these are exotic attack techniques. They’re operational drift, and NIS2’s risk management language specifically calls out the need for policies and procedures to assess the effectiveness of security measures – which means drift has to be caught, not just prevented in theory. Common port misconfigurations that lead to breaches tend to follow this same pattern: the mistake wasn’t sophisticated, it just went unnoticed for months.
Building a compliance-relevant monitoring approach
An NIS2-relevant approach to exposed services usually has four components:
Asset inventory first. You cannot secure what you don’t know exists. Every public IP, every server, every load balancer endpoint needs to be enumerated before anything else happens.
Continuous external scanning, not periodic. A quarterly pentest catches an open Redis port on the day of the test. It misses the six weeks that port was open beforehand. NIS2’s emphasis on ongoing risk assessment favors continuous or near-continuous scanning cadence over annual checklist exercises. Deciding the right frequency depends on the entity’s risk profile – a payment processor and a regional water utility don’t need identical schedules, a point covered in why your port scan schedule should match your risk profile.
Service and version identification. Article 21 explicitly calls out vulnerability handling. Knowing that port 443 is open isn’t enough – you need to know it’s running Apache 2.4.49 (CVE-2021-41773, path traversal) versus a patched 2.4.62 build. Fingerprinting matters more under NIS2 than a bare open/closed port list.
Assigned ownership. When an auditor asks “who is responsible for closing this port if it’s found unnecessary,” there needs to be a name attached, not a shrug. This is where a lot of mid-sized organizations fall down – nobody owns the finding, so it sits in a ticket queue for eight months. Port ownership records: who answers for each service covers how to structure that accountability so it doesn’t collapse the first time someone changes teams.
Common mistakes organizations make under NIS2
A few patterns show up repeatedly in how organizations mishandle this requirement. The first is treating the transposition deadline as the finish line – teams did a one-time cleanup around October 2024 and then stopped, as if compliance were a project rather than an operating state. NIS2 auditors in 2026 are specifically looking for evidence of an ongoing process, not a snapshot from 18 months ago.
The second is conflating vulnerability scanning with port monitoring. A vulnerability scanner authenticated inside the network tells you about patch levels on systems you already know about. It says nothing about the load balancer someone spun up in a dev environment that’s now reachable from the public internet. NIS2’s supply chain and third-party risk language (Article 21(2)(d)) pushes toward external, attacker’s-eye-view visibility that internal scanning doesn’t provide.
The third mistake is scoping the monitoring program only to production. Under NIS2, a breach originating in a staging environment that shares network segments with production still counts as an incident requiring notification – the 24-hour early warning and 72-hour detailed notification requirements to the national CSIRT don’t care which environment was hit first.
A practical starting point
For organizations bringing a new server online, the moment of deployment is the cheapest point to get this right – retrofitting monitoring onto infrastructure that’s been running unmanaged for two years is far more disruptive. Onboarding new servers into a port monitoring program lays out the sequence: inventory the IP, run a baseline scan, document expected open ports, assign an owner, then add it to the recurring scan schedule before it ever takes production traffic.
Frequently asked questions
Does NIS2 require a specific port scanning tool or frequency?
No. The directive is deliberately technology-neutral and leaves specifics to national implementing legislation and sector-specific guidance. What’s expected is that the frequency and depth of monitoring are proportionate to the entity’s risk exposure and that the organization can demonstrate the process is ongoing, not that a particular product is used.
Is a company already ISO 27001 certified automatically NIS2 compliant?
No, though there’s substantial overlap. ISO 27001’s Annex A controls around network security and vulnerability management align well with NIS2’s Article 21 requirements, but NIS2 adds specific incident notification timelines and supply chain provisions that ISO 27001 doesn’t mandate on its own. Organizations already aligned with ISO 27001 typically have less work to do, but shouldn’t assume certification alone satisfies a national CSIRT audit.
What counts as an “exposed” service under NIS2 scrutiny?
Practically, anything reachable from a public IP address without requiring VPN or internal network access – web servers, exposed databases, management interfaces like RDP or SSH, API gateways, and misconfigured cloud storage endpoints. If an external scan from the internet can reach it and get a response, it’s in scope for the risk assessment.
Getting exposed services under control for NIS2 isn’t really a one-time audit exercise – it’s closer to maintaining a habit. The organizations that handle this well treat their public attack surface the way they’d treat patch management: something reviewed on a schedule, owned by named people, with a paper trail an auditor can follow back at least a year.