Secure-by-Design under the Cyber Resilience Act: What It Means for Product Engineering

Since connectivity is now a basic requirement for devices and as these devices continue to evolve and become more connected in people's lives, cybersecurity has moved from being an additional aspect to a fundamental need. In this regard, Cyber Resilience Act (CRA) presented by the EU brings about the change whereby security is not anymore a post-designing checklist but a design element in itself.

No matter whether you are creating IoT products, embedded systems, automation products, or even consumer electronics products, a Secure by Design mind-set is imperative now for your regulatory and commercial success.

What Does Secure-by-Design Mean Under the CRA?

Secure-by-Design means incorporating cybersecurity into a product from the earliest engineering decisions and maintaining those controls throughout its supported lifecycle.

A practical approach focuses on three principles:

For engineering leaders, this changes how product requirements are defined, how architectures are reviewed and how development and testing teams collaborate.

Security requirements should be documented alongside functional and performance requirements.

Engineering teams should determine:

For example, instead of defining a requirement as “the device must support secure updates,” teams can specify that firmware must be cryptographically authenticated before installation and rejected if signature validation fails.

This creates a measurable requirement that architects, developers and testers can trace throughout the SDLC.

Architecture decisions have a major influence on product security. Retrofitting security into a completed architecture can require changes to firmware, hardware, manufacturing processes and update infrastructure.

Threat Modelling

Threat modelling helps teams identify:

Consider an industrial IoT gateway with Ethernet, Wi-Fi, USB, UART and cloud connectivity. Each interface introduces different risks. Engineers can use threat modelling to determine where authentication, encryption, access controls and monitoring are required.

Frameworks such as STRIDE can provide a structured approach to this analysis.

Security Controls at the Architecture Level

Depending on the product, Secure-by-Design may involve:

These controls should be selected according to the product's threat model rather than applied as a generic checklist.

Secure architecture needs to be supported by secure implementation.

Development teams should integrate:

Modern products also depend heavily on open-source libraries, SDKs, operating-system components and third-party software. An SBOM (Software Bill of Materials) provides visibility into these components and helps teams determine which products may be affected when a vulnerability is discovered.

This is particularly important for products with long support lifecycles.

Functional testing confirms whether a product works as intended. Security testing examines how the product behaves under malicious, unexpected or malformed conditions.

A Secure-by-Design testing strategy can include:

Why Fuzzing Matters for Embedded Products

Fuzzing sends unexpected or malformed inputs to software interfaces to uncover crashes, memory corruption and unexpected behaviour.

For embedded products, fuzzing can be applied to communication protocols, firmware parsers and external interfaces. Finding these weaknesses during development is considerably safer than discovering them after large-scale deployment.

For connected embedded products, firmware integrity is a critical security consideration.

A secure boot architecture establishes a chain of trust in which each stage verifies the next before execution:

Digital signatures can help ensure that only authorised firmware is installed.

However, secure boot should be considered alongside key provisioning, secure key storage, firmware signing, recovery mechanisms and update infrastructure.

The same principle applies to OTA updates. Engineering teams need to consider:

A product deployed across thousands of devices cannot rely on manual updates. Secure lifecycle management needs to be designed into the product architecture from the beginning.

Security can also be weakened during manufacturing and provisioning.

A secure production process may include:

For example, using a shared credential across an entire product fleet creates a substantially greater security risk than provisioning unique device identities.

This requires coordination between product engineering, manufacturing, and DevOps and operations teams.

Engineering teams often encounter avoidable problems when security is introduced too late, including:

These problems become increasingly expensive to fix once hardware, firmware and manufacturing processes have been finalised.

A product engineering team can structure its security process around:

Frameworks such as the NIST Secure Software Development Framework (SSDF) can complement this process by providing structured practices for integrating security into software development. The CRA itself remains the applicable regulatory framework for products within its scope.

A practical starting point is a CRA engineering readiness assessment covering:

The goal is not simply to produce compliance documentation. It is to identify technical gaps early enough for engineering teams to address them within normal development cycles.

At Ascenten Technologies, security can be integrated into the product engineering lifecycle—from requirements and architecture to embedded development, testing, deployment and lifecycle support.

Whether you are developing an IoT device, embedded system, industrial product or connected consumer product, Secure-by-Design can help reduce technical risk, minimise costly redesigns and create products prepared for evolving cybersecurity expectations.

Partner with Ascenten Technologies to build secure, resilient and future-ready products.

The Cyber Resilience Act changes cybersecurity from a final validation activity into a product engineering responsibility. Security decisions now need to influence architecture, firmware, software, testing, manufacturing, deployment and lifecycle maintenance.

For engineering leaders, the question is no longer simply “How do we meet CRA requirements?” It is “How do we engineer security into the product from the beginning?”

That is the foundation of Secure-by-Design—and a critical capability for building resilient, maintainable and future-ready connected products.