Cyber Resilience Act: The Hidden Engineering Work for Compliance

A vulnerability is reported in a library your product uses. The firmware shipped three years ago, the original developer has moved on, and the build server has been replaced.

Before anyone can write a patch, the team needs to answer a few basic questions. Which releases contain the library? Which devices received those releases? Can the team rebuild the affected firmware and test an update?

Those answers depend on engineering work that should have happened long before the vulnerability report arrived.

The Cyber Resilience Act brings that work into sharper focus. For in-scope products, manufacturers must address cybersecurity throughout development and maintenance and document how they meet the requirements. A penetration test near the end of the project cannot supply that entire history.

In this post, we’ll look at six areas of engineering work behind Cyber Resilience Act compliance: secure coding, runtime defect detection, development evidence, software component tracking, reproducible builds, and long-term support. You’ll learn how these activities fit together and where gaps in your current workflow could make a security issue harder to investigate, fix, and document.

Start with the Product and Its Support Commitments

The Cyber Resilience Act covers many hardware and software products made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection. There are exclusions, including products covered by certain other EU legislation, so confirm which requirements apply to your product before defining the compliance work.

The European Commission’s implementation timeline sets 11 December 2027 for full application. Reporting obligations for actively exploited vulnerabilities and severe security incidents have applied since 11 September 2026. Those reporting duties already matter; they are not something to leave until the full application date.

For an engineering team, the practical question is whether its normal development process produces the information and capabilities needed to meet those obligations. The following six areas are a useful place to look.

1. Secure Coding Starts with the Architecture

A coding standard cannot rescue an update mechanism that accepts unauthenticated firmware. It also cannot decide who should be allowed to change a device’s configuration.

Those are architecture decisions. Identify the interfaces exposed to untrusted input, the assets that need protection, and the operations that require authorization. Then decide how the design will enforce those boundaries. The Cyber Resilience Act’s cybersecurity risk assessment should inform those decisions throughout the product lifecycle.

Secure coding turns those design decisions into reliable implementation. For example, a communications parser needs rules for validating lengths, handling arithmetic, and rejecting malformed messages before they reach sensitive application logic.

The SEI CERT C and C++ coding standards address recurring sources of software vulnerabilities and describe safer alternatives. MISRA C/C++ can also provide a disciplined coding framework. The Cyber Resilience Act does not specifically mandate either family of coding standards; the team needs to choose appropriate practices and show how they support its security requirements.

The important step is enforcement. Put the selected rules into code review and automated analysis, and define how findings and justified deviations are handled. A standards document in a shared folder does little good if developers rarely consult it.

IAR C-STAT is one example of static analysis that can run in the developer workflow and CI. It supports MISRA and CERT checks and findings associated with CWE weakness categories. Running those checks on changes gives developers feedback while the affected code is still fresh in their minds.

A report is the beginning of a decision. Fix the defect, investigate whether it creates a security risk, or record why the finding does not require a code change. That decision becomes part of the evidence for the release.

2. Some Security Problems Begin as Ordinary Defects

An unchecked length field looks like a programming error. If an attacker can control that field and cause a buffer overrun, the same error becomes a security vulnerability.

A resource leak can have a similar progression. One failed connection may leave only a small allocation behind. Repeated requests may eventually exhaust memory and stop the device from providing its intended service.

Not every defect is exploitable, and vulnerabilities can also come from design and configuration mistakes. But memory corruption, undefined behavior, and resource handling deserve attention because their consequences can extend beyond a crash during development.

Source review and static analysis provide useful checks. Execution provides another view: what happens with this input, on this path, in this configuration?

IAR C-RUN adds runtime checking to supported IAR toolchains, including checks for arithmetic, bounds, and heap-related errors. It can help expose failures when the application runs that were not resolved through source analysis alone. Availability depends on the toolchain and target.

Use those checks with meaningful tests. Exercise truncated messages, extreme lengths, repeated failures, and recovery paths. Runtime analysis only observes behavior reached during execution, and instrumentation can change timing and memory use. Keep representative tests of the release configuration as well.

For each failure, retain the input, affected configuration, diagnostic output, and regression test. That makes the result useful to the next engineer and connects defect detection to the security evidence the team needs.

3. Evidence Matters More Than Intent

If an auditor asked you tomorrow how a security issue was prevented, detected, and documented, could your team answer with evidence?

That question is useful even when the applicable conformity assessment permits internal assessment rather than a third-party review. Someone still needs to establish what the team did and why the result supports the product’s security requirements.

