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

• Consumer electronics with connectivity (TVs, appliances, wearables, cameras)
• Displays with network interfaces
• Connected vehicle components and automotive electronics
• Industrial equipment and robotics
• Software products sold or licensed to EU customers

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

No. 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.

Large Korean manufacturers typically have the internal resources for governance and legal compliance, but often lack the embedded technical expertise to:

• Implement CRA-compliant DevSecOps workflows at scale
• Automate SBOM generation across multiple product lines
• Integrate vulnerability monitoring into CI/CD pipelines for firmware and embedded software
• Design the internal triage process for ENISA's 24-hour reporting obligation

We work at the engineering layer — alongside existing compliance and legal teams, not replacing them. The technical implementation of CRA is what we specialise in.

For mid-size manufacturers (500M–5B KRW revenue), we often run the full engagement. For larger groups, we work as the technical implementation partner embedded into existing compliance programmes.

• 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 or firmware 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 must be updated with each release. Most hardware manufacturers have never systematically tracked their software components. We start every engagement with an SBOM audit.

ISMS-P (issued by KISA) is a strong foundation for organisational information security and personal data management. It does not cover product-level cybersecurity requirements.

CRA requires cybersecurity to be built into the product itself:

• SBOM generation at each product release
• Vulnerability management built into firmware and software
• ENISA reporting obligations (24h/72h/14-day timelines)
• CE marking under CRA
• EU Declaration of Conformity

None of these are within ISMS-P scope.

Think of ISMS-P as your internal security management system — it tells the market that your organisation manages security well. CRA is the external product certification layer — it tells the market that your products are secure.

We run a structured gap analysis to map exactly what ISMS-P covers and what CRA adds on top.

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 Korean manufacturers have no vulnerability disclosure process mapped to these timelines. 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 (ISMS-P, KC Mark, IEC 62443 if applicable). 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 Korean 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, Declaration of Conformity, and 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 CE marking requirements — it adds mandatory cybersecurity obligations on top of them.

KC Mark certification means you already understand product certification flows. CRA follows similar conformity assessment logic: technical documentation, Declaration of Conformity, CE marking. The security content is new; the process structure is familiar.

• 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.
• IEC 62443 for industrial and automotive products: referenced in CRA Annex I and Machinery Regulation.

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