The CRA Paperwork Is Not the Point

Sep 29, 2026 |

The first CRA deadline is behind us. Now comes the opportunity to solve the engineering problem underneath it.

When I worked with connected appliances at Electrolux, I learned something that is obvious to customers but sometimes less obvious to product organizations:

Release day is not the end of product development. In many ways, it is the beginning of the longest and most unpredictable part of the product lifecycle.

A connected appliance may remain in someone’s home for ten years or more. During that time, its environment changes, software dependencies age, new vulnerabilities emerge, and the product encounters situations that nobody reproduced during development. The customer, quite reasonably, still expects it to work safely and reliably.

This is the engineering reality behind the EU Cyber Resilience Act.

The first major CRA milestone arrived on September 11, when new reporting obligations took effect for actively exploited vulnerabilities and severe security incidents. For many companies, the preparations have involved policies, reporting channels, responsibilities, documentation, and perhaps a few hurried conversations between engineering, legal, and management.

That work is necessary. But it would be a mistake to conclude that the CRA is mainly a documentation exercise.

The larger deadline is December 11, 2027, when the CRA’s main requirements become applicable. These extend across planning, design, development, and maintenance. Manufacturers must assess cybersecurity risks, build products with appropriate protections, handle vulnerabilities, and maintain their products throughout the declared support period.

And no, the CRA does not mandate that you subscribe to Percepio Detect, Tracealyzer, or any other particular development tool.

Let’s be honest about that.

But regulations such as the CRA are pointing toward a deeper principle: if you place a software-defined product on the market, you remain responsible for how that product behaves over time.

Documentation can describe the process you followed. An SBOM can tell you what components went into the product. Static analysis can identify certain classes of problems in the source code. All are important.

But none of them, by themselves, can tell you what the complete system actually did when the firmware was running.

Did timing assumptions hold under realistic load? Did a task miss its deadline? Did resource usage gradually approach a dangerous limit? Did an unusual sequence of events create a concurrency problem? And when something failed, do you have enough evidence to understand why, without first spending days trying to reproduce it?

These questions matter for product quality and reliability. In a security context, they also matter because unpredictable runtime behavior, resource exhaustion, and unexplained failures can complicate risk assessment, delay incident investigation, and undermine confidence in corrective releases.

This is where I believe Continuous Observability becomes increasingly important, not because the CRA explicitly demands it, but because lifecycle responsibility is difficult without visibility into runtime behavior.

Percepio Detect can monitor real firmware during integration testing, continuous testing, and extended system or field tests. It flags crashes, timing anomalies, and other stability risks when they occur, while preserving diagnostic context. Tracealyzer then gives engineers the detailed runtime view needed to understand what happened and why.

The result is more than faster debugging. It is a continuous engineering feedback loop:

Observe the real system. Detect abnormal behavior. Understand the cause. Correct it. Verify the new release.

We now have more than a year before the CRA’s main requirements apply. Companies can spend that time treating December 2027 as another compliance deadline, or use it as an opportunity to build better engineering practices and deliver safer, more dependable products.

The paperwork matters. But the product’s actual behavior matters more.

Andreas Klintemyr
Product Lead, Percepio

Stay Ahead of What’s Changing in Embedded Software

Get monthly insights from Percepio on embedded software development, observability, debugging, industry trends and the issues shaping engineering teams.

Subscribe to the Percepio newsletter!

Want to See What Your Software Is Doing at Runtime?

Explore Percepio Detect and Tracealyzer to see how continuous observability and visual trace diagnostics can help you detect problems earlier, understand what happened and get to the root cause faster.

Start an evaluation of Percepio Detect and Tracealyzer. 


Percepio offers Tracealyzer licenses to qualifying academic institutions and students. Please visit the Licensing page to review the terms and apply for an academic license.