Navigating the CRA (EU Cyber Resilience Act) — Building “Evidence-Backed Releases” into Your Pipeline with the JFrog Platform

Introduction: On December 11, 2027, Products Without a CE Mark Disappear from the EU Market

For details on any of the measures described here, please feel free to contact XLsoft or the author of this document, Alex Wang. (For Japanese inquiries, click here.)

You have probably heard the phrase “EU Cyber Resilience Act” (hereafter, CRA) more than a few times over the past year. Just as with GDPR, it is tempting to think, “It’s an EU regulation, so it doesn’t concern us.” But the CRA applies to every manufacturer that places a product with digital elements on the EU market. That includes embedded devices, industrial machinery, connected home appliances, business applications, and the software running on all of them. For Japanese manufacturers and software vendors, this is not somebody else’s problem.

And here is the most important point. The CRA manages a product’s compliance status as part of the CE mark. In other words, a product that cannot obtain a CE mark cannot be sold on the EU market from December 11, 2027 onward. The essence of the CRA is that security shifts from “something we ought to do” to a precondition for selling at all.

Behind this lies a collision of three forces.

• The demand for speed — Pressure on release velocity has made the software supply chain more complex and dramatically expanded the attack surface.
• A new threat frontline — Software supply chain attacks have reportedly tripled in scale in recent years.
• Regulatory mandate — Regulations such as the CRA and NIST SSDF have shifted liability from the user to the producer, and now demand auditable proof of security across the entire product lifecycle.

In this article, we will lay out exactly what the CRA requires, and then look at how to use the JFrog Platform to turn “releases that come with evidence” into a repeatable system.

Which Class Does Your Product Fall Into?

The CRA divides products into four tiers and varies the rigor of conformity assessment by tier. Until you establish where your product sits, you cannot estimate how much preparation you need.

Tier	Definition	Examples	Conformity assessment
Default ~90% of products	All products with digital elements not listed in Annex III or Annex IV	Smart TVs, general consumer IoT devices, basic applications, connected home appliances	Self-assessment (Module A): the manufacturer signs the EU Declaration of Conformity and affixes the CE mark. No notified body required
Important – Class I (Annex III, Part I)	Products that perform a function critical to cybersecurity, or that pose a significant risk of serious disruption if compromised. Classification is based on core functionality, not on embedded components	Identity management and PAM systems, password managers, web browsers, smart home security products (smart locks, cameras, alarms), VPNs, routers, network switches, operating systems (other than general-purpose), SIEM	Self-assessment (Module A) if harmonised standards are applied in full. Otherwise a third-party notified body is required. Manufacturers that comply with harmonised standards benefit from a presumption of conformity
Important – Class II (Annex III, Part II)	High-risk products that could have severe or cascading effects if compromised. Third-party assessment is mandatory regardless of whether standards are applied	Hypervisors, container runtimes, industrial firewalls and IDS/IPS, tamper-resistant microprocessors, industrial automation and control systems	A third-party notified body is mandatory (Module B+C or Module H). The self-assessment route is unavailable. Assessment typically takes 3–12 months
Critical (Annex IV)	The highest-risk products, on which EU critical infrastructure may depend, or whose failure could disrupt critical supply chains	HSMs (hardware security modules), smart meter gateways, smart cards and secure elements, secure cryptoprocessors	European cybersecurity certification (EUCC) at assurance level “substantial” or above. Note: until the European Commission mandates a scheme, the same route as Class II applies (B+C or H)

There are two practical implications.

First, roughly 90% of products fall into the Default tier — meaning self-assessment is sufficient. What is required there is not a third-party audit, but “technical documentation and an SBOM that demonstrate on your own terms that the essential requirements of Annex I are met, a risk assessment, and a signed Declaration of Conformity.” Put the other way around: everything comes down to whether you can produce the documentation and the evidence.

Second, for companies with Class I products or above, whether you can apply harmonised standards in full is the fork in the road that determines whether you stay on the self-assessment route. It is worth tracking developments on the standards side early.

Conformity Assessment Modules A / B / C

Once the tier is settled, the next question is which module you will be assessed under.

