EU Cyber Resilience Act — FAQ for Japanese 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 Japanese manufacturers this includes:

• Industrial controllers, PLCs, SCADA interfaces
• IoT sensors and gateways (factory automation, building systems)
• Consumer electronics with connectivity (TVs, cameras, wearables)
• Network equipment (switches, routers)
• Embedded software in physical products

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

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

No — and this is the most common misconception among non-EU 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 Articles 13–15.

If your products are non-compliant, market surveillance authorities pursue the manufacturer. Your distributor will be required to cooperate in identifying you.

No. CRA-compliant processes — SBOM generation, vulnerability management, secure development lifecycle — make you stronger under IEC 62443 and ISMS as well. Design for the highest bar (CRA) and both markets benefit.

We structure engagements to avoid duplication. IEC 62443-4-1 maps directly to CRA Annex I Part II (secure SDL). Work done for one standard feeds the other. You do not build two compliance programmes — you build one that satisfies both.

• 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 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. Most hardware manufacturers have never systematically tracked their software components. Firmware often includes dozens of open-source libraries with no inventory. We start every engagement with an SBOM audit.

What transfers well:

• IEC 62443-4-1 → CRA Annex I Part II (secure development lifecycle) — this is the most direct mapping of any certification to CRA. If you are certified under 62443-4-1, your SDL work carries over significantly.
• IEC 62443-2-1 → covers organisational security management, maps to CRA's governance requirements
• ISMS (ISO 27001 / JIPDEC) → strong governance foundation, but product-level requirements are outside its scope
• IPA Secure Development Guidelines → partial overlap with CRA secure development requirements
• JCMVP (Japan Cryptographic Module Validation Program) → relevant for products with cryptographic components; limited CRA overlap
• Common Criteria (CC) → product security evaluation; different scope than CRA's ongoing operational obligations

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. If you use GitHub Actions, GitLab CI, Jenkins, or similar systems, we build the pipelines with you. 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 non-EU 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, ISMS). 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 Japanese 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, 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. CRA applies to software components separately.
• Medical Device Regulation (MDR): Medical devices largely excluded from CRA scope, but software in general wellness or non-medical products from the same manufacturer is not.

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