Two EU cybersecurity laws are changing the terms on which Taiwan companies sell into Europe. The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is a product law: for hardware and software sold on the EU market that connects to a device or network, the manufacturer must meet cybersecurity requirements from design and development through the whole support period; it applies directly in every Member State and, unlike a directive, does not need to be transposed into national law first[1]. The CRA's main obligations apply from 11 December 2027, but the duty to report "actively exploited vulnerabilities" and "severe incidents" has applied since 11 September 2026, and it covers products already placed on the market before December 2027 as well[1].

The NIS2 Directive (Directive (EU) 2022/2555) instead regulates medium-sized and larger organizations that provide services or operate in the EU, in sectors such as energy, transport, health, digital infrastructure and manufacturing, and takes effect through each Member State's national law[2]. As a rule it does not bind Taiwan companies directly, but it requires those organizations to manage supply chain security[2], so European customers write the requirements into contracts and questionnaires that end up with their Taiwan suppliers.

This article is for Taiwan manufacturers, software and IoT vendors selling into the EU, and for Taiwan suppliers to European customers in NIS2 sectors. It is based on the official EU legal texts and on Commission and ENISA guidance; it is not legal advice, and for your specific case you should consult an adviser familiar with EU product law.

What the CRA covers: scope, dates and roles

The CRA applies to "products with digital elements" made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That includes software and hardware products and their remote data processing solutions, as well as software or hardware components placed on the market separately[1]. Remote data processing means processing at a distance that the manufacturer designs and develops and without which the product could not perform one of its functions, such as the cloud feature that lets users control a smart home device remotely; websites that do not support the product's functionality are out of scope, and cloud services such as SaaS fall under NIS2[1]. Medical devices, vehicles and aviation products covered by their own legislation, marine equipment, identical spare parts, and products developed exclusively for national security or defense are excluded, and open-source software not supplied in the course of a commercial activity is also out of scope[1]. On 27 July 2026 the Commission published guidance on applying the CRA, with 67 worked examples on scope, open-source software, substantial modification, support periods and reporting; it is not legally binding, but it helps you decide whether your products are in scope[3]. For a Chinese-language primer, the MOEA International Trade Administration's "Global Business Opportunities" section published a summary of the CRA prepared by the Economic Division of Taiwan's mission to the EU in November 2024[4]; rely on the official EU text for the details.

Key dates

The CRA was published in the Official Journal on 20 November 2024 and entered into force on the twentieth day, 10 December 2024; Chapter IV on notified bodies (third-party conformity assessment bodies) has applied since 11 June 2026, the Article 14 reporting obligations since 11 September 2026, and the rest of the Regulation applies from 11 December 2027[1]. Products placed on the market before 11 December 2027 only have to meet CRA requirements if they are substantially modified after that date, but the reporting obligations apply to every in-scope product, whenever it was placed on the market[1].

Wireless products need extra attention: the cybersecurity requirements of the Radio Equipment Directive (RED) Delegated Regulation (EU) 2022/30 have applied since 1 August 2025 to the radio equipment it covers, supported by the EN 18031 series of harmonized standards; in its December 2025 CRA FAQ, the Commission states that the CRA covers those requirements and that it aims to repeal the Delegated Regulation as of 11 December 2027[5].

Which role is your company in?

  • Manufacturer: a person who develops or manufactures products (or has them designed or manufactured) and markets them under its own name or trademark[1]. A Taiwan company selling its own brand into the EU is a manufacturer, even with no EU presence.
  • ODM/OEM: when the product is sold under a European customer's brand, the customer is the manufacturer; an importer or distributor that sells under its own name or trademark, or substantially modifies the product, is also treated as the manufacturer[1]. The contract manufacturer does not carry manufacturer obligations directly, but manufacturers must exercise due diligence when integrating third-party components and must report vulnerabilities they find in a component to whoever manufactures or maintains it[1], so those requirements will flow down to you.
  • Importers and distributors: before placing a product on the market, an EU-established importer must check that the manufacturer has carried out the conformity assessment and drawn up the technical documentation, and that the product bears the CE marking and comes with the declaration of conformity, user instructions, contact details and support-period end date; distributors must check the CE marking and the required documents before selling; both must inform the manufacturer when they learn of a vulnerability[1].

