Summary

On July 29, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) and 17 other agencies published a revised set of minimum elements for a Software Bill of Materials (SBOM)[A2]. The document states plainly that it replaces, rather than amends, the baseline established in 2021 by the National Telecommunications and Information Administration (NTIA).

The bar has risen noticeably. The data fields grew from 7 to 17, and six operational practices were specified alongside them. Ten of the elements are entirely new.

Three changes matter most in practice.

• Licensing entered the SBOM minimum baseline for the first time.
• Dependencies must now be recorded in full, down to transitive dependencies, with no depth limit.
• New fields were added to declare the origin and integrity of the SBOM document itself.

The document carries no effective date and no enforcement power. Preparation is still warranted, because national regulations increasingly require SBOMs without enumerating the fields those SBOMs must contain. The practical significance of this document is that it gives procurement contracts a multilateral consensus baseline to cite.

The nature of that preparation is easy to misjudge. Meeting the minimum elements is not a matter of picking a tool. Fewer than half of the 23 elements can be filled by a generation tool on its own. The rest are filled by the build pipeline, the signing infrastructure, and policies the organization decided on in advance.

I also checked how far an actual tool gets. BomLens is an SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. Assessing all 23 elements with it produced the following:

• The tool fills 11 of the 17 data fields directly with values.
• It inspects supplier-submitted SBOMs against all 23 elements, separating out the 4 that the organization must decide as items for human review.
• The remaining gaps exist not because the tool is deficient, but because those values must be determined by whoever runs it or by the build stage at which it runs.

The assessment screen can be viewed directly in thepublic demo, with nothing to install.

1. What Changed

1.1 The Structure of the Elements

The minimum elements fall into two categories. Seventeen data fields are the values actually carried in the SBOM document; six operational practices govern how an organization handles SBOMs.

Figure 1. The composition of the CISA 2026 SBOM minimum elements(source: 2026 Minimum Elements for a SBOM, 2026-07-29)

SBOM metadata is a category that did not exist in the 2021 edition. Where the earlier baseline asked for little more than an author and a timestamp, the document now requires the SBOM to declare for itself which tool produced it, when, at what stage, and who signed it.

1.2 Three Substantive Changes

Licensing became mandatory. The seven data fields of the 2021 edition did not include licensing, because that document was aimed at security and vulnerability management. The revision adds component licensing as a new element, requiring that it be conveyed in a machine-processable form such as an SPDX license identifier where possible, and that the presence of proprietary license terms be disclosed as well. Territory that belonged to the Open Source Program Office (OSPO) is now part of the SBOM minimum baseline.

The floor on dependency resolution is gone. The Depth element of the 2021 edition required only top-level dependencies. The revision replaces it with a Coverage element that requires all constituent components including transitive dependencies, and states explicitly that recording only to a certain depth is no longer sufficient. The document is candid about why. The 2021 baseline “reflected the capabilities of SBOM tooling at the time rather than the depth of information needed for informed security decisions,” and since tooling has advanced in the interim, the requirement has been raised.

Supplier Name became Component Producer. This is a change of definition, not merely of label. The document states that Supplier Name “proved ambiguous in practice, particularly in relation to software distributors.” The intent is to end the practice of naming redistributors and to point the field at the entity that originally created the software. Where the producer is unclear, as with open source projects, the document requires that the unknown provenance be stated explicitly.

Separately, Software Identification (SWID) tags were dropped from the list of accepted formats. Two remain: SPDX and CycloneDX.

2. What the OSPO Must Decide

The six operational practices are items an organization must answer, not a tool. The document says as much: organizations “should explicitly address these elements in all policies, contracts, and agreements that require or provide SBOMs.”

2.1 How Much to Include

The Coverage element requires all transitive dependencies while permitting the exclusion of non-code files. It adds that security-relevant files, such as configuration files, may be included. Where to draw the line on security relevance is for the organization to decide.

The vulnerability management test offered by the document is a useful criterion: an SBOM recipient should be able to conclude that a newly reported vulnerability does not affect them if the associated component is absent from the list. A scope definition that fails this test does not satisfy the Coverage requirement.

