EU Cyber Resilience Act (CRA)

EU CRA System Integration: Connecting PLM, SBOM Tools and Polarion

2026.11.13/in EU Cyber Resilience Act (CRA)

Do companies have to replace their existing PLM or deploy an entirely new system to meet CRA cybersecurity requirements?

Not necessarily.

The EU Cyber Resilience Act (CRA) will apply in full from 11 December 2027. The reporting obligations under Article 14 have applied since 11 September 2026, and they also apply to products placed on the market before 11 December 2027.

The CRA does not prescribe any particular software. The real challenge is whether a company can link product information, security requirements, vulnerability handling and test records, and provide traceable, auditable technical documentation.

📌 Three key management priorities under the CRA

🔹 Tracing vulnerability impact: When a vulnerability is found in a software component, if the SBOM is already linked to product versions and the BOM, the affected firmware versions and product models can be narrowed down more quickly. If ERP/shipment data is also connected, it can further help identify the customers who received the affected shipments.
🔹 Auditable cybersecurity documentation: Link cybersecurity risk assessments, security requirements, test and verification records, and SBOMs to support the preparation of CRA technical documentation.
🔹 Ongoing post-market management: Throughout the support period, keep recording vulnerability handling, security updates and product version changes.

🔍 Is your company facing any of these challenges? (Illustrative common industry scenarios, not legal requirements)

🔸 Part numbers, BOMs and engineering changes are managed in Agile PLM or Teamcenter.
🔸 SBOMs are produced by different R&D teams, with inconsistent versions and formats.
🔸 Vulnerability information is passed around by email, making assessment and remediation status hard to track.
🔸 Security requirements and test results are scattered across Excel files and other documents.
⚠️ When a vulnerability occurs, departments have to cross-check data manually to identify the affected products.

💡 How can you build a CRA traceability architecture on top of your existing systems?

We recommend letting three types of systems each play their own role:
🔹 PLM | Oracle Agile PLM / Siemens Teamcenter: Keep your existing processes for managing part numbers, BOMs, product versions and engineering changes.
🔹 SBOM tools | Syft + OWASP Dependency-Track: Generate SBOMs with Syft (output in CycloneDX format for import into Dependency-Track); Dependency-Track then continuously checks components against known vulnerability data sources to analyse software component risk.
🔹 ALM | Siemens Polarion: Manage cybersecurity risk assessments, security requirements, remediation tasks, test and verification, and electronic sign-off records (configured according to project templates and workflows) to establish a traceable management process. Anselm (安盛資訊) has developed an integration between Dependency-Track and Polarion, which can be combined with CI/CD pipelines to bring vulnerability analysis results into Polarion for assessment and tracking.
With appropriate system integration, companies can establish:
Product version ↔ SBOM components ↔ Vulnerability assessment ↔ Security requirements ↔ Test and verification
reducing the reliance of vulnerability handling on manual searches and scattered documents.

✅ Anselm has developed a data integration between Polarion and Oracle Agile PLM, so companies can go on to plan a CRA product cybersecurity traceability architecture while keeping their existing PLM management processes. The actual integration approach is planned according to each customer’s existing systems and data structures.

Companies can also refer to the IEC 62443-4-1 secure development lifecycle process to build, step by step, a cybersecurity management framework suited to their own products. IEC 62443-4-1 is not currently listed as a CRA harmonised standard.

⚠️ CRA compliance is not about how many systems you replace. It is about making the data across your systems linkable, traceable and auditable.

👉 Want to learn how to integrate your existing PLM, SBOM tools and Polarion to build product cybersecurity traceability?

Get in touch with Anselm.

📩 Contact Anselm: sales@anselm.com.tw

Further reading: Previous article: EU CRA Vulnerability Handling and Support Period: Ongoing Post-Market Responsibilities | This is the final article in the series: Back to the EU CRA series overview

