From Regulation to Repository: What the EU Cyber Resilience Act Asks of Engineering Teams

Kilo Code, now part of Anaconda, translates the CRA into the systems and workflows developers will need to put in place.

When Kilo Code joined Anaconda, it brought more than an open source, model-agnostic coding agent. It brought a community focused on the practical work of building, maintaining, and securing software.

That perspective matters as the first deadline under the European Union’s Cyber Resilience Act (CRA) arrives today. Kilo recently published a developer-focused analysis of the regulation, written by Arkadiy Kondrashov and Patrick Nack-Lehman. Its central point is simple: most CRA guidance is written for the people who own compliance, but much of the implementation work will fall to engineering and security teams.

The CRA regulates products, not companies. It establishes requirements for handling vulnerabilities in products you ship, reporting certain events within hours, and retaining evidence that may be needed years later. Those obligations will affect dependency management, incident response, release processes, product architecture, and engineering records.

This article translates the regulation and the European Commission’s guidance into the work it creates for the people who ship code.

Important: This article summarizes the CRA and the Commission’s guidance as we understand them. It is not legal advice. Whether the CRA applies to a particular product—and which role an organization holds—depends on the specific facts.

Two Dates Engineering Teams Need to Know

The CRA entered into force in December 2024, but its obligations apply in stages:

• September 11, 2026 (today): Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
• December 11, 2027: The CRA’s remaining requirements apply, including essential cybersecurity requirements, vulnerability handling, conformity assessment, and CE marking.

The European Commission’s implementation timeline tracks these milestones and the standards and guidance still in development.

The 2026 reporting deadline is no longer a planning horizon; it applies from today. The 2027 deadline may look more distant, but the required vulnerability-management, release, and documentation systems take time to design and operate reliably.

First Determine Whether the CRA Applies to Your Product

For software, a practical starting point is where it runs. Software executed on a user’s device can be a “product with digital elements.” Examples include downloaded applications, locally installed clients, command-line interfaces, browser extensions, mobile applications, and firmware.

Software accessed only through a browser generally does not fall within the CRA on that basis alone. However, a backend can come into scope as a remote data-processing solution when it is necessary for a covered product to perform one of its functions and is designed and developed by, or on behalf of, the product’s manufacturer. If a desktop application cannot perform one of its functions without its API, for example, that API may be part of the product.

Standalone cloud services designed outside the responsibility of a product manufacturer are generally outside the CRA’s scope; other rules, including NIS2, may apply. Calling a business “SaaS,” therefore, is not by itself an exemption. A company that also ships an installer, agent, CLI, application, or connected device may be a manufacturer for at least one product.

The organization’s role also matters. The CRA distinguishes among manufacturers, importers, distributors, open source software stewards, and contributors. The same organization can hold different roles for different products.

Publishing free and open source software to a public repository or package manager generally does not, by itself, constitute placing a product on the market. Charging for the software, monetizing related services through it, or making its use conditional on processing personal data can change that analysis. A repository or package manager that merely hosts third-party software is a separate case and is generally not placing that software on the market.

The Commission’s July 2026 CRA guidance addresses scope, free and open source software, remote data processing, support periods, reporting, and substantial modifications through 67 worked examples.

You Are Responsible for Vulnerabilities in Code You Did Not Write

This is the requirement most likely to reshape day-to-day engineering work.

The CRA’s vulnerability-handling obligations apply to the product as a whole, including integrated third-party components. When a component was not itself placed on the market, its developer may not be subject to the CRA’s vulnerability-handling obligations. The manufacturer of the finished product still is.

When a manufacturer identifies a vulnerability in an integrated component—including a free and open source component—the CRA requires more than internal remediation. Under Article 13(6), the manufacturer must report the vulnerability to the person or entity manufacturing or maintaining that component, and must address and remediate it in accordance with the vulnerability handling requirements in Annex I, Part II. Where the manufacturer has developed a modification that addresses the vulnerability in the component, it must share the relevant code or documentation with that maintainer, where appropriate in a machine-readable format. The Commission’s guidance clarifies that upstream notification is unnecessary when the maintainer is already aware of the vulnerability or no maintainer remains, and that the duty relates to the version actually integrated into the product.

Modern software products depend heavily on code developed elsewhere. Under the CRA, manufacturers can be accountable for those components even when they cannot fix the source directly. That makes dependency visibility, reachability analysis, documented triage, remediation, and upstream coordination part of the compliance implementation.