Module	Content
Module A: Internal production control	Self-declaration of conformity only. The manufacturer independently assesses conformity with the essential requirements of Annex I, prepares the technical documentation (Annex VII), prepares an SBOM, carries out a cybersecurity risk assessment, signs the EU Declaration of Conformity, and affixes the CE mark
Module B: EU type examination	A notified body assesses the design. It examines the product’s technical design and vulnerability-handling processes against the requirements of Annex I and issues an EU type examination certificate. For the manufacturing phase it is always applied in combination with Module C
Module C: Conformity to type	Manufacturer-led production control. The manufacturer ensures that every unit produced in volume conforms to the type approved under Module B, and maintains the technical file and the Declaration of Conformity (DoC)
Module H: Full quality assurance	A notified body audits the entire quality management system (covering design, development, production, and vulnerability handling). Adding a new product requires submitting updated documentation to, and being reassessed by, the same body. It is the alternative to B+C for Important (Class II) and Critical products

Pay particular attention to Module H. The requirement to “audit the entire quality management system and reassess every time a new product is added” means that it simply does not work if your processes depend on manual effort and individual know-how. Conversely, if your pipeline and policies are codified and evidence accumulates automatically, Module H becomes a repeatable operation. This is precisely where solving CRA compliance with tooling delivers the greatest value.

The Four Key Points the CRA Demands

The legal text is vast, but the manufacturer’s obligations boil down to four points.

1. Security by design — Build the product with security in mind from the very beginning.
2. Create a bill of materials (SBOM) — Manage the composition of the software you use.
3. Remediate vulnerabilities — Keep shipping updates and fixes after the sale.
4. Reporting obligations — Notify the authorities within 24 hours when something goes wrong.

On top of these come retention obligations that back them up. Technical documentation and the Declaration of Conformity must be retained for 10 years and kept in a state where they can be presented to the authorities. In addition, free security updates must be provided throughout the support period, and vulnerability tracking must continue for a minimum of 5 years per release.

This is not “ship it once and you’re done.” It means maintaining, for every version you have ever released, the ability to answer questions about its composition and vulnerability status for years afterward. That is the CRA’s substantive demand — and a hand-maintained Excel ledger will not survive it.

The Reporting Timeline — and Why “There Is No Fixed Threshold for Vulnerabilities”

The reporting obligations that take effect on September 11, 2026 have three stages.

Stage	Deadline	What must be reported
Early warning notification	Within 24 hours of the manufacturer becoming aware	The EU Member States in which, to the manufacturer’s knowledge, the digital product has been made available (where such information can be provided)
Vulnerability notification	Within 72 hours of the manufacturer becoming aware	General information about the digital product / the means of exploitation and the nature of the vulnerability / corrective or mitigating measures taken / corrective or mitigating measures available to users / how sensitive the manufacturer considers the reported information to be (where such information can be provided)
Final report	Within 14 days after a corrective or mitigating measure becomes available	A description of the vulnerability including its severity and impact / information about any malicious actor that has exploited or is exploiting the vulnerability (where available) / details of the security update or other corrective measures that fix the vulnerability

Note: the table above covers the track for “actively exploited vulnerabilities.” Severe incidents likewise require a 24-hour early warning and a 72-hour notification, but the final report deadline on the incident track is one month. Which of your own events fall on which track is something to sort out while you are designing the reporting flow.

Here is a critical point that many organizations overlook. There is no uniform, fixed threshold for vulnerabilities.

Under the CRA, checking whether a CVE exists and looking at its CVSS score is not enough. What is required is a reality-based judgment of whether the vulnerability is genuinely exploitable, and whether it is actively exploited — and in recent years the shift toward SSVC (Stakeholder-Specific Vulnerability Categorization) has drawn considerable attention.

This lands directly on day-to-day operations. A mechanical rule such as “fix everything with CVSS 7.0 or above” will cause you to miss events that must be reported, while burning your developers’ time on a mountain of vulnerabilities that cannot be exploited at all. In practical CRA compliance, a mechanism that can determine whether a given vulnerability is actually reachable and exploitable in the context of your own product becomes a precondition.

CRA Compliance Does Not End with Paperwork

If you map the CRA’s requirements onto the stages of the software supply chain (Design → Create → Package → Promote → Distribute → Deploy → Run), you can see that the requirements are scattered across every single stage.