The Cyber Resilience Act’s technical-documentation requirements in Annex VII include the cybersecurity risk assessment, relevant design information, vulnerability-handling processes, and test reports. The engineering challenge is keeping those records connected to the product that shipped.

Take the parser example. A useful record connects the risk of malformed input to the design requirement, the implementation, the analysis results, and tests that exercise the boundary conditions. If a finding was accepted rather than fixed, the record should explain the reasoning and identify the reviewer.

For each release, retain enough information to answer:

• Which source revision, build configuration, and component versions produced this firmware?
• Which security requirements and risks were evaluated?
• Which analysis and tests ran, and what did they find?
• How were open findings assessed, and who approved the release?

A folder full of reports is difficult to use if each report refers to a different build. Attach the release identifier to the records and keep the links intact. Let CI collect repeatable outputs, while engineers remain responsible for the judgments those outputs require.

Evidence also needs an owner after release. ENISA’s Single Reporting Platform supports CRA reporting of actively exploited vulnerabilities and severe incidents. Establish who receives reports, assesses them, and coordinates the required notifications. An analyzer warning alone is not the same as evidence of active exploitation.

The objective is to make a release’s security history understandable without asking the original developers to reconstruct it from memory.

4. An SBOM Tells You What Needs Investigating

Do you know what is actually inside your firmware image?

The answer includes more than the application code. It may include an RTOS, a TCP/IP stack, a cryptographic library, a bootloader, vendor middleware, and dependencies brought in by other components. Some are open source; others arrive as commercial libraries or binary-only packages.

A software bill of materials (SBOM) records software components and their relationships. Annex I, Part II of the Cyber Resilience Act requires a commonly used, machine-readable SBOM covering at least the product’s top-level dependencies. For engineering purposes, deeper dependency information can make investigations substantially easier.

Generate and retain an SBOM for each release, using the component versions and configuration actually used to build it. A manifest describing the current development branch cannot tell you what was inside firmware shipped three years earlier.

When a new CVE or supplier advisory appears, compare it against those release records. Determine which versions contain the component, whether the affected functionality is present and reachable, and what risk the issue creates in the product’s operating environment.

An SBOM match tells you where to investigate. It does not, by itself, establish that the product can be exploited. Document the assessment and the resulting fix, mitigation, or reason the product is not affected.

That is why component tracking is useful to an engineer. It turns “we might use that library somewhere” into a list of releases that need attention. The next challenge is being able to rebuild them.

5. A Source Archive Is Only Part of a Reproducible Build

Imagine the investigation identifies a vulnerable component in a release from five years ago. The source is tagged in version control, but the build now uses a newer compiler, different libraries, and a replacement linker script.

You can compile something. Can you show that it represents the firmware you are trying to fix?

A reproducible build starts with controlled inputs: source code, dependencies, compiler and linker versions, build options, generated files, and the surrounding environment. An archived source revision is only one part of that record. A traceable CI pipeline can preserve these inputs by automatically recording build configurations, toolchain versions, analysis results, and release artifacts alongside the firmware they produce; the broader argument for this approach is covered in Reproducible Builds: The Missing Foundation for Embedded CI/CD.

The Cyber Resilience Act does not explicitly prescribe bit-for-bit reproducible builds. They are an engineering method for reducing uncertainty during investigation and maintenance. Recreating the original binary gives the team a stronger baseline for comparing the patched version.

IAR Build Tools supports command-line and container-based builds on supported Linux and Windows environments. Teams can use it to automate the controlled build process and retain its outputs with the release evidence. For a broader look at how build configurations are structured, see Mastering Embedded Build Systems: Exploring the 5 Essential Configurations.

A container still needs to be managed. Archive the actual image and identify it by digest; a Dockerfile that downloads whatever is current will not preserve the environment indefinitely. Keep the required packages and license arrangements accessible, and test restoration on another machine.

Compare a rebuilt unsigned firmware payload with the archived payload where practical. Signed packages may contain changing signatures or timestamps, so decide which artifacts you are comparing and document any expected differences. Investigate unexplained changes before using the rebuilt firmware as a baseline.

Then run the patch through the same controlled process: update the component record, execute the relevant tests, review the results, and retain the new release evidence.

That workflow needs to keep working long after the original product team has moved on.

6. Long-Term Support Is the Commitment You Have to Make

The easiest security update to plan is the one for a product under active development. The difficult one arrives years later, when the compiler is old, the hardware is scarce, and the engineers now work on something else.

The Commission’s CRA FAQs, section 4.5, explain that the support period generally must be at least five years. If expected use is shorter, the support period corresponds to that shorter time. Expected use and other relevant factors also matter when determining whether a longer period is needed. Five years is not an automatic stopping point for a product expected to remain in service much longer.

