Summary

The EU Cyber Resilience Act (CRA — Regulation (EU) 2024/2847) is the first comprehensive product security regulation in EU history, imposing horizontal cybersecurity obligations on every “product with digital elements” (PDE) placed on the EU market. Entering into force on December 10, 2024, the Regulation applies in phases. From September 11, 2026, the Article 14 reporting obligations take effect, requiring manufacturers, importers, and distributors to notify ENISA (the European Union Agency for Cybersecurity) and member state CSIRTs of actively exploited vulnerabilities and severe security incidents within a staged 24-hour, 72-hour, and 14-day deadline structure. If a reporting workflow is not operational by this date, a company risks a fine of up to €15 million or 2.5% of worldwide annual turnover, and a Korean company becomes subject to these obligations the moment it places a product on the EU market.A1,B1,E1

1. Why September 11, 2026 Matters for Korean Companies

September 11, 2026 is the first application date for the CRA’s Article 14 reporting obligations. On the same day, ENISA’s Single Reporting Platform (SRP) also goes live.A1,B4 The CRA’s remaining essential obligations, including CE marking and conformity assessment, are due by December 11, 2027, but the reporting workflow must be in place 15 months ahead of that deadline.

The weight this date carries for Korean companies comes from the CRA’s legal character. The CRA is not a Directive that member states must transpose into national law; it is a Regulation with direct effect, applying immediately upon entry into the EU market without any separate national implementing legislation.A1 A company headquartered in Korea that exports directly to the EU without an EU legal entity does not escape coverage. It is also worth noting that legacy products — products already placed on the EU market — are covered as well.E1

As of June 2026, about three months remain before the reporting obligation takes effect. ENISA has said it will hold a testing period but has not yet released an official schedule, and it has announced that an operations manual will be provided sometime in June 2026. ENISA has also stated explicitly that, at this stage, it does not provide an API for SRP integration.B4 Companies that assumed automated integration will need to redesign their reporting process around manual submission to the platform by a human operator.

2. Structure of the CRA

2.1 Legislative Background and Entry-into-Force Timeline

The CRA’s official title isRegulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. It was first announced in President Ursula von der Leyen’s State of the Union address in September 2021, and the European Commission proposed the legislative text on September 15, 2022. The European Parliament adopted it in plenary on March 12, 2024 by a vote of 517 in favor to 12 against, and the Council gave its final adoption on October 10 of the same year, followed by signature on October 23 and publication in the Official Journal of the EU on November 20. The Regulation entered into force on December 10, 2024.A1,B1

Figure 1. CRA legislative and implementation timeline(Source: Regulation (EU) 2024/2847, EC Legislative Train)

The open source community’s advocacy stood out during the legislative process. During the 2022–2023 drafting stages, the Eclipse Foundation, the Open Source Initiative (OSI), the Document Foundation, and others warned that an unclear definition of “commercial activity” could push compliance burdens onto volunteer developers. The provisional agreement of December 2023 introduced the concept of an “open-source steward” along with exemption clauses, easing some of these concerns, but the scope of coverage for small-scale redistributors remains a matter of dispute.D1

2.2 Scope of Application (Art. 2–3)

The CRA applies to “products with digital elements” (PDE). This covers hardware and software capable of logical or physical data connection to a device or network, and includes software components placed on the market independently.B3

Some products fall outside the scope. The main examples are free and open-source software supplied without commercial activity, and products already covered by stricter sector-specific cybersecurity regulation, such as medical devices or automobiles. Even so, the CRA may apply in a “complementary” capacity to products already subject to existing cybersecurity regulation, so a sector-by-sector judgment is required.A1,E2

Figure 2. CRA scope determination flow(Source: CRA Art. 2–3, Implementing Regulation (EU) 2025/2392)

2.3 Phased Application

Full application of the CRA does not occur at a single point in time.

A1,B3

What must be in place by September 11, 2026 is not product certification but a vulnerability and incident reporting workflow. The deadline for CE marking and conformity assessment is 15 months later, on December 11, 2027.

3. Manufacturer Obligations (Art. 13)

3.1 Annex I Essential Requirements

Article 13 requires manufacturers to meet the essential cybersecurity requirements set out in CRA Annex I. These requirements fall into two broad groups.A1,B3

Part I — Product security requirements: placed on the market without known exploitable vulnerabilities, no default passwords, provision of security updates, application of the principle of least privilege, data protection, minimization of attack surfaces, resilience-by-design, and provision of records of access to and modification of personal data.

Part II — Vulnerability handling requirements: identifying and documenting vulnerabilities, maintaining an SBOM, providing patches promptly and distributing them free of charge, a Coordinated Vulnerability Disclosure (CVD) policy, reporting of exploited vulnerabilities and incidents (Art. 14), and monitoring for vulnerabilities across the full product lifecycle.

No harmonized standards for these requirements have been finalized yet, so manufacturers must implement them directly against the functional requirements in the CRA text itself. TheCRA Requirements Standards Mapping (2024), jointly published by ENISA and the JRC, maps these requirements to existing standards, with ISO/IEC 30111 (vulnerability handling), ISO/IEC 29147 (vulnerability disclosure), and NIST SP 800-218 (SSDF) serving as the main reference points.B5,C1,C2,C6