Linking each subcomponent to a separate SBOM is also permitted, but with a condition. The recipient must be able to access every linked SBOM. Providing links without access rights does not meet the requirement.

2.2 When to Regenerate

The Frequency element requires a corresponding SBOM for each software version or update. Every new build or release calls for a new SBOM, and that includes builds where only dependencies changed.

One more obligation attaches here. If errors are found in existing SBOM data, or new facts about a component come to light, a revised edition must be issued. This means an SBOM may need to be reissued without any accompanying release, which in turn requires a way to track where already-distributed SBOMs went.

2.3 How to Record What Is Not Known

Explicit identification of unknowns is a major update. The requirement is specific: when a value is absent, it must be clear whether the information is unknown to the author or whether the author is knowingly withholding it.

The distinction conveys different information to the recipient. Unknown means the supply chain trace broke off at that point; withheld means the supplier has the information and is not providing it. For the latter case, the document requires a process through which recipients can inquire, and adds that an SBOM withholding essential component data may be treated as incomplete.

In practice, the notation convention has to be settled first. Simply leaving a field empty makes the three cases indistinguishable: whether the value does not exist, was never confirmed, or was deliberately not disclosed.

2.4 Which Formats to Accept

The machine-readable data element names SPDX and CycloneDX while directing organizations to accept widely used, interoperable formats. One condition attaches: SBOMs for new software generated with deprecated versions should not be accepted.

That condition creates a second acceptance criterion. Format version matters as much as format name, and the new SBOM data format name and version elements provide the basis for that judgment.

2.5 What to Put in Contracts

Translated into contract language, the items above come out as follows.

• The required format and minimum version
• The coverage scope, including transitive dependencies
• The obligation to supply an SBOM with each release, and to supply a revision when errors are found
• Distinct notation for unknown versus withheld, and an inquiry process for withheld items

The three actions the document recommends to organizations point the same way: require SBOMs that satisfy the updated minimum elements, use tooling to generate, collect, and analyze SBOM data, and generate SBOMs that satisfy the minimum elements themselves.

3. Who Fills Each Element

Sorting the 23 elements by who fills them clarifies what preparation actually involves.

Figure 2. The four domains that fill the 23 minimum elements(source: compiled from the element definitions in the original document)

What a generation tool can handle alone sits on the component data side. The rest must be filled from outside the tool.

Generation context must be recorded inside the build pipeline to be accurate. An SBOM built from source corresponds to “pre-build” and one built from binary analysis to “post-build” — a value determined by when the scan runs, not by what it scans.

Component hashes require an executable artifact to compute. At source-scan time that artifact does not yet exist, making it inherently impossible, and the document itself prescribes an unknown marking for this case. Requiring hashes means generating or updating the SBOM at a post-build stage.

Author signatures presuppose key management. The document directs organizations to use existing software signing infrastructure and key management, which falls outside the scope of an SBOM tool.

SBOM Author is a value the tool cannot know. Since the definition is the entity operating the tool, whoever runs it has to supply it.

3.1 Which Formats Carry the New Elements

Formats differ in how far they carry the 10 new fields, which makes the choice of format itself a practical decision[C3].

Table 1. How each format can express the new elements(source: RunSafe Security field mapping analysis, 2026)

CycloneDX has the advantage on the new metadata. Generation context and signatures exist as native fields, and the lifecycle phase vocabulary the original document uses as an example maps across directly.

Conversely, SPDX offers the better mechanism for marking unknowns. Its standardNOASSERTION marker distinguishes “no value” from “not determined,” whereas CycloneDX has no marker at that level, requiring a separate convention using properties or annotations. And marking unknowns is precisely one of the requirements this revision strengthened.

The judgment at this point is as follows. The combination that carries the minimum elements most completely is CycloneDX 1.6, provided the organization establishes its own convention for marking unknowns. Organizations using SPDX as their primary format have no place in 2.3 for generation context or signatures, which makes this the moment to consider migrating to 3.0.

