What the EU CRA actually asks of your engineering team

This post summarises the regulation and the Commission’s guidance as we read them. It isn’t legal advice. Whether the CRA applies to your products, and in what role, depends on your specific facts.

Most writing about the EU Cyber Resilience Act is aimed at whoever owns compliance. That’s not who ends up doing the work.

Subscribe for free to receive new posts about AI industry and engineering.

The CRA regulates products, not companies. It says things about vulnerabilities in products you ship, deadlines measured in hours, and evidence you’re expected to produce years later. All of that lands on engineering and security teams, usually without a budget line and often without anyone senior having read past the summary.

This is the version for those teams. What changes, when, and what you need to have working.

From 11 September 2026 you have to report actively exploited vulnerabilities and severe incidents.

From 11 December 2027 the rest of the regulation applies: the essential requirements, vulnerability handling, conformity assessment, CE marking.

Both sets of requirements are worth understanding now, because the December 2027 work takes longer than sixteen months of runway suggests.

First, whether it applies to you

The test is where your software runs. Software that executes on a user’s device is a product with digital elements: a downloaded application, a locally installed client, a CLI, a browser extension, firmware. Software reached only through a browser generally isn’t, on that basis alone.

Backends come in scope as remote data processing where they’re necessary for the product to work. The practical test: is processing happening at a distance, would its absence stop the product doing one of its jobs, and did you build it. If your desktop app is useless without your API, the API is part of the product.

Recital 12 draws the line from the other side. Cloud services designed outside the responsibility of a product manufacturer aren’t in scope, and pure SaaS, PaaS and IaaS are handled by NIS2 instead.

So “we’re a SaaS company” isn’t the exemption people hope for. If you ship an installer, an agent, a CLI, a mobile app or a device, you’re probably a manufacturer for at least one thing.

Your role matters too. The CRA distinguishes manufacturers, distributors, open-source stewards and plain contributors, each with different obligations, and one company can hold different roles for different products.

Publishing free and open-source code to a public repository or package manager is generally not placing a product on the market, and the Commission’s guidance says so. But charging for it, monetising other services through it, or conditioning its use on processing personal data may change that determination. Hosting is a separate question: a repository or package manager that merely hosts other people’s software isn’t placing it on the market either, which is what Recital 20 addresses.

You own the vulnerabilities in code you didn’t write

This is the part that reshapes the work.

Vulnerability-handling obligations apply to your product in its entirety, including every integrated component. The Commission’s own FAQ is direct about the consequence: where you’ve integrated a component that wasn’t itself placed on the market, whoever developed it isn’t subject to the CRA’s vulnerability-handling obligations. You still are, for your whole product.

Recital 34 goes further. When you identify a vulnerability in a component, including a free and open-source one, you’re expected to tell whoever maintains it, remediate it in your product, and where applicable hand them the fix you applied. The July guidance narrows the upstream half usefully: you don’t have to report upstream if you can confirm the maintainer already knows, or if the component has no maintainer left, and the duty runs only to the version you actually integrate.

Read that as an engineer and the shape of the problem is clear. A modern product is mostly other people’s code. You’re accountable for all of it, you frequently can’t fix it at source, and you’re expected to push fixes upstream. Nobody’s dependency tree was built with that in mind.

From 11 September, some vulnerabilities start a clock

Article 14 reporting starts on 11 September 2026. Reporting has two triggers.

An actively exploited vulnerability. Article 3(42) sets the bar at reliable evidence that a malicious actor “has exploited it in a system without permission of the system owner,” and Article 14(1) attaches the duty to such a vulnerability “contained in” the product you placed on the market. A published proof of concept doesn’t count. A high CVSS score doesn’t count. And the Commission’s guidance is direct that a vulnerability in a third-party component which “cannot be exploited” in your product, its example being vulnerable code that is not reachable, is not caught by mandatory reporting.

A severe incident affecting product security. Article 14(5) frames it as something that negatively affects, or can negatively affect, the product’s ability to protect availability, authenticity, integrity or confidentiality, or that has led or can lead to malicious code running in the product or in a user’s systems.

That second trigger catches things people don’t expect. A compromised build pipeline or release channel can be a severe incident in its own right, whether or not any vulnerability was exploited. If someone could have tampered with what ships to customers, that’s product security.

The rhythm, once you’re aware: early warning “without undue delay and in any event within 24 hours,” the fuller notification on the same standard within 72 hours, and a final report no later than 14 days after a corrective measure is available. For a severe incident the final report is due within a month of the 72-hour notification. Note the construction on the first two. The hours are an outer limit, not a target.

The awareness problem

The clock starts when you become aware. Not when you decide to look.