3.2 Support Period

Manufacturers must provide security support for the product’s expected lifetime after it is placed on the market, for a minimum of five years. For products with an expected lifetime of less than five years, that shorter period may serve as the support period. The support period must be stated explicitly on the product, and vulnerability handling and the provision of security updates are mandatory throughout it.A1,B3

3.3 SBOM Requirements

CRA Annex I Part II mandates a Software Bill of Materials (SBOM). Manufacturers must generate an SBOM for every released version and keep it in a machine-readable format, ready for requests from a Market Surveillance Authority. There is no obligation to disclose the SBOM to third parties, but it must be provided to the Market Surveillance Authority on request.A1

SPDX and CycloneDX have established themselves as the de facto standard formats. SPDX was standardized as ISO/IEC 5962:2021 (based on SPDX v2.2.1; the current specification is v3.0),C3,C4 and CycloneDX, a specification maintained by OWASP, saw ECMA-424 2nd Edition (based on v1.7) published on December 10, 2025.C5 No official CRA-level implementing act for an SBOM schema has been issued as of June 2026. Technical Guideline TR-03183-2 v2.1.0, published in August 2025 by Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI), serves as a practical reference point for field mapping to a CRA-conformant SBOM.G1

4. Reporting Obligations (Art. 14) — Effective 2026-09-11

4.1 Notification Triggers

Article 14 defines two categories of events that trigger a manufacturer’s notification obligation.A1,B2

One is an actively exploited vulnerability. The trigger is not the vulnerability’s mere theoretical existence but the confirmed point at which an attacker is actually exploiting it. The other is a severe incident — an event that has caused, or is likely to cause, serious operational disruption, loss, or damage affecting the security of the product.

Beyond manufacturers, importers and distributors must also notify the manufacturer of relevant information when they discover non-compliance or become aware of an incident.

4.2 The Three-Stage Deadline (24h/72h/14d)

Figure 3. CRA Article 14 reporting deadlines(Source: CRA Art. 14, EC “CRA — Reporting obligations”)

The required content differs at each stage.A1,B2

The CRA text makes clear that the 24-hour deadline does not require vulnerability classification or full resolution. Its purpose is simply to flag the existence of the issue as an early warning. Microenterprises and small enterprises may be exempted from fines for failing to meet the 24-hour deadline.A1

4.3 Single Reporting Platform (Art. 16)

All Article 14 notifications go through the Single Reporting Platform (SRP). Operated by ENISA, the SRP automatically routes a single manufacturer submission to both the coordinator Computer Security Incident Response Team (CSIRT) of the member state where the manufacturer’s main establishment is located and to ENISA itself.B4,A1

In procuring the SRP, ENISA required a forward-looking architecture capable of integrating with the incident and vulnerability reporting systems of NIS2 and DORA. The design goal extends beyond CRA obligations alone, aiming for a platform that can interoperate with adjacent regulatory regimes.

Figure 4. Stakeholder interactions in the CRA reporting system(Source: CRA Art. 13–16, Delegated Regulation (EU) 2026/881)

4.4 Conditions for Delaying CSIRT-to-CSIRT Dissemination (Delegated Regulation 2026/881)

Delegated Regulation (EU) 2026/881, adopted on December 11, 2025 (published in the Official Journal on April 20, 2026), sets out the conditions under which a member state CSIRT need not immediately disseminate a notification it has received via the Single Reporting Platform to other CSIRTs.A2 Delay is permitted where an assessment of the nature of the notified information justifies it, where the receiving CSIRT cannot guarantee the confidentiality of the information, or where the Single Reporting Platform itself has been compromised or is temporarily unable to operate. Beyond that, delay is allowed only for the “period strictly necessary,” and only when the risk cannot be mitigated through tools such as the Traffic Light Protocol (TLP) or the Permissible Actions Protocol (PAP).

The 24-hour deadline for a manufacturer’s notification to a CSIRT is unaffected by this Delegated Regulation. What the Delegated Regulation touches is the further dissemination step between CSIRTs, where it introduces a security-based relief mechanism.

4.5 Parallel Application with GDPR and NIS2

A CRA reporting obligation can arise alongside reporting obligations under other regulations. Where the data compromised by a vulnerability or incident includes personal data, a CRA notification does not substitute for the 72-hour notification obligation to the supervisory authority under Article 33 of the General Data Protection Regulation (GDPR).A5 The two notifications must go through separate channels to separate recipients — the data protection authority on one side, the CSIRT/ENISA on the other.

The same holds for operators of essential and important services covered by the NIS2 Directive (Directive (EU) 2022/2555) that become aware of a vulnerability or incident in their own products. Both a CRA report and a NIS2 report may be required simultaneously. The Digital Omnibus package’s “report once, share many” model is being discussed as a way to unify the two reporting obligations, but it has not yet been settled in legislation.A4,E2

5. Conformity Assessment and CE Marking (2027-12-11)

December 11, 2027 is the deadline for conformity assessment. The pathway differs by risk class. Default-class products may self-assess to issue an EU Declaration of Conformity and affix the CE marking. Important Class I products may either self-assess by applying EU harmonized standards or obtain an assessment from a third-party Conformity Assessment Body (CAB). Important Class II and critical-class products require enhanced examination by a CAB.A1,B3

