EU Cyber Resilience Act: What Software Vendors Need to Implement

A release pipeline can produce a signed artifact, a clean vulnerability scan and a software bill of materials while the product team still cannot answer a basic question: how long will this product receive security updates?

The EU Cyber Resilience Act (CRA) makes that gap consequential. For software vendors within scope, security becomes a product-lifecycle responsibility with evidence, reporting and conformity obligations. Buying another scanner will not establish who owns those responsibilities.

Start with the product boundary and the economic operator’s role. Then connect the applicable legal duties to engineering work. Applying the same checklist to every downloadable application, hosted service and open-source project will produce expensive mistakes.

Determine what the product actually includes

Binding framework: Article 2 sets the scope; Article 3 supplies definitions. The CRA concerns products with digital elements made available on the Union market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A product can be hardware or software, including components placed on the market separately. Check the exclusions in Article 2 before applying the general requirements, including relevant sector-specific regimes. [1]

The difficult boundary is often the backend. Article 3 includes a product’s remote data processing solution where the software was designed and developed by, or on behalf of, its manufacturer and its absence would prevent the product from performing one of its functions. Hosting location alone does not settle this question.

Consider two hypothetical offerings:

• A connected device depends on its manufacturer’s hosted processing service to perform a product function. That service needs assessment as a remote data processing solution within the product boundary.

• A standalone browser-based business service has no such relationship with a product. Calling it SaaS does not establish CRA scope; being software delivered over a network does not by itself settle the legal test either.

The CRA therefore does not automatically apply to every SaaS offering. Equally, attaching a SaaS label to a product-dependent backend does not remove that backend from consideration. Distributed applications, downloadable clients, optional cloud functions and mixed product/service contracts need a documented assessment of the actual functions and commercial arrangement. Recital 12 provides interpretive context for remote processing; the operative definitions remain the starting point. [1]

Engineering recommendation: Draw the product boundary before drawing the compliance backlog. Record the client, firmware, separately marketed components, remote functions, dependencies and intended users. Ask legal counsel to review ambiguous boundaries. Record the reasoning, rather than a checkbox saying “cloud: out of scope.”

Assign the economic operator role

A company can occupy different roles for different products. Article 3’s definitions distinguish manufacturers, importers and distributors. A manufacturer includes a person who develops or manufactures a product, or has it designed, developed or manufactured, and markets it under their name or trademark. Outsourcing development does not automatically outsource manufacturer responsibility. Articles 13, 19 and 20 set out the respective duties; Articles 21 and 22 address circumstances in which other parties take on manufacturer obligations, including relevant modifications. [1]

Binding distinction: Free and open-source software developed or supplied outside a commercial activity is excluded by Article 2(3). That is not a blanket exemption for products containing open source. A commercial product manufacturer must assess its own obligations, including due diligence concerning third-party components under Article 13. [1]

An open-source software steward is a separate defined role. Article 24 requires a cybersecurity policy and cooperation with market-surveillance authorities; it also applies specified reporting duties in the circumstances described there. Do not simply copy the manufacturer’s complete conformity checklist onto a volunteer maintainer or assume every foundation is a steward. Determine the legal entity’s activities and the definition’s conditions first. [1]

Engineering recommendation: Name an accountable product owner, security response owner and release-evidence owner. Suppliers can supply evidence and fixes. Your customer-facing obligation needs an owner inside the responsible economic operator.

Plan against three application dates

The dates in Article 71 have different effects. They should not be collapsed into a single “CRA deadline.” [1]

Article 69 adds transitional rules. Products placed on the market before 11 December 2027 are generally subject to the requirements only if substantially modified from that date, but Article 14 reporting also applies to in-scope products placed on the market earlier. Product version, placement on the market and substantial modification need assessment; “we launched before 2027” is an inadequate conclusion. [1]