• Design — Cybersecurity risk assessment, security-by-design requirements (Annex I), determining the product classification (Annexes III and IV)
• Create — Secure development practices, establishing a vulnerability-handling process, opening the technical documentation (Annex VII)
• Package — Generating the SBOM
• Promote — Finalizing the technical documentation and DoC, signing the EU Declaration of Conformity, affixing the CE mark. For Class I and above, this is where a notified body’s type examination (Module B) or QMS audit (Module H) comes into play
• Distribute — Retaining the technical file and documentation for 10 years, providing the SBOM to the authorities
• Deploy / Run — Free security updates throughout the support period, vulnerability reporting (24-hour early warning / 72-hour notification)

In short, if you confine CRA compliance to the legal and QA departments as a “certification project,” you will fail. The majority of the requirements have to be satisfied inside your day-to-day development and release pipeline.

And what sits at the center of that pipeline? Not source code. The binaries — the artifacts — you actually ship. What the SBOM describes, what you track vulnerabilities against, what the evidence you retain for 10 years points to: all of it is “that specific binary we shipped back then.” This is exactly why the JFrog Platform works as the foundation for CRA compliance.

How to Address the CRA with the JFrog Platform

The JFrog Platform makes Artifactory the single source of truth, centrally managing packages in every language, binaries, container images, and even AI models — all with their metadata attached. It caches external OSS repositories, natively supports CI/CD tools, and handles distribution to multi-cloud environments, data centers, and IoT devices in one continuous flow.

On top of this architecture, we implement the CRA’s requirements in three layers.

Lock Down the Entry Point — JFrog Curation / Catalog / IDE Plugins

The CRA imposes strict legal liability on manufacturers. Even when a vulnerability originates in an OSS component you did not write, the responsibility for shipping it as part of your product is yours. That is precisely why blocking at the entry point is the most cost-effective control available.

• Secure by design enforcement — Unsafe open source packages, and those carrying severe vulnerabilities, are automatically blocked at the gate before they can enter the software supply chain. Because the model is “don’t let it in” rather than “pull it in and fix it later,” downstream rework disappears.
• Third-party due diligence — Build a “clean pipeline” environment that guarantees third-party components will not compromise your product’s cybersecurity, and reduce the CRA’s strict liability risk.
• Shift-left resolution — IDE plugins let developers identify and resolve vulnerabilities directly from their own desks. The ability to maintain continuous compliance without slowing release velocity is the key to keeping regulatory work from becoming a drag on development.

Automate Detection and Proof — JFrog Xray / Advanced Security / Runtime

• Automated SBOMs & VEX — Generate the machine-readable, mandatory SBOMs enriched with VEX (Vulnerability Exploitability eXchange) data. This lets you satisfy the CRA’s strict product documentation requirements, and the obligation to track vulnerabilities for a minimum of 5 years per release, at the artifact level. Turning the SBOM from “a deliverable hand-assembled at release time” into “a by-product of the pipeline” is the only realistic way to withstand 5- and 10-year retention obligations.
• Contextual Analysis — This is the direct answer to the “no fixed threshold” problem described above. By identifying which CVEs are genuinely reachable and exploitable, it resolves the prioritization paradox. It also provides automated alerts so teams can meet the CRA’s reporting deadlines to ENISA (24-hour early warning / 72-hour detailed notification / final report). Given that the reporting obligations apply ahead of everything else, in September 2026, this is the area to address first.
• Secure by design infrastructure — Continuously scan Infrastructure-as-Code (IaC) to ensure your deployments satisfy the CRA’s security-by-design configuration obligations.
• Runtime — Scan and monitor container runtime environments to track CVEs newly discovered in the “post-shipment world.” The continuous vulnerability handling the CRA requires throughout the support period is not achievable without runtime visibility.

Back Every Release with Evidence — JFrog AppTrust

The last and thorniest challenge in CRA compliance is proof. There is a deep gulf between claiming “we built it securely” and proving it in an auditable form to authorities and notified bodies. AppTrust removes manual bottlenecks through a legally defensible system of record, and automates CRA compliance and continuous governance.

