CRA: Must I Report an Exploited Flaw in an Open Source Component?

Yes, when there is reliable evidence the flaw has been exploited in your product. The Commission's guidance says the integrating manufacturer must notify an actively exploited vulnerability that comes from a third party component. If the vulnerable code cannot be exploited, or has not been exploited, in your product, reporting is not mandatory, but you still tell the maintainer.

This post is a practical reading of Regulation (EU) 2024/2847 (the Cyber Resilience Act, or CRA) and the official European Commission and ENISA guidance as of 22 October 2026. It is not legal advice. The Commission's guidance and FAQ are non binding, and your counsel and your CSIRT have the final word on your case.

Key takeaways

• The trigger is exploitation, not disclosure. Article 14(1) covers "any actively exploited vulnerability contained in the product with digital elements" that the manufacturer becomes aware of. A new CVE with no evidence of malicious use does not start the clock.
• Upstream origin does not move the duty. The Commission's guidance (paragraph 218) and FAQ 5.4 both say the manufacturer of the product must notify an actively exploited vulnerability that originates from an integrated component.
• Unreachable or unexploited in your product means not mandatory. Paragraph 218 says such a vulnerability does not qualify for mandatory reporting for that manufacturer. Voluntary reporting under Article 15 stays open, and the duty to report upstream under Article 13(6) remains.
• Three deadlines. Early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, a final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)).
• One platform. Notifications go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator in the Member State of your main establishment.
• "Not affected" must be evidenced. Record reachability analysis and a VEX statement for every decision not to notify.
• SBOMs and VEX make 24 hours realistic. Without a searchable inventory per shipped version, the first day goes on finding the component.

The rules in one table

Two things stand out. Reporting is live while the handling requirements that make it easy only become mandatory in December 2027. And, as paragraph 210 of the Commission's guidance notes, reporting covers products already on the market and continues after a product's support period ends.

What counts as "actively exploited" under the CRA, and who decides?

The definition

Article 3(42) defines an actively exploited vulnerability as one "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". ENISA's platform FAQ uses the same definition. Three conditions sit inside it.

1. Reliable evidence. A forum rumour, a scanner banner or a severity score is not evidence of exploitation. A government catalogue entry, a maintainer advisory stating exploitation in the wild, a CSIRT alert, incident response findings or your own telemetry can be.
2. A malicious actor. The Commission FAQ (5.2), citing Recital 68, says vulnerabilities found in good faith testing should not be subject to mandatory notification. Its examples: a zero day reported through a bug bounty, or found by a lab testing on your behalf, with no evidence of prior malicious exploitation, is not reportable under Article 14.
3. Without the owner's permission. Exploitation happened against a real system, not in a lab.

Exploited somewhere versus exploited in your product

This is the distinction that matters most for open source. A library can be under attack in other vendors' products while your product, which ships the same library, has not been touched. The Commission's guidance answers this directly in paragraph 218: if a manufacturer knows a third party component contains a vulnerability that "(i) cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable) or (ii) has not been exploited in its product", it "is not subject to mandatory reporting for that manufacturer".

FAQ 5.2 frames actively exploited vulnerabilities as cases where a manufacturer establishes that a breach "has resulted from a malicious actor making use of a flaw in one of the products" it made available. So the practical test for an integrator is evidence of exploitation of your product, not of the library in general.

That does not make wider exploitation irrelevant. If attackers are mass scanning for the vulnerable code path and your product exposes it, you may have evidence of exploitation in your own fleet within hours. Wider exploitation is the signal to go looking.

What does not count

A public proof of concept, a high CVSS score or a high EPSS probability do not by themselves meet the definition. Article 3(41) separately defines an "exploitable vulnerability" as one with the potential to be effectively used by an adversary under practical operational conditions. That concept drives a different obligation: placing products on the market without known exploitable vulnerabilities. Article 14 attaches to the narrower "actively exploited" category.

Who decides, and when "becoming aware" happens

You do. FAQ 5.1 says the CRA does not specify how a manufacturer becomes aware; it lists examples such as customer reports, threat intelligence, government agency notifications, ethical hackers, telemetry and honeypots. The Commission's guidance (paragraph 213) says that after a suspicious event, the manufacturer should assess it immediately, and is regarded as having become aware when, after that initial assessment, it has "a reasonable degree of certainty" that a vulnerability in its product is being actively exploited. Paragraph 214 stresses prompt action on that initial assessment.