For manufacturers, Article 14 distinguishes actively exploited vulnerabilities from severe incidents having an impact on product security. It does not require the same reporting treatment for every vulnerability found by a scanner. The staged process includes early warning without undue delay and within 24 hours of awareness, followed by the relevant notification within 72 hours. Later reporting differs: the vulnerability final report is due no later than 14 days after a corrective or mitigating measure becomes available; the incident final report is due within one month after the incident notification, with progress reporting where required for an ongoing incident. Read the exact trigger, contents and recipient rules for each case. [1]

Engineering recommendation: Rehearse both paths with a security-response team and legal counsel. Record when the organisation became aware, who decides that a trigger is met, who submits through the applicable single reporting platform, and how affected users are informed. A hypothetical exercise can reveal missing ownership without manufacturing an actual incident.

Official guidance: The Commission’s reporting and implementation resources and ENISA’s Single Reporting Platform FAQ describe the current reporting arrangements. ENISA confirms that the platform became operational on 11 September 2026. Manufacturers report through the platform; reporting obligations for open-source software stewards under Article 24(3) apply from 11 December 2027. Check the latest operational instructions before filing. [2–5]

Translate Annex I into product-lifecycle work

Article 13 links the manufacturer’s obligations to a cybersecurity risk assessment and Annex I. The assessment must inform planning, design, development, production, delivery and maintenance. Annex I Part I sets product requirements; Part II sets vulnerability-handling requirements. Applicability must be reasoned in the context of the product and its risks. [1]

Annex I Part I also requires products to be made available without known exploitable vulnerabilities, based on the cybersecurity risk assessment. A scanner result is an input to that assessment; it cannot resolve reachability, exploitability or product context by itself. [1] In practice, engineering teams need a machine-readable way to justify unpatched or non-impactful findings. Standardized Vulnerability Exploitability eXchange (VEX) documents (such as CycloneDX VEX or CSAF) bridge this gap by formally recording whether a flagged component is reachable or exploitable in execution, providing an auditable record of the assessment and its rationale. A VEX status does not, by itself, prove that a vulnerability is unexploitable.

The following controls are engineering recommendations for implementing and demonstrating those duties. The legal anchors identify the obligations they support; the suggested implementation is not a prescribed CRA toolchain.

An SBOM helps establish what is present . It does not show whether a vulnerability is exploitable, whether a fix reaches users, or whether a conformity assessment is complete. Signing can help authenticate updates. SLSA provenance can support build-evidence work. Neither a signature nor a SLSA level proves CRA conformity.

Article 13 generally requires a support period of at least five years, unless the product is expected to be used for less than five years, in which case the period corresponds to its expected use time. Expected use can also require a longer support period. The assessment must consider the factors in Article 13; five years is not a universal ceiling. Security updates must remain available under the separate availability rule in that article. [1] The support period is distinct from the longer technical-documentation retention requirement described below.

Engineering recommendation: Keep the declared support duration and its end date together in the product lifecycle record. Make the same information available to customers in product information and purchasing material, and check that the release documentation agrees with it. Machine-readable lifecycle metadata, automated end-of-support notifications and reminders to renew dependency support are useful implementation choices; they are not prescribed CRA file formats or notification systems. The duration of support, availability of previously issued updates and retention of technical documentation are separate concepts.

Engineering consequence: A dependency that loses upstream maintenance before your product’s support ends creates a maintenance decision. Plan to replace it, maintain it yourself or obtain support. A green scan at release cannot make that future obligation disappear.

Build the evidence and choose the conformity route

Annex VII describes technical documentation. It goes beyond a vulnerability report: product description, design and development information, risk assessment, vulnerability-handling processes, applicable standards and assessment evidence must fit together. Annex II covers information and instructions for users, including the support-period end date. Treat these as maintained product records. [1]

Binding framework: Article 32 and Annex VIII govern conformity-assessment procedures. Classification matters. Do not assume every software product requires third-party certification, or that every vendor can rely on internal control. Important products in Annex III have class-dependent routes; critical products in Annex IV require their own assessment of the applicable provisions. For products outside the important and critical categories, internal control (Module A) is generally available. Important and critical product classifications require a product-specific assessment of Annex III or IV and the applicable Article 32 route. For important Class I products, internal control may remain available where the conditions concerning harmonised standards, common specifications or applicable certification schemes are met; otherwise third-party assessment may be necessary. Important Class II products generally require third-party assessment. Do not infer a product’s class from a broad label such as “security software” or “networking component”. Confirm the current lists and implementation measures for the product. [1]