This article is for general information only and does not constitute legal advice. Product capabilities are subject to each vendor's public documentation and the actual version and licence plan. Official sources: Regulation (EU) 2024/2847 (Recital 8; Articles 13(8), 14, 69(3) and 71(2); Annex VII); Siemens Polarion Cybersecurity; Polarion X 2512: What's New and Noteworthy; Siemens Polarion on CRA compliance; OWASP Dependency-Track file formats; Anchore Syft.

EU CRA Vulnerability Handling and Support Period: Ongoing Post-Market Responsibilities

2026.11.13/in EU Cyber Resilience Act (CRA)

Once a product has shipped, or has even been discontinued, is the manufacturer still responsible for security updates?

The EU Cyber Resilience Act (CRA) will apply in full from 11 December 2027. The CRA explicitly requires manufacturers to keep managing vulnerabilities and providing the necessary security updates during a product’s support period. Placing a product on the market does not mean its cybersecurity responsibilities end there.

For products placed on the market from 11 December 2027, the manufacturer must still handle vulnerabilities and provide security updates during the support period, even if the model has been discontinued. The reporting obligations for actively exploited vulnerabilities (Article 14) are not limited by the support period and, since 11 September 2026, also apply to products placed on the market before 11 December 2027.

📌 CRA vulnerability handling and support period: key points (summary)

🔹 Vulnerability handling and disclosure: Establish a coordinated vulnerability disclosure (CVD) policy and an external reporting channel, so that vulnerability reports can be risk-assessed, remediated and tracked once received.
🔹 Security updates: As a general rule, security updates should be provided free of charge (exception: a separate agreement between the manufacturer and a business user for a tailor-made product) and, where technically feasible, released separately from functionality updates, so that users can fix vulnerabilities in time.
🔹 Product support period: The support period shall reflect the time the product is expected to be in use, taking into account factors such as reasonable user expectations and the nature and intended purpose of the product. It is at least 5 years as a general rule; a shorter period may be set only where the product is expected to be in use for less than 5 years. The basis for this determination must be recorded in the technical documentation. At the time of purchase, the manufacturer should indicate the end date of the support period (at least the month and year) in a clear, understandable and easily accessible way.
🔹 Availability of security updates: Each security update issued during the support period must remain available for at least 10 years after it is issued, or until the end of the support period if that is longer, whichever is longer.
🔹 Vulnerabilities in third-party components: When a vulnerability is found in a third-party or open-source component integrated in the product, the manufacturer must report it to the person or entity manufacturing or maintaining the component, and handle and remediate it in its own product in line with the CRA vulnerability handling requirements. If the manufacturer has developed a fix, it should share the relevant code or documentation with the component's maintainer.

🔍 Is your company also facing these issues? (Illustrative common industry scenarios, not legal requirements)

🖥️ Industrial PCs (IPC): Products may stay in use for 5 years or more, and customers may still be running them in the field after they have been discontinued. When a firmware vulnerability is found, which models and versions still need support?
🌐 Networking equipment: Firmware needs long-term maintenance, but different customers may be running different versions. How do you confirm the patch and update status of each version?
🔋 Energy storage systems (ESS): Systems such as the EMS and BMS need long-term operation and maintenance. When a security vulnerability occurs, how do you track the patching, verification and deployment records?

💡 How should companies prepare?

We recommend setting up management mechanisms in three areas:
✅ Set up a PSIRT contact point: Receive vulnerability reports through a single channel and define the assessment, remediation, verification and release process.
✅ Clearly define support periods: Manage support end dates by product model and expected period of use.
✅ Build version and vulnerability traceability: Link vulnerabilities, affected components, firmware versions, security updates and test records.
⚠️ The CRA is not only about releasing patches. It is about knowing, on an ongoing basis, the vulnerability handling and security update status of every product version.

👉 Want to learn how to set up a vulnerability management process, product support periods and security update traceability?

