NIS2 in healthcare: why outdated servers and blocked OTPs are now compliance failures
An unsent OTP code. A patient portal that times out at 8 a.m. on a Monday. A booking gateway running on an operating system that stopped receiving security patches two years ago. Until recently, these were filed under “IT annoyances” and pushed down the ticket queue. Under the NIS2 directive, they are something else entirely: documented evidence that an organisation is not managing its cyber risk, and that can carry legal and financial consequences for the people running the business.
Healthcare is explicitly named as a “highly critical” sector in Annex I of NIS2, which means hospitals, clinics, diagnostic labs, and a long tail of suppliers now sit inside a regulatory perimeter they were never in before. In Italy, Legislative Decree 138/2024 transposed the directive and put ACN (Agenzia per la Cybersicurezza Nazionale) in charge of enforcement. The registration deadline passed in early 2025, and the technical obligations are now phasing in. For small and medium healthcare providers, and for the IT companies serving them, the question is no longer whether NIS2 applies but how much of your current infrastructure would survive an audit.
Why healthcare became the test case
The sector concentrates every risk factor at once. Medical devices with 10 to 15 year lifecycles run embedded software that cannot be patched without recertification. Clinical continuity means systems cannot simply be taken offline for maintenance. And the data involved is health data under Article 9 GDPR, the most heavily protected category there is.
The numbers back this up. ENISA’s threat landscape work on the health sector found ransomware to be the dominant threat, accounting for roughly 54% of analysed incidents, with over 40% of incidents affecting patients directly through delayed or cancelled procedures. IBM’s Cost of a Data Breach report has ranked healthcare as the most expensive sector for breaches for well over a decade, with average costs sitting near 9.8 million dollars at their peak. These are not abstract compliance figures. They are what happens when an unpatched server is the entry point.
What NIS2 actually requires, in plain terms
Article 21 of the directive lists ten minimum risk management measures. Read them as an operational checklist rather than legal text and the picture becomes concrete for any SMB.
You need a documented risk analysis and information system security policy. You need incident handling procedures with defined roles. You need business continuity, including backup management, disaster recovery, and crisis management. You need supply chain security covering your direct suppliers and service providers. You need policies on vulnerability handling and disclosure, plus procedures to assess whether your measures actually work.
The remaining measures cover cyber hygiene and training, cryptography, human resources security and access control, and multi-factor authentication or continuous authentication solutions. That last point is where the OTP problem becomes a compliance problem.
The OTP that never arrives
An OTP code that fails to reach a doctor logging into a clinical records system is not a UX glitch. It is a failure of the authentication control that Article 21 explicitly requires. Worse, it usually triggers a predictable chain reaction: staff request a bypass, someone disables MFA “temporarily” for a specific account, and that exception is never reversed.
Under NIS2 logic, what matters is not just that the control existed on paper but that it was operating and monitored. If your SMS gateway silently drops messages for three weeks and nobody notices, you have a monitoring gap, an authentication gap, and no evidence of the “effectiveness assessment” the directive requires. Structured cybersecurity services treat MFA delivery as a monitored production dependency, with alerting and a documented fallback channel, rather than as a feature that either works or does not.
Outdated servers as documented negligence
Outdated server risks change character under NIS2. Before, running an end-of-life system was a technical debt item you could defer with a business justification. Now, the absence of vendor security patches means known vulnerabilities remain permanently open, and the directive’s vulnerability handling requirement has no realistic answer for a system that cannot be patched.
The practical trap for SMBs is the gateway or middleware layer: the VPN concentrator, the interoperability engine connecting the lab system to the hospital record, the appliance that authenticates external radiologists. These sit at network boundaries, are internet-facing by design, and are frequently forgotten because “they just work.” They are also, consistently, the initial access vector in real ransomware cases.
If you cannot replace an out-of-support system immediately, and in healthcare you often genuinely cannot, the compliant path is compensating controls that are documented and tested: network segmentation isolating the legacy asset, strict access control lists, enhanced logging, and a written remediation roadmap with dates. What is not defensible is having no plan at all.
NIS2 business continuity is not the same as having backups
This is where most SMB assessments come apart. Organisations report that they have backups, and they usually do. What they cannot produce is evidence of a tested restore, a defined RTO and RPO agreed with clinical management, or a crisis procedure that works when Active Directory itself is encrypted.
NIS2 business continuity means answering specific questions with specific numbers. How long can the booking system be down before appointments must be cancelled? How much data can you afford to lose, measured in hours? Who declares a crisis, who talks to ACN, and who talks to patients? If the answers live only in the head of one system administrator, you have a single point of failure that no technology purchase fixes.
The reporting timeline makes this urgent. NIS2 requires an early warning to the national CSIRT within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. Twenty four hours is not enough time to build a process from scratch while a network is down.
Governance, and why this reaches the owner’s desk
Article 20 places responsibility for approving and overseeing cybersecurity measures on management bodies, and requires that management receive training. Member States must ensure that managers can be held liable for infringements. Administrative fines reach up to 10 million euro or 2% of global annual turnover for essential entities, and up to 7 million euro or 1.4% for important entities.
For a mid-sized diagnostic group or a private clinic, the reputational and operational impact of a temporary suspension of activity typically hurts more than the fine. That is the shift worth internalising: cybersecurity has moved from the IT budget line to the governance agenda.
NIS2 compliance for healthcare organisations: where to start
The gap between “we should look at NIS2” and a defensible security posture is usually six to twelve months of structured work. A realistic sequence looks like this.
Start with an honest asset inventory. You cannot protect or patch what you have not listed. Include medical devices, third party remote access accounts, and shadow systems that a department bought independently. In our experience with healthcare IT environments, the inventory phase alone surfaces two or three internet-exposed systems nobody knew were still running.
Map your supply chain. NIS2 makes you responsible for supplier risk, and healthcare runs on suppliers: the RIS/PACS vendor, the cloud booking platform, the outsourced help desk. Contracts need security clauses, incident notification obligations, and defined support windows.
Fix the identity layer. MFA everywhere it is technically possible, privileged account separation, removal of dormant accounts, and monitored delivery for authentication factors. This is the highest-value work per euro spent.
Test continuity for real. Run a restore from backup into an isolated environment and time it. Document the result, including what went wrong, because a documented failed test followed by remediation is stronger evidence of diligence than an untested claim of readiness.
Build the incident process before you need it. Contact points, escalation paths, a 24-hour reporting template, and a decision tree for when an event becomes “significant.”
Organisations that share infrastructure with or supply services to the public sector should note that similar obligations flow through public administration IT requirements, and that reliable operational support, including a properly staffed help desk, is part of the continuity picture rather than separate from it. A deeper walkthrough of the directive’s structure and timelines is available in our NIS2 compliance guide.
The underlying message of the Italian regulatory approach is consistent: NIS2 does not ask for perfection. It asks you to know your risks, decide consciously what to do about them, document those decisions, and prove the controls work. An obsolete server with a funded replacement plan and compensating controls is a managed risk. The same server with no plan is a finding.