Author : Thierry Julien, CEO & Founder, TJC Group
On 17th October, the European Commission unveiled a supplementary section, known as an “annex”, to their implementing regulation governing the implementation of Directive (EU) 2022/2555. NIS2 is a European Union (EU) law that aims to improve cybersecurity across the region. It stands for Network and Information Systems Directive 2.In simple terms, corporations like cloud service providers must adhere to the updated requirements under the revised NIS2 directive.
NIS2 applies to public and private sector entities that provide certain critical services or critical infrastructure, that qualify as medium-sized or large-sized enterprises and provide their services or conduct their activities within the EU.
Paragraph 6.6 of the above-mentioned annex is about security patch management. Not surprisingly, paragraph 6.6.1 mentions these patches should, when available, be applied reasonably fast, from trusted sources, and with previous testing. When not available, workarounds should apply. What is interesting is the second paragraph (6.6.2), which I quote verbatim:
“By way of derogation from point 6.6.1. (a), the relevant entities may choose not to
apply security patches when the disadvantages of applying the security patches
outweigh the cybersecurity benefits. The relevant entities shall duly document and
substantiate the reasons for any such decision.”
When may this derogation apply?
Some argue continuity of service may be an argument in the NIS2 risk management context. However, paragraph 6.6.1 does not request an immediate patch, but a reasonably fast, and with testing approach. Therefore, the continuity of service should not require a derogation.
Others will assume critical system dependencies, where a patch in one system may have larger consequences (think of energy, healthcare, and transportation industries). A good example could be the Meltdown Vulnerability in 2018 (CVE-2017-5754) affecting CPUs. The reason for not patching was a significant drop in performance (5 to 30%) in some applications (as in Research or Finance) We could also think of the Windows 10 Update (KB4524244) in 2020.
Another example most of us have heard of is the Windows XP inability of patching countless medical devices. While Microsoft officially ended support for Windows XP in 2014, many of these devices remained operational due to their high cost and the lengthy replacement cycles. Not only patching those systems could make them out of order (with a potential life risk for patients), but patching could also invalidate regulatory certifications.
Is this an Open Bar for Vulnerabilities?
It’s kind of easy to come up with a list of data breaches due, or partly due, to a lack of patching. A famous case is the data breach at Equifax started on May 12, 2017, when Equifax had yet to update its credit dispute website with the new version of struts.
The possibility of derogation doesn’t give a free pass but rather a structured approach where entities must assess, document, and justify decisions for not applying specific patches.
Additionally, NIS2 is not the onlyregulation to consider. Let’s pick a single example. ke GDPR, for instance: while it does not mandate that organizations apply every patch, it enforces a high standard for protecting personal data. Under GDPR, if failing to apply a patch result in a data breach, the organization could face legal consequences. Regulators may interpret the failure to patch critical vulnerabilities—particularly if they were known and left unmitigated—as a breach of the duty to protect personal data (Article 32 – Security of Processing).
Does this apply to SAP legacy systems?
Yes, it may be a strange question to ask, as SAP ERP systems used to be, and still are, the core of integrated IT systems for most of the largest corporations worldwide.
Firstly, the SAP legacy systems must be kept for tax audit reasons, even if transitioning to S/4HANA through a “lift and shift” (brownfield) migration. Additionally, preserving detailed historical business data can be valuable, as it provides essential material for AI models. Still, many SAP systems are unpatched legacy systems. Why? I’ve heard all sorts of justification, such as…
- Yes, but it’s an old version.
- Yes, but it’s on a Virtual Machine, so not an issue.
- Yes, legacies are unpatched, but our current system is patched.
- Yes, but it’s disconnected from our external network (as if employees never hacked their own company).
At the time of sunsetting, a legacy ERP system typically holds a wealth of sensitive information: detailed information about customers and suppliers, employee records, assets, project details, product names, sales details, and even proprietary information such as bills of materials (BOM), routings, product costs, and profit margins. This data poses a high security risk, even if it is two to five years old. If considering the application of 6.6.1 derogation, here are some reasons that might serve as a ‘duly documented’ rationale for not patching:
- I did not patch the system before sunsetting it.
- Maintenance fees are no longer paid, so patching was not feasible. Database maintenance was also stopped, which could cost up to a quarter million dollars annually for a mid-sized company.
… feel free to add more to the list.
Yes, leaving systems unpatched, unsecured, and not applying data privacy regulations is cheaper than complying with regulatory requirements. But article 6.6.1 suggests you don’t patch when “the disadvantages of applying the security patches
outweigh the cybersecurity benefits” … It does not read as ‘outweigh the costs”.
So, I guess corporations will have a tough time documenting non-patching of SAP legacy systems, specifically now than decommissioning solutions exists. For instance, have a look at Enterprise Legacy System Application.
Conclusion
In conclusion, section 6 paragraph 6.6.2 recognizes that a one-size-fits-all approach to patching can be impractical or counterproductive in certain contexts but is not a getaway from Responsible Cyber Hygiene. It aligns with NIS2’s goal of improving overall resilience without imposing rigid requirements that could inadvertently compromise critical services. It’s definitely not an ‘out of jail’ card.
More information
THE STRATEGIC IMPERATIVE: DECOMMISSIONING LEGACY SYSTEMS FOR BETTER CYBERSECURITY
LEGACY DATA AND LEGACY SYSTEM DECOMMISSIONING TO REDUCE CYBERSECURITY THREATS
SAP VULNERABILITIES – IS IT SAFE TO KEEP LEGACY DATA IN AN OLD SAP SYSTEM?