Get in touch with Anselm (安盛資訊).

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: EU CRA Vulnerability Reporting: 24-Hour Early Warning and 72-Hour Notification | Next article: EU CRA System Integration: Connecting PLM, SBOM Tools and Polarion

This article is for general information only and does not constitute legal advice. Official sources: Regulation (EU) 2024/2847 (Articles 13, 14 and 69 and Annex I Part II); European Commission guidance on CRA implementation.

EU CRA Vulnerability Reporting: 24-Hour Early Warning and 72-Hour Notification

2026.11.13/in EU Cyber Resilience Act (CRA)

If an actively exploited vulnerability is found in your product, can you submit an early warning within 24 hours?

The reporting obligations under Article 14 of the EU Cyber Resilience Act (CRA) have applied since 11 September 2026. Even products placed on the EU market before 11 December 2027 are covered, as long as the reporting conditions are met.

📌 Four key points on CRA vulnerability reporting

🔹 What has to be reported? Actively exploited vulnerabilities in the product, and severe incidents having an impact on the security of the product. Not every CVE you discover has to be reported.
🔹 24-hour and 72-hour notifications:
・Within 24 hours: submit an early warning, indicating the Member States in which the product has been made available (where applicable). An early warning of an incident must at least indicate whether the incident is suspected of being caused by unlawful or malicious acts.
・Within 72 hours: submit a vulnerability or incident notification with the general information available (for a vulnerability, the nature of the vulnerability and of the exploit; for an incident, the nature of the incident and an initial assessment), the corrective or mitigating measures taken and those users can take, and, where necessary, how sensitive the information is.
Both deadlines run from the moment the manufacturer becomes aware of a vulnerability or incident that meets the reporting conditions, and the notification must be made without undue delay.
🔹 Final report deadlines:
・Actively exploited vulnerability: within 14 days after a corrective or mitigating measure is available.
・Severe incident: within one month after the 72-hour incident notification is submitted.
🔹 Reporting and informing users: Notify the CSIRT designated as coordinator and ENISA simultaneously via the ENISA Single Reporting Platform (SRP). The CSIRT designated as coordinator is, as a general rule, the CSIRT of the Member State where the manufacturer has its main establishment in the EU. For manufacturers with no establishment in the EU, it is determined in order by the Member State of the authorised representative, the importer, the distributor and so on. Manufacturers must also inform impacted users (and, where appropriate, all users) and, where necessary, describe the mitigating and corrective measures users can take.

🔍 Is your company facing this kind of challenge?

Suppose an open-source component used in an industrial PC (IPC)'s firmware is actively exploited by attackers. The cybersecurity and R&D teams need to establish quickly:
✅ Which firmware versions use the component?
✅ Which product models are affected?
✅ Which customers have these products been shipped to?
✅ Which functional or security tests need to be re-verified?
If component, firmware version, product model and customer data are spread across different systems, it may be hard to complete the impact analysis quickly, even once the vulnerability has been found. Networking equipment and energy storage systems (ESS) face the same challenge.

💡 How can companies prepare in advance?

1️⃣ Build product traceability links: Map "software component → firmware version → product model → customer shipped to".
2️⃣ Set up a vulnerability assessment mechanism: Clearly record when you became aware, the evidence of exploitation, the affected products and the basis for your decisions.
3️⃣ Prepare for reporting in advance: Designate a reporting contact (an Assigned Representative on the SRP) and have them create a personal EU Login account with MFA in advance; get familiar with the SRP reporting process and confirm which CSIRT designated as coordinator applies. ENISA advises registering on the SRP and starting manufacturer validation only when you actually need to submit a notification; with an active EU Login account, registration takes just a few minutes.
⚠️ Not every CVE has to be reported! When the reporting conditions are met, submit the early warning within 24 hours first; you don't need to wait for the full analysis to be completed.