In February 2025, ENISA publishedCyber Resilience Act implementation via EUCC and its applicable technical elements, analyzing pathways for using EU Common Criteria (EUCC) certification in CRA conformity assessment.B6

From June 11, 2026, the provisions on notification of conformity assessment bodies apply. Each member state must designate a notifying authority by this date, and the accreditation process begins so that a sufficient number of notified bodies to carry out third-party conformity assessment are in place by December 11, 2026.B3

Penalties for non-compliance vary by the type of violation. The most serious violations — failure to meet essential requirements, breach of reporting obligations — can draw a fine of up to €15 million or 2.5% of worldwide annual turnover, whichever is greater, and can also result in an order to withdraw the product from the EU market.A1,E1

6. Standards and Framework Mapping

The CRA sets out only essential requirements and delegates technical detail to harmonized standards. CEN/CENELEC JTC 13 WG 9 is developing European harmonized standards (EN) for the CRA, targeting publication of the horizontal standards by August 30, 2026 and the vertical standards by October 30, 2026. The horizontal standards proceed as the prEN 40000-1 series, consisting of vocabulary (prEN 40000-1-1), principles (prEN 40000-1-2), vulnerability handling (prEN 40000-1-3), and general security requirements (prEN 40000-1-4). The final list of cited standards has not yet been settled, so the table below can be used as a set of candidate mappings for the time being.B5

C1,C2,C3,C4,C5,C6,G1,C7

The European Vulnerability Database (EUVD), implementing Article 12 of the NIS2 Directive, was formally launched by ENISA on May 13, 2025.F1 It can serve as a primary monitoring source for the CRA’s “vulnerability monitoring” requirement. The EUVD uses its own identifier (EUVD-YYYY-NNNNNN) while also recording the corresponding CVE ID and CVSS score. It is a separate system from the SRP: the SRP is the channel through which manufacturers notify authorities, while the EUVD is a public database.B4,F2

7. Recent Developments (2025–2026)

Since entry into force in December 2024, the regulatory landscape has taken shape along three tracks: delegated regulations, implementing regulations, and guidance.

Implementing Regulation (EU) 2025/2392 was adopted on November 28, 2025 and entered into force on December 21. It finalized the technical definitions dividing “important” and “critical” products — as referenced in CRA Annexes III and IV — into 28 categories, placed across the three tiers of Class I, Class II, and critical. This Regulation is the primary legal basis manufacturers use to determine the conformity assessment pathway for their products.A3

Delegated Regulation (EU) 2026/881 was adopted on December 11, 2025 and published in the Official Journal on April 20, 2026. It codifies the conditions under which CSIRT-to-CSIRT dissemination of notifications may be delayed (see §4.4).A2

Guidance documents have arrived in two stages. The Commission’s first official FAQ was published on December 3, 2025 (updated December 19), offering the first — non-binding — clarification of the scope and iterativeness of risk assessment and of the “intended purpose” concept. The first draft guidance under CRA Article 26 followed on March 3, 2026. Running to 75 pages, with roughly a quarter devoted to defining the open-source steward, the draft covered remote data processing solutions, free and open-source software, the support period, and the CRA’s interrelationship with other regulations such as NIS2 and DORA. The consultation closed on March 31, but the final version has not been issued as of June 2026.E3

The open source community’s collective response became visible on April 2, 2024, when seven foundations — the Apache Software Foundation, the Blender Foundation, the Eclipse Foundation, OpenSSL, the PHP Foundation, the Python Software Foundation, and the Rust Foundation — announced they would jointly develop common standards for secure software development. The effort was led by the Eclipse Foundation AISBL in Brussels and evolved, on September 24 of the same year, into the Open Regulatory Compliance Working Group (ORC WG), which published a white paper laying out the scope of a steward’s obligations. OpenSSF published its direction for aligning SBOM standards on October 22, 2025.F3,D1

The most persistent point of contention is the practical value of 24-hour notification. Security researchers, HackerOne among them, have repeatedly argued since 2024 that notifying authorities of a vulnerability’s existence before a patch is ready risks exposing an unmitigated vulnerability.E4 Delegated Regulation (EU) 2026/881 only introduced conditions for delaying CSIRT-to-CSIRT dissemination; it left the manufacturer’s 24-hour deadline to the CSIRT itself untouched.

8. A Korean Company Perspective — What to Do in the Next Three Months

8.1 Determining Whether the CRA Applies

The first step is to determine whether the reporting obligation, due September 11, 2026, applies to the company at all. Check in turn: whether the product is distributed in the EU market, whether the product is a product with digital elements, and whether stricter sector-specific cybersecurity legislation already applies. EU distribution covers direct sales, resale, and OEM supply alike, and the CRA applies even without an EU legal entity if the Korean headquarters exports directly. Software or hardware capable of data connection with a network or a device qualifies as a product with digital elements. Areas already covered by stricter regulation, such as medical devices or automotive safety, may be excluded from CRA application.

Legacy products are covered too. Many companies overlook the fact that the reporting obligation, effective September 11, applies even to products already placed on the EU market.E1