• Release lifecycle management — Provides a structured promotion flow that physically moves immutable application bundles through defined stages (DEV → QA → PROD). Each stage has entry and exit gates, so only releases verified by audit reach production. Accidents of the form “a different binary from the one we tested went to production” become structurally impossible.
• Automated evidence collection — Consolidates security, quality, performance, and release evidence into a single source of truth and cryptographically binds it to the binary. This establishes a tamper-evident chain of custody. Ten years from now, when someone says “show me the technical documentation for this version,” you can retrieve it with the original binary and its evidence still linked together — that is the answer to the CRA’s retention obligations.
• Policy as Code (PaC) — Translates complex CRA regulations into executable Open Policy Agent (OPA) code. You can apply automated release gates that pre-emptively block non-compliant software, turning your interpretation of the regulation into an asset that is reviewable, testable, and version-controlled. Codified processes like these are what stand up to Module H’s “audit of the entire quality management system, plus reassessment whenever a new product is added.”

The “Application Risk Governance” AppTrust Delivers

Let me add a little more about where AppTrust sits. AppTrust is the layer that lets you trust your software’s security and drive compliant releases through evidence-based controls and contextualized insights. It puts GRC and compliance, release and engineering management, DevOps, and DevSecOps/AppSec — the very functions that inevitably collide during CRA compliance — on top of the same data.

Trust gets built like this.

1. A clear application entity and overview — The unit called “the product” is uniquely defined, together with its artifacts, versions, and dependencies.
2. Evidence-based policies acting as strategic gates across the SDLC — The conditions for passing each gate are backed by evidence.
3. Application versions that comply with defined policies are marked “Trusted” — The basis for the Declaration of Conformity is established mechanically.
4. Post-release monitoring for new CVEs to ensure continued trust — Vulnerabilities discovered after shipment feed directly into the 24-hour and 72-hour reporting flow.

What the CRA asks for is precisely the operationalization of these four points.

Three Steps to Start Today

Working backward from the deadlines, the order in which to begin is clear.

Step 1: Confirm your product classification (right now)

Determine whether your EU-bound products fall under Default, Important Class I, Important Class II, or Critical. Note that classification is based on core functionality, not on embedded components. If Class II or above is in scope, third-party assessment will take 3 to 12 months — and no notified body has been designated yet. When you start preparing becomes decisive.

Step 2: Build out your reporting capability (targeting September 11, 2026)

The reporting obligations arrive before full applicability. Against a clock that starts ticking “24 hours from becoming aware of an exploited vulnerability,” you need to be able to answer immediately which versions of your product were supplied to which EU Member States. That is physically impossible unless your artifacts and SBOMs are centrally managed. The fastest route is to build the path from detection to reporting first, using Xray’s Contextual Analysis and automated alerts.

Step 3: Automate the evidence (targeting December 11, 2027)

Technical documentation, SBOMs, risk assessments, test results, exception management, scheduled reviews — the CRA calls for a wide range of deliverables, and collecting them by hand will break down with every release. Use AppTrust’s automated evidence collection and Policy as Code to reach a state where the evidence is already assembled the moment you release. That is the foundation for maintaining the CE mark on an ongoing basis.

Summary

The CRA has turned security from an aspirational goal into a condition of market access. And what it demands is not the fact that you have deployed security products, but auditable proof across the entire product lifecycle.

• Two deadlines. Reporting obligations on September 11, 2026; full applicability on December 11, 2027.
• Roughly 90% of products can be handled by self-assessment (Module A) — provided you can produce technical documentation, an SBOM, a risk assessment, and a signed Declaration of Conformity.
• Class II and above require third-party assessment. No notified body has been designated yet, and assessment takes 3–12 months.
• There is no uniform threshold for judging vulnerabilities. Judgment must be based on exploitability (SSVC and similar approaches).
• Technical documentation must be retained for 10 years; vulnerability tracking must run for at least 5 years per release.

The JFrog Platform locks down the entry point with Curation, automates detection and the generation of SBOMs and VEX with Xray / Advanced Security / Runtime, and delivers tamper-evident evidence and policy gates with AppTrust. Move CRA compliance from “a project where you scramble to gather documents before an audit” to “a system where evidence accumulates every time you release.” That is the most realistic approach to making the deadlines.

Article Author: Alex Wang | JFrog Japan

During my time in strategy consulting, I led projects across the IT, automotive, and manufacturing industries as an Agile and DevOps coach, building out development environments and CI/CD pipelines. Today I work on bringing DevSecOps and Liquid Software to the Japanese market.

---

If you would like to discuss concrete next steps for your own CRA program, please do not hesitate to get in touch.

---

This article is published with permission from JFrog.
Reference: What Is the EU Cyber Resilience Act (CRA)? (Japanese)