For manufacturers, CRA reporting is not just the cybersecurity team’s job. It also involves bringing together information from R&D, product management, quality and customer service. SBOMs, product version management and requirements traceability can help companies analyse the scope of a vulnerability’s impact more efficiently, supporting reporting and the subsequent remediation work.

👉 Want to assess your company’s vulnerability impact analysis and product traceability capabilities?

Get in touch with Anselm (安盛資訊).

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: EU CRA SBOM: Which Software and Firmware Do Industrial PCs Need to Track? | Next article: EU CRA Vulnerability Handling and Support Period: Ongoing Post-Market Responsibilities

This article is for general information only and does not constitute legal advice. Official sources: Regulation (EU) 2024/2847 (Articles 14, 69 and 71); ENISA Single Reporting Platform; ENISA SRP FAQ (questions 9 and 28).

EU CRA SBOM: Which Software and Firmware Do Industrial PCs Need to Track?

2026.11.13/in EU Cyber Resilience Act (CRA)

Do you know how much software and firmware is actually inside an industrial PC?

The EU Cyber Resilience Act (CRA) will apply in full from 11 December 2027. Annex I Part II of the CRA (vulnerability handling requirements) requires manufacturers to identify and document the components and vulnerabilities in their products. This includes drawing up an SBOM (software bill of materials) as the basis for vulnerability management and impact analysis.

📌 Three key points on CRA SBOMs

✅ A commonly used, machine-readable format: The SBOM must cover at least the top-level dependencies of the product. The CRA does not prescribe a format; CycloneDX and SPDX are commonly used in the industry. The Commission may later specify the format and content through implementing acts.
✅ Part of the technical documentation: The SBOM must be included in the technical documentation, but it does not have to be made public. Market surveillance authorities may request it with a reasoned request.
✅ Supporting vulnerability management: Knowing your software components and versions helps you quickly identify affected products.

🔍 What should be inventoried in an industrial PC (IPC)?

The software and firmware in an industrial PC often come from different departments and suppliers:
🔹 BIOS/UEFI: low-level system firmware
🔹 BMC: remote management controller firmware
🔹 Windows/Linux: operating system and related packages
🔹 Drivers/utilities: hardware drivers and management tools
🔹 Wi-Fi/LTE modules: third-party communication module firmware
Other products face the same challenge:
🌐 Networking equipment: Linux firmware, open-source packages and third-party components.
🔋 Energy storage systems (ESS): software and firmware for the BMS, PCS, EMS, etc.

💡 How can companies set up SBOM management?

We recommend starting with four steps:
1️⃣ Inventory components: Take stock of the software, firmware and third-party components used in the product.
2️⃣ Generate SBOMs: Use tools to generate SBOMs in CycloneDX/SPDX format.
3️⃣ Link to versions: Link each SBOM to product models, firmware versions and shipped versions.
4️⃣ Track vulnerabilities: Continuously track component vulnerabilities and quickly identify affected product versions.
⚠️ The value of an SBOM is not just producing a list. What matters more is ongoing maintenance, version traceability and vulnerability impact analysis.

When a security vulnerability is disclosed in an open-source component, can your company answer straight away: “Which products use this component? Which shipped versions are affected?” That is a key purpose of setting up SBOM management.

👉 Want to plan SBOM and product version traceability that suits your company?

Get in touch with Anselm (安盛資訊).

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: EU CRA Essential Cybersecurity Requirements: From Default Passwords to Security Updates | Next article: EU CRA Vulnerability Reporting: 24-Hour Early Warning and 72-Hour Notification

This article is for general information only and does not constitute legal advice.

EU CRA Essential Cybersecurity Requirements: From Default Passwords to Security Updates

2026.11.13/in EU Cyber Resilience Act (CRA)

Does your product have adequate cybersecurity protection when it leaves the factory?