8.2 Preparation Steps

There is no need to have certification in place by September 11. What is needed is a reporting workflow. The company needs a human structure and technical connection able to send an early warning within 24 hours of becoming aware of a vulnerability or incident, and an on-call rotation, decision-making authority, and an external communications owner should all be designated in advance.

A pipeline that automatically generates and retains an SBOM in SPDX or CycloneDX format for every released version is also needed by September 11. The field mapping in BSI TR-03183-2 v2.1.0 can serve as a practical reference.G1

ENISA has stated that it does not provide an API for SRP integration at this stage (as of June 2026). Since the operations manual is expected during June, companies should build a manual submission process rather than assuming automated integration, and watch for ENISA’s manual and its announcements about the testing period.

A process for monitoring the EUVD (https://euvd.enisa.europa.eu) against the company’s own product components is also needed. The company must be able to handle both the CVE ID andEUVD-YYYY-NNNNNN identifier schemes.

By December 11, 2027, companies need to go a step further: CE marking, conformity assessment, selecting a CAB matched to the product’s class (for Class I and above), and issuing a declaration of conformity once the harmonized standards are published. Companies should track the publication of CEN/CENELEC’s horizontal standards (targeting August 30, 2026) and vertical standards (targeting October 30, 2026).

8.3 Comparison with Other Jurisdictions

C6,E2

The CRA’s most notable feature is its horizontal application, cutting across IoT, software, and embedded systems alike, combined with direct effect. Korea’s Software Supply Chain Guideline 1.0, based on NIST SSDF, recommends 30 checklist items and SBOM procedures; because the CRA’s essential requirements are functionally aligned with the SSDF, a system built to follow the Korean guideline is a starting point for CRA readiness. That said, the Korean guideline is advisory, whereas the CRA is a legal obligation backed by a fine regime, and the CRA adds a separate reporting obligation on top.

9. Conclusion and Recommendations

September 11, 2026 is the day the CRA first imposes a substantive compliance obligation on manufacturers. CE marking and conformity assessment are due by December 11, 2027, but the reporting workflow must be complete before then.

For a Korean company, the priority is first to confirm whether its products fall within CRA scope, and if so, to determine — under the criteria of Implementing Regulation (EU) 2025/2392 — which class applies: default, important, or critical. The class determines both the 2027 conformity assessment pathway and the lead time required to prepare for it.

Building the reporting infrastructure and internal playbook comes next. The SRP operations manual has not yet been released, but the human structure and internal procedures can be designed right now regardless. Since ENISA has said it will not provide an integration API, companies should set up a manual submission process for the platform rather than automated integration, and watch for the manual and announcements about the testing period.

SBOM pipeline automation must be finished by September 11. Without an SBOM in SPDX or CycloneDX format automatically generated and retained for every released version, a company will find itself lacking the very software composition information the reporting obligation requires.A1,B2,E2,E4

References

A. Primary Legislative and Regulatory Texts

A1. European Parliament and Council (2024).Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024.https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed: 2026-05-12).↩

A2. European Commission (2025).Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 with regard to the conditions for delaying dissemination of notifications of actively exploited vulnerabilities and severe incidents. Published 20 April 2026.https://eur-lex.europa.eu/eli/reg_del/2026/881/oj (accessed: 2026-05-12).↩

A3. European Commission (2025).Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 laying down technical descriptions of categories of important and critical products with digital elements. OJ L, 2025/2392.https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392 (accessed: 2026-05-12).↩

A4. European Parliament and Council (2022).Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). OJ L 333, 27.12.2022.https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (accessed: 2026-05-12).↩

A5. European Parliament and Council (2016).Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR). OJ L 119, 4.5.2016.https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 (accessed: 2026-05-12).↩

B. Official Documents from Issuing Bodies

B1. European Commission, DG CNECT (2026).Cyber Resilience Act — Shaping Europe’s digital future.https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed: 2026-05-12).↩

B2. European Commission, DG CNECT (2026).Cyber Resilience Act — Reporting obligations.https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (accessed: 2026-05-12).↩

B3. European Commission, DG CNECT (2024).The Cyber Resilience Act — Summary of the legislative text.https://digital-strategy.ec.europa.eu/en/policies/cra-summary (accessed: 2026-05-12).↩

B4. ENISA (2026).Single Reporting Platform (SRP).https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp (accessed: 2026-05-12).↩

B5. ENISA & Joint Research Centre (2024).Cyber Resilience Act Requirements Standards Mapping — Joint Analysis. April 2024.https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping (accessed: 2026-05-12).↩

B6. ENISA (2025).Cyber Resilience Act implementation via EUCC and its applicable technical elements. 26 February 2025.https://certification.enisa.europa.eu/publications/cyber-resilience-act-implementation-eucc-and-its-applicable-technical-elements_en (accessed: 2026-05-12).↩

C. Standards and Frameworks

C1. ISO/IEC (2019).ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. Edition 2.https://www.iso.org/standard/69725.html (accessed: 2026-05-12).↩

C2. ISO/IEC (2018).ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure. Edition 2.https://www.iso.org/standard/72311.html (accessed: 2026-05-12).↩

