NIS2 and the Cyber Resilience Act, or CRA, both address cybersecurity. However, they apply to different parties and require different types of evidence.
NIS2 asks: How resilient is your organisation against cyber risks?
The CRA asks: How secure is your product with digital elements throughout its lifecycle?
For many companies, the answer is therefore not “NIS2 or CRA?” It is: Which requirements apply to our role, our products, and our supply chain?
| NIS2 | Cyber Resilience Act (CRA) | |
| Who is affected? | Certain essential and important entities in the sectors covered by the applicable framework | Manufacturers, importers, and distributors of products with digital elements |
| What is the focus? | Protecting the organisation, its network and information systems, and its ability to operate | Ensuring the security of digital products before they are placed on the market and throughout their lifecycle |
| What is at the centre? | Risk management, incident response, supply-chain security, governance, and reporting processes | Secure-by-design, vulnerability management, security updates, technical documentation, and conformity assessment |
| What is the role of the supply chain? | Supply-chain risks and service providers form part of organisational risk management | Components, software, firmware, and known vulnerabilities must be traceable in the product context |
| Who is responsible? | The management of the entity within scope | Above all, the manufacturer of the product; depending on their role, also importers and distributors |
| What must be demonstrated? | Appropriate security measures, processes, responsibilities, and response capability | Product-security requirements, technical documentation, documented processes, and vulnerability management |
NIS2 strengthens organisational resilience. The CRA strengthens product security.
Where a company develops, manufactures, or places digital products on the market and is also within the scope of NIS2, both frameworks may apply in parallel. The precise obligations depend on the company’s sector, its role, its products, and the national implementation of NIS2.
Key Dates at a Glance
| Date | What applies? | What companies should clarify now |
| 1 August 2025 | RED cybersecurity requirements apply to certain categories of internet-connected radio equipment. EN 18031 may be relevant as a harmonised standards series for demonstrating compliance. | Does our product fall within the RED cybersecurity scope? Do we have the necessary technical documentation and evidence? |
| 11 September 2026 | CRA reporting obligations for actively exploited vulnerabilities and severe security incidents apply. | Who assesses vulnerabilities? Who reports, and when? Which product, component, and firmware data are immediately available in an incident? |
| 20 January 2027 | The EU Machinery Regulation 2023/1230 becomes applicable. | Are safety-relevant software, data, and changes in connected machinery adequately protected and documented? |
| 11 December 2027 | The CRA’s main requirements become fully applicable. | Are product development, vulnerability management, technical documentation, and conformity assessment prepared in time? |
CRA Reporting Obligations Apply from 11 September 2026
Manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements within the required deadlines.
This requires more than a reporting address. Companies need clearly defined responsibilities, internal escalation processes, and reliable information on affected products, software versions, firmware versions, components, and deliveries.
If a vulnerability becomes known, the relevant question is not only whether the product is affected. It is also whether the company can quickly determine which product versions, components, customers, or production batches are affected.
BSI TR-03183: A Practical CRA Starting Point
BSI TR-03183 is not an additional legal obligation. It is technical guidance from Germany’s Federal Office for Information Security for manufacturers preparing their products and processes for the Cyber Resilience Act.
The guidance addresses four practical workstreams in particular:
- General cyber-resilience requirements for products
- Software Bills of Materials, or SBOMs
- The handling of vulnerability reports
- Conformity assessment through full quality assurance
BSI TR-03183 does not create a presumption of conformity and does not replace the harmonised European standards that may become relevant for the CRA. It does, however, help manufacturers identify the questions they should already be able to answer in a structured way regarding products, software versions, and security processes.
What This Means for the Component Supply Chain
Three questions are becoming increasingly important for manufacturers and system integrators:
- Which software and firmware are present in which product?
- Which components and versions are affected when a vulnerability becomes known?
- Who can document the path of firmware, key material, and component?
An SBOM describes the software components of a product. It does not automatically show when a particular firmware version was programmed onto a specific physical component.
This is where reliable process documentation complements product documentation. It creates the connection between digital information and the physical component that ultimately enters production.
With btv SEEL®, btv can support technical evidence from the programming stage onward: through traceable firmware transfers, documented component assignment, and controlled process documentation.
Responsibility for the final product, its risk assessment, and its conformity remains with the manufacturer.
What NIS2 and the CRA Share
Although their objectives differ, both frameworks require more than isolated security measures.
What matters is whether a company can manage risks, responsibilities, and processes in a traceable way. This includes, in particular:
- Clearly defined cybersecurity responsibilities
- Risk assessments across products, systems, and supply chains
- Documented processes for vulnerabilities, security incidents, and changes
- Traceable information on components, software, and firmware
- The ability to identify affected products, versions, or batches quickly
- Effective cooperation between engineering, procurement, production, information security, and quality management
For the electronics supply chain, this means that a lot number alone will often no longer be sufficient.
Where software, firmware, or cryptographic keys are relevant, companies need to know which component received which version and under which controlled conditions that process took place.
Where EN 18031 Fits In
EN 18031 specifies cybersecurity requirements for certain radio equipment under the European Radio Equipment Directive, or RED.
The standards series is especially relevant for internet-connected radio equipment and addresses areas such as network protection, protection of personal data, and protection against fraud.
EN 18031 is therefore neither a replacement for NIS2 nor for the CRA. It is a product-law requirement for a specific scope.
Depending on its type, functionality, and route to market, a product may be subject to RED/EN 18031, the CRA, or several requirements at the same time.
Additional Requirements by Industry
NIS2 and the CRA provide the cross-industry framework. Depending on the product, market, and role within the supply chain, additional requirements may apply.
| Your Industry | Additional Requirements to Consider | What This Means for You |
| Automotive | UN ECE R155/R156, IATF 16949, ISO/SAE 21434 | Cybersecurity, software updates, and technical evidence need to work together reliably across the supply chain. |
| Mechanical Engineering and Industrial Applications | EU Machinery Regulation 2023/1230, IEC 62443, and potentially ATEX | For connected machinery, functional safety, cybersecurity, and secure change processes meet directly. |
| Telecommunications | RED / EN 18031 and, where applicable, NIS2 | For connected radio equipment, product security, secure updates, and traceable configurations are central. |
| Medical Technology | MDR/IVDR, IEC 62304, ISO 14971 | Software lifecycle management, risk management, and technical documentation are closely connected to product safety. |
| Semiconductors | EU Dual-Use Regulation, REACH/RoHS, and potentially origin and export requirements | For certain components, technologies, or target markets, origin, end use, and supply routes can be decisive. |
| Aerospace and Aviation | EASA Part-IS, EN 9100, and demanding development and change-evidence requirements | Information security, configuration management, and controlled changes are safety-critical. |
| Defence | EU Dual-Use Regulation, export controls, and security requirements for sensitive information | Sensitive technology, access rights, recipients, and supply routes require particularly strict controls and documentation. |
| EMS | IPC standards, REACH/RoHS, and customer-specific quality and traceability requirements | Material compliance, production quality, and documented process steps are often prerequisites for approval. |
Not every requirement applies automatically to every company in a sector.
Product type, technical functionality, target market, and role – for example as a manufacturer, importer, supplier, operator, or service provider – determine which obligations are relevant.
For mechanical engineering, the EU Machinery Regulation is especially important. It replaces the former Machinery Directive and applies from 20 January 2027. It includes requirements related to protection against corruption and the security of safety-relevant software and data.
For medical devices, the MDR explicitly addresses information security and IT security in its general safety and performance requirements. Guidance for medical-device cybersecurity helps manufacturers assess security throughout the product lifecycle.
What This Means for Your Components
Regulatory requirements do not start only with the finished product.
They begin when components are sourced, stored, programmed, tested, processed, and prepared for production.
The key question is not only:
Is our product secure?
It is also:
Can we demonstrate which component was processed when, with which firmware, and under which controlled conditions?
A reliable foundation includes:
- Unique identification of components, batches, and supply sources
- Documentation of firmware versions and programming times
- Controlled handovers of firmware and key material
- Traceable changes across the process chain
- Fast identification of affected components in the event of vulnerabilities or recalls
- Securely stored components with documented availability and origin
btv combines these requirements with services across the electronics supply chain: from strategic parts management and long-term storage to programming, testing, packaging, and documented provision for manufacturing.
The result is not only line-ready components. It is a stronger data foundation for quality, security, and compliance.
Learn more about btv TAK®
Learn more about btv SEEL®
Learn more about Long-Term Storage
Learn more about Component Services
Frequently asked questions about NIS2 and CRA
btv does not take over the legal conformity assessment of the final product.
With btv SEEL®, however, btv can support technical evidence from the programming stage onward – for example through documented firmware transfers, traceable assignment to components, and controlled process documentation.
This creates a reliable foundation for technical documentation, change management, vulnerability assessment, and targeted recall processes.
Build Technical Evidence in Early
The later missing traceability, firmware documentation, or process evidence is discovered, the more difficult it becomes to reconstruct.
Companies that capture this information in a structured way during sourcing, programming, and provision create a stronger basis for audits, faster responses, and more resilient supply chains.
Talk to us about the evidence your products, components, and processes can already provide today – and which information may still be missing for future requirements.