Paragraph 217 covers timing. Exploitation you were already aware of before 11 September 2026 needs no retroactive report. A vulnerability you knew about before that date, but whose exploitation you learn of afterwards, is reportable.

Write a rule into your vulnerability handling policy: who performs the initial assessment, how fast, and what time stamp counts as awareness. Then apply it consistently.

If the flaw is in an upstream open source component, is it my vulnerability to report?

Yes, if it is exploited in your product

FAQ 5.4 asks exactly this question and answers it: "Where the product with digital elements contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product with digital elements is required to notify that vulnerability." Paragraph 218 of the guidance says the same.

That fits the regulation's structure. Article 14(1) covers vulnerabilities "contained in the product", not only in code you wrote. Article 13(5) requires due diligence "when integrating components sourced from third parties", including free and open source components not made available commercially. FAQ 4.3.6 adds that vulnerability handling obligations apply to products "in their entirety, including to all integrated components".

Who else reports?

FAQ 5.4 adds that the manufacturer of the integrated component "is also required to notify it, if that component has been placed on the market". A commercial SDK vendor would report too. A non commercial open source project usually is not a manufacturer, so do not assume anyone upstream has reported anything.

ENISA's FAQ says "only one notification is required for any given actively exploited vulnerability (AEV) or severe incident (SI)" for a manufacturer, including groups with several EU entities. It does not say one vendor's notification covers another's. Each manufacturer whose product is affected reports its own.

What about the open source project itself?

Stewards (legal persons other than manufacturers that systematically support free and open source software intended for commercial activities) have duties under Article 24(3). FAQ 5.5 says Article 24(3) applies parts of Article 14 (paragraphs 1, 3 and 8) to stewards, and per Article 71(2) only from 11 December 2027. The guidance (paragraphs 80 to 82) says a steward providing only non technical support is not required to report actively exploited vulnerabilities, while one providing engineering resources to a project is. Paragraph 216 expects stewards to learn of exploitation mostly from downstream manufacturers. Your report upstream is how that happens.

Do I report if the vulnerable code is present but not exploitable in my product?

According to the Commission, no, not as a mandatory notification. FAQ 5.4: if a manufacturer is aware an integrated component contains a vulnerability that "cannot be exploited in its product with digital elements, that vulnerability is not actively exploited, and therefore it is not subject to mandatory reporting". Paragraph 218 gives unreachable code as the example.

The same passages list what you still owe: you "can still notify" voluntarily under Article 15, you must comply with the vulnerability handling requirements in Part II of Annex I, and you must report the vulnerability upstream under Article 13(6).

A defensible way to decide

The guidance makes "not affected" a legitimate outcome, which raises the bar on proving it. A market surveillance authority will ask how you knew.

Two cautions. Judge reachability against every configuration customers can enable, not only your lab defaults. And remember the asymmetry: an over report produces a notification your CSIRT closes, while a missed one is a breach of Article 14, which Article 64(2) places in the highest fine band: up to 15 million euro or 2.5% of total worldwide annual turnover, whichever is higher.

What a good "not affected" record looks like

• The exact product versions examined, with their SBOMs.
• The advisory and exploitation evidence, with retrieval time stamps.
• The reachability analysis: entry points, call paths and configurations traced.
• A VEX statement with status not_affected and a standard justification such as vulnerable_code_not_in_execute_path.
• Who approved it, when, and a review date in case a later advisory widens the affected function list.

What goes in the 24 hour early warning when facts are thin?

Article 14(2)(a) requires the early warning "without undue delay and in any event within 24 hours" of becoming aware, indicating, where applicable, the Member States in which you know the product has been made available. That is the whole legal content. Paragraph 215 of the guidance says the structure "requires manufacturers to update their notifications progressively" as investigations advance.

The 72 hour notification (Article 14(2)(b)) adds, as available, general information about the product, "the general nature of the exploit and of the vulnerability concerned", corrective or mitigating measures taken and those users can take, and how sensitive you consider the information. The final report (Article 14(2)(c)) includes at least a description with severity and impact, information on any malicious actor where available, and details of the security update or other corrective measures.

ENISA's FAQ says some platform fields are optional at the early warning and become required later, and its glossary lists the stage for each field. Download it before you need it.

A practical template

Early warning: actively exploited vulnerability (CRA Article 14(2)(a))

