Does NIS2 Require Replacing Your Legacy ERP? What Enterprise Teams Actually Need to Know in 2026

The question lands in every CTO's inbox eventually. Your compliance team has flagged NIS2. Your auditor has flagged NIS2. Your insurance provider is asking questions about NIS2. And somewhere in the background is a 15-year-old ERP that runs the core of your business, and a very uncomfortable sense that these two things are going to collide.

The short answer is: NIS2 does not explicitly require you to replace your ERP. The longer answer is that what NIS2 does require is specific enough that many legacy ERP architectures cannot meet it without a modernization project that amounts to the same thing.

This article breaks down exactly what the directive demands, where legacy systems fail against those demands, and how to think through the decision in practical terms for your organization.

What NIS2 Actually Is and Who It Covers

NIS2 (Directive EU 2022/2555) is the European Union's most significant overhaul of cybersecurity regulation since the original NIS Directive of 2016. It came into force with a transposition deadline of October 17, 2024, and as of early 2026, enforcement is active across member states with real financial consequences.

The scope is wider than most organizations initially assume. NIS2 applies to medium and large organizations with 50 or more employees or annual turnover above 10 million euros, operating across 18 critical sectors. Those sectors include energy, transport, healthcare, banking, financial market infrastructure, digital infrastructure, public administration, manufacturing of certain categories, food, chemicals, and several others. If your organization provides services considered essential or important to the functioning of the EU economy or society, you are likely in scope.

The scale of enforcement is now real. Germany issued its first NIS2 penalty in February 2026, an 850,000 euro fine against a mid-sized cloud service provider for failure to implement risk management measures and incident response procedures. France opened investigations into 14 entities across healthcare and digital infrastructure for inadequate cybersecurity governance. Italy's national cybersecurity agency has announced systematic audits of essential entities beginning in 2026.

Fines for essential entities reach up to 10 million euros or 2% of global annual turnover, whichever is higher. For important entities, the ceiling is 7 million euros or 1.4% of global turnover. Beyond financial penalties, NIS2 enables member states to hold individual managers personally liable for gross negligence following a breach, including temporary bans from holding management positions for repeated violations. Gartner projected in 2024 that by 2026, 75% of CEOs would be personally liable for cyber-physical security incidents as a result of regulations like NIS2.

What NIS2 Article 21 Actually Requires

The core technical and organizational obligations sit in Article 21 of the directive. This is where legacy ERP systems start to create problems.

Article 21 requires essential and important entities to implement appropriate and proportionate measures across ten specific control areas. The ones that legacy ERP architectures most commonly fail against are the following.

Access control and multi-factor authentication. NIS2 mandates appropriate access control measures, with multi-factor authentication explicitly required for systems handling sensitive data and operations. Legacy ERP platforms built in the 2000s and early 2010s were not designed around MFA as a native capability. Retrofitting MFA onto these systems is possible through network-layer controls, but it requires documented compensating controls and carries ongoing audit risk.

Incident detection and time-bound reporting. Article 23 of the directive requires an early warning to national authorities within 24 hours of becoming aware of a significant incident, a detailed notification within 72 hours, and a final report within one month. Detecting incidents on systems that lack native monitoring integration is the operational problem. Reporting on incidents you did not detect is the compliance problem. Legacy ERP systems that cannot be instrumented with modern SIEM tooling leave organizations unable to meet these timelines in practice.

Vulnerability management and patching. NIS2 requires organizations to manage security in the acquisition, development, and maintenance of their network and information systems, including vulnerability handling and disclosure. A system that cannot receive regular security patches because of vendor end-of-life, customization depth, or compatibility constraints requires documented compensating controls. Those compensating controls must be verifiable by auditors. ENISA's implementation guidance explicitly addresses this: organizations must demonstrate evidence-backed compensating controls for systems that cannot be patched, including network segmentation, restricted access, and continuous monitoring.

Encryption. Sensitive data must be protected with encryption at rest and in transit. Legacy ERP architectures frequently communicate over internal protocols that predate modern cryptographic standards. Documenting alternatives is possible, but auditors increasingly require demonstrated technical enforcement, not policy statements.