Some Vulnerabilities Will Start a 24-Hour Clock

The CRA’s reporting obligations begin today. There are two reporting triggers.

An Actively Exploited Vulnerability

The regulation defines an actively exploited vulnerability in Article 3(42) as one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission.

A published proof of concept does not by itself meet that test. Neither does a high Common Vulnerability Scoring System (CVSS) score. The vulnerability must also be contained in the product placed on the market.

The Commission’s guidance clarifies that a vulnerability in a third-party component is not subject to mandatory reporting when it cannot be exploited in the product—for example, when the vulnerable code is not reachable in the way the component is used.

A Severe Incident Affecting Product Security

A severe incident is one that negatively affects, or can negatively affect, a product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. It also includes incidents that have led, or can lead, to malicious code executing in the product or in a user’s systems.

This category is broader than an exploited software vulnerability. A compromised build pipeline or release channel can be a severe incident in its own right. If an attacker could have altered what reaches customers, product security may have been affected even if no specific product vulnerability was exploited.

Once a manufacturer becomes aware of a reportable event, the timetable is:

1. An early warning without undue delay and no later than 24 hours after awareness.
2. A fuller notification without undue delay and no later than 72 hours after awareness.
3. For an actively exploited vulnerability, a final report no later than 14 days after a corrective or mitigating measure becomes available.
4. For a severe incident, a final report no later than one month after the 72-hour notification.

The Commission’s reporting overview confirms these deadlines. The 24- and 72-hour periods are maximum limits, not target response times.

Reporting to a CSIRT is not the only duty that awareness triggers. Article 14(8) also requires the manufacturer to inform users of the product about the vulnerability or incident and, where necessary, about the risk mitigation and corrective measures those users can deploy, where appropriate in a structured, machine-readable format. If the manufacturer does not do so in a timely manner, the notified CSIRT may provide that information to users itself.

“Awareness” Depends on Prompt Triage

The reporting clock starts when the manufacturer becomes aware of the event, not when someone eventually chooses to investigate an alert.

The Commission’s guidance describes awareness of an actively exploited vulnerability as the point at which a prompt initial assessment provides a reasonable degree of certainty that a vulnerability contained in the product is being actively exploited. The important word for engineering teams is prompt. An organization cannot defer awareness indefinitely by leaving an alert untriaged.

That changes the meaning of a vulnerability backlog. It is no longer only a queue of maintenance work. It can contain events that require fast assessment to determine whether a legal reporting obligation has been triggered.

In practice, teams need three capabilities:

• A way to evaluate new advisories against the product’s dependency tree quickly enough to support a 24-hour reporting window.
• A way to determine whether vulnerable code is actually reachable in the product, because severity alone does not establish reportability.
• A durable record of what was assessed, what the team concluded, and why—including decisions not to take action.

The Reporting Process Has to Work Today

Manufacturers report once through ENISA’s Single Reporting Platform (SRP). The platform routes the submission to the appropriate national Computer Security Incident Response Team (CSIRT) and, except in defined exceptional circumstances, makes it available to ENISA at the same time.

The relevant CSIRT is generally the one in the Member State where the manufacturer has its main establishment. Under Article 14(7), that is the Member State where decisions about the cybersecurity of the manufacturer’s products are predominantly taken, which is not necessarily where the company is headquartered. Where that cannot be determined, it is the Member State in which the manufacturer has the highest number of employees in the Union. For manufacturers without a main establishment in the EU, the CRA establishes an order based on the location of the authorized representative, importer, distributor, and, ultimately, the largest number of users.

The Single Reporting Platform is scheduled to be operational from today, the date the reporting requirements begin. ENISA published the supporting material in the days immediately before launch: a list of the CSIRTs designated as coordinators for all 27 Member States, a field-by-field SRP Glossary, and registration and interface guidance. Teams should now have in place the organizational pieces that cannot be assembled comfortably inside a 24-hour response:

• Create an EU Login account now. ENISA advises organizations to register on the SRP itself only when they need to submit a notification. CSIRT validation of the assigned representative occurs in parallel with reporting and does not block submission.
• Pre-stage the legal entity, product, representative, and contact details the filing will require. ENISA’s SRP Glossary sets out the submission fields individually, so this can be prepared against the actual form rather than estimated.
• Plan for manual portal entry. ENISA has confirmed that the initial release offers no reporting API.
• Identify the designated CSIRT from ENISA’s published list of coordinators and decide who has authority to file.
• Name a primary assigned representative and a backup. Note that ENISA’s “assigned representative” is a platform login role, not the authorized representative appointed under Article 18. ENISA’s registration guidance uses a primary-and-secondary model, and invitations to secondary representatives expire after seven days.

Ambiguous escalation and filing authority can consume most of a 24-hour window. Put these decisions in the incident-response runbook now, if they are not there already.

Define What “Without Delay” Means for Remediation

The broader vulnerability-handling requirements apply from December 11, 2027, to products placed on the market from that date. Under Article 69(2), a product placed on the market earlier generally becomes subject to these requirements only if it is substantially modified after that date.

The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks they pose, including by providing security updates (Annex I, Part II, point 2). Where technically feasible, those security updates should be distributed separately from functionality updates.

The regulation does not assign a universal number of days to “without delay.” That does not remove the need for measurable internal deadlines. An assessor can examine whether an organization established a risk-based remediation policy, followed it, and retained evidence.

Engineering and security leaders should define deadlines by severity, escalation paths, exception handling, and the evidence retained for each decision. A policy such as 15 days for critical vulnerabilities and 30 days for high-severity vulnerabilities can be defensible only if it is appropriate to the risk, consistently followed, and documented. An unwritten intention to move quickly is not an operational control.

Separating security updates from feature releases is also more than a scheduling preference. It affects architecture, release processes, and the product’s conformity-assessment lifecycle.

Security Patches Generally Do Not Restart Conformity Assessment

Teams sometimes delay security fixes because they fear that an update will be considered a “substantial modification,” causing the product to be treated as newly placed on the market and requiring another conformity assessment.

A security update designed to reduce cybersecurity risk generally is not a substantial modification when it does not change the product’s intended purpose. The CRA’s recitals describe updates that make minor source-code changes to address a known vulnerability as a typical example. The Commission’s guidance goes further: a qualifying security update may avoid classification as a substantial modification even when it introduces significant technical changes.

The relevant test is not the size or complexity of the change. Article 3(30) defines a substantial modification as a change that affects the product’s compliance with the essential requirements in Annex I, Part I, or that modifies the intended purpose for which the product was assessed. The Commission’s guidance frames the practical question as whether the change has a potential adverse impact on the cybersecurity risk profile that was not accounted for in the original assessment.

This supports keeping security releases focused. Bundling a feature with a security fix does not protect the feature from a substantial-modification analysis. A feature that adds a new input or externally reachable interface may expand the attack surface regardless of whether it ships beside a patch.

There is an important boundary. A security-motivated update can still be a substantial modification if it materially changes dependency structures or data flows, or adds externally reachable interfaces. Replacing internal key management with a third-party service to address a cryptographic weakness is one example from the Commission’s guidance: the motivation is security, but the product’s risk profile has changed.

In Some Cases, Manufacturers Can Fix Forward

The CRA, in Article 13(10), allows a manufacturer that has placed a later, substantially modified version of a software product on the market to satisfy the remediation requirement only for the latest version, subject to conditions. Users of earlier versions must be able to obtain the latest version free of charge and without additional costs to adjust the hardware or software environment in which it runs.

This is not blanket permission to abandon old releases. The provision is connected to substantial modification, and each version placed on the market has its own declared support period. Releasing version 2.0 does not extend version 1.0’s support period, although it may reduce what must be remediated in 1.0 when the conditions for fixing forward are met. Other vulnerability-handling duties continue to apply.

The Commission interprets “additional costs” relatively narrowly. Ordinary personnel time, testing, configuration changes, and dependency upgrades associated with applying an update do not generally count. Requiring new hardware, replacement infrastructure, or a fundamental change to the operating environment does.

Support Periods Create a Long-Term Records Requirement

Five years is a floor for support periods, not an automatic default. The support period must reflect how long the product is expected to be in use (Article 13(8)). Products such as operating systems and industrial control systems can routinely require longer support.

A period shorter than five years requires justification based on the nature of the product and a genuine expectation that it will be used for less time (Recital 60).

The documentation obligations can last even longer:

• Technical documentation and the EU declaration of conformity must remain available to market-surveillance authorities for at least 10 years after the product is placed on the market, or for the support period if that is longer (Article 13(13)).
• Each security update made available during the support period must remain available for at least 10 years after it is issued, or for the remainder of the support period, whichever is longer (Article 13(9)).

The product’s vulnerability-handling process forms part of its technical documentation. Decisions about advisories therefore need to remain understandable and retrievable years later. Many teams cannot currently explain why a specific advisory was dismissed 18 months ago, much less produce that reasoning after a decade.

The system you implement now becomes the record. Information that is never captured may be impossible to reconstruct later.

Important Implementation Details Are Still Developing

Two areas deserve monitoring.

First, no CRA harmonized standard has yet been cited in the Official Journal of the European Union. Until that happens, the CRA’s presumption of conformity based on harmonized standards under Article 27 is not available for a product category. The horizontal standard for vulnerability handling will be particularly important because it will help define what adequate vulnerability handling looks like.

The timetable remains unsettled. In July 2026, the Commission published a draft amendment that would move some 2026 standardization deadlines back by two months. That amendment is still a draft and has not itself been published in the Official Journal. A finished standard and its citation in the Official Journal are also separate milestones. Drafts can help teams anticipate requirements, but they cannot yet establish conformity.

Second, the Commission’s guidance published on July 27, 2026, is non-binding. It was issued under Article 26 as the annex to Commission Decision C(2026) 5252. It is nevertheless the Commission’s own detailed interpretation of questions such as scope, substantial modification, support periods, risk assessment, and reporting, supported by 67 examples. It is useful for implementation planning and internal decision-making, but it does not replace the regulation itself.

What Engineering Teams Should Do Now

The reporting obligations are in force from today. Engineering, security, product, and legal teams should jointly:

1. Determine which products are in scope and document the role the organization holds for each one.
2. Create EU Login accounts for the people who may need to report and identify the designated CSIRT.
3. Decide who is authorized to file, name primary and backup representatives, and write the reporting runbook.
4. Establish risk-based remediation deadlines and escalation paths. These are part of the 2027 obligations, but the vulnerabilities identified through today’s triage need a defined destination.
5. Assess the existing dependency-alert backlog rather than allowing potentially relevant alerts to remain unexamined.
6. Begin recording triage and remediation decisions, including documented decisions not to act.

None of these steps depends on a completed harmonized standard.

Where Kilo Security Agent Fits—and Where It Does Not

No tool can deliver complete CRA compliance. Kilo Security Agent is intentionally narrower: it supports part of the vulnerability-remediation workflow for dependency vulnerabilities under Annex I, Part II, point 2.

The agent starts with GitHub Dependabot alerts. It triages each finding and, where needed, examines the repository to determine whether the advisory reaches code the product actually runs. It records the relevant files, code paths, and reasoning; opens remediation pull requests; tracks deadlines set by severity; warns before those deadlines are missed; and keeps the decision history attached to the finding.

A pull request is treated as an attempt to fix the issue, not proof of resolution. A finding remains open until the fix is confirmed or a person explicitly dismisses it.

That workflow addresses three engineering problems created by the CRA:

• The awareness backlog: Alerts are assessed as they arrive instead of waiting indefinitely in a queue.
• The reportability question: Reachability evidence helps a team decide whether an exploited vulnerability affects its product.
• The records problem: The assessment and its reasoning persist for later review.

The boundaries are equally important. Kilo Security Agent does not generate software bills of materials, file reports with ENISA or a CSIRT, notify upstream maintainers, or cover the other requirements in Annex I, Part II. It does not inspect application vulnerabilities, infrastructure, or container images. It requires GitHub with Dependabot enabled, so components outside that system are not visible. It also does not decide whether a vulnerability is legally reportable; it gives the responsible team evidence to support that decision.

That is one narrow part of a much larger regulation. But it is the part concerned with identifying, assessing, documenting, and fixing dependency vulnerabilities—and it is a workflow many engineering teams still need to build.

The CRA turns software security from a collection of good practices into a lifecycle obligation with deadlines and durable evidence. Compliance leadership can interpret the regulation and assign responsibility. Engineering teams will make it real—in dependency graphs, triage queues, incident runbooks, release pipelines, security updates, and records that need to remain useful for years.

The most productive way to prepare is to start with those systems now.