Cyber Resilience Act (CRA): What Software Manufacturers Must Implement by 2027

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU-wide regulation to establish minimum cybersecurity requirements for all products with digital elements. This includes any hardware or software that can be connected directly or indirectly to a device or network and is made available on the EU market (BSI: Cyber Resilience Act). What matters, therefore, is not the industry but the product: the same logic applies to everything from inexpensive consumer gadgets to B2B software to complex industrial systems.

Most products are considered standard products for which self-assessment is sufficient. The regulation lists categories that are more critical to security in Annexes III and IV as important and critical products, such as password managers, firewalls, smart card readers, and smart meter gateways. Stricter conformity assessment procedures apply to these products. Exceptions include products that are already regulated by other EU regulations, such as medical devices, motor vehicles, civil aviation products, and marine equipment.

Important practical information regarding the CRA and software: Commercial open-source software is also fully subject to the regulation. Only non-commercial open-source projects are exempt. Anyone who integrates open-source components into commercial products is therefore also responsible for their security.

The CRA took effect at the end of 2024, but its provisions are being phased in gradually. This phased implementation is actually the good news, as it gives manufacturers a clearly defined preparation period. Three dates should be included in the project calendar (European Commission: CRA Summary):

• June 2026: The regulations governing conformity assessment bodies (notified bodies) take effect. Member States designate the bodies that will subsequently be authorized to assess the conformity of more complex products.
• September 2026: The reporting requirements take effect. Starting on this date, manufacturers must report actively exploited vulnerabilities and serious security incidents.
• December 2027: The regulation will be fully in effect. Products newly placed on the market must meet all CRA requirements and bear the CE mark, which will also certify cybersecurity in the future.

Three years may sound like a long time. But in the reality of complex, long-lived software systems, it rarely is. Security requirements cannot be reliably retrofitted without affecting the architecture and release schedule. Anyone who waits until 2027 runs the risk of having to overhaul entire product lines under time pressure.

CRA obligations can be traced back to a simple principle: Cybersecurity must be ensured and demonstrated throughout a product’s entire lifecycle, from planning through development and delivery to operation. In concrete terms, this involves five closely interrelated areas of responsibility.

Until now, “Security by Design” has been a best practice; with the CRA, it becomes a “Security by Design” requirement. Products must be developed according to the “Secure by Default” principle from the very first design phase. This includes a minimal attack surface, secure default configurations, encrypted communication, the elimination of hard-coded passwords, and robust, signed update mechanisms. Security is thus not a feature that is added later, but rather an inherent characteristic of the architecture.

The first step is risk assessment. For every product with digital elements, the manufacturer must analyze the cybersecurity risks and take the results into account throughout all phases of the product lifecycle. This forms the basis for the Software Bill of Materials (SBOM), a structured inventory of all components and dependencies used. The SBOM is mandatory but does not have to be published. Its practical benefit is that if a new vulnerability emerges in a library, it takes only minutes—rather than days—to determine which products are affected.

In our projects, a well-maintained SBOM is standard practice anyway, and automated security scans—some of which are AI-powered—are an integral part of our CI/CD pipelines. For us, ensuring transparency regarding all components used is therefore not an extra burden for the CRA, but rather part of the normal development process.

Responsibility does not end with the sale. Throughout the entire support period—which is typically at least five years and must be transparently communicated by the manufacturer—security updates must be provided and continuous vulnerability management must be carried out. Within the organization, this task is best centralized in a PSIRT (Product Security Incident Response Team), which records, assesses, and coordinates the resolution of vulnerabilities.

Starting September 11, 2026, actively exploited vulnerabilities and serious security incidents must be reported via a central platform operated by the EU Cybersecurity Agency (ENISA). The timeline is tight: an initial early warning within 24 hours, supplementary information within 72 hours, and a final report no later than 14 days after a security update is released or one month after the initial report in the case of incidents. Those who wait until an emergency to set up these processes will lose valuable hours.

In addition, there are the formal requirements: technical documentation, conformity assessment, and CE marking, which must be kept up to date throughout the entire support period (European Commission: Conformity Assessment).

The CRA is not a toothless set of regulations. Violations of the essential safety requirements set forth in Annex I, as well as of the reporting and evaluation obligations, may be punishable by fines of up to 15 million euros or 2.5 percent of global annual revenue, whichever is higher. Violations of other obligations are subject to fines of up to 10 million euros or 2 percent of revenue, while providing false or misleading information to authorities is subject to fines of up to 5 million euros or 1 percent.

In addition to the financial risk, market access is at stake: Products that are not CRA-compliant as of December 2027 may no longer be placed on the market in the EU. Added to this is the damage to a company’s reputation—which is difficult to quantify but very real—if a product is publicly deemed unsafe.

The CRA is particularly noticeable where physical products and software converge. In mechanical and plant engineering, control systems are now networked; in the smart home segment, nearly every device communicates with the cloud. It is precisely these networked products that are the focus of the regulation, and it is here in particular that update mechanisms and vulnerability management over long product lifecycles pose significant challenges.

For small and medium-sized enterprises, the message is uncomfortable but clear: The CRA does not ask about company size. Any company offering connected products must establish structures for risk analysis, updates, and reporting channels early on. The workload is distributed much more effectively when it is integrated into ongoing development cycles rather than launched as a special project shortly before the deadline.

Artificial intelligence can significantly reduce this effort. AI now provides reliable support in risk analysis and threat modeling, automated security scans, and reviewing dependencies for the SBOM.

At BAYOOTEC, a significant portion of the new code is generated with the help of AI, and we use AI-powered automation for tasks such as pull request reviews and security scans. To ensure that AI remains compliant with regulations even in regulated environments, we have established an internal AI compliance officer with TÜV certification who oversees its use. This allows us to accelerate CRA implementation without sacrificing control over security and traceability.

As complex as implementation may be, the CRA has a strategic upside. Companies that demonstrably incorporate security into their products will be able to highlight this as a quality feature in the future. In a market where buyers and clients are increasingly demanding proof of security, CRA compliance becomes a differentiating factor. The CE mark for cybersecurity will then signal not only legal compliance but also robust product quality “made for Europe.”

This perspective aligns with our project experience: Incorporating security from the very beginning not only ensures compliance but also results in more stable, maintainable, and durable systems. That is precisely the essence of Security by Design.

The Cyber Resilience Act is changing how software is developed, operated, and placed on the market in Europe. The key CRA requirements—risk analysis, security by design, SBOM, updates throughout the support period, PSIRT, and reporting obligations to ENISA—are challenging but manageable. Those who take the timeline—with deadlines in September 2026 and December 2027—seriously and start early will avoid costly rework and turn security into an advantage rather than a burden.

A good place to start is often a concise risk analysis or a clearly defined discovery phase, which makes it possible to identify the need for action and the required effort with a manageable level of resources before the major program begins.

At BAYOOTEC, we combine “Security by Design” with over 25 years of experience in regulated and security-critical environments—from risk analysis and architecture to secure operations. In addition, we boast an exceptionally high track record of successful implementation: We have successfully brought every project we’ve started to date into production. Feel free to contact us, and we’ll schedule a meeting to get to know each other.