A Taiwan manufacturer with no EU establishment still carries the Article 13 (manufacturer) and Article 14 (reporting) obligations itself. The CRA lets you appoint an EU authorized representative by written mandate, but the core duties, such as designing the product to Annex I, the risk assessment, vulnerability handling and drawing up the technical documentation, cannot be delegated[1].

Manufacturer obligations: from design to end of support

Essential requirements and vulnerability handling (Annex I)

Manufacturers must first carry out and document a cybersecurity risk assessment and apply its results through design, development, production and maintenance[1]. Part I of Annex I requires products, based on the risks, to: be placed on the market without known exploitable vulnerabilities; ship with a secure-by-default configuration that can be reset; allow vulnerabilities to be fixed through security updates, with automatic updates on by default where applicable and an opt-out; prevent unauthorized access through authentication and access control; protect the confidentiality and integrity of data, for example with encryption; minimize data; keep essential functions available, including against denial-of-service attacks, and minimize the product's own impact on other devices or networks; limit attack surfaces; record relevant internal activity; and let users securely and permanently delete data and settings[1].

Part II of Annex I sets out the vulnerability handling process[1]:

  • Draw up a software bill of materials (SBOM) in a commonly used, machine-readable format, covering at least the top-level dependencies
  • Remediate vulnerabilities without delay in relation to the risks; where technically feasible, ship security updates separately from feature updates
  • Test and review product security regularly
  • Once an update is out, publish a description of fixed vulnerabilities with their impact and severity; in justified cases, publication can wait until users have had a chance to patch
  • Put in place and enforce a coordinated vulnerability disclosure (CVD) policy, with a contact address for reporting vulnerabilities
  • Distribute updates securely, and provide security updates and advisories promptly and free of charge (unless otherwise agreed with a business user for a tailor-made product)

The SBOM goes into the technical documentation; the CRA does not require it to be published, and market surveillance authorities can request it where necessary[1]. Manufacturers must also designate a single point of contact so users can reach them directly and quickly, including to report vulnerabilities[1]. For SBOM practice, see supply chain attacks.

Support period

The support period must reflect how long the product is expected to be in use and must be at least five years; only products expected to be used for less than five years may have a correspondingly shorter period[1]. The end of the support period, at least month and year, must be clearly stated at the time of purchase; each security update must remain available for at least 10 years after release or for the rest of the support period, and the technical documentation and declaration of conformity must be kept for at least 10 years or for the support period, whichever is longer in each case[1]. When setting the support period you may take into account the support periods of integrated third-party components that provide core functions and the availability of the operating environment[1]; for Taiwan hardware makers, the vendor support lifetimes of chip SDKs, operating systems and third-party modules directly cap what you can commit to.

Technical documentation, conformity assessment and CE marking

Before placing a product on the market you must draw up technical documentation covering at least the product and design description, the vulnerability handling process (including the SBOM and CVD policy), the risk assessment, the basis for the support period, the standards applied and test reports; after the conformity assessment, you sign the EU declaration of conformity and affix the CE marking[1]. The assessment route depends on the product category:

  • Default products: most products can be self-assessed by the manufacturer[6].
  • Important products, class I (Annex III): for example identity and access management systems, browsers, password managers, anti-malware software, VPNs, SIEM, operating systems, physical and virtual network interfaces, routers and switches, microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities, and smart home products with security functions such as smart door locks and security cameras. Self-assessment is allowed when harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level "substantial" or higher are applied in full; otherwise a notified body must be involved[1].
  • Important products, class II: hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers require a notified body assessment or European cybersecurity certification[1].
  • Critical products (Annex IV): hardware devices with security boxes, smart meter gateways, and smartcards and secure elements need European cybersecurity certification where the Commission requires it by delegated act, and otherwise follow the class II procedures[1].

The technical descriptions of each category are set by Implementing Regulation (EU) 2025/2392[6]. Integrating an Annex III product (for example a microcontroller with security functions) into your own product does not, on that basis alone, make the whole product subject to the important-product assessment procedures[1].

Penalties and harmonized standards

Breaching Annex I or the manufacturer obligations in Articles 13 and 14 carries fines of up to EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher; breaching importer or distributor obligations or the rules on declarations of conformity, CE marking and similar provisions, up to EUR 10 million or 2%; and supplying incorrect, incomplete or misleading information in reply to a request from notified bodies or market surveillance authorities, up to EUR 5 million or 1%[1].

