EU Cyber Resilience Act — FAQ for Taiwanese Manufacturers

Yes — if you place products with digital elements on the EU market, CRA applies to you regardless of where your company is headquartered. "Placing on the market" means making a product available to EU customers for the first time, including through distribution partners, online stores, or resellers operating in the EU.

There is no exemption for non-EU origin. The regulation follows the product, not the manufacturer's location.

CRA covers any product that contains software or firmware and can connect to a network or another device — directly or indirectly. For Taiwanese manufacturers this includes:

• NAS devices, routers, switches, and network equipment
• IoT sensors and gateways
• Industrial PCs and embedded controllers
• Consumer electronics with connectivity (cameras, displays, wearables)
• Software products sold or licensed to EU customers

Excluded: products covered by sector-specific regulations with equivalent requirements (some medical devices, aviation components).

If you export hardware to the EU and it has any network capability, assume it is in scope until proven otherwise.

No — and this is the most critical misconception for Taiwanese manufacturers.

Under CRA, the manufacturer bears primary responsibility for cybersecurity requirements regardless of who handles distribution or CE marking administration. Your EU distributor takes on limited obligations (due diligence checks, not technical compliance) but cannot substitute for the manufacturer's obligations under CRA Articles 13–15.

The specific scenario — "our products are shipped to a European distributor who handles CE marking" — describes the most common arrangement among Taiwanese exporters. It does not transfer legal exposure. If your products are non-compliant, market surveillance authorities pursue the manufacturer. Your distributor will be required to cooperate in identifying you.

We regularly work with manufacturers who discovered this situation when their EU distributor began requiring CRA compliance documentation as a condition of continued orders.

CRA primarily applies to the final product manufacturer placing the product on the EU market. However:

• If your components have independent network connectivity or are classified as "important" under CRA Annex III, obligations may apply to you directly.
• If you supply software components embedded into products placed on the EU market, CRA's supply chain provisions apply.

More importantly: your EU customers will contractually require you to provide SBOMs, vulnerability disclosures, and security documentation for your components. This is already happening across the Taiwanese supply chain as larger manufacturers begin their CRA compliance work.

Prepare now — it is a commercial requirement regardless of direct legal obligation.

• September 2026: Vulnerability reporting obligations take effect — 24-hour reporting to ENISA
• December 2027: Full CRA enforcement — all products placed on the EU market must comply

Products already on the market before December 2027 receive a transitional grace period. Products placed on the market for the first time after December 2027 must comply from day one.

The 15-month gap between the two deadlines is significant: your security processes must be operational before your full technical documentation and conformity assessments are complete.

Yes. EU market surveillance authorities have broad enforcement powers:

• Prohibition on placing the product on the market
• Mandatory withdrawal from the EU market
• Mandatory product recall from end users
• Financial penalties up to €15 million or 2.5% of global annual turnover (whichever is higher)

Enforcement is coordinated at EU level — a decision in one member state applies across all 27.

Products placed on the EU market before December 2027 benefit from transitional provisions. However:

• If you continue selling the same product after December 2027, it must comply
• If you release a significant firmware or software update, you may trigger full compliance obligations
• Vulnerability reporting obligations (September 2026) apply to products already in use

We recommend starting the compliance assessment now for your highest-volume EU products.

An SBOM (Software Bill of Materials) is a complete inventory of every software component, library, and dependency in your product — including open-source components, third-party libraries, and their versions.

CRA requires manufacturers to:

• Generate and maintain an SBOM per product
• Track known vulnerabilities in each component
• Disclose the SBOM to regulators on request
• Use it as the operational foundation for vulnerability management

SBOMs are not a document you produce once — they must be updated with each release. Firmware on hardware products often includes dozens of open-source libraries with no existing inventory. We start every engagement with an SBOM audit.

What transfers well:

• IEC 62443-4-1 → CRA Annex I Part II (secure development lifecycle) — the strongest transfer available. If you are certified under 62443-4-1, your SDL work carries over significantly.
• BSMI certification — you already understand conformity assessment logic. CRA follows the same pattern: technical documentation, Declaration of Conformity, CE marking. Your team already knows this process.
• Common Criteria → relevant for IC design and security chip work (Himax, Realtek ecosystem)
• ISO 27001 → organisational security governance; does not cover product-level requirements

What CRA requires that these certifications do not cover:

• SBOM generation and maintenance at each product release
• ENISA vulnerability reporting (24h/72h/14-day timelines)
• EU Declaration of Conformity under CRA
• EU Authorised Representative appointment

Our engagement starts with a structured gap analysis so existing certified work is not repeated.

CRA compliance is not a one-time audit — it requires ongoing processes embedded in your development workflow:

• SBOM generation: automated at build time (CycloneDX or SPDX format), integrated into CI/CD
• Dependency vulnerability scanning: continuous monitoring against NVD/GHSA/ENISA EUVD
• Vulnerability triage and response: documented process with defined timelines, linked to SBOM
• Security testing in CI: SAST, dependency audits, container scanning as pipeline gates
• Release documentation: automated changelogs linked to CVE remediation records

We design and implement these workflows directly in GitHub Actions, GitLab CI, Jenkins, or similar systems. We do not hand you a checklist.

CRA Article 14 — timelines are non-negotiable and apply from the moment you become aware of active exploitation:

• 24 hours: Notify ENISA of any actively exploited vulnerability in your product
• 72 hours: Initial vulnerability report with preliminary assessment
• 14 days: Detailed technical report

Most Taiwanese hardware manufacturers have no vulnerability disclosure process at all. This is the highest-risk gap: September 2026 enforcement arrives before full CRA enforcement in December 2027.

We help you design a CVD (Coordinated Vulnerability Disclosure) policy, set up the internal triage process, and prepare your team to operate within these timelines.

A typical engagement works in four stages:

1. Assessment: Audit current products, development process, and existing certifications (IEC 62443, BSMI). Map against CRA requirements. Produce written gap analysis with priorities.
2. Workflow integration: Design and implement SBOM generation, vulnerability tracking, and CI/CD pipeline changes — turning CRA into an operational workflow, not a documentation exercise.
3. Documentation and legal: Prepare the technical documentation CRA requires, work alongside your legal team (or connect you with EU lawyers we work with), handle translation of technical documents for EU market requirements.
4. Ongoing support: Vulnerability monitoring, annual reviews, support for new product releases, help responding to market surveillance inquiries.

We work remotely. Timezone-friendly scheduling for Taiwanese engagements.

CRA compliance has two sides: technical and legal. Most companies need both.

We work alongside EU-qualified lawyers who specialise in product safety and CE marking. We handle the technical translation (turning engineering reality into the documentation lawyers need) and coordinate between both sides so you are not managing two separate tracks.

CRA technical documentation must be available in the official language(s) of each EU member state where your product is sold. We handle translation of:

• Technical documentation (security risk assessments, test reports, vulnerability management records)
• Declaration of Conformity
• User-facing security information

We also help you appoint an EU Authorised Representative if you have no EU establishment — a CRA requirement for all non-EU manufacturers.

CRA does not replace existing CE marking requirements — it adds mandatory cybersecurity obligations on top of them.

• Radio Equipment Directive (RED): Cybersecurity requirements under Article 3.3(d)(e)(f) effective August 2025. For wireless products (routers, IoT gateways, wireless adapters), RED and CRA overlap significantly — a single technical assessment can satisfy both.
• Machinery Regulation: New regulation (effective January 2027) includes cybersecurity requirements for safety-related control functions. IEC 62443 is referenced.

If your products fall under multiple EU regulations, we map the overlap at the start of the engagement to avoid duplicating compliance work.