The EU Cyber Resilience Act Is Now an Engineering Delivery Programme
What CTOs and VPs of Engineering need to fund for the September 2026 reporting deadline and full application in December 2027.
Executive brief
The Cyber Resilience Act changes the release criteria for hardware and software sold in the European Union. Product security can no longer depend on a penetration test near launch, an inventory spreadsheet maintained by one engineer, or a support team trying to reconstruct old builds after a vulnerability is disclosed.
For engineering leaders, the immediate work is clear:
- Confirm which products, components and remote services are in scope, and identify the legal role your company plays for each one.
- Make the 24-hour and 72-hour reporting workflow operational before 11 September 2026.
- Build product security requirements into planning, architecture, CI/CD, release approval and maintenance.
- Produce version-specific SBOMs and evidence from the build system instead of reconstructing them before an audit.
- Fund secure update delivery and vulnerability handling for the declared support period.
- Decide the conformity route early, especially for important and critical product categories.
Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents affecting product security.
The main CRA obligations apply, including essential cybersecurity requirements, conformity assessment, technical documentation and CE marking.
Start with scope, not tools
A surprising amount of CRA work can be wasted by starting with scanners or SBOM platforms before deciding which products and company roles the regulation covers.
The CRA applies broadly to hardware and software products with a direct or indirect data connection that are made available on the EU market. It can cover finished products, separately sold components and remote data processing that is necessary for a product to perform one of its functions. A company outside the EU can still be affected when its products are supplied in the EU.
The word manufacturer also matters. Under the CRA, it includes a business that develops or has a product developed and markets it under its own name or trademark. Importers and distributors have their own obligations. A contract manufacturer, an OEM, a software supplier and a brand owner may therefore have different responsibilities for the same product.
Do not assume every connected product follows the same route
Some products are excluded or treated differently because other EU legislation already covers their cybersecurity. Medical devices, certain vehicle systems, civil aviation products and marine equipment require careful regulatory mapping. Ask legal and regulatory specialists to confirm scope. Engineering should provide the product architecture, connectivity, component and market facts that make that decision possible.
Your first deliverable should be a product applicability register. For every product family, record:
- legal manufacturer, importer and distributor;
- EU markets and channels;
- hardware, firmware, applications and required remote services;
- product category and expected conformity route;
- current and expected support period;
- engineering, product security and regulatory owners;
- products already on the EU market that fall under the September 2026 reporting obligations.
The decisions engineering leaders own
The legal team can interpret the regulation. It cannot decide how an old firmware branch will be rebuilt, how signing keys will be protected, which team owns a vulnerable bootloader, or whether the update service can safely recover ten thousand devices after a failed rollout. Those are engineering and product decisions.
| Leadership decision | What must be funded | Evidence of progress |
|---|---|---|
| Who owns product security? | A named accountable executive, product security lead and cross-functional response team. | Decision rights, escalation path, on-call coverage and tested response playbook. |
| Can every shipped release be reconstructed? | Reproducible build practices, retained source and dependencies, protected artefacts and release provenance. | A team can rebuild and patch a supported release without relying on a retired laptop or untracked package feed. |
| Can affected products be found quickly? | Product and release inventory, automated SBOM generation and vulnerability correlation. | A component or CVE query returns affected products, versions, owners and customers within hours. |
| Can updates be delivered safely? | Signing, key management, authenticated delivery, staged rollout, recovery and telemetry. | A signed security release is deployed, monitored and rolled back in a controlled exercise. |
| Can the company demonstrate conformity? | Risk assessment, secure lifecycle controls, technical documentation and the correct assessment route. | Evidence is linked to the released product version and remains available after team changes. |
Do not hide this work inside a generic security budget. The programme crosses product engineering, platform engineering, cloud operations, quality, regulatory affairs, legal, customer support and procurement. Someone needs authority to resolve priorities across those teams.
Prepare for the September 2026 reporting deadline first
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The reporting clock starts when the manufacturer becomes aware, not when engineering has completed a root cause analysis.
| Deadline | Required action | Engineering implication |
|---|---|---|
| Within 24 hours | Submit an early warning after becoming aware of an actively exploited vulnerability or severe incident. | The intake and escalation process must operate outside normal office hours. The team needs enough verified product context to make an initial report. |
| Within 72 hours | Submit the main notification with available general information and an initial assessment. | Engineering, security, legal and communications need a common incident room, clear approval authority and preserved technical evidence. |
| After corrective action | For an actively exploited vulnerability, submit the final report no later than 14 days after a corrective or mitigating measure is available. | Remediation, test, release, customer communication and reporting records must refer to the same product versions. |
| Within one month | For a severe incident, submit the final report within one month of the 72-hour notification. | The investigation must produce an approved technical account, impact assessment and corrective action record. |
Notifications will go through ENISA's Single Reporting Platform to the relevant Computer Security Incident Response Team and ENISA. Registration mechanics and operational guidance should be checked against the latest ENISA information as the platform goes live.
Run a reporting drill before the deadline
Use a realistic scenario: a widely used open-source component in three released product families is confirmed as actively exploited. Start the clock. Ask the team to identify affected versions, determine ownership, preserve evidence, draft the 24-hour warning, form an initial risk view, brief leadership and plan customer action. The drill will expose missing contacts and approval delays faster than another policy review.
Build the engineering capabilities behind compliance
The CRA describes outcomes and obligations. Your engineering system has to produce those outcomes repeatedly across every supported release. Seven capabilities deserve dedicated ownership.
-
Product, release and ownership inventory
Maintain a queryable record of product families, hardware revisions, firmware and software versions, required cloud services, support dates and accountable owners. Link releases to source revisions, build records, SBOMs, tests, signing events and deployed populations.
The operational test is simple: when a new vulnerability arrives, can the company identify the affected products and the person who can make a remediation decision before the reporting clock becomes a problem?
-
Cybersecurity risk assessment tied to product decisions
The risk assessment should follow the product from planning through maintenance. It needs to cover intended purpose, reasonably foreseeable use, attack surfaces, trust boundaries, data and function criticality, supply-chain dependencies and misuse cases.
Threat modelling is useful only when findings become backlog items, architecture decisions, tests or accepted risks with an owner and review date. A diagram that is filed once and never revisited will not change the product.
-
Automated SBOM and component governance
The CRA's vulnerability handling requirements include creating a machine-readable SBOM that covers at least top-level dependencies. Generate it in the production build, version it with the release and protect it as part of the technical record.
An SBOM alone does not answer whether a vulnerability is reachable or exploitable in your product. Add component approval, supplier due diligence, licence controls, vulnerability correlation and impact analysis. VEX can communicate exploitability decisions in a structured way, although VEX itself is an implementation choice rather than a separately named CRA obligation.
-
Secure development and release controls
Translate product risk into controls engineers can use. Typical measures include secure coding standards, peer review, secret scanning, static analysis, dependency and container scanning, infrastructure-as-code checks, fuzzing for parsers and network interfaces, penetration testing for higher-risk releases, and release approval based on risk.
A scanner result is not evidence that risk is controlled. Define who triages findings, what blocks a release, how exceptions expire and how unresolved risk reaches the accountable product owner.
-
Secure build, signing and update delivery
Protect build identities, signing keys and artefact repositories. Sign release artefacts, verify authenticity before installation and prevent unauthorised downgrade where product safety permits. For connected devices, use staged rollout, deployment telemetry, recovery paths and tested key rotation.
Automatic security updates are preferred where appropriate, but the design must reflect safety, availability, bandwidth and regulated change-control constraints. The control should follow the risk assessment, not a universal checklist copied across products.
-
Vulnerability intake and coordinated response
Provide a clear way for researchers, customers, suppliers and internal teams to report vulnerabilities. Define severity and exploitability assessment, remediation ownership, coordinated disclosure, customer communication and regulatory reporting.
Many companies call this function a PSIRT. The CRA does not require that job title, but it does require the underlying work to happen. Give the function authority, engineering capacity and an executive escalation path.
-
Support-period engineering
The support period needs a technical and commercial basis. In general, it must be at least five years. If the product is reasonably expected to be used for less than five years, the support period can reflect that shorter expected use. For longer-lived equipment, the reasonable support commitment may be much longer.
This decision affects dependency choices, maintenance branches, test infrastructure, cloud compatibility, signing-key lifetime, supplier contracts and staffing. The reasoning belongs in the technical documentation, and the end date must be communicated to users at the time of purchase.
There is also a retention consequence. A security update issued during the support period must remain available for at least ten years after it is issued, or for the remainder of the support period, whichever is longer.
Before committing to a long support period, prove that the organisation can rebuild, test, sign and distribute an update for an older supported release. Sales promises do not create maintenance capability.
Make compliance evidence a release output
The full CRA regime requires more than secure code. Before placing an in-scope product on the market, the manufacturer needs the applicable conformity assessment, technical documentation, an EU declaration of conformity and CE marking.
Most default-category products can use manufacturer self-assessment. Important and critical product categories can require harmonised standards, an applicable certification route or participation by a notified body. Misclassification can leave the company with too little time to secure external assessment capacity.
Standards are still developing
Harmonised standards can provide a presumption of conformity, but the CRA standardisation programme is still progressing. Do not postpone basic engineering improvements while waiting for every standard. Maintain a requirements-to-evidence map that can be updated as standards and Commission guidance mature.
A practical release evidence pack should contain or link to:
- product description, intended purpose and architecture;
- cybersecurity risk assessment and threat model;
- requirements and design decisions addressing identified risks;
- version-specific SBOM and third-party component records;
- security test results, accepted exceptions and approvals;
- build provenance, artefact hashes and signing records;
- update, recovery and vulnerability handling procedures;
- support-period decision and user-facing security instructions;
- conformity assessment records and declaration of conformity.
Generate this pack from delivery systems where possible. Evidence assembled by hand after release is expensive, incomplete and difficult to trust. Technical documentation and the EU declaration of conformity need to remain available to market surveillance authorities for at least ten years after the product is placed on the market, or for the support period if that is longer.
Use a two-speed delivery plan
Engineering leaders now have two different deadlines. Reporting readiness is urgent. Full product conformity is a broader programme. Treating both as one large project is likely to delay the first and blur the second.
| Period | Delivery focus | Exit test |
|---|---|---|
| Now to 11 September 2026 | Confirm reporting scope, name accountable owners, establish 24-hour and 72-hour workflows, monitor for exploitation, prepare platform access and run a timed drill. | A simulated actively exploited vulnerability is identified, assessed, escalated and reported within the required windows. |
| September to December 2026 | Complete product applicability and classification, baseline gaps, choose pilot product families and define the common product-security platform backlog. | Every in-scope family has an owner, conformity route, support assumption and prioritised remediation plan. |
| January to June 2027 | Automate SBOMs and evidence, strengthen secure development controls, formalise vulnerability handling, address build provenance and improve signing and key management. | Pilot releases produce a complete, reviewable evidence pack without a manual collection exercise. |
| July to September 2027 | Scale controls across product lines, complete higher-risk security testing, engage notified bodies where required and close update or recovery gaps. | Representative products pass internal conformity reviews and operational update exercises. |
| October to 11 December 2027 | Resolve residual findings, approve declarations, confirm CE marking and user information, validate retained evidence and exercise post-market response. | No product enters the EU market without the approved assessment route, evidence and post-market owner. |
Review metrics that expose real risk
A monthly steering meeting does not need a large maturity dashboard. It needs a small set of measures that reveal whether the organisation can secure and support what it sells.
| Metric | Question it answers |
|---|---|
| Product families with confirmed scope, category and owner | Do we know what we are accountable for? |
| Supported releases with build-generated, version-specific SBOMs | Can we locate third-party exposure quickly? |
| Time to identify affected products after a critical component advisory | Is our inventory useful under pressure? |
| Time from vulnerability intake to accountable engineering owner | Does the response workflow work? |
| Supported products that passed an update and recovery exercise | Can we safely remediate products already in use? |
| Open high-risk exceptions beyond their agreed date | Are temporary decisions becoming permanent risk? |
| Target releases producing a complete evidence pack | Are we building auditability into delivery? |
Tool counts, scan counts and training attendance can help teams manage work, but they are weak executive measures. A thousand scans do not prove that a supported product can be patched or that a severe incident can be reported on time.
Questions a CTO or VP Engineering should ask this month
- Which of our current and planned products are in scope, and who has approved that conclusion?
- Which products already on the EU market fall under the reporting obligations from 11 September 2026?
- Who can declare that we are aware of an actively exploited vulnerability or severe incident?
- Can that person start a regulatory reporting workflow at 02:00 on a Sunday?
- How long would it take to find every release containing a vulnerable open-source component?
- Can we rebuild and patch the oldest release that is still within its support period?
- Which product categories may require a notified body, and when must we reserve assessment capacity?
- Where are signing keys held, who can use them and when was key rotation last tested?
- What happens to a device if an update loses power, fails validation or needs to be withdrawn?
- Can a release reviewer see the risk assessment, exceptions, SBOM, tests and approvals in one place?
- Do supplier contracts support the vulnerability, evidence and maintenance commitments we make to customers?
- Which team has funded capacity to investigate and remediate vulnerabilities after launch?
The leadership mistake to avoid
The common failure is not the absence of another security tool. It is the gap between product promises and engineering capability.
A company may promise five years of support while being unable to rebuild a three-year-old release. It may generate an SBOM but have no process to decide whether a disclosed vulnerability is exploitable. It may have an incident policy but no one authorised to make a reporting decision outside working hours. These gaps only become visible when time is short.
The CRA gives engineering leaders a reason to fix that operating model. The work can also reduce component investigation time, improve release traceability, make updates safer and give enterprise buyers better answers during security reviews. Those benefits are available before a conformity assessment is completed.
Frequently asked questions
Is the CRA relevant to a company headquartered outside the EU?
Yes, it can be. The key question is whether an in-scope product with digital elements is made available on the EU market, not where the manufacturer is headquartered.
Is an SBOM enough for CRA compliance?
No. An SBOM supports component visibility and vulnerability handling. Manufacturers also need risk-based product security, vulnerability response, security updates, user information, technical documentation and the applicable conformity assessment.
Does the CRA require VEX?
The regulation does not name VEX as a standalone requirement. VEX is a useful machine-readable way to record and communicate whether a known vulnerability affects a product and why. It can make SBOM-driven vulnerability work more manageable.
Does every product need a third-party assessment?
No. Many default-category products can use manufacturer self-assessment. Important and critical categories follow stricter routes, and some require a notified body. Product classification should be confirmed early.
Do the September 2026 reporting rules affect products already sold?
They can. The Commission's summary states that reporting obligations apply to products with digital elements made available on the EU market, including products placed on the market before 11 December 2027.
Turn the deadline into a delivery plan
Stonetusker Systems helps connected-product organisations assess CRA engineering readiness, establish reporting and vulnerability workflows, automate SBOM and release evidence, strengthen secure development, and build practical firmware and update controls.
A focused readiness workshop can map product scope, expose the highest-risk gaps and turn them into an owned engineering backlog.
Discuss your CRA engineering roadmapPrimary references
- Regulation (EU) 2024/2847, Cyber Resilience Act
- European Commission summary of the legislative text
- European Commission guidance on CRA reporting obligations
- ENISA Single Reporting Platform information and FAQs
- European Commission guidance on conformity assessment
- European Commission information on CRA standardisation
This article provides engineering and programme guidance. It is not legal advice. Confirm product scope, classification, obligations and conformity routes with qualified legal and regulatory specialists.
