The EU’s Cyber Resilience Act: Why Secure-by-Design Alone Is Not Enough

An embedded system that is secure at deployment is no longer enough.

The European Union’s Cyber Resilience Act (CRA) places responsibility for maintaining a product’s cybersecurity on the manufacturer throughout its lifecycle, not just at release. It requires that vulnerabilities discovered after deployment be addressed and that systems receive security support over a defined period.

These requirements extend cybersecurity obligations well beyond initial design and into a years-long process that ultimately defines whether a product complies with the CRA.

That challenge affects both new and existing systems.

First, new systems being developed for the EU market need to account for the CRA from the start. The CRA sets requirements at market entry, but those requirements can only be met if they are considered during design. Designing with long-term support in mind requires understanding how vulnerabilities will be handled before the system is deployed. It also requires ensuring the system can be maintained over time without requiring fundamental redesign.

Second, existing systems present a different set of questions. The CRA includes provisions around when products must meet its requirements, which makes timing and product status an important part of the evaluation. Many embedded systems, designed under different assumptions, are already deployed or in active production. Bringing those systems into alignment with the CRA requires evaluating what can be updated, what must be mitigated, and where earlier design decisions create limits that cannot be removed.

Across both scenarios, one thing becomes clear.

The CRA is not addressed through design alone. It depends on having the right processes in place to manage security and respond to issues as they arise.

How the CRA Changes the Work

Manufacturer responsibility under the CRA

The CRA is a regulation that sets mandatory cybersecurity requirements for products with digital elements across the full product lifecycle. The regulation becomes fully enforceable in December 2027, giving companies a limited window to align both new and existing products before they are placed on the EU market.

It applies to hardware and software that connect to or process data within a networked system, including many industrial and embedded platforms. For manufacturers, the CRA changes the work by extending responsibility beyond product release.

Manufacturers will no longer be responsible only for how a product is built. They will also be responsible for how that product is supported after deployment.

That includes what happens when a vulnerability is discovered and how it is assessed within the company. It also defines how an appropriate response is determined and communicated to customers and stakeholders. In practice, that means engineering teams make early decisions that shape how vulnerabilities are identified, relayed, and addressed over the long term.

From product reliability to operational accountability

Operational accountability expands from delivering a secure, reliable product to managing security as an ongoing function.

This is where business practices like PSIRT, SBOM, and TARA serve as mechanisms that support this operational model. A Product Security Incident Response Team (PSIRT) defines how incidents are handled. A Software Bill of Materials (SBOM) provides visibility into system components. A Threat Analysis and Risk Assessment (TARA) documents how risks are identified and addressed.

“CRA is as much a process issue as a design one,” said Martin Bowman, software engineering team lead at Sealevel Systems. “The challenge is in the CRA details. While we engineer for secure-by-design, we also must account for the operational side, including PSIRT workflows, TARA, SBOMs, and timely support.”

Individually, each of these concepts is already part of standard engineering practice. Taken together, they provide the structure and visibility needed to manage security for the long haul. For Sealevel, that means continuing to refine established security management processes, including PSIRT workflows, SBOM publication, TARA documentation, and internal alignment to support ongoing vulnerability management.

Why operational accountability matters for engineering teams

Operational accountability is the bridge between design and lifecycle. Design decisions determine what is possible, and process determines how those decisions are sustained over time.

A system can be well designed and still require ongoing attention. New vulnerabilities emerge. Underlying components change. Customer environments evolve. Under the CRA, those conditions are considered part of the product lifecycle.

Without a defined way for receiving, evaluating, documenting, and responding to issues, it becomes difficult for engineering teams to meet the requirements the CRA sets. When that structure is in place, however, the work becomes clearer and more manageable, even as the scope expands.

The Support Stack Needed to Address the CRA

Handling security issues through engineering workflow

The CRA establishes security expectations at the regulatory level. Meeting them depends on whether a team has a repeatable way to handle security issues once a product is deployed.