Supply chain security. NIS2 requires organizations to evaluate the cybersecurity posture of third-party vendors and suppliers. If your ERP vendor is no longer actively maintaining the version you run, that vendor relationship becomes a supply chain security gap under the directive.

Business continuity and operational resilience. The directive requires organizations to maintain essential services during cyber incidents and minimize operational disruptions. Legacy systems with manual recovery procedures and no automated failover capability are difficult to align with this requirement in a demonstrable way.

The Legacy ERP Compliance Problem in Concrete Terms

The compliance gap is not theoretical. It shows up at the specific intersection of what NIS2 requires technically and what legacy ERP systems can support architecturally.

Legacy systems that cannot support modern identity controls are frequently excluded from Zero Trust security initiatives, yet they remain critical to operations and squarely within regulatory scope. That is the exact phrase that appears in CISO guidance for NIS2, and it describes the situation precisely. You cannot exclude your ERP from your compliance program because it processes the business-critical data that the directive is designed to protect. But the system itself may not be capable of supporting the controls the directive requires.

The patching problem compounds this. When a system cannot receive patches and has a well-documented catalog of unresolved vulnerabilities, the organization must demonstrate what compensating measures are in place. Policies alone do not satisfy auditors. Evidence of technical enforcement does. For organizations running ERP versions on vendor end-of-life support schedules, the documented vulnerability catalog grows every quarter while the remediation options shrink.

SAP's situation is a specific example of how this converges. At the end of 2024, only 39% of SAP's 35,000 ECC customers had migrated to S/4HANA. Gartner projects approximately 17,000 holdouts will still be running legacy ECC when mainstream support ends in December 2027. SAP ECC Compatibility Packs expired May 31, 2026. For European enterprises, roughly half of German-speaking SAP users planned to miss the 2027 migration deadline entirely, according to DSAG data from 2026. These migration timelines sit directly alongside NIS2 compliance deadlines, creating a compound pressure that most organizations are not yet treating as a single problem.

NIS2 compliance requirements favor centralized security monitoring that modern cloud architectures enable. Legacy on-premise ERP systems were not designed to expose the monitoring surfaces that modern SIEM and SOC tooling requires.

Can You Retrofit Compliance Without Replacing the ERP?

The honest answer is: sometimes, and at a cost that is often underappreciated.

NIS2 does not mandate specific technologies. It mandates specific outcomes: you must be able to detect incidents, report them within defined windows, control access with MFA, encrypt data appropriately, manage vulnerabilities, and demonstrate all of this to auditors with evidence, not policies. If your legacy ERP can be instrumented to deliver those outcomes through compensating controls, and if you can document and evidence those controls, a full replacement is not mandated by the directive.

The realistic barriers are three.

Technical instrumentation. Many legacy ERP systems cannot expose the log streams and audit trails that modern SIEM platforms consume. Compensating controls like network segmentation and monitoring at the perimeter can partially substitute, but they do not give you visibility into what is happening inside the ERP itself. An auditor asking to see evidence of incident detection capability will be looking for evidence of internal system visibility, not just perimeter monitoring.

MFA enforcement. Network-layer MFA solutions can add an authentication layer in front of a legacy system that cannot support it natively. This satisfies the compensating control requirement in most cases, but it must be documented, tested, and evidenced. It is an ongoing compliance maintenance burden, not a one-time configuration.

The cost comparison that most organizations do not run. Building and maintaining compensating controls for a legacy ERP costs engineering time, security tooling licenses, ongoing audit preparation, and incident response readiness that modern architectures handle natively. That ongoing cost, run over three to five years, frequently exceeds a phased modernization program. Organizations that modernized between 2022 and 2025 report 25 to 35 percent reductions in infrastructure costs, 40 to 60 percent faster release cycles, and a 50 percent reduction in security breach risk. The business case for modernization has become significantly stronger precisely because the cost of staying compliant on legacy infrastructure has risen.

The Modernization Decision Framework

If your organization is trying to determine the right path, the following questions are the ones that matter.