Manufacturer: <legal name>, main establishment <Member State>
Product(s): <product name>, versions <list or range>
Component: <open source package and version(s)>, identifier <CVE / GHSA / EUVD id>
Evidence of exploitation in our product: <source and date>
Became aware: <UTC date and time>, after initial assessment by <role>
Member States where the product is made available: <list>
Current assessment: under analysis; update within 72 hours
Immediate user guidance: <mitigation, or "none yet">
Upstream maintainer informed: <yes, date, channel / not needed: maintainer aware>
Contact: <PSIRT contact>

Separate what you know from what you assume. Do not wait for a CVE number. Leave exploit details out and use the platform's sensitivity field.

How does the ENISA Single Reporting Platform work in practice?

ENISA runs the platform under Article 16 with the CSIRT Network. It went live on 11 September 2026.

Before an incident

• Register Assigned Representatives. Each Primary or Secondary representative needs a personal EU Login account with multi factor authentication, per ENISA's FAQ. Version 1.2.1, released 20 October 2026, changed how secondary representatives and backups are invited.
• Pick the right CSIRT. Article 14(7) routes notifications to the CSIRT designated as coordinator where you have your main establishment, which ENISA describes as "the place where decisions related to the cybersecurity of your products with digital elements are predominantly taken". Without an EU main establishment, a fallback order applies. A notification sent to the wrong coordinator must be resubmitted.
• Plan for English. The platform has been English only since launch.

During an incident

ENISA's guidance describes three stages:

1. Early Warning. Choose "Submit new notification", select the manufacturer, complete the mandatory fields and submit. Drafts are visible only to their author. The coordinator and ENISA can then see it; other CSIRTs get it only after the coordinator disseminates it.
2. 72 hour Notification. Complete the next tab of the same notification. The state becomes "72h Submitted", or "72h Submitted under PEC" if you invoke particularly exceptional circumstances under Article 16(2), in which case ENISA does not receive it automatically.
3. Final Report. Once submitted, the notification can no longer be edited.

Quirks worth knowing

• The platform's 72 hour counter currently runs from the early warning submission, so a notification "may be displayed as overdue before 72 hours have elapsed", says ENISA's FAQ. Track your legal deadline from your own awareness time stamp.
• There is no counter for the final report on actively exploited vulnerabilities. Track it yourself.
• Voluntary reporting under Article 15 is not yet implemented; contact your national CSIRT for now.

What do I owe the open source maintainer?

The legal duty

Article 13(6) requires manufacturers, "upon identifying a vulnerability in a component, including in an open source-component", to "report the vulnerability to the person or entity manufacturing or maintaining the component" and to remediate it under Part II of Annex I. Where you developed a fix, you share the relevant code or documentation, where appropriate in a machine readable format. Article 13 applies from 11 December 2027, but the guidance ties it to the reporting question already: paragraph 218 lists it as an obligation even where Article 14 does not apply.

What the guidance narrows

Section 9.2.1 of the guidance (paragraphs 222 to 229) is practical:

• You report upstream only for the version of the component you integrate (paragraph 223).
• Use the maintainer's security policy or designated channel, "particularly where premature disclosure of unpatched vulnerabilities could increase cybersecurity risks".
• You are not required to report where you can confirm the maintainer already knows. Check public vulnerability databases, project advisories and issue trackers first to avoid duplicates.
• Report flaws in the component itself, not ones created by how you integrated it (paragraph 224), though integration insights are encouraged.
• No duty applies where the component has no maintainer, or you no longer rely on the original maintainer (paragraph 225).
• Share fixes in a licence compatible way and follow the maintainer's guidelines (paragraph 227). You do not have to get your fix accepted, and you may reject the maintainer's fix and mitigate differently (paragraph 228).

Informing your users

Article 14(8) requires you to inform impacted users, and where appropriate all users, with risk mitigation and corrective measures where necessary. If you do not do so in a timely manner, the CSIRTs may inform them. Paragraph 220 adds that this is risk based and "does not imply that such information must be made public"; for sensitive deployments you may limit detail to the customers concerned. A CSAF advisory with VEX is a practical machine readable format.

How do SBOMs and VEX make the 24 hour clock achievable?

The SBOM answers "where is it?"

Annex I, Part II, point 1 requires manufacturers to document components, including by drawing up an SBOM in a commonly used, machine readable format covering at the very least the top level dependencies. For reporting, the top level is not enough: exploited open source flaws usually sit in transitive dependencies, base images or bundled runtimes. Generate full SBOMs for every release and keep them with the shipped version.

VEX answers "does it matter here?"