Awareness is not the alert landing. The Commission’s July 2026 guidance places it at the point where, after a prompt initial assessment, you have “a reasonable degree of certainty” that a vulnerability “contained in” your product is being actively exploited. What you cannot do is stall that assessment. The guidance is explicit that the emphasis falls on prompt action to carry it out, so “nobody triaged it” is a worse position than “we triaged it and concluded it wasn’t reportable.”

Which reframes the alert backlog. It isn’t a queue of maintenance work anymore. It’s a queue of things you might already owe a report on and haven’t looked at. Triage stops being housekeeping and becomes the thing that discharges the obligation.

Practically, that means you need three capabilities you may not have:

• Something that assesses new advisories against your dependency tree fast enough to matter on a 24-hour clock
• A way to determine whether an advisory actually reaches code your product runs, because severity alone can’t answer the reportability question
• A record of what you assessed and concluded, including the ones you decided not to act on

Where to file, and why to set it up now

You report once, through ENISA’s Single Reporting Platform. It routes to the CSIRT of the member state where you have your main establishment and to ENISA at the same time. If you have no main establishment in the EU, Article 14(7) sets an order: the Member State of your authorised representative, then your importer, then your distributor, then where most of your users are. You file to that state’s CSIRT.

The platform wasn’t live as of the start of August 2026. It’s in pre-operational testing, scheduled to go live on 11 September, the day the duty starts. Three things worth doing before then:

• Registration uses an EU Login account, which you can create now at ecas.ec.europa.eu. Do that. But ENISA’s own guidance says to register on the platform itself only when you need to file, because CSIRT validation of your representative runs in parallel with reporting rather than blocking it. So pre-stage your legal entity, product and contact details and make same-day registration a step in the runbook, not a box you tick in advance.
• The initial rollout isn’t expected to include APIs, so filing will be manual portal entry rather than system-to-system. Don’t design a pipeline that assumes an API.
• Identify your designated CSIRT and decide who has authority to file. A 24-hour clock doesn’t survive an ambiguous escalation path. ENISA’s registration guidance uses a primary-representative model: one person registers for the entity and invites the others, and invitations expire after seven days. Name a primary and a backup.

“Without delay” has no number, so you set one

The remediation duty applies from 11 December 2027, and only to products placed on the market from that date onward. Under Article 69(2) a product placed on the market before 11 December 2027 only picks up the CRA’s remediation requirements if you substantially modify it after that date, and the Commission’s guidance confirms the Annex I Part II vulnerability handling duties don’t apply to it.

Remediation is described in Annex I Part II point (2), and the whole of it matters: in relation to the risks posed, address and remediate vulnerabilities without delay, including by providing security updates, and where technically feasible ship those updates separately from functionality updates.

There’s no timeframe in the text. Nobody hits compliance by clearing a threshold, because none exists. What can be assessed is whether you set a policy calibrated to risk, followed it, and can show it.

So write the policy. Deadlines by severity, a defined escalation path, and a record of adherence. Something like 15 days for critical and 30 for high is defensible if you meet it and can prove it. An undocumented intention to be quick is not.

Note the second half of that requirement too: ship security updates separately from feature work where you can. That’s an architecture and release-process decision, and it has a payoff explained below.

Patching won’t restart your conformity assessment

Teams sit on security patches because of a specific fear: that shipping the fix counts as a substantial modification, which treats the product as newly placed on the market and pulls it back through conformity assessment.

It generally doesn’t. Recital 39 says that where a security update designed to reduce a product’s cybersecurity risk doesn’t modify its intended purpose, it isn’t a substantial modification, and that this usually covers updates involving only minor source-code adjustments. It gives the example of an update addressing a known vulnerability. The July guidance goes further than the recital: a qualifying security update isn’t a substantial modification “even where that update may introduce significant technical changes.”

The test is whether the cybersecurity risk profile moved in a way you hadn’t already accounted for, not how big the change is. A dependency bump that closes a known vulnerability doesn’t move it in the direction that matters. So keep security releases clean.

The catch, and this is why separation matters: Recital 39 is explicit that bundling a feature change with a security update doesn’t shelter the feature change. A feature that adds a new input element broadens the attack surface and can be a substantial modification whether or not it shipped alongside a patch. The guidance puts it almost the same way: the assessment “should therefore not be based on the scale or complexity of the change, but on its potential adverse impact on the cybersecurity risk profile.”

One boundary. The guidance flags security updates that materially change your dependency structure or data flows, or add new externally reachable interfaces. Its own example is replacing internal key management with a third-party service to fix a cryptographic weakness. Security-motivated, still a substantial modification.

You may be able to fix forward

Article 13(10) lets a manufacturer that has placed subsequent substantially modified versions of a software product on the market meet the remediation requirement only for the version last placed on the market. Conditions: users of earlier versions can get the latest version free of charge, and they don’t incur additional costs to adjust the hardware or software environment they run it in.