C3. ISO/IEC (2021).ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1.https://www.iso.org/standard/81870.html (accessed: 2026-05-12).↩

C4. The Linux Foundation / SPDX Project (2024).SPDX Specifications (current: v3.0).https://spdx.dev/specifications/ (accessed: 2026-05-12).↩

C5. OWASP Foundation / Ecma International (2025).CycloneDX Specification v1.7 / ECMA-424, 2nd Edition. ECMA-424 published 2025-12-10.https://cyclonedx.org/specification/overview/ (accessed: 2026-05-12).↩

C6. Souppaya, M., Scarfone, K., Dodson, D. — NIST (2022).Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218.https://csrc.nist.gov/publications/detail/sp/800-218/final (accessed: 2026-05-12).↩

C7. OpenSSF Global Cyber Policy Working Group (2026).CRA Standards Map.https://policy.openssf.org/CRA/standards.html (accessed: 2026-06-09). —Used to verify the numbering and status of CEN/CENELEC JTC 13 WG 9’s prEN 40000-1 series (horizontal harmonized standards).↩

D. Academic and Policy Research

D1. OpenSSF Best Practices WG / Global Cyber Policy WG (2025).Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers. Lead author: David A. Wheeler.https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html (accessed: 2026-05-12).↩

E. Industry and Law Firm Analysis

E1. Bird & Bird LLP (2026).CRA’s phased entry into application starts in September 2026. Bird & Bird Insights.https://www.twobirds.com/en/insights/2026/cra%E2%80%99s-phased-entry-into-application-starts-in-september-2026 (accessed: 2026-05-12).↩

E2. DLA Piper — Blum, L. & Moylan Burke, L. (2026).Cyber Resilience Act: What you need to know and what you need to be doing. 19 February 2026.https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-what-you-need-to-know-and-what-you-need-to-be-doing (accessed: 2026-05-12).↩

E3. DLA Piper (2026).Cyber Resilience Act: Commission unveils draft implementation guidance. Law in Tech.https://www.dlapiper.com/en-us/insights/publications/law-in-tech/2026/cyber-resilience-act (accessed: 2026-05-12).↩

E4. HackerOne — Eldering, B. (2026).EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements.https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness (accessed: 2026-05-12).↩

F. Press and Official Announcements (Supplementary)

F1. ENISA (2025).Consult the European Vulnerability Database to enhance your digital security! News release, 13 May 2025.https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security (accessed: 2026-05-12).↩

F2. European Commission (2025).EU launches a European vulnerability database to boost its digital security.https://digital-strategy.ec.europa.eu/en/news/eu-launches-european-vulnerability-database-boost-its-digital-security (accessed: 2026-05-12).↩

F3. Eclipse Foundation (2024).The Open Source Community is Building Cybersecurity Processes for CRA Compliance. Life at Eclipse, 2 April 2024.https://eclipse-foundation.blog/2024/04/02/open-source-community-cra-compliance/ (accessed: 2026-05-29).↩

G. Member State Technical Guidance

G1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (2025).Technical Guideline TR-03183-2 v2.1.0 — Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM). August 2025. Summary compiled by: Sbomify,EU Cyber Resilience Act (CRA) SBOM Requirements.https://sbomify.com/compliance/eu-cra/ (accessed: 2026-05-12).↩

Introduction

Three major pieces of legislation the European Union (EU) has recently introduced carry very significant implications for Korean companies. TheProduct Liability Directive (PLD), theCyber Resilience Act (CRA), and theAI Act present a comprehensive regulatory framework governing the development, deployment, and use of software and AI systems.

These pieces of legislation matter to Korean companies for the following reasons:

1. Access to the EU market: The EU is one of the largest single markets in the world, and many Korean companies aim to enter it. Failure to comply with these laws can restrict access to the EU market.
2. Setting a global standard: EU regulation tends to become a de facto global standard. This is the so-called ‘Brussels effect’, and other countries are likely to introduce similar regulations.
3. Expanded corporate liability: These laws significantly expand the scope of corporate liability. In particular, the strict liability principle under the PLD could pose a new challenge for Korean companies.

Important perspectives for Korean companies to keep in mind when approaching these laws include the following:

• Proactive response: Companies should prepare in advance of the laws taking effect in order to secure a competitive advantage.
• Integrated approach: Rather than viewing each law individually, companies should recognize them as a single, overall shift in the regulatory environment.
• Balancing innovation and regulatory compliance: Care must be taken not to stifle innovation in the process of complying with regulation.

Now let’s look at the key content of each law.

1. Product Liability Directive (PLD)

1.1 Overview

TheProduct Liability Directive (PLD) aims to modernize the EU’s legal framework for product liability and adapt it to the digital age. This directive introduces a strict liability regime for all products, including software and AI systems.

1.2 Key Changes

1. Inclusion of software in the definition of a product: The PLD expands the definition of a “product” to explicitly include software. This applies to all kinds of software, including operating systems, firmware, computer programs, applications, and AI systems.
2. Strict liability principle: The PLD introduces the principle of ‘strict liability’. This means that a manufacturer can be held liable for damage caused by a defect in a product even without fault.
3. Expanded scope of damage: The PLD expands the scope of damage to include not only harm to persons or property but also data corruption.

