Cyber Resilience Act Compliance Consulting
The engineering side of the CRA: secure-by-design evidence, a vulnerability handling process that runs for the whole support period, technical documentation generated by your pipeline, and a team able to meet the 24-hour reporting clock.
The problem I usually find
Most teams I meet on this topic have already read the regulation, or a summary of it, and have concluded that the hard part is the paperwork. It is not. The hard part is that the CRA describes a process that runs for the entire support period of every product, and the current delivery process was never designed to produce that kind of evidence continuously.
The typical starting point has a few recurring features. Nobody has a complete list of which products, versions and embedded components are actually in scope. An SBOM was generated once, by hand, for a customer questionnaire, and nobody knows which build it describes. The vulnerability scanner reports two hundred findings per release, most of them in code the product never executes, so the team has stopped reading it. Security fixes ship inside feature releases, so a customer who cannot take the feature does not get the fix either. There is no published address to report a vulnerability to, and if a researcher wrote to the sales mailbox tomorrow it would take days to reach an engineer. And since 11 September 2026 the reporting clock is already running for products that were sold years ago.
How I work
I start from what the product and the pipeline already do, not from the text of the regulation. Annex I lists thirteen properties the product must have and eight things the manufacturer must be able to do with vulnerabilities. Each maps to a design choice, a build step or a process that either exists or does not, and the gap assessment is that mapping, done per product, together with the classification that decides whether a notified body is involved.
The work is then sequenced by what is already enforceable and by return. First the vulnerability handling process and reporting readiness, because Article 14 applies today and covers products already on the market. Then the supply chain evidence, SBOM, signing, secure updates, because everything downstream depends on knowing what is in each release. Then the Part I product requirements, which are mostly design work with the product team and feed the risk assessment. Technical documentation is not a phase of its own: it is assembled from the outputs of the previous three, so that it describes what ships and stays current on every release.
The tooling comes from what you already run. GitLab CI and GitHub Actions both have adequate options for generating SBOMs, signing artifacts and publishing advisories; the differences between them matter far less than whether the output is reviewed, kept and reachable when an authority asks for it.
I have done this kind of work for startups, scale-ups, enterprises and public sector organisations. Size changes who signs off, how long procurement takes and how many products share one pipeline; it does not change the sequence above.
What the engineering work covers
Scope and classification. An inventory of products with digital elements, including firmware, on-premise software, agents and edge components of SaaS products, and the third-party components they embed. Each product gets a class (default, important class I or II, critical) using the technical descriptions in Implementing Regulation 2025/2392, because that decides the conformity assessment route and therefore the calendar.
Product requirements (Annex I, Part I). Work with the product team on the requirements that are design decisions rather than pipeline steps: secure-by-default configuration and factory reset, automatic security updates with opt-out, authentication and access control, encryption in transit and at rest, integrity of configuration and firmware, data minimisation, resilience of essential functions, attack surface reduction, exploit mitigations, security logging, secure data deletion. Each one is either met, met with a documented justification, or an open item in the risk assessment.
Vulnerability handling (Annex I, Part II). A single point of contact that users and researchers can find, a coordinated vulnerability disclosure policy, and an intake that reaches an engineer. Triage recorded as VEX statements so that the same question is not investigated twice. Remediation targets by severity. Reporting upstream when the vulnerability is in a third-party component, as Article 13(6) requires. Security updates built and shipped separately from feature updates where technically feasible, with advisories in a machine-readable format.
Supply chain evidence. SBOM generated at build time, per artifact, in CycloneDX or SPDX, stored next to the artifact it describes, with the signature covering both. Provenance attestations that link the artifact to the commit and the pipeline run that produced it. A VDR per supported release, generated from the VEX history. Signing keys kept out of the pipeline and used through short-lived credentials, the same work I do on the SecDevOps side.
Secure update distribution. A channel through which users can verify that an update comes from you, security updates disseminated without delay and free of charge, and a retention plan so that each update stays available for the ten years the regulation requires.
Continuous monitoring. The SBOMs of every release still inside its support period are checked continuously against new vulnerability data. Matches go to the team that owns the component, with the VEX history attached, and feed the awareness assessment that may start the reporting clock.
Reporting readiness. Registration on the Single Reporting Platform, a written criterion for what “becoming aware” means in your organisation and where that moment is recorded, a runbook for the 24-hour early warning, the 72-hour notification and the final report, templates for informing impacted users, and a tabletop exercise so that the first time the team runs the sequence is not the real one.
Technical documentation (Annex VII). Versions affecting compliance, architecture, the vulnerability handling process with its SBOM and disclosure policy, the risk assessment, the support period rationale, test reports and the declaration of conformity, assembled from pipeline outputs on every release rather than written once before the assessment.
Typical situations
A manufacturer of connected devices whose firmware is built by a supplier, and who has to answer for the SBOM, the update channel and the support period without owning the build. An independent software vendor shipping on-premise software to customers who are themselves in scope and are already asking for SBOMs and disclosure policies in procurement. A SaaS company that thought it was out of scope until it counted its edge agents, mobile apps and on-premise connectors. A product built on Kubernetes that ships a container runtime or a hypervisor and is therefore class II. A public sector supplier whose tender responses now include CRA questions. In each case the regulation is the same; what changes is where the evidence has to come from.
What I do not do
I do not classify your product, choose the conformity assessment route or write the declaration of conformity. Those are decisions for you, your legal counsel and, when the class requires it, a notified body. What I make sure of is that when those decisions are taken, the product, the process and the documentation they depend on actually exist, are produced by your pipeline and describe what you ship.
What's included
- Product inventory and gap assessment: scope, classification (default, important class I or II, critical), current state against Annex I Parts I and II
- Engineering input to the cybersecurity risk assessment: attack surface, secure-by-default configuration, logging, data deletion, exploit mitigations, mapped to Part I requirements
- Vulnerability handling process: single point of contact, coordinated vulnerability disclosure policy, intake, triage with VEX, remediation targets, upstream reporting for third-party components
- SBOM generation in the pipeline (CycloneDX or SPDX), per artifact and per release, with VDR published alongside each supported version
- Artifact signing and provenance attestations, plus a secure update channel: security updates separate from functionality updates, advisories in machine-readable form, updates retained for the required period
- Continuous monitoring of every release inside its support period, with alerts routed to the owning team
- Reporting readiness: awareness criteria, 24-hour / 72-hour / 14-day runbook, Single Reporting Platform registration, user notification templates, and a tabletop exercise
- Annex VII technical documentation assembled from pipeline outputs: versions, architecture, processes, SBOM, test reports, support period rationale
- Release classification so the team can tell a maintenance update from a substantial modification before shipping it
- Handover: the internal team runs and extends everything without me
Frequently asked questions
Who does the Cyber Resilience Act apply to?
Manufacturers placing products with digital elements on the EU market: software and hardware that can connect to a network, directly or indirectly, and the components embedded in them, regardless of where the manufacturer is established. Importers and distributors have their own duties. Software offered purely as a service is out of scope, since NIS2 covers it, unless it is remote data processing without which the product cannot perform its functions. Free and open source software developed outside a commercial activity is not covered; organisations that sustain such projects may be 'open source stewards' with a lighter regime. The Commission guidance of 27 July 2026 (C(2026) 5252) walks through these boundaries with worked examples. Whether your product is in scope and in which class is a question for your legal advisor; my work starts once the answer is yes.
What are the Cyber Resilience Act deadlines?
Regulation (EU) 2024/2847 entered into force on 10 December 2024. Chapter IV, on notified bodies, applies since 11 June 2026. The reporting obligations of Article 14 apply since 11 September 2026, and they cover every in-scope product already on the market, not only new ones. Everything else, essential requirements, conformity assessment, CE marking and technical documentation, applies from 11 December 2027 to products placed on the market from that date, and to older products only if they are substantially modified. The Digital Omnibus package has not changed these dates.
What does the CRA actually require beyond an SBOM?
Two sets of essential requirements in Annex I. Part I concerns the product: no known exploitable vulnerabilities at release, secure-by-default configuration, security updates that can be installed automatically, access control, encryption of data at rest and in transit, integrity protection, data minimisation, availability under denial of service, limited attack surface, exploit mitigations, security logging and secure data deletion, each applied on the basis of a documented risk assessment. Part II concerns the manufacturer's processes: identify and document vulnerabilities and components (this is where the SBOM lives), fix them without delay, test regularly, disclose fixed vulnerabilities publicly, run a coordinated vulnerability disclosure policy, provide a contact for vulnerability reports, distribute updates securely, and ship security updates free of charge with an advisory. The SBOM is one point out of twenty-one.
Which class is my product in, and does it change the conformity assessment route?
Most products are in the default category and can be self-assessed. Annex III lists 'important' products in two classes, with technical descriptions in Implementing Regulation (EU) 2025/2392: class I includes operating systems, browsers, password managers, VPNs, network management systems, SIEMs, routers and switches, smart home security devices; class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, tamper-resistant microprocessors. Annex IV lists 'critical' products such as hardware security modules and smart meter gateways. Class II and critical products need a notified body or a European certification scheme. Class I can be self-assessed only by applying a harmonised standard, and no CRA harmonised standard has been cited in the Official Journal yet, so for now class I in practice also means a notified body. This is the decision that most affects timing and budget, and it should be taken early.
Is there a mandated SBOM format?
No. The regulation asks for a commonly used, machine-readable format covering at least the top-level dependencies, and gives the Commission the power to specify format and elements by implementing act, which has not been exercised. In practice this means CycloneDX or SPDX. The most concrete reference for content today is the German BSI Technical Guideline TR-03183-2, which market surveillance authorities are likely to lean on; building to that bar avoids rework when a standard is cited. The SBOM is not required to be public: it goes into the technical documentation and is handed to a market surveillance authority on reasoned request.
What is the difference between SBOM, VEX and VDR, and why do I need all three?
The SBOM is the inventory of components in a specific version of the product. A VEX statement is a judgement about one vulnerability in one of those components: affected, not affected, fixed or under investigation, with the reasoning. The VDR is the report assembled from those judgements, listing which known vulnerabilities concern a release and what has been done about them. The SBOM alone produces a long list of matches, most of them not exploitable in your product; the Commission guidance itself notes that a vulnerable component whose code is not reachable does not make the product's vulnerability 'actively exploited'. VEX is how you record that judgement once instead of re-investigating every week, and the VDR is what you hand to a customer or an authority.
What starts the 24-hour reporting clock?
Becoming aware of an actively exploited vulnerability in your product, or of a severe incident affecting its security. The Commission guidance reads 'aware' as having reached a reasonable degree of certainty after an initial assessment, and the Single Reporting Platform does not record that moment for you, so you need your own evidence of when the assessment concluded. From there: early warning within 24 hours, notification within 72 hours, final report within 14 days of a corrective measure being available (one month for incidents), all through ENISA's platform, with the CSIRT coordinator of your main establishment as the recipient. Separately, impacted users must be informed. Vulnerabilities you already knew were exploited before 11 September 2026 do not have to be reported retroactively.
How long do the obligations last?
For the support period, which the manufacturer sets according to the expected time of use and which must be at least five years unless the product is expected to be used for less. During that period vulnerabilities must be handled and security updates provided; each security update must then remain available for at least ten years or the rest of the support period, whichever is longer. The end date of support has to be printed in the user information. A vulnerability handling process that only covers the latest release does not meet this.
What is a substantial modification, and why does it matter for software that ships continuously?
A change after placing on the market that affects compliance with the Part I requirements or changes the intended purpose the product was assessed for. When that happens the modified product counts as newly placed on the market and must go through conformity assessment again. Security updates and maintenance releases are not substantial modifications; a release that adds control over connected machines to a monitoring dashboard is, to take one of the Commission's own examples. Teams that release weekly need a way to classify each release against this test before it ships, not after.
What are the penalties, and who enforces the CRA in Italy?
Up to EUR 15 million or 2.5% of worldwide annual turnover for breaching the essential requirements or the manufacturer obligations in Articles 13 and 14; lower ceilings for other breaches and for supplying misleading information to authorities. Enforcement is national. In Italy, Law 36/2026 designates the Agenzia per la Cybersicurezza Nazionale (ACN) both as notifying authority for conformity assessment bodies and as market surveillance authority, and CSIRT Italia, run by ACN, is the CSIRT coordinator that receives Article 14 notifications. The implementing legislative decree that fixes the national penalty scale is still pending.
Do you provide legal advice on the Cyber Resilience Act?
No. Product classification, the conformity assessment route, the support period decision and the contents of the EU declaration of conformity are decisions you take with legal counsel and, where the class requires it, a notified body. I cover the engineering side: making sure the product, the pipeline and the team produce the evidence those decisions rely on, and keep producing it after the assessment.