4. Relationship to Regulation

The minimum elements carry no legal force in themselves. The disclaimer states that the publication “is not intended as compliance, regulatory, or legal advice.”

Its real influence comes through citation. The European Union Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to provide an SBOM as part of the technical documentation, but does not enumerate the fields in its text[A5]. Germany’s BSI TR-03183-2 filled that gap with concrete technical requirements, and India’s CERT-In and Japan’s Ministry of Economy, Trade and Industry have issued guidance of their own. The minimum elements are the baseline these all reference in common.

One caution applies. Although the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT) contributed to the drafting, a footnote states that the document does not interpret European Union law, does not bind the Commission, and that not all of its elements reflect Union law. It cannot be used as-is to demonstrate Cyber Resilience Act compliance.

There is also a terminological trap. A footnote in the original explicitly warns against confusing the “producer” of Component Producer with the “manufacturer” of the Cyber Resilience Act. Every manufacturer is a producer, but not every producer is a manufacturer. Documents that address both regimes need to keep the terms distinct.

From Korea, two organizations participated as co-authors: the National Cyber Security Center under the National Intelligence Service, and the Korea Internet & Security Agency. That participation gives domestic procurement and internal policy a basis for citing this document. Because the international common baseline was updated immediately after the government’s joint Software Supply Chain Security Roadmap was announced in June 2026, domestic policy now has a reference to draw on when it comes to specifying required fields.

Organizations working with AI systems should note the ordering. The original document introduces no AI-specific elements, deferring them to the G7 joint guidance[A10]. The two documents are hierarchical: fill this general software baseline first, then add the AI-specific elements.

5. How Far Do Actual Tools Get Today

Reading a baseline and confirming that a tool actually meets it are separate exercises. Even when a format has a place for a value, the field stays empty if the tool does not put one there.

I assessed all 23 elements using BomLens, the SBOM generation and management tool that SK telecom developed for software supply chain security and released as open source. The basis was actual scan output and source code rather than estimation[D1].

5.1 What the Tool Fills with Values

The tool fills 11 of the 17 data fields directly.

• SBOM metadata: data format name and version, generation context, timestamp, tool name, SBOM version
• Component data: name, version, identifier, license, dependency relationships

Three of these are filled in ways that bear directly on the minimum element requirements.

• Generation context is determined automatically from the input type. Source scans are recorded aspre-build and container and binary scans aspost-build, so the user never selects the value.
• Licensing is filled for 98.4% of components on the source path and 94.7% on the container path. The source side reads from package manifests, the container side from the operating system package database.
• The tool name records both BomLens itself and its underlying generators. The minimum elements ask for the tools that generated or modified the SBOM, so both are retained.

Among the six operational practices, it satisfies machine-readability and distribution and delivery. It emits CycloneDX 1.6 as its default format and supports conversion to SPDX 2.3, covering both formats the minimum elements designate.

5.2 What the Tool Cannot Fill

The remaining items are empty not because the tool falls short, but because of the structure described in section 3.

• SBOM author and author signature: the entity running the tool must supply the value. The author is passed via--sbom-author, and signing is a separate option that uses cosign.
• Component hash: at source-scan time no executable artifact exists to hash. On paths where an artifact does exist, such as containers and firmware, the scan target itself is hashed.
• Component producer: the package metadata must carry producer information for this to be filled. Coverage is 60.9% on the source path and 94.7% on the container path.

How the absence of a value is handled matters from the minimum elements perspective. When no author is specified, this tool does not writeunknown; it leaves the field empty and adds a document-level declaration that empty fields were not determined by the author. Because the minimum elements define the author as the entity operating the tool, and that entity knows who it is, a tool writingunknown would not be marking an unknown but making a false statement. Hashes follow the same principle: no value is invented.

5.3 Assessing Received SBOMs Against the Minimum Elements

The tool can also inspect supplier-submitted SBOMs against all 23 elements. Results come out in three branches.

Figure 3. The conformance assessment screen. All 23 elements are assessed, with the 4 the tool cannot judge separated out for human review(BomLens 1.10.3 output, 2026-08-09)

