In the server rooms of many plants, there is a machine that no one wants to touch anymore. The operating system hasn’t received any security updates for years, the application’s manufacturer has long since disappeared from the market, and yet the computer cannot be shut down: It contains test reports, batch data, and order history that you are required to retain for ten years or longer. Until the end of 2025, this was an IT problem that could be put on the back burner. As of December 6, 2025, the German NIS2 Implementation Act has been in effect, and it requires vulnerability management, access control, and a recovery plan that works in an emergency. Senior management is personally responsible for ensuring compliance.
THE MOST IMPORTANT POINTS AT A GLANCENIS2 and legacy systems are in direct conflict: The BSI Act requires manufacturing companies with 50 or more employees or annual revenue and total assets exceeding 10 million euros to implement risk management measures in accordance with Section 30 of the BSI Act. Legacy systems without security updates—which are kept running solely to meet legal retention requirements—undermine these obligations. The solution: transfer the data to a standalone archive in an audit-proof manner and then decommission the legacy system. |
|
FREE WHITE PAPER Securing Legacy Data Under NIS2Before you decommission your first legacy system: The white paper “Data Governance for Structured Data” shows you how to establish binding policies for retention, access, and deletion. |

IN A NUTSHELL
|
What specific requirements does NIS2 place on manufacturing companies?
NIS2 is EU Directive 2022/2555 on measures for a high common level of cybersecurity. In Germany, the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) implements the directive. At the heart of the law is the revised Federal Office for Information Security Act (BSIG), which has been in effect since December 6, 2025, with no transition period. New for the manufacturing sector: Even medium-sized manufacturers are now subject to cybersecurity regulations that previously applied primarily to energy suppliers and hospitals.
The BSIG distinguishes between two categories. Particularly important facilities are those in sectors with high criticality as defined in Annex 1, such as energy, transportation, or healthcare. Important facilities also include the other critical sectors listed in Annex 2, which include the manufacturing industry—specifically mechanical engineering, automotive suppliers, and medical technology.
Which manufacturing sectors fall under NIS2
Appendix 2 of the BSIG lists six industries within the manufacturing sector. Companies in these industries are considered important facilities if they have at least 50 employees or achieve an annual revenue and total assets of more than 10 million euros each:
- Manufacture of medical devices and in vitro diagnostics
- Manufacture of data processing equipment, electronic, and optical products
- Manufacture of electrical equipment
- Mechanical engineering
- Manufacture of motor vehicles, motor vehicle parts, and trailers
- Other vehicle manufacturing
As an automotive supplier, mechanical engineering firm, or medical technology manufacturer, you should therefore clarify your compliance status early on and in writing. Even companies below the threshold are affected by NIS2: Affected customers must manage the security of their supply chain in accordance with Section 30 of the Federal Information Security Act (BSIG) and pass on requirements to their suppliers through contracts.
| Value | Significance | Source |
|---|---|---|
| 29,500 | Estimated number of affected organizations in Germany | BSI estimate, as reported by Börse Express, July 2026 |
| 18,500 | Organizations registered with the BSI as of the end of May 2026 | BSI, as reported by Börse Express, July 2026 |
| 34% | of companies have fully implemented NIS2 | Plusserver Study 2026 |
| 7 million € | Maximum fine for critical infrastructure operators or 1.4% of revenue | § 65 BSIG |
Overview of Obligations
Registration with the BSI offers little benefit. The work involves three sets of obligations that apply on an ongoing basis:
- Risk management measures under Section 30 of the BSIG: ten minimum measures that ensure the availability, integrity, and confidentiality of IT systems, and whose implementation must be documented.
- Reporting obligations under Section 32 of the BSIG: You must report significant security incidents by issuing an early warning within 24 hours, a formal report within 72 hours, and a final report after one month.
- Management obligations under Section 38 of the BSIG: Senior management must approve the measures, monitor their implementation, and regularly participate in training sessions.
For legacy systems, the first section is particularly important. Section 30 of the BSIG makes no exception for older systems: Every system you use for your services must be adequately protected.
Why do legacy systems pose a risk under NIS2?
A legacy system is an application or database that is still in operation even though the manufacturer, platform, or expertise needed for its further development is no longer available. In manufacturing, these are typically old MES instances, deprecated ERP systems, test bench computers, CAQ databases, or in-house developments from the 2000s. Many of these no longer serve any business purpose and are kept running solely because their data must be retained.
This brings them into conflict with the minimum requirements specified in Section 30(2) of the BSIG. The assessment matrix shows where a typical legacy system fails to meet the requirements. Go through it once for each system in your inventory.
| Requirement under Section 30(2) of the BSIG | What the Law Requires | Typical Situation in the Legacy System |
|---|---|---|
| No. 3 Maintenance of Operations | Backup management, disaster recovery, crisis management | Recovery never tested; hardware no longer available |
| No. 5 Acquisition, Development, Maintenance | Security throughout the lifecycle, including vulnerability management | No patches; manufacturer no longer available |
| No. 7 Cyber Hygiene | Basic security procedures and training | Outdated protocols, default passwords, local accounts |
| No. 8 Cryptography | Concepts and procedures for encryption | Unencrypted databases, outdated TLS versions |
| No. 9 Access Control and Asset Management | Concepts for access control, asset management | Collective accounts, no logging, system missing from inventory |
| No. 10 Authentication | Multi-factor authentication, secure communication where appropriate | Only username and password allowed |
The law does not require absolute security. It requires appropriate, proportionate, and effective measures, taking into account risk exposure, the size of the organization, and implementation costs. However, this does not give organizations free rein. Anyone operating a system online without security updates must justify why the remaining risks are controlled. For a system that no longer serves any technical purpose, providing this justification is difficult.
Every legacy system connected to the network increases the attack surface
The vulnerabilities of old operating systems and databases are publicly documented, and for systems no longer supported, no one is patching them anymore. An attacker can move laterally into the production network via a single unpatched database server. For NIS2, therefore, every system connected to the network, domain, or file shares counts. You can read more about the hidden costs of such systems in the article “Replacing Legacy Systems.”
Retention Requirements vs. Security Requirements: How Do You Resolve This Dilemma?
In most cases, legacy systems continue to operate for legal reasons. Commercial law, tax law, and industry standards require that certain data remain readable and unchanged for many years. These obligations continue to apply even if the underlying system has long since been decommissioned.
| Legal Basis | Data Subject to Retention | Retention Period |
|---|---|---|
| Section 257 of the German Commercial Code (HGB), Section 147 of the German Fiscal Code (AO) | Books, annual financial statements, inventories | 10 years |
| Section 257 of the German Commercial Code (HGB), Section 147 of the German Fiscal Code (AO) (effective 2025) | Accounting documents | 8 years |
| IATF 16949 Section 7.5.3.2.1 | Quality records, production part approvals, tooling records | Product service life plus one calendar year, unless the customer specifies otherwise |
| MDR Article 10, Paragraph 8 | Technical documentation, declaration of conformity | At least 10 years after the last product was placed on the market; 15 years for implants |
In many companies, one distinction tends to be overlooked: None of these regulations require the continued operation of a specific system. They require that the data remain complete, unalterable, machine-readable, and available within a reasonable timeframe. None of these regulations specifies the system in which the data must be stored. This resolves the dilemma. The article “Retention Periods According to the German Commercial Code (HGB), the General Data Protection Regulation (GDPR), and the German Principles of Sound Bookkeeping (GoBD)” provides a comprehensive overview of the retention periods.
|
Common Mistake: “But the server is disconnected from the network” A popular workaround: taking the legacy system offline. On paper, this reduces the risk. But by the time the next customer complaint, tax audit, or audit rolls around, the isolation is lifted again: Someone needs data, so a network cable is plugged in, an access permission is granted, or a USB drive is used. An isolated system without an access policy meets neither the availability requirements of the retention obligation nor the security requirements under NIS2. |
The Cost of Continuing to Operate the System
In addition to electricity and maintenance, there are database licenses, support contracts for outdated platforms, the specialized knowledge of individual employees, and liability risks—all of which extend throughout the entire retention period. NIS2 adds another item to the list: the effort required to plan and implement compensatory measures for each legacy system and to demonstrate compliance to the BSI. The article “Costs of Non-Archiving” describes the consequences of data not being archived at all or being archived incorrectly.
|
WHITE PAPER Data Governance for Structured DataHow to establish binding rules for the retention, access, and deletion of production and historical data, thereby laying the foundation for your NIS2 documentation. |
What options do you have for legacy systems under NIS2?
There are four approaches for each legacy system, and which one is appropriate depends on whether the system still performs a business function or merely stores data. The matrix organizes the options according to their impact on NIS2 obligations.
| Option | Impact on NIS2 obligations | Suitable if | Limit |
|---|---|---|---|
| Continued operation with hardening | Risk decreases but remains | the system is still technically needed and updates are available | Not sustainable in the long term without manufacturer support |
| Isolation and segmentation | Compensatory measure; verification is time-consuming | Replacement is not possible in the short term | Every instance of data access undermines the isolation |
| Migration to a successor system | The legacy system is completely phased out | the data is functionally required in the successor system | expensive if data models are incompatible |
| Archiving and decommissioning | The legacy system is phased out, but data remains available | The system now serves only as a data repository | Requires an audit-compliant archive with an access policy |
In manufacturing companies, many legacy systems end up on the back burner. Production runs on the successor system, while the old MES or test bench computer now only responds to inquiries related to complaints and audits. A complete migration of this historical data is rarely cost-effective because data models, master data, and keys do not match the successor system. With archiving, this is not an issue: it takes the data in its original structure and makes it readable independently of the source system.
The guide “Decommissioning Legacy Systems in Manufacturing ” describes in detail how the decommissioning process works from both a technical and organizational perspective.
Archiving Instead of Continuing Operation: What Must a NIS2-Compliant Archive Be Capable Of?
The archive itself must address the shortcomings of the legacy system. Otherwise, the risk simply shifts from one system to the next. Section 30 of the BSIG and the retention requirements establish six requirements for an archive of legacy data:
- Independence from the source system: The archive must keep the data readable without the original application, database, or license. Only then can you actually decommission the legacy system.
- Audit-proof: Archived data records must not be altered or deleted without being noticed. Every action must be traceable.
- Role-based access control: Departments such as Quality, Purchasing, or Controlling are granted exactly the level of access they need—and no more. This is covered by Section 30(2)(9) of the BSIG.
- Logging of all accesses: Who accessed or exported which data, and when? These logs serve as your proof for the BSI, auditors, and tax examiners.
- Deletion Policy After Retention Period Expires: Once the retention period ends, it must be possible to delete data in a targeted manner. This closes the gap with the GDPR and reduces the volume of data that must be protected.
- Well-maintained platform: The archive itself must receive security updates, be integrated into your backup strategy, and be listed in the asset inventory.
If the archive meets these six criteria, you’ll have a controlled data set instead of an unprotected legacy system. For the business unit, this often means only a change in the access method. The article “Archive Access Without an IT Ticket” shows how this works without an IT ticket.
Before and After: What’s Changing for NIS2 Documentation
| Criterion | Legacy system still in operation | Data in the archive, legacy system decommissioned |
|---|---|---|
| Attack surface | Operating system, database, and application with known vulnerabilities | A well-maintained system with defined access |
| Vulnerability management | Not possible; no patches available | Regular patch cycle for the archive platform |
| Access logs | Aggregate accounts, no logs | Roles based on individuals, complete logging |
| Recovery | Dependent on legacy hardware and specialized knowledge | Part of the regular backup and recovery plan |
| Verification for the BSI | Justify compensating measures for each system | A documented archiving process for all legacy data |
Why doesn’t a backup under NIS2 replace an archive?
Section 30(2)(3) of the BSIG explicitly mentions backup management. It does not follow from this that a complete backup of the legacy system is sufficient for both retention and security purposes. Backups and archiving serve different purposes.
A backup is a copy of the current state intended to restore operations following a failure. An archive is a permanent, unalterable data repository that can be systematically searched and analyzed over the course of years. For legacy systems, this means that if you only have a backup, you need the source system for every request in order to restore the backup. The vulnerable legacy system therefore remains in operation.
| Feature | Backup | Archive |
|---|---|---|
| Purpose | Restoring operations after an incident | Long-term preservation and analysis of data |
| Time Horizon | Days to months; generations are overwritten | Years to decades, until the retention period expires |
| Access to individual data | Requires a full system backup | Targeted search and retrieval of individual data records |
| Dependence on the source system | High; source system required for backup | None; data can be read independently |
| Contribution to § 30 BSIG | No. 3 Maintenance of operations | Nos. 5 and 9, since the legacy system can be eliminated |
Both are part of a NIS2 strategy. The backup protects your production systems and the archive itself, and only the archive makes it possible to decommission legacy systems. For a detailed comparison, see the article “Backup vs. Archiving.”
How do you decommission legacy systems in five steps to ensure NIS2 compliance?
Each of the five steps generates documented evidence that you can incorporate directly into your NIS2 risk management process.
Step 1: Take inventory of legacy systems
Record every system that is no longer actively being developed: servers, databases, test bench computers, and virtual machines. Document the operating system, database version, vendor support, network connectivity, and the person responsible. The result also serves as your asset management record in accordance with Section 30(2)(9) of the BSIG.
Step 2: Clarify technical roles
For each system, ask: Does it still perform an operational function, or does it now serve only as data storage? Systems in the second category are candidates for archiving and decommissioning.
Step 3: Assign Retention Requirements
Assign the legal basis and retention period to each dataset. Consult with the quality assurance, finance, and legal departments to determine which data must be available, for how long, and to whom. This will result in a roles-based concept and a deletion plan.
Step 4: Archive and validate data
Transfer the data to the archive, preserving its structure and relationships. Verify completeness by checking record counts and conducting spot checks with the business units. Document the verification process, as this evidence will be important later during the audit.
Step 5: Decommission the legacy system and provide documentation
Shut down the legacy system, remove it from the network and domain, and delete it from the active inventory. Record the date, management approval, and archiving documentation. This will allow you to demonstrate to the BSI that the risk has been eliminated.
“Organizations are required to implement appropriate, proportionate, and effective technical and organizational measures.”
Section 30(1) of the BSIG, summarized in essence
“Effective” means that the measure measurably reduces the risk. A decommissioned system no longer has any exploitable vulnerabilities, which segmentation or hardening cannot achieve. For pure data storage systems, decommissioning after archiving is therefore generally the strongest response to NIS2.
The Role of Management
Section 38 of the BSIG requires senior management to approve risk management measures and oversee their implementation. If senior management violates these obligations, it is liable to the organization in accordance with corporate law. Consequently, the decision on whether a known, unprotected legacy system continues to operate is no longer made by IT alone. Submit the inventory list from Step 1 to management with a clear recommendation for each system and have the decision formally approved and documented.
The article “Audit Readiness in Manufacturing” describes how to quickly establish the entire audit trail for audits.
How does CHRONOS support NIS2 implementation for legacy data?
CHRONOS is the module for audit-compliant long-term archiving in the Manufacturing OS. It transfers data from databases and legacy systems to a standalone archive, allowing companies to decommission their source systems without losing access to their data.
|
PRODUCT CHRONOS in the NIS2 Context
|
This addresses the areas of the audit matrix where legacy systems fall short: The vulnerability issue is eliminated upon decommissioning; access control and logging are handled by the archive; and deletion after the retention period ends reduces the volume of data you need to protect. The KLS Martin Group case study demonstrates how a medical technology company secures its application data using CHRONOS.
CHRONOS does not replace an information security management system or reporting processes under Section 32 of the BSIG. It addresses a clearly defined part of the NIS2 requirements: the secure handling of legacy data and the decommissioning of vulnerable legacy systems. You can find an overview of features and use cases on the CHRONOS Data Archiving page.
You don’t need a major RFP to take your next step. Start with the legacy system that has gone the longest without updates and now only stores data. Once it’s archived and decommissioned, you’ll have completed the first row of your NIS2 audit matrix and will have solid evidence to present to the BSI.
Frequently Asked Questions About NIS2 and Legacy Systems
Do manufacturing companies fall under NIS2?
Yes, provided they belong to one of the six manufacturing sectors listed in Annex 2 of the BSIG, such as mechanical engineering, motor vehicles and motor vehicle parts, electrical equipment, or medical devices. They are considered critical infrastructure if they have 50 or more employees or an annual turnover and balance sheet total of more than 10 million euros.
Do legacy systems have to be taken offline under NIS2?
NIS2 does not prohibit legacy systems. However, Section 30 of the BSIG requires appropriate measures, including vulnerability management. For systems without security updates that now only store data, archiving followed by decommissioning is generally the most effective and easiest-to-document solution.
Is it sufficient to disconnect a legacy system from the network?
Only as a temporary measure. Disconnecting a system from the network is a compensatory measure that is suspended whenever data is accessed. It does not meet the availability requirements of the retention obligations nor does it constitute a documented access concept as required by Section 30(2)(9) of the BSIG.
Does a backup under NIS2 replace archiving?
No. A backup restores operations after a failure and requires the source system for each restore. An archive keeps data permanently available and searchable, independent of the source system. Only the archive allows the legacy system to be taken offline.
Who is liable if legacy systems violate NIS2 requirements?
According to § 38 BSIG, management must approve risk management measures and oversee their implementation. If management violates these obligations, it is liable to the organization under the rules of corporate law. In addition, fines may be imposed under § 65 BSIG.
How long must archived production data be retained?
That depends on the legal basis. The German Commercial Code (HGB) and the German Fiscal Code (AO) require up to 10 years; IATF 16949 requires the product’s service life plus one calendar year; and the Medical Device Regulation (MDR) requires at least 10 years after the last placing on the market, or 15 years for implants.
What is the penalty for violating § 30 of the BSIG?
For critical facilities, § 65 of the BSIG provides for fines of up to 7 million euros; for those with total revenue exceeding 500 million euros, fines of up to 1.4 percent of global revenue. For particularly critical facilities, the limits are 10 million euros or 2 percent.
|
YOUR NEXT STEP Decommission Legacy Systems, Retain DataThis white paper shows you how to systematically migrate legacy data into a data governance framework. In the demo, you’ll see how CHRONOS archives data from your legacy systems in an audit-compliant manner. |
Responsible for strategy and innovative software solutions for the manufacturing industry.