The EU Cyber Resilience Act (CRA) will apply in full from 11 December 2027. The CRA requires manufacturers to build appropriate security measures into the planning, design, development and production phases, based on the product’s cybersecurity risk assessment (Annex I). After the product is placed on the market, they must keep handling vulnerabilities and providing security updates throughout the support period.

🔹 Five security design priorities in CRA Annex I

✅ No known exploitable vulnerabilities: Products must not contain known exploitable vulnerabilities when they are made available on the market. Checking for vulnerabilities before release is one way to achieve this.
✅ Secure by default configuration: Products ship with a secure configuration and can be reset to their original state.
✅ Access control and data protection: Prevent unauthorised access and protect the confidentiality and integrity of data.
✅ Attack surface reduction: Limit unnecessary external interfaces and services to reduce potential attack risks.
✅ Security update mechanism: Ensure vulnerabilities can be fixed through security updates. Where applicable, automatic security updates should be enabled by default, with an option for users to opt out or postpone them.
📝 Note: Annex I Part I contains 13 requirements in total, and the above are five key points among them. It also includes requirements such as data minimisation, resilience against DoS and logging and monitoring, as well as the vulnerability handling requirements in Part II (such as SBOM and a vulnerability disclosure policy). Each requirement is implemented according to the results of the cybersecurity risk assessment and where applicable.

📌 Does your product carry any of these risks?

🏭 Industrial PCs (IPC)
・The same default password is used on every unit shipped
・The BMC remote management interface is enabled by default
・BIOS/firmware updates are installed without digital signature verification
🌐 Networking equipment
・The management interface can be accessed directly from the internet
・Unencrypted management protocols are used
🔋 Energy storage systems (ESS)
・The EMS remote maintenance interface lacks security protection
・Accounts and operating permissions are not managed by privilege level
⚠️ All of these issues can be addressed at the product design stage through clear security requirements and testing mechanisms.
These are examples of common design risks; the CRA text does not name them one by one. Whether they amount to non-compliance must be judged against Annex I based on the product's cybersecurity risk assessment.

💡 How should companies prepare?

📋 Build end-to-end traceability: Turn the CRA Annex I requirements into actionable security requirements and establish the traceability chain "regulatory requirement → security requirement → design implementation → test and verification".
🔗 Build on existing processes: Companies that have already adopted IEC 62443-4-1/4-2 can build on their existing secure development process and product security requirements, then map them against CRA Annex I to fill the gaps, such as SBOM, vulnerability handling, security updates during the support period and the reporting process. Note: IEC 62443 is not currently listed as a CRA harmonised standard, and conforming to it does not give a presumption of conformity with the CRA. CRA harmonised standards are being developed by CEN, CENELEC and ETSI under standardisation request M/606 (some based on EN IEC 62443) and only give a presumption of conformity once cited in the Official Journal.
🎯 Manage from the design stage: CRA compliance is not just about completing cybersecurity tests. What matters more is that security requirements can be managed, verified and traced from the design stage onward.

👉 Want to learn how to turn CRA requirements into actionable security requirements?

Get in touch with Anselm (安盛資訊).

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: EU CRA Product Classification and CE Marking: Choosing the Conformity Assessment Route | Next article: EU CRA SBOM: Which Software and Firmware Do Industrial PCs Need to Track?

This article is for general information only and does not constitute legal advice. Official sources: European Commission: CRA standardisation.

EU CRA Product Classification and CE Marking: Choosing the Conformity Assessment Route

2026.11.13/in EU Cyber Resilience Act (CRA)

Can your product self-declare conformity with the CRA, or does it need a third-party assessment?

The EU Cyber Resilience Act (CRA) will apply in full from 11 December 2027. Taiwanese manufacturers selling on the EU market need to prepare SBOMs, vulnerability management and cybersecurity test data. More importantly, they first need to confirm:

👉 Which CRA category does your product fall into, and which conformity assessment procedure applies?

📌 The four CRA product categories