Two limits worth knowing before you plan around it. It’s tied to substantial modification, so it isn’t blanket permission to abandon old releases. And every version placed on the market carries its own declared support period under Article 13(8). Shipping 2.0 doesn’t extend 1.0’s declared support period, though it can cut short what you actually have to remediate in 1.0, which is the point of the provision. Other vulnerability-handling duties keep running across all of them.

The guidance also reads “additional costs” narrowly. Personnel time, routine testing, configuration changes and dependency upgrades are the ordinary cost of applying an update and don’t count against you. Mandatory new hardware, infrastructure replacement or fundamental changes to the operating environment do.

Support periods and the records problem

Five years is a floor, not a default, and the two directions aren’t symmetric. Under Article 13(8) the support period reflects how long the product is expected to be in use. Longer than five years simply follows, and Recital 60 treats operating systems and industrial control systems as routine cases. Going below five is gated: Recital 60 permits it only where the shorter period is justified by the nature of the product and the product is genuinely expected to be in use for less.

Separately, Article 13(13) requires the technical documentation and EU declaration of conformity to stay available to market surveillance authorities for at least 10 years after the product is placed on the market, or the support period if that’s longer.

Article 13(9) is a separate duty in the same family. Each security update you make available during the support period has to stay available for at least 10 years after you issue it, or the remainder of the support period, whichever is longer.

Your vulnerability-handling process is part of what that documentation describes. Which means the decisions you make about advisories need to survive in a form someone can retrieve years later. Most teams have nothing that remembers why they dismissed a particular advisory eighteen months ago, let alone ten years. Whatever you build now is the record; whatever you don’t record is unrecoverable.

What’s still missing

Two things worth tracking rather than waiting for.

No CRA harmonised standard has been cited in the Official Journal, so the Article 27 presumption of conformity isn’t available for any product category. The horizontal standard on vulnerability handling is the one that will matter most, since it will define what adequate vulnerability handling looks like. Its timing is unsettled, and got less settled in early July when the Commission published a draft amendment to the standardisation request pushing the 2026 drafting deadlines back two months. That amendment is itself still a draft and not yet in the Official Journal. Citation is a separate, later milestone than a standard being finished. Drafts are public and worth reading to anticipate requirements, not to claim conformity.

And the Commission’s guidance published on 27 July 2026 is non-binding, and was approved as a draft pending all EU language versions. It’s the Commission’s own reading of scope, substantial modification, support periods and reporting, with 67 worked examples. Useful for settling internal arguments. Not a substitute for the regulation.

The five-week version

If you do nothing else before 11 September:

1. Work out which of your products are in scope and which role you hold for each.
2. Create an EU Login account and identify your designated CSIRT.
3. Decide who is authorised to file a report, and write the runbook.
4. Set remediation deadlines by severity and write them down. Not a September duty, but the September triage work needs somewhere to route what it finds.
5. Get your dependency alert backlog assessed, so you know what you’re already aware of.
6. Start recording decisions, including the ones not to act.

None of that requires a harmonised standard, a notified body, or a finished platform.

Where Kilo Security Agent fits

Plenty of tools claim to deliver CRA compliance. None do, this one included, so here’s the boundary.

Security Agent covers one requirement: Annex I Part II point (2), for dependency vulnerabilities. It works from GitHub Dependabot alerts, triages each one, and where it matters inspects your repository to determine whether the advisory reaches code your product actually runs, capturing the files, paths and reasoning behind the answer. It opens remediation PRs, tracks the deadlines you set by severity with warnings before they slip, and keeps every decision attached to the finding. A pull request counts as an attempt, not a resolution: findings stay open until the fix is confirmed or someone dismisses them explicitly.

That maps onto three of the problems above. The awareness backlog, because triage happens as alerts arrive rather than when someone gets to them. The reportability question, because reachability is what tells you whether an exploited CVE affects your product. And the records problem, because the assessment and the reasoning persist.

What it doesn’t do: generate SBOMs, file reports to ENISA or your CSIRT, notify upstream maintainers, or cover the other seven Annex I Part II requirements. It doesn’t touch application code, infrastructure or container images. It needs GitHub with Dependabot enabled, so components outside that are invisible to it. And it doesn’t decide whether a vulnerability is reportable. It gives you what you need to decide.

That’s a narrow slice of the regulation. It’s the slice about actually fixing things, and it’s the one most teams have no system for.

This post summarises the regulation and the Commission’s guidance as we read them. It isn’t legal advice. Whether the CRA applies to your products, and in what role, depends on your specific facts.

Thanks for reading Kilo Blog! Subscribe for free to receive new posts and support my work.