Vulnerability Exploitability eXchange (VEX) states whether a product is affected by a vulnerability, with a reason. Common formats are the CSAF VEX profile, CycloneDX VEX and OpenVEX. OpenVEX defines four statuses (not_affected, affected, fixed, under_investigation) and five justifications for not affected: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. Those justifications map neatly onto paragraph 218's "cannot be exploited in its product".

Step by step: the first 24 hours for an exploited open source component

The commands assume a CycloneDX JSON SBOM per release and a shell with curl and jq.

Step 1: Capture the exploitation evidence

CISA publishes its Known Exploited Vulnerabilities catalogue as a JSON feed:

CVE="CVE-YYYY-NNNNN"
mkdir -p "evidence/$CVE"
curl -s -o "evidence/$CVE/kev.json" \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
jq --arg cve "$CVE" '.vulnerabilities[] | select(.cveID == $cve)
  | {cveID, vendorProject, product, dateAdded, knownRansomwareCampaignUse}' \
  "evidence/$CVE/kev.json"
date -u +"%Y-%m-%dT%H:%M:%SZ" > "evidence/$CVE/retrieved_at.txt"
sha256sum "evidence/$CVE"/* > "evidence/$CVE/SHA256SUMS"

Also check ENISA's European Vulnerability Database, the maintainer's advisory and CSIRT alerts. Remember the guidance test: a catalogue entry shows exploitation somewhere; you still need evidence about your product.

Step 2: Find every shipped release that contains the component

PKG="libexample"
for f in sboms/*/*.cdx.json; do
  jq -r --arg pkg "$PKG" --arg file "$f" '
    .components[]? | select(.name == $pkg)
    | "\($file)\t\(.name)\t\(.version)\t\(.purl // "no-purl")"' "$f"
done | sort -u

No per release SBOMs yet? Generate them from tagged source or the shipped artifact:

npm sbom --sbom-format cyclonedx > sbom.cdx.json          # npm 10 and later
pip install cyclonedx-bom && cyclonedx-py environment > sbom.cdx.json
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom  # Maven
go version -m ./bin/yourservice                            # modules linked into a Go binary

safeguard scan --dir .
safeguard scan --image registry.example.com/product:5.2.1
safeguard scan --sbom sbom.cdx.json

go version -m is worth singling out: it reports what was actually linked into the binary you shipped.

Step 3: Decide reachability, then look for exploitation

For each release, check reachability against the advisory's affected functions. Where reachable, search product telemetry, support tickets and customer incident reports for the advisory's indicators. Record each outcome as VEX, for example with the OpenVEX tool:

vexctl create \
  --product="pkg:oci/product@sha256:<digest>" \
  --vuln="$CVE" \
  --status="not_affected" \
  --justification="vulnerable_code_not_in_execute_path" \
  > "vex/$CVE-product-5.2.1.openvex.json"

For affected releases, use --status="affected" with a statement of the mitigation users can apply now.

Step 4: Notify, or record why not

If you have a reasonable degree of certainty your product is being exploited, submit the early warning before hour 24 and log the platform reference:

echo "- $(date -u +%FT%TZ): early warning via SRP, ref <id>, by <AR>" \
  >> "evidence/$CVE/timeline.md"

If not, log the decision, the evidence and the next review time in the same file.

Step 5: Report upstream, inform users, calendar deadlines

Check whether the maintainer already knows; if not, report through their security policy and offer any patch. Publish user guidance. Put the 72 hour deadline (from awareness) and the final report deadline (14 days after a fix is available) in the incident ticket.

What evidence should I keep for a market surveillance authority?

Article 13(13) requires manufacturers to keep the technical documentation and EU declaration of conformity available to market surveillance authorities "for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer". Annex VII's technical documentation covers your vulnerability handling process, including the SBOM. Article 13(25) also lets market surveillance authorities request SBOMs from manufacturers of particular product categories.

Keep one case file per exploited component vulnerability:

Make the file immutable once closed. A checksum manifest and write once storage are enough for most teams.

Common mistakes

1. Notifying because a CVE exists. Disclosure is not the trigger; evidence of exploitation of your product is.
2. Not looking because "it is upstream's problem". FAQ 5.4 puts integrated components inside your duty.
3. Treating a catalogue entry as the whole answer. It shows exploitation somewhere. Paragraph 218 asks about your product.
4. Deciding "not reachable" without writing it down. A decision without VEX, reviewer and date looks like a missed deadline.
5. Counting 72 hours from the platform display instead of your awareness time stamp.
6. Reporting to the wrong CSIRT, or registering only one Assigned Representative.
7. Forgetting old and unsupported products. Reporting covers products placed before December 2027 and continues after support ends.
8. Top level only SBOMs, which meet Annex I's minimum but not the operational need.
9. Flooding maintainers with duplicates when the guidance says you need not report what they already know.
10. Saying nothing to users until upstream releases. Article 14(8) asks for mitigations users can deploy now.