For an industrial product with a ten-year or longer service life, the engineering plan must address the years after launch. Who monitors component advisories? Who maintains the build environment? Who can test a patch on representative hardware? How will the update reach customers securely? Teams carrying legacy codebases will recognize these questions from the ongoing cost of legacy code and fragmented toolchains.

A toolchain supplier’s support commitment is one part of that plan. IAR Long-Term Support Services provides contractual support for selected certified toolchains, including Validated Service Packs, Known Problem Reports, and prioritized technical assistance with investigation and mitigation guidance. The service page describes agreements of up to ten years; scope and duration need to match the actual contract.

These services can help a team manage compiler issues and maintain its development environment. They do not take over the manufacturer’s responsibility to assess vulnerabilities in the product, test fixes, and deliver security updates. Functional-safety toolchain certification also does not establish CRA conformity for the finished product.

Before launch, fund the work needed to keep the entire maintenance path available: people, component information, build tools, test equipment, update infrastructure, and customer communication. Rehearse that path with an older release instead of waiting for an urgent vulnerability to expose the gaps.

Next Steps

Cyber Resilience Act readiness brings together six parts of embedded development that are easy to treat as separate tasks. Secure coding and static analysis help prevent defects. Runtime checks help expose failures during execution. Release evidence and SBOMs let us trace what shipped and investigate what might be affected. Reproducible builds and long-term support give us the ability to turn those findings into a tested update, even years after launch.

That connection is where the engineering effort pays off. When a vulnerability report arrives, your team needs to know where to look, what to fix, and how to get the update into customers’ hands. Every missing component record or lost build environment adds work at the moment you can least afford the delay. Building these practices into everyday development gives the next engineer a much better starting point and helps you keep the support commitments your customers depend on.

You can start making progress with one product and three concrete steps:

• Review one release’s security records. Trace a security requirement through the design, coding rules, static and runtime analysis results, and tests. Check that the SBOM and supporting evidence describe the firmware that actually shipped. Turn missing records and unresolved findings into assigned work.
• Rehearse a security update. Choose an older supported release and a hypothetical component vulnerability. Have someone other than the original developer identify the affected firmware, restore the build, test a change, and walk through secure update delivery. Record what slows them down.
• Fund the work beyond launch. Assign owners for vulnerability monitoring, reporting, build maintenance, testing, and update delivery. Confirm that the tools, licenses, hardware, and supplier support will remain available for the product’s planned support period.

The firmware you ship today may need a security update long after your current project is forgotten. Give the engineer who answers that call something solid to work with.

Your next security update starts with the engineering decisions you make today.

---

Want embedded engineering insights like this delivered to your inbox? Sign up for my Embedded Bytes newsletter to get the latest posts, insights, and hands-on tips delivered straight to your inbox.

Frequently Asked Questions

What does the Cyber Resilience Act mean for embedded product teams?

For products within its scope, the Cyber Resilience Act (CRA) requires manufacturers to address cybersecurity during development and handle vulnerabilities during the support period. Embedded teams need risk assessments, security controls, technical evidence, and a working process for delivering security updates. The European Commission CRA summary explains these responsibilities.

When do the Cyber Resilience Act requirements apply?

CRA reporting obligations began applying on September 11, 2026. The regulation applies fully from December 11, 2027. Teams should distinguish these dates when planning their compliance work. See the European Commission implementation timeline for details.

Why does an SBOM matter for embedded firmware?

A software bill of materials (SBOM) identifies the software components in a firmware release. When a vulnerability advisory arrives, the team can use that inventory to identify potentially affected releases and investigate whether a fix is needed. An SBOM supports the investigation; it does not establish whether the vulnerability is exploitable in the product.

How do static and runtime analysis support secure development?

Static analysis examines source code for potential defects without running the application. Runtime analysis checks for problems while instrumented code executes. Used together, these techniques help teams find defects earlier and record how findings were resolved. Neither technique alone demonstrates that a product meets all Cyber Resilience Act requirements.

Why should teams preserve the build environment for released firmware?

A security patch may be needed years after a release. Preserving the source, compiler version, dependencies, configuration, and build instructions helps the team rebuild that release and evaluate the change. The maintenance process also needs representative hardware, regression tests, and a secure way to deliver the update.

What is a practical first step toward Cyber Resilience Act readiness?

Choose one supported product and rehearse the response to a hypothetical component vulnerability. Identify affected releases, rebuild the firmware, test a fix, collect the evidence, and walk through update delivery. Assign an owner to each gap the exercise uncovers so that missing tools, records, or responsibilities become actionable work.