In practice, the support stack ­­­— reporting paths, security review processes, documentation, and update mechanisms — is the operational framework that carries a problem from initial report through to resolution. Each issue may require a different technical response, but the underlying process must remain consistent. This is where PSIRT becomes necessary. It establishes a consistent intake point and a defined path for evaluation so that issues are tracked, reviewed, and resolved using the same criteria.

Without it, issues are handled inconsistently, making it harder to coordinate a response. At Sealevel, that framework is being built deliberately, with reporting channels, continuous vulnerability monitoring, documented response timelines, and processes to ensure security issues are tracked, evaluated, and resolved.

Making security decisions visible and actionable

SBOMs and TARA serve different roles, but they connect directly to this workflow.

When a vulnerability is identified, teams first need to understand exactly which components are affected. An SBOM provides that visibility through an inventory of the software components used within the system. The next question is how that component was evaluated when the system was designed. TARA provides that context by documenting the original assumptions, threats, and risk decisions. Used together, those practices enable support teams to act.

Meeting these requirements also depends on supply chains. Working with partners that provide security documentation and validated components makes it easier for internal teams to make security decisions.

At Sealevel, that includes working closely with suppliers to improve visibility into component-level security and strengthen long-term support planning across the full system lifecycle.

Legacy Systems Introduce Different Engineering Constraints

Artificial Intelligence (AI) can help assess risks

The CRA creates challenges for legacy embedded systems because many were designed before modern cybersecurity expectations existed. Unlike new designs, legacy systems bring a different set of engineering constraints. The architecture is already structured, the hardware is fixed, components may be outdated or near end-of-life (EOL), and many of those systems are still deployed in environments where uninterrupted reliability is essential.

That makes CRA alignment in part an evaluation effort, focused on bringing existing systems into compliance. AI can support that work by helping teams assess risks more efficiently.

“We can use AI to analyze some of our architectural decisions and look at what common vulnerabilities potentially would exist in a topology like this,” Bowman said. “We can provide scenarios, ask it to generate additional scenarios, and use it to research known CVEs (Common Vulnerabilities and Exposures) that may apply.”

There are cases where meaningful improvement would require redesign, but engineering teams have to examine current systems and decide what can realistically be improved.

In some cases, a firmware update may address the issue. In others, mitigation may be the only practical option because of legacy hardware limitations. Those decisions depend on how the system was built and how it is used in the field.

Retrofitting security has technical limits

Some security capabilities cannot be added later. Protections such as secure execution or a hardware root of trust require hardware-level support that software updates alone cannot fully address after deployment.

That does not make older systems ineffective. It means those systems may have technical limits. Certain protections may not be available, and some vulnerabilities can only be mitigated because retrofitting those capabilities is not technically possible. For engineering teams, that reality reinforces the need to plan ahead.

Secure by Design Requires Engineering Decisions Early

Building security into system architecture

Secure-by-design is not a new concept, but the CRA raises the consequence of getting it wrong. For engineering teams, that means security decisions with long-term implications need to be made when the system architecture is still flexible.

At that stage, teams shape how the system will function and how much flexibility it will have once it is deployed. Those early decisions determine whether the system can be evaluated clearly and adjusted when vulnerabilities are discovered or requirements change.

This is where engineering judgment matters most. The choices made during design set the boundaries for what can be secured, what can be updated, and how effectively issues can be addressed as the system ages.

That doesn’t mean overengineering; it means making deliberate decisions about what will be required later and ensuring the system can support those needs. When those boundaries are well defined, the system is easier to manage. When they are not, even small issues can become difficult to resolve and the ability to adapt becomes more limited.

For Sealevel, this includes integrating security controls at the architecture level through secure boot, firmware validation, hardened operating system and board support package options, and attack surface reduction strategies that support long-term lifecycle management.

Support Strategy Becomes a Design Constraint

The five-year baseline may not reflect real-world lifecycles

The CRA establishes a minimum support expectation of five years, with that obligation tied to each individual product placed on the market. That distinction changes how support must be planned from the start.