What does your specific ERP version support natively? The answer is not the same for every legacy system. Some older platforms support SAML-based authentication that enables MFA integration. Others do not. Start with a technical capability assessment of your current system before assuming the worst or the best.

What compensating controls do you currently have and can evidence? If you can demonstrate network segmentation, monitored access logs, and documented incident response procedures, your current posture may be closer to compliance than you think. A gap analysis against Article 21's ten requirements, with evidence documentation, is the right starting point.

What is your vendor's end-of-life timeline? If your ERP version moves off mainstream support in the next 24 months, the compensating control burden increases significantly at that point. Factor the future cost, not just the current cost.

What is the total cost of compliance maintenance on your current architecture? Include engineering labor for security tooling integration, annual audit preparation, the cost of documenting and testing compensating controls, and any incremental incident response capability you need to build. Compare that over three years against a phased modernization program.

Do you have the organizational capacity for a modernization project right now? A poorly executed modernization creates compliance risk of its own. Phased approaches that keep existing systems running in parallel during transition, such as the Strangler Fig pattern for application-level modernization or blue-green infrastructure approaches, are significantly safer than big-bang migrations.

How Marka's Team Approaches This Problem

The organizations that make the most expensive mistakes in this situation are the ones that treat the NIS2 question and the ERP modernization question as separate decisions. They are not.

Marka's engineering team has worked with enterprises in healthcare, finance, manufacturing, and public administration since 1993, across exactly the intersection of compliance-driven architecture decisions and legacy system modernization. As a Microsoft Gold Certified Partner, the practical architecture we most often recommend for organizations in this position starts with a structured gap analysis, not a modernization proposal.

The gap analysis runs the current ERP architecture against Article 21's ten control areas with evidence documentation, not policy review. It identifies which gaps can be closed with compensating controls at acceptable ongoing cost, which gaps require architectural change, and what the realistic three-year cost of each path looks like. That analysis is the foundation for a modernization business case that finance teams can evaluate honestly, rather than a technology recommendation in search of a budget approval.

For organizations on Microsoft's stack, Azure-native tooling solves several of the NIS2 monitoring and access control requirements in ways that can bridge a legacy ERP during a phased migration. Microsoft Sentinel provides the SIEM capability that legacy systems need for incident detection. Entra ID handles MFA enforcement at the network layer for systems that cannot support it natively. Azure Policy and Defender for Cloud provide the continuous monitoring and vulnerability management evidence that auditors require. This does not eliminate the need to eventually modernize the ERP itself, but it can bring a legacy system into a defensible compliance posture while the migration proceeds on a controlled timeline.

The cloud and platform modernization work Marka's team does is built around this kind of phased approach. We have seen organizations attempt full ERP replacements under compliance pressure and create larger risk than they started with. We have also seen organizations spend three years and significant budget on compensating controls for a legacy system that they eventually modernize anyway. The right answer is specific to your architecture, your vendor timeline, your regulatory classification, and your organizational capacity.

If your team is working through this question, the starting point is a conversation, not a proposal. You can reach Marka's team directly at marka-development.com/contacts.

NIS2 Compliance and Legacy ERP: The Final Answer

NIS2 does not mandate a specific technology or require you to replace your ERP by name. What it mandates is demonstrable compliance with ten specific cybersecurity control requirements, evidenced to auditors, with time-bound incident reporting, and with personal management liability for failures.

Whether your legacy ERP can support those requirements through compensating controls or requires modernization to meet them is a technical and financial question specific to your system, your vendor, and your architecture. That question deserves an honest answer based on your actual situation, not a vendor's interest in selling you a migration project, and not the opposite instinct to defer the decision until enforcement arrives at your door.

Enforcement is already arriving. Germany fined a cloud provider 850,000 euros in February 2026. Systematic audits of essential entities are underway in Italy. The Dutch authorities are requiring self-assessments from all in-scope organizations by June 2026. The window for treating NIS2 as a future compliance problem closed when the first penalties were issued.

The organizations that handle this well start with the gap analysis, run the cost comparison honestly, and make the architectural decision with complete information. That is the work worth doing now.