1.3 Scope of Application

The PLD applies to all products placed on the market or made available as a service in the EU. This applies even to products manufactured outside the EU, if they are sold in the EU market.

1.4 Key Obligations

1.5 Implementation Timeline

The PLD is expected to be published in November 2024, with penalties applying from 2026, two years later.

1.6 Impact on Companies

1. Expanded scope of liability: Software companies must now take responsibility for all kinds of damage their products could cause. This includes not only physical harm but also data loss or privacy breaches.
2. Changes to product design and development processes: Companies must consider safety and security from the product design stage onward. This means applying the ‘Security by Design’ principle.
3. Stronger documentation and transparency: Companies must provide more detailed and clear documentation regarding a product’s functionality, risks, safety features, and more.
4. Continuous monitoring and updates: Companies must continue to monitor products after they are placed on the market and provide security updates where necessary.

2. Cyber Resilience Act (CRA)

2.1 Overview

TheCyber Resilience Act (CRA) is a piece of legislation introduced in the EU to strengthen the cybersecurity of digital products. This law applies to all products with digital elements (PDEs), including software.

2.2 Scope of Application

The CRA applies to all PDEs sold in the EU market. This applies even to products manufactured outside the EU, if they are sold in the EU market.

2.3 Key Requirements

1. Essential cybersecurity requirements: Manufacturers must develop, produce, and distribute products that meet “essential cybersecurity requirements” appropriate to the product’s risk.
2. Cybersecurity risk assessment: Manufacturers must carry out a cybersecurity risk assessment related to the PDE. This assessment must be updated throughout the support period and considered across the entire product lifecycle.
3. Vulnerability management: PDEs must be placed on the market free of known vulnerabilities, and security updates for vulnerabilities must be provided without delay. Resolved vulnerabilities must also be publicly disclosed.
4. Support period: A product’s support period must correspond to its expected duration of use and must be at least 5 years. The end date of the support period (month and year) must be accessible to the user at the time of purchase.
5. Software Bill of Materials (SBOM): Manufacturers must identify and document the product’s components and vulnerabilities. This includes, at minimum, preparing a Software Bill of Materials (SBOM) covering the product’s top-level dependencies.
6. Testing: Manufacturers must regularly test the security of their products.
7. Vulnerability reporting: Manufacturers must establish a vulnerability reporting policy and make it publicly available.

2.4 Implementation Timeline

The CRA is expected to enter into force in the second half of 2024, and manufacturers must bring compliant products to the EU market by 2027.

2.5 Impact on Companies

2.6 Company Response Measures

1. Adopt security-focused design: Introduce a design methodology that considers security from the earliest stage of product development.
2. Build an SBOM management system: Build a system to track and manage all software components used in a product.
3. Improve vulnerability management processes: Establish a system to quickly discover and respond to vulnerabilities.
4. Establish a long-term support plan: Establish a long-term support plan that takes the product’s expected lifetime into account.
5. Strengthen security testing: Introduce a regular, systematic security testing process.
6. Improve documentation and reporting systems: Build a detailed documentation and reporting system that meets CRA requirements.
7. Train personnel and build capacity: Hire cybersecurity experts or build up the capacity of existing staff.

The CRA is expected to significantly strengthen the cybersecurity of digital products. Companies should treat this not as mere regulatory compliance but as an opportunity to improve product quality and reliability. A proactive response can secure competitiveness in the EU market and, further, an edge in the global market as well.

3. AI Act

3.1 Overview

TheAI Act is the EU’s first comprehensive legal framework governing the development, deployment, and use of AI systems. This law aims to address the risks of AI systems while enabling Europe to play a leading role globally.

3.2 Classification of AI Systems

The AI Act classifies AI systems by risk level as follows:

1. Unacceptable risk
2. High risk
3. Limited risk
4. Minimal risk

3.3 Key Requirements

1. Requirements for high-risk AI systems: High-risk AI systems must comply with the following strict obligations before being placed on the market:
   • An adequate risk assessment and mitigation system
   • High-quality datasets to minimize risk and discriminatory outcomes
   • Activity logging to ensure traceability of results
   • Detailed documentation providing authorities with all the information needed to assess compliance
   • Clear and adequate information provided to deployers
   • Appropriate human oversight measures to minimize risk
   • A high level of robustness, security, and accuracy
2. Requirements for limited-risk AI systems: Specific transparency obligations apply to limited-risk AI systems. For example, when using achatbot, users must be aware that they are interacting with a machine.
3. Requirements for General-Purpose AI models: Transparency obligations apply to General-Purpose AI models. Additional risk management obligations apply to particularly powerful and influential models.

3.4 Implementation Timeline

The AI Act entered into force on August 1, 2024, and will fully apply from August 2026, two years later. However, some provisions apply sooner:

• Prohibitions apply after 6 months
• Governance rules and obligations for General-Purpose AI models apply after 12 months
• Rules for AI systems embedded in regulated products apply after 36 months

3.5 Impact on Companies

3.6 Company Response Measures to Prepare for Implementation