Article 13 also addresses technical documentation, the EU declaration of conformity and CE marking following the applicable demonstration of conformity. A generated SBOM is one evidence input, not permission to attach a CE mark.

Engineering recommendation: Give each shipped release an evidence record linking its binary or image digest to the component inventory, test evidence, risk decisions, user information and support commitment. Retain the legally required documentation for the applicable period: Article 13 provides for ten years after placing on the market or the support period, whichever is longer. Retention of records and availability of updates are separate requirements. [1]

An illustrative release evidence manifest

The following YAML is a recommended engineering pattern, not a CRA-mandated file format. It links one fictional release to its evidence; it does not establish regulatory conformity or replace the applicable conformity assessment and technical documentation.

# Fictional identifiers and digest; no real build or assessment is claimed.

release: "example-product/2.4.1"
artifact:
  uri: "registry.example.com/vendor/example-product:2.4.1"
  digest: "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

evidence:
  sbom: "evidence/sbom.cdx.json"
  build_provenance: "evidence/provenance.intoto.jsonl"
  supply_chain_attestations: "evidence/attestations/"
  security_assessment: "evidence/product-risk-assessment.pdf"
  vulnerability_analysis: "evidence/vulnerability-analysis.json"
  tests_and_validation: "evidence/validation-report.json"

support:
  declared_period: "5 years from 2027-03-16"
  end_date: "2032-03-16"
  user_information: "docs/support-policy.html"

Paths are relative to a retained release-evidence archive; they are illustrative references, not downloadable evidence. The example’s five-year period is a fictional product decision, not a conclusion about the appropriate period for another product.

In a real implementation, verify that the artifact digest identifies the shipped bytes and that the SBOM and attestations refer to that same artifact. Retain immutable versions of the referenced evidence, with checksums and access controls. A mutable registry tag or a directory of reports alone cannot establish that connection. Treat a vulnerability analysis as an assessment with a date and product context, not a permanent declaration that the release is safe.

Start with one product and follow it through support

Engineering roadmap (illustrative; not a conformity-assessment procedure):

A workable roadmap has four outcomes:

1. A reviewed scope decision. Document the product, remote processing boundary, market activity, operator role and exclusions. Identify questions that require legal interpretation.

2. A reporting process that can run now. Assign authority, rehearse awareness and escalation, and verify the live submission procedure. Keep vulnerability and incident reporting paths distinct.

3. A release evidence chain. Connect risk assessment, Annex I requirements, component inventory, test results and Annex II user information to a specific release. Confirm classification and conformity route early enough to obtain external assessment if needed.

4. A funded support plan. Match the stated support period to dependency maintenance, update delivery, disclosure handling and evidence retention. Repeat the assessment when product functions or commercial arrangements change.

Product boundaries, commercial open-source activity, operator roles, substantial modifications and conformity classification can require product-specific legal advice. This article explains engineering planning and does not provide a legal opinion or a conformity determination.

The engineering test is concrete: can the responsible team take one supported release, explain its risks, identify its components, demonstrate its security decisions and deliver a verified fix to its users? That is a useful starting point for the work the CRA demands. Formal conformity still requires the full applicable legal process.

For help implementing the engineering work, talk to us about release automation, SBOM generation, provenance, vulnerability management and evidence retention. Our platform engineering work connects secure delivery pipelines with the teams operating and maintaining them. Scope interpretation and formal conformity decisions require the appropriate legal and assessment expertise.

Sources

[1] Regulation (EU) 2024/2847, EUR-Lex : Articles 2, 3, 13, 14, 19–24, 32, 69 and 71; Annexes I, II, III, IV, VII and VIII; Recital 12.

[2] European Commission: CRA summary .

[3] European Commission: CRA reporting .

[4] European Commission: CRA implementation .

[5] ENISA: single reporting platform FAQ .