🔹 Default products | Self-assessment as a general rule
Products that are not on the CRA lists of important or critical products can, as a general rule, be self-assessed by the manufacturer using the internal control procedure (Module A).
🔹 Important Class I | Self-assessment under conditions
Examples: routers, modems intended for connection to the internet, switches (with a management plane, including managed and smart switches, and bridges such as wireless access points), operating systems.
Where applicable harmonised standards, common specifications or a European cybersecurity certification at assurance level of at least "substantial" have been fully applied, the internal control procedure (Module A) may be used; otherwise a third-party procedure (Module B+C or Module H) is required. No harmonised standards have been published in the Official Journal of the EU yet, so this needs to be monitored in practice.
🔹 Important Class II | Mainly third-party assessment
Examples: firewalls, intrusion detection and prevention systems (IDS/IPS), hypervisors and container runtime systems.
Self-declaration is not possible. A notified body must take part in the assessment (Module B+C or Module H), or a European cybersecurity certification at assurance level of at least "substantial" must be obtained. Open-source software products whose technical documentation is made public are subject to an exception.
🔹 Critical products | Stricter assessment requirements
Examples: smartcards, secure elements, smart meter gateways.
For now they follow the same assessment procedures as Important Class II. If the Commission later adopts a delegated act, certain products may be required to obtain a European cybersecurity certification.
⚠️ Key concept: a product's category depends on its core functionality, not on how many functions it has built in.
・An industrial PC running an operating system is not automatically moved up to Important Class I as a whole device.
・A router with a built-in firewall is not necessarily classified as Important Class II.

👉 Which category does your product fall into?

🏭 Industrial PCs (IPC): General-purpose industrial PCs may often fall into the default category, but their main intended use and core functionality still need to be confirmed.
🌐 Networking equipment: Devices whose core functionality is routing, internet-connecting modem or managed switching are Important Class I. Devices that merely contain a routing or switching module but have a different core functionality are not automatically included. Devices whose core functionality is a firewall or IDS/IPS are Important Class II.
🔋 Energy storage systems (ESS): Communication gateways, energy management systems (EMS) and control equipment should each be assessed individually, based on their own core functionality and scope.

📄 Whatever the product category, you need evidence of conformity

Manufacturers must prepare:
✔️ Technical documentation
✔️ Conformity assessment
✔️ EU declaration of conformity (DoC)
✔️ CE marking
⚠️ The technical documentation and the EU DoC must be kept for at least 10 years after the product is placed on the market, or until the end of the support period, whichever is longer, and be available to market surveillance authorities at any time.

📋 Four tasks companies can start on now

1️⃣ Product cybersecurity risk assessment
2️⃣ Security requirements and traceability
3️⃣ Security verification and test evidence
4️⃣ Software bill of materials (SBOM)
This information is not only needed to pass the CE conformity assessment. It is also an important foundation for future product vulnerability management, version traceability and customer audits.

📢 The technical descriptions of the CRA’s important and critical product categories have been published in Implementing Regulation (EU) 2025/2392 (published in the Official Journal of the EU on 1 December 2025). Companies should confirm their product category early and keep track of the latest information on harmonised standards, certification schemes and notified bodies.

👉 Need help assessing your CRA product category and technical documentation?

Anselm (安盛資訊) helps companies set up product security requirements management, SBOM, vulnerability management and end-to-end requirements traceability, making CRA compliance preparation more systematic.

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: EU CRA: Three Key Dates, and Why Existing Models Matter Too | Next article: EU CRA Essential Cybersecurity Requirements: From Default Passwords to Security Updates

This article is for general information only and does not constitute legal advice.

EU CRA: Three Key Dates, and Why Existing Models Matter Too

2026.11.13/in EU Cyber Resilience Act (CRA)

The CRA applies in phases. Knowing when each phase starts helps companies decide what to prepare first, and early planning matters even more in industries with long product life cycles.

📅 Three key CRA dates