1. Assess and classify AI systems: Companies must assess their AI systems and classify them according to the risk categories under the AI Act. This allows them to identify the regulatory requirements applicable to each system.
2. Establish a regulatory compliance roadmap: Companies must establish a phased regulatory compliance roadmap aligned with the AI Act’s implementation timeline. This should include the necessary resource allocation, process improvements, and technology development.
3. Secure and train specialized personnel: Companies must secure specialized personnel for AI regulatory compliance and train existing employees. This should cover expertise across various fields, including law, technology, and ethics.
4. Improve documentation and reporting systems: Companies must thoroughly document the development, testing, deployment, and monitoring processes of AI systems, and build a system to report to regulators as needed.
5. Strengthen stakeholder communication: Companies must actively communicate with customers, partners, investors, and other stakeholders about the impact of the AI Act and the company’s response measures.

3.7 Key Features and Significance of the AI Act

• Risk-based approach: The AI Act adopts an approach that varies the intensity of regulation according to the risk level of the AI system. This is a balanced approach that allows necessary regulation to be applied without stifling innovation.
• Strengthened transparency and accountability: This law significantly strengthens transparency and accountability throughout the development and use of AI systems. This is expected to help increase social trust in AI.
• Promoting ethical AI development: By requiring AI systems to respectthe EU’s fundamental values and rights, the AI Act promotes ethical and responsible AI development.
• Setting a global standard: EU AI regulation is likely to become a global standard. This can be an opportunity for EU companies to gain competitiveness in the global market.

The AI Act is a comprehensive regulatory framework that takes into account both the advancement of AI technology and its social impact. This law aims to increase the safety and reliability of AI while also promoting innovation. By proactively responding to these regulatory changes, companies will be able to manage risk and create new opportunities. The AI Act should be used not merely as a target for regulatory compliance, but as a guideline for responsible and sustainable AI development.

4. Interrelationship Among the Three Laws

The EU’s three major laws (PLD, CRA, AI Act) are closely related to one another and together form a comprehensive regulatory framework for digital products and services. Understanding this interrelationship is important for companies in establishing an effective response strategy.

4.1 Common Regulatory Purposes

All three laws share the common goal of increasing the safety and reliability of digital technology.

4.2 Overlapping Scope of Application

In many cases, a single product or service may be subject to multiple laws at once. For example, an IoT device that includes AI functionality could be subject to all three laws as follows:

• PLD: from a product liability perspective
• CRA: cybersecurity requirements
• AI Act: regulation of AI functionality

4.3 The Need for an Integrated Approach

Rather than responding to these laws individually, companies should adopt an integrated approach. This offers the following benefits:

1. Avoiding duplicated work
2. Establishing a consistent regulatory compliance strategy
3. Efficient use of resources
4. Strengthened overall risk management

5. Recommendations for Korean Companies

The following are key recommendations for Korean companies to consider in responding to the EU’s new regulatory environment.

5.1 Form a Regulatory Compliance Task Force

• Form a multidisciplinary team of legal, technical, and business experts
• Assign this team the role of continuously monitoring and analyzing EU regulatory trends
• Build a system for smooth communication and cooperation with other departments within the company

5.2 Review the Product and Service Portfolio

• Assess whether current and upcoming products/services are subject to EU regulation
• Identify the specific regulatory requirements applicable to each product/service
• Establish a plan to redesign or improve products/services as needed

5.3 Strengthen Documentation and Transparency

• Build a detailed documentation system covering the product development, testing, and deployment process
• Introduce a process for preparing and managing anSBOM (Software Bill of Materials)
• Develop a way to explain the decision-making process of AI systems

5.4 Strengthen the Risk Management Framework

• Establish a risk assessment and management process spanning the entire product lifecycle
• Build a system for continuous monitoring of and response to cybersecurity risk
• Introduce an ethical impact assessment for AI systems

5.5 Build Human Capacity

• Hire or develop experts on EU regulation
• Run EU regulatory training programs for employees
• Build cooperative relationships with external experts and consulting firms

5.6 Reassess R&D and Innovation Strategy

• Redesign the R&D process with regulatory compliance in mind
• Apply the ‘Security by Design’ and ‘Privacy by Design’ principles
• Establish guidelines for ethical AI development

5.7 Adjust the Business Model and Strategy

• Analyze the impact of EU regulation on the business model
• Adjust the business model or develop a new revenue model as needed
• Reassess the strategy for entering or expanding in the EU market

5.8 Strengthen Stakeholder Communication

• Regularly share the status of EU regulatory response with customers, partners, investors, and other stakeholders
• Emphasize the improvement in product/service safety and reliability achieved through regulatory compliance
• Where necessary, seek understanding regarding increased costs resulting from regulatory compliance

6. Conclusion

The EU’s new digital regulatory environment is both a challenge and an opportunity for Korean companies. The PLD, CRA, and AI Act should not be treated merely as targets of regulatory compliance, but can be used as a framework for developing safer, more reliable digital products and services.

Companies that respond proactively to this regulation can gain the following benefits:

1. Securing a competitive advantage in the EU market
2. Gaining the opportunity to lead global standards
3. Improving the quality and safety of products and services
4. Enhancing customer trust
5. Securing long-term business sustainability

