Cyber Resilience Act: Security by Design for Products with Digital Elements

TL;DR

• The Cyber Resilience Act (CRA) mandates manufacturers of “Products with Digital Elements” (PDE) to demonstrate cybersecurity throughout the entire product lifecycle—from design through operation to end-of-support—starting from its enforcement on August 20, 2024.
• Products are classified based on risk into non-classified, “Important” (Class I/II), and “Critical”; the class determines whether a self-assessment is sufficient or if a third-party assessment or EU certification is required.
• Core requirements include Security by Design, comprehensive and maintained SBOMs, systematic CVE management, structured update strategies with clearly defined support periods, and coordinated vulnerability disclosure processes including reporting deadlines.
• The CRA creates transparency in the supply chain—including non-technical risks like jurisdictional dependencies—and offers European providers the opportunity to leverage security and sovereignty as competitive advantages.
• ayedo supports you practically in achieving CRA readiness: automated SBOM generation, signed build pipelines, continuous vulnerability management, and a coordinated incident and support model—up to a structured CRA readiness check.

Cyber Resilience Act: Context and Timeline

With the Cyber Resilience Act, the EU is establishing a horizontal legal framework for the cybersecurity of products with digital elements for the first time. The CRA comes into force on August 20, 2024, with most obligations applying after a transition period of 36 months—likely from late summer 2027. Certain parts, particularly those related to vulnerability disclosure and reporting, will take effect earlier.

Importantly, the CRA complements existing regulations such as NIS2 but does not replace them. While NIS2 primarily addresses operators of critical services, the CRA targets manufacturers, importers, and distributors of hardware and software. Those placing products in Europe today will need to demonstrate that cybersecurity is systematically considered throughout the entire lifecycle.

For technically responsible executives, this means cybersecurity shifts from being a “best practice” to a legally binding product attribute—with clear requirements for architecture, processes, and documentation.

Products with Digital Elements: Scope and Classification

What is considered a “Product with Digital Elements”?

The CRA refers to “Products with Digital Elements” (PDE). This includes:

• traditional software products (on-premise, embedded, and partially SaaS-like models, if they are part of a product),
• hardware with software components (routers, gateways, industrial controllers, connected devices),
• remote processing components necessary for the product’s function (e.g., cloud backends).

Once a product is connected to other devices or networks, it typically falls within the CRA’s scope. Purely internal enterprise software without “market placement” may be exempt, but hybrid scenarios (e.g., OEM software deployed at customers) are clearly in scope.

Risk-Based Categorization

A core aspect of the CRA is risk-based classification:

• Non-Classified PDE
  Standard products without critical security functions. They are subject to general CRA obligations but can usually demonstrate compliance through internal self-assessment.

• Important Class I
  Products whose core function fulfills security-relevant tasks (e.g., authentication solutions, certain endpoint security or network components). Here, the requirements for risk analysis, testing, and documentation increase. Self-assessment remains possible if harmonized standards are consistently applied.

• Important Class II
  Products with particularly high potential damage impact (e.g., intrusion detection/prevention systems, central security gateways). For these, third-party assessments by “Notified Bodies” are mandatory, including an examination of product design and development processes.

• Critical Products
  Product categories designated as “Critical” by delegated acts may be subject to mandatory EU certification (e.g., EUCC at “substantial” or higher). A comprehensive security evaluation is obligatory.

The classification does not determine whether you need to take security seriously—that is always the case—but how deep your compliance demonstration must go. Strategically, it is wise to map your product range early: What PDE do we have? Into which categories do they likely fall? What compliance paths arise from this?

Lifecycle Requirements: Security by Design Becomes Standard

Perhaps the most significant paradigm shift in the CRA is the consistent lifecycle perspective. Cybersecurity is no longer just a feature of the delivered version but of the entire product lifecycle.

Secure by Design and Secure by Default

Security by Design becomes a mandatory principle. The CRA expects, among other things:

• documented risk analyses and threat modeling already in the conception phase,
• clear security requirements before implementation begins,
• architectural decisions that consider principles like Least Privilege, Defense in Depth, and Zero Trust,
• sensible secure-by-default settings (e.g., secure default configurations, disabled unnecessary interfaces).

For executives, this means security must explicitly become part of the product development process—with clear responsibilities, quality gates, and the necessary governance. Informal “we already make it secure” promises will no longer suffice.