In practice, support timelines are tied to individual units, which are shipped at different times and carry their own support window, extending obligations well beyond the end of production. A product may be discontinued, but support requirements continue for years after the last unit is delivered.

Long-term support is no longer determined by product performance alone. If a system depends on components with limited availability or restricted support, those constraints will surface later. That creates a different kind of challenge for engineering teams. Systems must be designed to remain maintainable across staggered timelines, not just a single defined lifecycle. Those support limitations also affect whether systems can continue to meet compliance expectations for the EU market.

That’s why Sealevel addresses long lifecycle planning early in development. Sealevel’s engineers align product design, component selection, and update mechanisms to help ensure systems can meet both regulatory requirements and real-world deployment expectations.

This becomes more important as security expectations change. As cryptographic standards change and new vulnerabilities are discovered in previously trusted components, systems that cannot adapt become harder to service.

That is why support strategy is tied directly to design. It is not just about how long a product will be supported, but whether the system was built in a way that makes that support possible.

How Engineering Teams Can Respond

Process alignment defines the workflow

Process alignment brings consistency to the work. The activities that will help teams operate within the scope of the CRA may already be in place but handled differently across teams or products.

That work typically begins with understanding the current product inventory and how each system fits within CRA requirements. Sealevel is preparing by defining core product functionality and aligning products within the CRA classification structure so security requirements can be evaluated consistently across the portfolio.

“CRA pushes teams to assess current inventory while also engineering for change from the start. Internal oversight, customer communication, and strong supplier partnerships are essential to making that work,” Bowman said.

With process alignment, issues move through an organized workflow. When that structure is applied systematically, teams can respond more quickly with effective security solutions.

Cross-functional coordination creates structure

Security responses depend on coordination between engineering, support, product management, and suppliers. Each group contributes different information and decisions to support a concerted effort to achieve compliance.

At Sealevel, that coordination is supported through continuous collaboration and open communication across teams, rather than isolated decision-making within separate functions. Without coordination, responses become fragmented and harder to manage. With that coordination in place, teams can move from isolated responses to a structured cross-functional approach under the CRA.

Getting Started with CRA Alignment

Getting started begins with understanding what the CRA requires and how those requirements apply to your products. From there, teams should begin aligning internal processes and defining how vulnerabilities will be handled while identifying where current systems may fall short. The goal is not to solve everything at once, but to establish a clear path forward.

Frequently Asked Questions

FAQ: What is the EU Cyber Resilience Act (CRA)?

The EU Cyber Resilience Act (CRA) is a cybersecurity regulation that establishes mandatory security and support requirements for products with digital elements sold in the European Union. It applies across the full product lifecycle and requires manufacturers to address vulnerabilities, maintain security support, and manage cybersecurity risks after deployment.

FAQ: Why is secure-by-design alone not enough for CRA compliance?

Secure-by-design is only one part of CRA compliance because the regulation also requires ongoing vulnerability management and long-term security support. Manufacturers must have processes in place to evaluate vulnerabilities, communicate responses, deliver updates, and maintain systems throughout the defined support period.

FAQ: What roles do PSIRT, SBOM, and TARA play in CRA compliance?

PSIRT, SBOM, and TARA help manufacturers manage cybersecurity operationally after deployment. A PSIRT defines how security incidents are handled, an SBOM provides visibility into software components, and a TARA documents how risks were originally evaluated. Together, they support consistent vulnerability management and lifecycle security.

FAQ: How does the CRA affect legacy embedded systems?

The CRA creates challenges for legacy embedded systems because many were designed before modern cybersecurity expectations existed. Engineering teams must evaluate what can realistically be updated, mitigated, or supported within existing hardware and architectural limits while still meeting CRA compliance expectations.

FAQ: When does the Cyber Resilience Act become enforceable?

The Cyber Resilience Act becomes fully enforceable in December 2027. That timeline gives manufacturers a limited window to evaluate current products, align internal security processes, and prepare both new and existing systems for CRA compliance before products are placed on the EU market.