Korean companies can treat these regulatory changes as an opportunity for new innovation and growth, and build stronger competitiveness in the global digital economy. By going beyond mere regulatory compliance to pursue responsible technology development and use, they can increase their social value and achieve sustainable growth.

Disclaimer: I am not a legal expert, and this content should not be relied upon as a legal basis. For specific matters related to licensing or legal issues, please be sure to seek the advice of a legal professional.

A Software Bill of Materials (SBOM) is a formal record of what components make up a piece of software and how those components connect within the supply chain. A US executive order compares it to the ingredient list on food packaging. Just as an ingredient list is the starting point for responding to allergies, an SBOM is the data layer on which vulnerability response, license management, and asset management all rest. An SBOM is not a security tool in itself, but without one, an organization cannot immediately answer the question, “Where in our product is this library used?”

This guide covers that data layer from beginning to end. Drawing on primary sources, it explains why SBOM has moved to the forefront of regulation and procurement, what standards and identifiers underpin it, in what order organizations adopt it and with what tools they automate it, how they manage vulnerabilities and licenses, and how they share it securely across the supply chain.

Intended Audience

• Security, development, procurement, and legal staff at organizations that develop or procure software
• Practitioners who must respond to the EU Cyber Resilience Act (CRA) or US federal procurement requirements
• Teams seeking to establish supply chain transparency and open source license compliance systems

Guide Structure

The guide is divided into eight sections. The earlier sections cover concepts, standards, and regulation, while the later sections cover the practicalities of adoption and operation. You can read only the sections you need.

Quick Starting Points

If you already understand SBOM and are looking for where to start, see4. Adoption Roadmap and8. Recommendations and Checklist first. If you are deciding which format and tools to use,2. Standards and Formats and5. Tools and Automation are good starting points. If your goal is regulatory compliance, check the jurisdiction-specific obligations in3. Regulatory Trends.

Sources and Editorial Basis

This guide is not a translation of any single document; it is a reconstruction that synthesizes current primary sources. It draws on the National Telecommunications and Information Administration (NTIA)’s 2021 minimum elements and its update by the Cybersecurity and Infrastructure Security Agency (CISA) — the 2024Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements — as well as the SPDX and CycloneDX standard specifications, the EU Cyber Resilience Act (Regulation (EU) 2024/2847), and the supply chain security guidelines of India’s CERT-In and Korea. The first edition began as a translation of CERT-In’s SBOM technical guidelines; the current edition updates that framework with the sources above and broadens it to a general practitioner’s perspective.

Every factual claim is cited to a primary source, and the materials cited were accessed on June 14, 2026.

Author :Haksung Jang

The first major piece of legislation to establish SBOM as an explicit legal obligation is the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). Whereas the United States effectively mandates SBOM through the market of federal procurement, the CRA is a directly effective law that applies horizontally across products with digital elements.

Legal Basis of the SBOM Obligation

In the CRA, the SBOM obligation appears in Annex I, Part II (vulnerability handling requirements), point (1). Manufacturers must identify and document the vulnerabilities and components contained in a product, and as a means of doing so, the CRA specifies that they must “draw up a software bill of materials, in a commonly used and machine-readable format, covering at the very least the top-level dependencies of the product.”

Two points that matter in practice differ from the US pathway.

• The scope of the obligation is top-level dependencies: There is no obligation to expand the entire dependency tree; covering at least the top-level dependencies is sufficient. That said, going deeper than this is clearly the recommended direction.
• It is an obligation to retain and submit, not to disclose: There is no obligation to disclose the SBOM to the general public. It is sufficient to retain it so that it can be submitted when a market surveillance authority makes a reasoned request.

The core of the CRA is that producing an SBOM is not a recommendation but a legal obligation backed by a system of fines.

Implementation Timeline

Figure 1. Phased implementation timeline of the EU CRA(source: Regulation (EU) 2024/2847; collected June 14, 2026)

The CRA was published in the Official Journal on November 20, 2024, and entered into force on December 10, 2024. Its application is staged: the Article 14 obligation to report exploited vulnerabilities and severe incidents applies from September 11, 2026, and full application of the essential cybersecurity requirements, including SBOM, begins on December 11, 2027.

Absence of Format Implementing Rules and a Practical Reference Point

As of June 2026, no official CRA-level implementing rule for SBOM format has been published. This means there is not yet a document that establishes, as an EU-wide binding norm, which schema and fields must be used to conform to the CRA.

The current practical reference point is Technical Guideline TR-03183-2 v2.1.0, published in August 2025 by Germany’s Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). This document provides specific field mappings for CRA-conformant SBOM for both CycloneDX and SPDX. Note, however, that this is a German guideline, not an EU-wide binding norm.

Considerations for Open Source

The CRA uses commercial activity as its applicability criterion, and in principle excludes non-commercial open source that is distributed free of charge without commercial activity. This is a mechanism to avoid imposing manufacturer-level obligations directly on open source maintainers. However, the obligations still apply in full to manufacturers who integrate open source into a product and supply it commercially, so obtaining and managing SBOMs for open source components remains the manufacturer’s responsibility.

Sources

European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024.https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng. European Commission, DG CNECT.Cyber Resilience Act.https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. BSI.Technical Guideline TR-03183-2. (all accessed: June 14, 2026)