SolidSyslog 0.1.0: CRA audit logging you can retrofit

If a product is still on the EU market after 11 December 2027, it needs a security audit trail. SolidSyslog is the fast way to add one – and you can evaluate it free, today.

---

Most R&D teams I talk to aren’t worried about the Cyber Resilience Act because of the products they’re designing now. They’re worried about the ones they designed ten years ago and are still selling.

That’s the right thing to worry about. The CRA (Regulation (EU) 2024/2847) applies in full to products with digital elements placed on the EU market from 11 December 2027 – and in EU product law “placing on the market” attaches to each unit made available, not to a design released once. A controller you shipped happily for a decade must either comply or come off the price list. Nor is 2027 the first date that bites: Chapter IV has applied since 11 June 2026, and from 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents. This has stopped being a future problem.

Among the CRA’s essential requirements in Annex I is one that lands squarely on firmware teams: products must be able to record security-relevant events – an audit trail. For a greenfield design that’s a line item. For a legacy portfolio it’s a retrofit, and everyone who has costed that retrofit knows why it stings. Structured message formatting to RFC 5424. Reliable delivery to a collector. Buffering that survives network outages and power loss without losing or corrupting records. TLS on hardware that was never sized for it. All with no dynamic allocation, to your coding standard, across every product variant. Each piece is unglamorous; together they are months of engineering per product line – multiplied across the portfolio, on top of the roadmap you already had.

I’ve spent my career in exactly these systems – industrial data recording, industrial and process control, PLCs, test and measurement – and that retrofit maths is why I built SolidSyslog.

What it is

SolidSyslog is a syslog library written for embedded reality:

• Standards-first: RFC 5424 message format, with UDP (RFC 5426), TCP (RFC 6587), and TLS/mutual TLS (RFC 5425) transports.
• No dynamic allocation. Static memory throughout, every instance drawn from a pool sized at compile time.
• It owns no threads. Two calls at run time – SolidSyslog_Log() and SolidSyslog_Service() – and you decide which of your tasks they run on. The only OS primitives it needs are a mutex and an atomic counter, and both are injected like everything else. That’s what makes it drop into a 2010 RTOS design without re-architecting it.
• Everything platform-specific is pluggable. OS, network stack, filesystem and crypto each sit behind a small adapter interface. The core library doesn’t care whether it’s talking to lwIP or Winsock, FatFs or POSIX files, Mbed TLS or OpenSSL – and if your platform isn’t on the list yet, the adapter surface is deliberately small enough to write your own. More adapters are coming, steered by demand.
• Store-and-forward that survives the network. Records are numbered so a gap is visible, held across outages and reboots, and replayed when the link returns. What protects them at rest is your decision, not mine: a CRC-16 catches accidental corruption, HMAC-SHA256 makes them tamper-evident, AES-256-GCM encrypts and authenticates. The store reaches the medium through a file and block-device seam, with ChaN FatFs and FreeRTOS-Plus-FAT adapters shipped and raw flash a port away.
• Written to be audited: C99 core, MISRA C:2012 informed with a public deviation register, exercised in CI against real collectors – syslog-ng on Linux and FreeRTOS, an OpenTelemetry collector on Windows – with a CycloneDX SBOM and a source-tree hash, both signed and attached to every release.

It ships validated on four reference builds – FreeRTOS with lwIP and FatFs, FreeRTOS with Plus-TCP and Plus-FAT, Linux, and Windows – with Mbed TLS and OpenSSL back-ends.

And because “how big is it?” is always the first question: integrating into a representative FreeRTOS product costs about 5 KB of flash and under 2 KB of RAM to get the first compliant record out; the fully hardened configuration – buffering, store-and-forward, mutual TLS, encrypted at rest – measures 13.5 KB of flash and around 35 KB of RAM. Those are measurements taken from the running target and rounded up, not estimates, with the run report committed alongside the code that produced it. The example repositories carry the exact figures.

Built for the awkward end of the portfolio

Not every legacy product can carry TLS, and pretending otherwise helps nobody. The documentation takes a position: use TLS where the hardware allows it; where it doesn’t, prefer TCP over UDP – because TCP at least tells you the collector is gone, which is what makes store-and-forward meaningful – and send to a local relay that speaks TLS upstream. It also states the limit of that shape plainly: TLS protects each hop and does not carry provenance across one, so a collector behind a relay authenticates the relay rather than your device. Deployment postures for constrained devices are set out in the hardening path, limits included, so your compliance case can be honest about what the device does and what the network around it provides.

Where it stands – honestly

Version 0.1.0 was released this week. The library is feature-complete with comprehensive test coverage, and it is a 0.x by deliberate choice – the number describes how many platforms are covered so far and how little field integration exists yet, not the maturity of the code. 1.0.0 lands in Q4 2026, after the API has been exercised by real evaluations.

I’m telling you that plainly because it’s exactly why now is the right time to look at it: evaluators over the next few months get direct influence over the 1.0.0 API and the platform adapter list, and the timeline still works – evaluate now, ship against 1.0.0, and you’re producing audit trails with a year of runway before December 2027.

The licensing was designed for that. SolidSyslog is source-available, and the PolyForm Internal Use licence means any organisation can download, build, and evaluate it internally, free, without talking to me first. A commercial licence (from £5,000 per product line) is only needed when SolidSyslog ships inside a product. PolyForm Noncommercial covers hobby, charitable, educational, public research, public safety and government use – and, unlike Internal Use, it permits redistribution.

Try it this week

The fastest way in is the worked example: a simulated embedded product (FreeRTOS, lwIP, FatFs, Mbed TLS on QEMU – no hardware needed) taken from “no logging” to the most hardened configuration in 18 incremental commits, each one buildable, each with its footprint cost measured. Skim the commit history and you’ll know in twenty minutes whether this fits your products. Repos in both CMake and Make flavours: solid-syslog-example and solid-syslog-example-make.

If you would rather read the reasoning than the diffs, the hardening path walks the same eighteen steps in prose – what each one adds, the question that decides whether you need it, and what it costs.

Three more things, if it looks useful:

1. Tell me what platforms you need. Every adapter candidate is an open issue on GitHub – Zephyr, wolfSSL, LittleFS and the lwIP Sockets API so far, listed most-wanted first. Open the one you need and give it a thumbs-up; that is the vote, and demand is how I order the queue. If yours isn’t there, ask for it.
2. If you’re facing this across a portfolio, talk to me. Early adopters get my direct involvement in their evaluation – contact@cososo.co.uk.
3. Or just watch from a distance – the newsletter carries release announcements and occasional CRA compliance notes, and you can sign up right here.

Documentation · Product page · GitHub

---

David Cozens is a Chartered Engineer with nearly forty years in embedded systems, acknowledged in MISRA C:2012 for his contribution to its development and review, and the founder of COSOSO.