Presumption of conformity comes from three routes: harmonized standards published in the Official Journal, common specifications set by the Commission, and certificates or statements of conformity under a European cybersecurity certification scheme[1]. The Commission has issued standardization request M/606 for 41 horizontal and vertical standards supporting the CRA, prioritizing important and critical products; on 10 November 2026 it extended the delivery deadline for all vertical standards and some horizontal standards by three months[7]. For class I important products, if you have not applied harmonized standards, common specifications or a certification scheme in full, you must go through a notified body[1], so the pace of standardization directly affects certification timelines.

Vulnerability and incident reporting: in force since September 2026

When a manufacturer becomes aware of an actively exploited vulnerability in its product (one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission), or of a severe incident affecting the product's security, it must notify the CSIRT designated as coordinator and ENISA simultaneously through the Single Reporting Platform (SRP) run by ENISA[1]. A severe incident is one that affects or could affect the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code being introduced or executed in the product or in users' systems[1]. Reporting has three stages[1]:

  1. Within 24 hours, early warning: state the Member States where you know the product has been made available; for a severe incident, also say whether it is suspected to be caused by malicious acts.
  2. Within 72 hours, notification: describe the affected product, the general nature of the vulnerability or incident, the measures taken, and the mitigations users can apply.
  3. Final report: for a vulnerability, within 14 days after a corrective or mitigating measure is available; for a severe incident, within one month of the 72-hour notification, including the root cause and mitigation measures.

Manufacturers must also inform affected users and tell them what mitigations they can apply[1]. SRP vulnerability fields include the CVE and European Vulnerability Database (EUVD) identifiers[8]; for how to read those identifiers and scores, see CVE, CVSS, EPSS and KEV.

No EU establishment: who do you report to?

Notifications go to the CSIRT of the Member State where the manufacturer has its main EU establishment. A manufacturer with no EU establishment looks, in order, at the Member State of the authorized representative acting for most of its products, then of the importer placing most of its products on the market, then of the distributor selling most of its products, and finally the Member State with the most users of its products; each step applies only if the previous one does not[1]. If you select the wrong CSIRT, the notification may be invalidated and need resubmitting; even a group with several EU subsidiaries reports each vulnerability or incident only once, and the manufacturer coordinates internally[8].

Current status of the SRP

The Commission says the SRP has been operational since 11 September 2026[9]; ENISA deployed the platform's initial operating capability that day and upgraded it to version 1.3 on 4 November 2026[10]. At the time of writing (14 November 2026), ENISA's status page shows the platform as available[11]. According to ENISA's FAQ, the people submitting notifications for a manufacturer must use personal EU Login accounts with multi-factor authentication, which can be created in advance; the initial release has no API, so notifications are entered through the platform interface; and vulnerabilities whose active exploitation the manufacturer knew about before 11 September 2026 need not be reported retrospectively, while those it learns about afterwards must be reported even if the vulnerability itself is older[8].

NIS2: not aimed at Taiwan companies, but written into contracts

NIS2 required Member States to adopt and publish national law by 17 October 2024 and apply it from 18 October 2024[2]. As a rule it applies to medium-sized and larger organizations of the types listed in Annexes I and II that operate in the EU; the manufacturing sectors in Annex II cover medical devices, computer, electronic and optical products, electrical equipment, machinery, motor vehicles and other transport equipment[2]. For infringements of Article 21 or 23, national fines must reach a maximum of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher[2]. For Taiwan companies, three situations arise:

  • You have an EU subsidiary: if it is in one of those sectors and meets the size threshold, the subsidiary itself may be in scope under the national law where it is established[2].
  • You provide cloud, data center, managed services (MSP) or managed security services (MSSP): if you are not established in the EU but offer services there, you must designate a representative in the EU[2].
  • You are an ordinary supplier: you are not regulated directly, but your customers' supply chain obligations reach you through contracts and questionnaires.

Articles 21 and 23: what customers will ask of you

Article 21 requires regulated entities to take cybersecurity risk-management measures including at least incident handling, business continuity, supply chain security, security in system acquisition, development and maintenance (including vulnerability handling and disclosure), and multi-factor authentication; when choosing supply chain measures they must consider each direct supplier's vulnerabilities, product quality and cybersecurity practices, including secure development procedures[2]. Recital 13 of the CRA also notes that these measures may require entities to use products meeting stricter cybersecurity requirements than the CRA[1].

