Cyber Resilience Act requirements arrive in two waves, and the first one is already here. From 11 September 2026, an actively exploited vulnerability in a product you shipped years ago starts a 24 hour reporting clock. From 11 December 2027, no product with digital elements goes on the EU market without CE marking that covers cybersecurity.
This article sets out what applies and when, how your product is likely to be classified, and which engineering decisions cannot wait for the harmonised standards to be finalised.
The Business Challenge Behind Cyber Resilience Act Requirements
Manufacturers of connected and embedded products face four distinct problems under the Cyber Resilience Act requirements. They do not arrive at the same time, and they do not have the same owner inside the company.
Reporting starts before certification.
From 11 September 2026, actively exploited vulnerabilities must be reported to ENISA and the national CSIRT within 24 hours. That obligation reaches products already in the field, long before CE marking applies in December 2027.
Security cannot be retrofitted.
Secure boot, a hardware root of trust and key provisioning are architecture and factory decisions. Adding them after the board is frozen means a hardware respin and a new production flow.
Classification is unclear.
Default, important class I or II, or critical. The tier decides whether you can self assess or need a notified body, and it changes the budget, the schedule and the evidence you must collect.
The support period is a commitment.
At least five years of monitoring, patching and coordinated disclosure, declared at the point of sale. That is a staffed rota for the whole product lifetime, not a line item in a budget.
The Technical Solution: 5 Proven Steps to Meet Cyber Resilience Act Requirements
The work splits into five packages. Sequenced correctly, they fit inside a single embedded product cycle. Sequenced badly, they collide with your hardware freeze.
1. Classification and Gap Assessment
The first question is what your product actually is under the regulation. Default products can be self assessed. Important class I products can be self assessed only if harmonised standards are applied in full. Important class II products need a notified body, and critical products may require a European cybersecurity certificate.
Once the tier is settled, the product is measured against the essential requirements in Annex I: secure by default configuration, protection against unauthorised access, data confidentiality and integrity, secure update mechanisms, minimised attack surface, resilience and security logging. The output is a prioritised list of what must change, not a generic checklist.
2. Vulnerability Reporting and Disclosure Process
An early warning goes to ENISA and the relevant national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report once a corrective measure exists. The reporting obligations published by the European Commission set out the platform and the timelines in detail.
Meeting them needs a named single point of contact, a decision rule for what counts as actively exploited, a coordinated vulnerability disclosure policy and one rehearsal before the first real incident. This part of the Cyber Resilience Act requirements can be stood up in weeks, which is why it goes first.
3. Secure Boot, Root of Trust and Key Provisioning
A device that cannot verify its own firmware cannot satisfy the essential requirements, whatever the documentation says. Secure boot depends on silicon choice and key hierarchy. Key provisioning is a factory process that touches the contract manufacturer, the test fixtures and the logistics chain, not just the firmware image.
A fleet provisioned with one shared key cannot revoke a single unit without touching all of them. These are embedded software development decisions with lead times measured in months, which is why they cannot wait for the standards to be published.
4. Secure Update, SBOM and CI Evidence
Updates must be distributed securely and, where technically feasible, automatically. In practice that means signed over the air updates with an A/B partition scheme and enough flash budget on the board to hold both images.
The software bill of materials has to be machine readable and current, generated in CycloneDX or SPDX on every build rather than assembled by hand for the audit. Static analysis and fuzzing in the pipeline produce the evidence that system validation and verification work is actually being done, and that evidence is what the technical documentation is built from.
5. Post-Market Monitoring for the Full Support Period
The support period is declared at the point of sale and is at least five years, unless the product expected lifetime is genuinely shorter. For industrial, building and infrastructure products, five years is the floor rather than the target.
Across that period someone has to monitor vulnerabilities against your bill of materials, qualify them, run impact analysis, deliver patches and manage coordinated disclosure. For connected fleets this is where connectivity and smart systems work continues long after the last unit leaves the factory.
Results: What Meeting Cyber Resilience Act Requirements Delivers
Market access. From 11 December 2027, CE marking that covers cybersecurity is the condition for placing a product with digital elements on the EU market. Without it there is no market.
Faster incident response. A rehearsed reporting path turns a 24 hour deadline into a routine process instead of an escalation that reaches the board.
Lower cost of change. Architecture decided early costs a design review. The same decision taken after the hardware freeze costs a respin, a new provisioning flow and a slipped launch.
Why Cyber Resilience Act Requirements Are an Engineering Problem, Not a Paperwork Problem
Cyber Resilience Act requirements cannot be retrofitted with a document pack. The regulation reaches into how a product boots, how it holds its keys, how it takes an update and how it is supported for years after production ends.
The two core horizontal standards, covering secure development and vulnerability handling, are expected through 2026, with vertical standards following into 2027. Harmonised standards give a presumption of conformity and a cleaner self assessment route, but they will not change the fact that a device needs a root of trust, verified boot and a signed update path. Teams waiting for the final text before starting architecture work are, in practice, choosing to start late.
Traceability is the other half. Requirements, threat model, test evidence and software bill of materials have to connect, which is the same discipline platform integration and software validation brings to any regulated programme, and where AI-enabled engineering can shorten gap analysis considerably.
Technology Stack
Category | Technologies |
Key Technologies | Secure boot, TPM and secure elements, HSM-backed key provisioning, signed OTA with A/B update |
Languages and Methods | TLS and mTLS, CycloneDX and SPDX SBOM, static analysis and fuzzing in CI |
Standards | EU Regulation 2024/2847 (CRA), Annex I essential requirements, IEC 62443, ETSI EN 303 645 |
Avel Technologies provides nearshore embedded engineering and regulatory support for companies navigating Cyber Resilience Act requirements, from classification and gap assessment through to post-market vulnerability handling. We are not a notified body and we do not certify products. We are the engineers who make the product certifiable. Learn more about our embedded software development and connectivity and smart systems practices.