⏰ 11 June 2026 | Provisions on notified bodies start to apply
The provisions on notified bodies start to apply. Companies can find out in advance what resources and procedures product conformity assessment will require.
⏰ 11 September 2026 | Reporting obligations for vulnerabilities and cybersecurity incidents start to apply
When an actively exploited vulnerability is found in a product, or a severe incident having an impact on the security of the product occurs, it must be reported as required. Products placed on the market before 11 December 2027 are also subject to the reporting obligations.
⏰ 11 December 2027 | The CRA applies in full
Products must meet the CRA's essential cybersecurity requirements and complete the conformity assessment and CE marking procedures.
⚠️ Important: the transitional arrangements are determined per individual product, not per product model.
In other words, individual units of the same model placed on the EU market (first made available on the EU market) on or after 11 December 2027 must meet the full CRA requirements.

👉 Do any of these situations apply to your company?

🏭 Industrial PCs: Product life cycles are long, with supply and use often running for more than five years. If a model launched in 2022 is still shipping in 2028, units newly placed on the EU market must comply with the CRA; for units already in operation at customer sites, an actively exploited vulnerability must still be reported as required.
🌐 Networking equipment: Firmware is updated continuously. If a functionality update changes the product's original intended purpose or affects its compliance, it may constitute a substantial modification.
🔋 Energy storage systems: Project delivery lead times are long, so check which applicability phase the actual delivery date falls into.

📋 Recommended approach

Start by identifying models that will still be in mass production or shipping after the end of 2027, check their product versions, SBOMs, vulnerability management and test records, and plan your CRA conformity preparations early.

👉 Want to confirm which of your models need to be prepared first?

Get in touch with Anselm (安盛資訊). We help companies set up traceability for product versions, SBOMs, vulnerabilities and test records.

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Previous article: What Is the EU CRA? Who Counts as a Manufacturer and Which Products Are in Scope? | Next article: EU CRA Product Classification and CE Marking: Choosing the Conformity Assessment Route

This article is for general information only and does not constitute legal advice.

What Is the EU CRA? Who Counts as a Manufacturer and Which Products Are in Scope?

2026.11.13/in EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA) is a cybersecurity regulation for “products with digital elements”. If your products are sold on the EU market, your company in Taiwan needs to understand its role and responsibilities.

📌 Key points of the CRA

🔹 Scope: Hardware and software products that can be connected, directly or indirectly, to a device or a network. Products already covered by their own dedicated legislation, such as medical devices and vehicles, are not subject to the CRA.
🔹 Manufacturer: Whoever places a product on the EU market under their own name or trademark bears the main responsibility, regardless of whether the company is established in the EU.
🔹 Other roles: Importers and distributors have verification obligations; anyone who substantially modifies a product is treated as the manufacturer.

👉 Which role does your company play under the CRA?

🏭 Own-brand industrial PCs: If you sell products under your own brand to European system integrators, your company is the manufacturer.
🔧 ODM manufacturing: The brand customer is the manufacturer, but it will usually ask your company to provide SBOMs, vulnerability information and test records.
🌐 Networking and energy storage equipment: When products are sold through a European agent, the agent acts as the importer and will ask your company for conformity documentation.
⚠️ A single company may hold several roles at the same time, and CRA responsibilities may differ from one product line to another.

📋 Recommended approach
First clarify, product line by product line, whether you act as an “own brand” or as a “contract manufacturer”. Then take stock of the data you will need to provide to customers and authorities, as the basis for your subsequent CRA compliance planning.

👉 Want to understand the roles and responsibilities of each of your product lines under the CRA?
Get in touch with Anselm (安盛資訊). We can help you clarify your product compliance requirements and set up product cybersecurity management and traceability.

📩 Contact Anselm: sales@anselm.com.tw

Further reading: EU CRA series | Next article: EU CRA: Three Key Dates, and Why Existing Models Matter Too

This article is for general information only and does not constitute legal advice.