The CRA is a portfolio problem

One deadline, applied to every product still on the price list. For a legacy range, the audit trail is among the costlier changes each of them needs, and the way to be ready is to add it once, the same way, everywhere.

From 11 December 2027, a product with digital elements placed on the EU market must meet the essential requirements in Annex I of the Cyber Resilience Act, Regulation (EU) 2024/2847. In EU product law “placing on the market” attaches to each unit made available, not to a design released once. So the date does not apply to your next product. It applies to every product you are still shipping, including the controller designed in 2010 that sells steadily and has not had a significant firmware release in years.

Most teams I talk to have understood that. What takes longer to sink in is the shape of the work it implies. The CRA is not a project. It is a portfolio of projects, one per product line, all with the same deadline, and mostly the same team.

What each product needs

Annex I Part I lists what the product itself must do: secure defaults, protection against unauthorised access, confidentiality and integrity of data, resilience, minimised attack surface, a way to receive security updates. Part II lists what you as manufacturer must do: keep a software bill of materials, handle vulnerabilities, disclose and fix them, distribute updates securely.

Part II is largely process, and a process can be built once for the whole company. Part I is firmware. Each point that a legacy product does not already meet is a change to that product, which means a release of that product, with whatever qualification the product demands. A range of five controllers is five releases. If some have certified variants, it is more than five.

Among the Part I points is (2)(l): products shall “provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions”. Syslog is not named anywhere in the Act. The Act names capabilities and leaves the realisation to you. But the capability it describes, a record of security-relevant events that somebody outside the device can collect and monitor, is exactly what syslog collectors and SIEMs already ingest, from every other vendor’s equipment on the same network. That is where your evidence has to end up if anyone is to look at it.

Why the audit trail costs more than it looks

Some Annex I changes are settings. Turning off a debug port, changing a default password policy, removing an unused service. Unglamorous, but bounded.

An audit trail is not a setting. It is a subsystem the product never had, and it touches parts of the design that were not built to be touched. Written out as the questions the Article 13(2) risk assessment forces:

• Which events are security-relevant? Logins and failed logins, configuration changes, firmware updates, mode changes. Only the product team can decide, and the decision has to be instrumented throughout the application.
• In what format? Structured, so the customer’s collector can parse it alongside everyone else’s records. In practice that is RFC 5424.
• How does anyone know a record went missing? Numbered records, and a transport that reports when the collector is unreachable.
• What happens when the network is down, or the device reboots? The record most worth keeping is the one produced during an incident, which is when the network may be the thing under attack. Records have to survive an outage and a power cycle and replay when the link returns.
• Who can read or alter records held on the device? Points (2)(e) and (2)(f) ask for confidentiality and integrity of stored data. Tamper evidence at least; encryption at rest where the records warrant it.
• What can the hardware carry? A 2010 design has a flash and RAM budget, and TLS was not in it.

None of these is hard on its own. Together they are formatting, transport, storage, cryptography and a security review, all with no dynamic allocation, to the product’s coding standard, in a footprint the smallest variant can afford. And the parts that matter most for security are the ones that look finished long before they are. That is months of engineering for one product.

Now multiply

Here is the arithmetic that makes it a portfolio problem. Each legacy product in the range was built on its own RTOS, its own network stack, its own filesystem if it has one, and its own vintage of everything. Written per product, the audit trail is a bespoke subsystem five times over: five implementations to get right, five to security-review, five to test against the customer’s collector, five to document in five technical files, and five to maintain when the first vulnerability in any of them is found.

It is also five slightly different things for your customer’s SIEM to make sense of, from a single vendor.

And it is done by the one team, in sequence, on top of the roadmap they already had, inside fifteen months that also have to hold integration, qualification and production for every one of those releases. Counted back honestly from December 2027, the decision about how to do it belongs in this quarter.

Once, the same way, everywhere

The alternative is one library, added to every product in the range the same way. What that buys is not only the months saved on the first product. It is the consistency:

• One integration pattern, learned once, repeated across the range by the same engineers.
• One evidence format from every product you sell, so a customer’s collector treats your range as one thing.
• One compliance narrative, written once and reused in each technical file, with the same answers to the same questions.
• One place security fixes land, and flow to every product that consumes it.
• One evaluation, not five.

For that to work across a legacy range, the library has to have been built for embedded reality rather than ported to it. No heap. No threads of its own, so it runs on whichever of your tasks you choose. Every platform dependency, the OS primitives, the network stack, the filesystem, the crypto, injected behind a small interface, so the 2010 controller on its RTOS and the 2018 one on lwIP consume the same code. And a footprint the smallest variant can afford.

That is what I built SolidSyslog to be. It is a C99 syslog library for embedded and industrial products: RFC 5424 over UDP, TCP and TLS, store-and-forward across outages and reboots, tamper-evident or encrypted records at rest, MISRA C:2012 informed, with the platform adapters for FreeRTOS, lwIP, FreeRTOS-Plus-TCP, FatFs, Mbed TLS and OpenSSL shipped and the adapter surface small enough to write your own. On a representative FreeRTOS product it costs about 5 KB of flash and under 2 KB of RAM for the first compliant record, and 13.5 KB of flash and around 35 KB of RAM fully hardened, measured on the running target.

Any organisation can evaluate it free, today, under the PolyForm Internal Use licence: no time limit, no licence key, no sales call. A commercial licence is needed only when it ships inside a product, and it is priced per product line, because the portfolio is the point. Version 1.0.0, the stable API commitment, lands in Q4 2026, which leaves a team that evaluates now a year of runway before December 2027.

If your team has not yet written down its answers to the questions above, the CRA page of the documentation maps each Annex I point to what a library can carry and what stays yours. It is guidance rather than a guarantee, and no substitute for assessing your finished product. It is also the fastest way I know to turn the regulation into a list of engineering decisions you can put a date against.

The newsletter carries release announcements and occasional notes like this one.

Documentation · Product page · GitHub