• Met, 13 — the 11 data fields plus 2 operational practices.
• Not met, 6 — the items covered in section 5.2.
• Human review, 4 — Coverage, Accommodation of Updates to SBOM Data, Distribution and Delivery, and Frequency. These are decided by the organization, so the tool passes them to a person rather than judging them.

Not treating what it cannot judge as a pass is what makes this useful in practice. The four items marked for human review are the same organizational decisions covered in section 2.

The same screen can be opened directly in thepublic demo. It runs in a browser with nothing to install, and each element carries a note on what is missing and how to fill it. Note that the demo shows the result of inspecting a supplier-submitted SBOM, so its subject differs from the figure above.

5.4 What Remains

Some gaps remain before the minimum elements are fully met.

• The tool version is recorded as an image tag rather than a release number. The minimum elements call for a value that identifies a specific delivery of code.
• The SBOM version stays fixed at 1 across regenerations and cannot express revision relationships. This connects directly to the accommodation of updates element, but a locally running tool cannot know where its previous output went, which makes user-specified versioning the realistic alternative.

6. Conclusion

What the revised minimum elements demand is not more fields but a different kind of preparation.

With licensing in the minimum baseline, the SBOM is no longer a document belonging to the security team alone. Filling in license identifiers in machine-processable form, disclosing the presence of proprietary terms, and stating plainly when something is not known — this is how an OSPO already works. What changed is that the result now has to leave the organization in a standard format.

Much of the preparation has to be finished before a tool is selected. Four items are for the organization to decide.

• How much to include
• When to regenerate
• How to mark what is not known
• Which formats and versions to accept

Adopt a tool without settling these, and whatever defaults the tool produces become the organization’s policy.

It is equally necessary to separate what can be demanded of a tool from what cannot. A source-scanning tool cannot be asked for the hash of an executable artifact, and no tool can decide an organization’s name on its behalf. Demand that unfillable values be filled and the tool will invent plausible ones, which is the direction the minimum elements prohibit.

Checking what your current tool fills and what it leaves empty is worth doing once. Format support and field satisfaction are different questions, and the gap between them only shows when you open the output yourself. If there is no obvious tool at hand to check, BomLens from section 5 is a starting point. It is open source and free to download, and it shows both how far a generated SBOM meets the 23 elements and whether a supplier-submitted SBOM meets the baseline, on the same screen.

References

A2. Cybersecurity and Infrastructure Security Agency and 17 other agencies (2026).2026 Minimum Elements for a Software Bill of Materials (SBOM). v2.1, published July 29, 2026, TLP:CLEAR.https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf.

A5. European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the European Union, October 23, 2024.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847.

A10. CISA and G7 partners (2026).Software Bill of Materials for AI – Minimum Elements. May 2026. — Covered in detail in theG7 SBOM for AI Minimum Elements report.

A1. National Telecommunications and Information Administration (2021).The Minimum Elements For a Software Bill of Materials (SBOM). Published July 12, 2021.https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

A3. Federal Register (2025).Request for Comment on 2025 Minimum Elements for a Software Bill of Materials. Published August 22, 2025; comment period closed October 3, 2025.https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials.

B1. SPDX.The System Package Data Exchange.https://spdx.dev/. ISO/IEC 5962:2021.

B2. CycloneDX.https://cyclonedx.org/. Ecma International,ECMA-424: CycloneDX Bill of Materials Specification, December 2025.

C3. RunSafe Security (2026).Mapping CISA’s 2026 SBOM Minimum Elements to CycloneDX and SPDX.https://runsafesecurity.com/blog/sbom-minimum-elements-cyclonedx-spdx/. — The basis for Table 1. The per-format field mapping is taken from this analysis and was not verified directly against the specifications.

D1. BomLens. An SBOM generation and management tool developed and released by SK telecom for software supply chain security, Apache-2.0.https://github.com/sktelecom/bomlens. The coverage assessment in section 5 was determined from actual scan output and source code using version 1.10.3 of this tool.

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).↩