For cloud, data center, MSP, MSSP, online marketplace and trust service providers, among others, Implementing Regulation (EU) 2024/2690 spells out what supplier contracts should specify: cybersecurity requirements for the supplier, prompt notification of incidents that put the customer at risk, a right to audit or to receive audit reports, an obligation to handle vulnerabilities, and requirements for subcontractors; when acquiring critical ICT products, entities must also set security update requirements for the full lifetime and obtain a description of hardware and software components[12]. Customers in other sectors are not bound by this regulation, but it is a good guide to what their questionnaires will ask.

Article 23 requires regulated entities to submit an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month[2]. To meet the 24-hour deadline, your customer needs to hear from you quickly, so check before signing that you can meet the notification time in the contract.

Transposition status

The competent authorities, reporting channels and details depend on each country's national law. The Commission's transposition page (last updated 1 July 2025) records that on 7 May 2025 the Commission sent reasoned opinions to 19 Member States for failing to notify full transposition[13]; that is a snapshot, so check the country pages there and the local authority's announcements. The Commission also proposed targeted amendments to NIS2 on 20 January 2026[14]; until amendments complete the legislative process and take effect, the current Directive and national laws apply.

Preparation steps for Taiwan companies

  1. Determine your role and product categories: list the products you sell into the EU and check whether each is a product with digital elements, whether you are the manufacturer or a contract manufacturer, whether it falls under Annex III or IV (per the technical descriptions in Implementing Regulation (EU) 2025/2392[6]), and which importers and distributors sell it. This list determines your conformity assessment route and which country's CSIRT you report to[1].
  2. Set up a PSIRT and a disclosure policy: FIRST defines a product security incident response team (PSIRT) as the function that identifies, assesses and disposes of the risks of security vulnerabilities in the organization's products, and says it should be part of the secure development lifecycle[15]. When publishing your CVD policy and reporting channel, consider RFC 9116 security.txt: place it under the website's /.well-known/ path, and always include the Contact and Expires fields[16].
  3. Rehearse 24-hour reporting: decide who judges "actively exploited" and who submits in the SRP, create EU Login accounts in advance[8], and run a tabletop exercise from early warning through the 72-hour notification to the final report.
  4. Generate SBOMs and set support periods: generate an SBOM automatically for every shipped release in your build pipeline and put it in the technical documentation; check that upstream components' vendor support lasts as long as your support period[1].
  5. Map your existing IEC 62443 and ISO 27001 work: the Commission and ENISA pages reviewed for this article do not say that an IEC 62443 or ISO 27001 certificate counts as proof of CRA conformity; the Commission guidance only lists evidence of conformity with ISO/IEC 27001:2022 or 27017:2015 as one reusable assurance artifact when assessing third-party remote services[3]. The practical approach is to map your existing secure development process (for example IEC 62443-4-1), vulnerability handling procedures and documentation against Annex I, item by item, and find the gaps.
  6. Prepare for NIS2 customer questionnaires: assemble answers and evidence on secure development, vulnerability handling, incident notification, audits and subcontractor management in advance[12], and never answer "yes" to a control you do not have; see SOC 2, ISO 27001 and security questionnaires.

Action checklist

  • Inventory the products you sell into the EU and record your role (manufacturer, contract manufacturer, component supplier), the product category, and your EU importers and distributors.
  • Get CRA reporting ready now: name owners, create EU Login accounts with multi-factor authentication, and identify the CSIRT you report to.
  • Set up a PSIRT, publish a CVD policy and vulnerability reporting channel, and designate a single point of contact.
  • Generate an SBOM automatically for every shipped release; set a support period for each product line (at least five years as a rule), confirm upstream components last that long, and state the end month and year.
  • Check default settings, automatic updates, access control, data deletion and logging against Annex I, and list what must be fixed before December 2027.
  • If your products are important or critical, track the M/606 harmonized standards and plan notified body timelines.
  • Build an answer library and evidence folder for NIS2 customer questionnaires, and confirm you can meet the incident notification times in your contracts.
  • For outside help reviewing product weaknesses, see our vulnerability assessment service, and follow supply chain advisories.