SBOM as the Foundation of Transparency

A complete and maintained Software Bill of Materials (SBOM) is a central requirement to fulfill CRA obligations. Without an SBOM, you cannot:

• accurately assess vulnerabilities in dependencies,
• demonstrate which components you actually deliver,
• make reliable statements about license and supply chain risks.

The CRA requires manufacturers to know which components they use, how they are maintained, and how they handle vulnerabilities. Practically, this means:

• automated SBOM generation in the build process,
• updating the SBOM with every relevant change,
• linking with vulnerability scanners and CVE databases.

CVE Management as a Continuous Process

An SBOM is only as valuable as the vulnerability management built upon it. The CRA demands:

• systematic monitoring of relevant sources for new vulnerabilities,
• assessment of relevance for your own product (context, exposure, exploitability),
• prioritized planning of remediation measures (patches, configuration changes, workarounds),
• comprehensive documentation of decisions.

This is more than “occasional scanning.” A structured CVE management process is required, connecting engineering, product management, legal, and support—and one that can be substantiated to authorities and customers if necessary.

Update Strategy and Support Periods

The CRA mandates that security updates be provided over the expected usage period—with minimum periods of several years. In practice, this means:

• defined support strategies for all product lines,
• separation of security fixes and feature releases, where technically possible,
• secure, signed update mechanisms with rollback capabilities,
• clear communication on how customers receive updates and for how long.

Here, technical and organizational questions intersect with business models. Those who previously had short or unclear support cycles must now define and document them structurally. This also affects managed offerings and services; a well-defined support model becomes a compliance component.

Coordinated Vulnerability Disclosure: From “Ad-hoc” to Process

The CRA makes coordinated vulnerability disclosure (CVD) mandatory. Manufacturers must:

• provide a publicly accessible CVD policy,
• establish a functioning contact point for vulnerability reports,
• triage and prioritize incoming reports systematically,
• appropriately involve researchers and reporting parties.

Additionally, there are reporting obligations to authorities: Serious security incidents and actively exploited vulnerabilities must be reported via a central ENISA portal—within tight deadlines:

• initial early warning within 24 hours of awareness,
• a structured incident report within 72 hours,
• a final report with root-cause analysis within 30 days,
• regular status updates for actively exploited vulnerabilities, especially after providing patches or workarounds.

For organizations, this means incident response and vulnerability management must not remain purely technical topics for the ops team. Clearly defined roles, escalation paths, and prepared communication lines are needed—both internally and externally.

Supply Chain Transparency: Technical and Non-Technical Risks

The CRA addresses a reality that many engineering teams already feel: The real risks often lie not in their own code but in the supply chain.

Technical Supply Chain Risks

Technically, the CRA addresses particularly:

• transparency over all used components (SBOM),
• traceability of origin (repositories, manufacturers, maintainers),
• requirements for secure update sources and signature chains,
• responsibilities for vulnerabilities in third-party or open-source components.

If a critical vulnerability in a component becomes known, you as a manufacturer must:

• assess the relevance for your products,
• inform maintainers and suppliers if necessary,
• keep your customers informed about risks and measures.

Non-Technical Risk Factors and Digital Sovereignty

Particularly interesting is the explicit inclusion of non-technical risk factors: jurisdiction, state influence possibilities, economic dependencies. This results in:

• dependencies on providers in “high-risk” jurisdictions can become regulatory relevant,
• EU-based alternatives gain weight, especially in security-critical areas,
• multi-sourcing strategies and transparency over sub-suppliers are strengthened.

Thus, the CRA connects cybersecurity with digital sovereignty. For European technology providers, this is a structural opportunity: Those who can offer transparent, traceable supply chains with high resilience score not only in compliance but also in building trust.

Organizational Preparations for CRA Compliance

The technical requirements are only one side. Equally crucial is how you organize yourself. Three levers are particularly effective based on experience:

1. Product Mapping and Classification
   Create an overview of all products and components entering the EU market. Provisionally assign them to CRA categories and derive where third-party assessment or certification will likely be required.

2. Establish Lifecycle Governance
   Enhance your product development process with explicit security gates: requirements, architecture reviews, SBOM and CVE checks, release criteria. It is important that these steps are documented and auditable.

3. Define Incident and Vulnerability Organization
   Determine who is responsible for