FAQ

Does the CRA require me to report vulnerabilities in open source libraries I use?

Only actively exploited ones, and per the Commission's guidance only where they are exploited in your product. Others go through vulnerability handling, an upstream report, and optionally voluntary reporting under Article 15.

When did CRA vulnerability reporting start?

On 11 September 2026, under Article 71(2). Article 69(3) extends it to products placed on the market before 11 December 2027.

Is a public proof of concept enough to count as actively exploited?

No. Article 3(42) requires reliable evidence of malicious exploitation. The Commission's FAQ says good faith findings, such as bug bounty reports without prior exploitation, are not mandatory reports.

Does a CISA KEV listing mean I must notify under the CRA?

Not automatically. It is strong evidence of exploitation somewhere. You must then assess whether your product contains the vulnerable code, whether it is reachable, and whether there is evidence your product has been exploited.

Who do I report to under the CRA?

Through ENISA's Single Reporting Platform to the CSIRT designated as coordinator where your main establishment is. ENISA gets simultaneous access unless particularly exceptional circumstances apply.

What happens if I miss the 24 hour CRA deadline?

Article 64(2) sets fines for breaches of Articles 13 and 14 of up to 15 million euro or 2.5% of worldwide annual turnover. Article 64(10) excludes microenterprises and small enterprises from fines for missing the 24 hour early warning deadline, and stewards from fines entirely. Submit late rather than never.

Do open source maintainers have to report under the CRA?

Most non commercial maintainers are not manufacturers. Stewards involved in development have reporting duties under Article 24(3) from 11 December 2027.

Do I need to tell the open source project about the vulnerability?

Yes under Article 13(6), unless you can confirm they already know, the component has no maintainer, or you no longer rely on them, per the guidance. Share your fix if you wrote one.

Can a VEX "not affected" statement replace a CRA notification?

It documents why no notification was mandatory, if the code truly cannot be exploited in your product. It cannot replace a notification where your product has been exploited.

Does the CRA final report deadline start from the exploit or from the fix?

From the fix: no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)).

Fix it without waiting for upstream

Under the CRA, a slow upstream release does not pause your duty to remediate, and the Commission's FAQ 4.3.6 expects integrators whose upstream will not help to switch components or develop a patch themselves. These are the ways Safeguard shortens that path.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The reporting decision rests on three questions: which shipped products contain the component, whether the vulnerable code is reachable there, and how quickly a fix reaches users. Safeguard scans repositories, container images and SBOM files, shows which projects contain a given component and version, applies reachability analysis, and accepts CSAF and VEX uploads. Its compliance suite lists the EU Cyber Resilience Act among its frameworks. It does not file your CRA notification; that stays with your Assigned Representative on ENISA's platform.

The first demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. In a CRA case, that loop builds and tests the corrective measure, and the fix date starts the 14 day final report window.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. That matters when the artifacts you must examine, such as old firmware images or customer specific builds, cannot leave your network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. During a 24 hour window, an analyst can ask in plain language which products carry a component and version, while you control which actions the assistant may take.

Click through it at your own pace, or open it full screen.

To try it, download Safeguard or read the CLI documentation. For the general reporting clock, see CRA Article 14 reporting in 72 hours and how fast a manufacturer must report an exploited vulnerability. For inventory, see SBOM incident response.

Quick check

Sources

• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act (official text)
• Regulation (EU) 2024/2847, Article 13, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 14, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 64, as published in OJ L 2024/2847
• European Commission: CRA reporting obligations
• European Commission: new guidance to support timely Cyber Resilience Act implementation (27 July 2026)
• European Commission: guidance on the application of the CRA, C(2026) 5252 annex
• European Commission: FAQs on the Cyber Resilience Act, version 1.4
• ENISA: CRA Single Reporting Platform
• ENISA: CRA SRP frequently asked questions
• ENISA: CRA SRP guidance, notification submission and update
• CISA: Known Exploited Vulnerabilities catalog
• OpenVEX specification
• OpenVEX vexctl

Last reviewed: 22 October 2026. This post is general information, not legal advice; check the linked Commission and ENISA pages for the latest guidance.