Structured syslog for embedded and industrial systems.

The security audit trail the Cyber Resilience Act and IEC 62443 expect — as a drop-in component for the products you already ship. Bring your own OS, network stack, TLS and filesystem; nothing else about your product has to change.

Talk to us about your product Explore the documentation →

Free to evaluate — and open on GitHub.

Figures measured by the worked example below — a representative device, not a specification.

Connected products now have to prove what happened on them

Regulation is converging on one expectation: a device must keep a trustworthy record of its security-relevant events. IEC 62443 asks it of industrial products and the systems built from them. The EU Cyber Resilience Act makes it a condition of placing a product on the European market. NIS2 pushes the same duty onto the operators who deploy those products — and they increasingly require it of their suppliers.

The CRA’s dates are already close. Manufacturers must report actively exploited vulnerabilities and severe incidents from 11 September 2026, and the Regulation applies in full from 11 December 2027. Work that backwards through assessment, design freeze and integration, and the window for deciding how your product produces its audit trail is a good deal narrower than the deadline suggests.

None of these frameworks names a protocol. But on an embedded device, syslog is the established way to produce that audit trail: a proven, universally understood format that every SIEM already ingests, far lighter to add to a product than the alternatives, and exactly what an assessor expects to see.

SolidSyslog gives you that as a component you drop in, not a subsystem you invent — a fully tested, scalable, standards-compliant syslog implementation you can add to an existing product or design into a new one, rapidly and without building it yourself.

What SolidSyslog does

It records a security event inside your device, stamps it with trusted metadata, holds it safely if the network drops, and delivers it to any central log server — over UDP (RFC 5426), TCP (RFC 6587), or TLS with optional mutual authentication (RFC 5425) — in the standard, structured syslog format (RFC 5424) that every SIEM already understands.

SolidSyslog runs inside your product. The pink tags are the seams where it fits around what you already run — your OS, filesystem, network stack and TLS library — so Core never changes.

It runs from small networked microcontrollers up to Linux hosts, needs no dynamically allocated memory, and asks for nothing it can avoid: omit a capability and a built-in null object stands in.

Records are assembled in bounded buffers throughout, so a long message cannot overrun one. A record too long for its buffer is truncated without ever splitting a UTF-8 character, ill-formed input is substituted rather than passed through to your SIEM, and every structured-data value is escaped on the way out. It is built on the established syslog standards — the RFC compliance matrix sets out exactly what it implements.

Designed for retrofit, at home in a new design

Retrofit is the design centre, because it is the harder problem. Every platform dependency — network stack, TLS library, filesystem, OS primitives, clock — is injected, so you bring what you already run. Features are composed at link time rather than switched on with #ifdef, there is no dynamic allocation anywhere, and it is plain C99. Nothing about your existing product has to change around it: you add sources to a build you already have, and wire the roles your deployment actually needs.

Those same properties are why it stays out of the way in a clean-sheet design. It constrains nothing about your architecture — pick your RTOS, stack and toolchain on their own merits, and SolidSyslog fits whatever you pick.

Devices that cannot run TLS are not excluded. Plain TCP to a syslog relay on a protected, firewalled control network — with the relay speaking TLS onward to your SIEM — is a workable shape, and TCP is the better choice over UDP because a send that fails tells the device the collector is gone, which is what gives store-and-forward something to act on. Be clear-eyed about what it buys, though: TLS protects each hop and does not carry provenance across one, so a collector behind a relay authenticates the relay rather than your device. The hardening path and our threat-model input both state that limit plainly, so you can document your expected usage against it rather than around it.

Build up the protection you need

You don’t buy a tier. Start from the system you already have, add one capability at a time, and stop where your threat model, your requirements and your resources say to stop — a capability you don’t need costs nothing. The hardening path walks all twenty steps, each with what it adds, the question that decides whether you need it, and what it costs.

Step	What it adds	The question it answers	Cost so far
On the wire	A valid, timestamped RFC 5424 record, naming the device, delivered to your collector.	Every device needs this much.	+5 KB flash +0.4 KB RAM
Nothing lost	Numbered records so a gap is visible, logging decoupled from sending, TCP so a failed send is detected, store-and-forward across outages and reboots, and how far the clock can be trusted.	What is your audit-loss budget? If the collector is unreachable for an hour, is losing that hour acceptable?	+12 KB flash +7 KB RAM
A trusted channel	TLS to an authenticated collector, tamper-evident records at rest, and a record that states the protection its own pipeline is under.	Does the log path cross a network you don’t control, or could someone reach the storage medium?	+13.5 KB flash +35 KB RAM mainly TLS buffers
Provable origin	Mutual TLS, so the receiver authenticates the device rather than taking its word, and authenticated encryption at rest.	Must the collector prove which device sent a record — and would a disk that leaves the device give something away?	+13.5 KB flash +37.5 KB RAM mainly TLS buffers

None of the standards — not the CRA, IEC 62443 or NIS2 — hands you a parts list. IEC 62443 assigns Security Levels to a system in its deployment and its assessment, not to a component, and the CRA gates its Annex I requirements on your own risk assessment and applies them “where applicable”. What your device needs from its audit trail therefore follows from your threat model and your documented intended purpose. This is our best guidance on how SolidSyslog helps with the audit-logging controls, not a guarantee of compliance, and no substitute for assessment of your finished product.

See the integration, step by step

Don’t take our word for “fast and easy” — read the commits. We built a realistic embedded product on QEMU — FreeRTOS, lwIP, FatFs and Mbed TLS, a device that already networks, stores and holds a TLS session before any syslog exists — and then added SolidSyslog to it one commit at a time, from the first UDP message through buffering, store-and-forward, TLS and mutual TLS to encrypted storage.

Every stage is a single commit. It says what it does, what it changes, what it gives you, and what it costs — and the costs are measured by the device itself, not estimated, with the run report committed alongside. git show on any stage gives you the diff to apply to your own build and the reasoning behind it. The same integration is published twice, so you can read it in whichever build system you use:

From the smallest networked devices upward

The same Core runs on a small networked microcontroller and on a Linux server. Written in C99 with no dynamically allocated memory, dependency-injected throughout, and MISRA C:2012 informed, it scales across your product range without a different codebase. The platforms guide shows what runs where.

Why SolidSyslog

Fits your product — and grows to fit more

Porting SolidSyslog is filling roles, not editing Core: supply an adapter for a platform we don’t ship yet, or omit one and its null object stands in. Reference adapters already ship for FreeRTOS, lwIP and FreeRTOS-Plus-TCP, Mbed TLS and OpenSSL, ChaN FatFs and FreeRTOS-Plus-FAT, C11 atomics, POSIX and Windows. Logging is as simple as SolidSyslog_Log(); servicing the secure storage and network is as simple as SolidSyslog_Service(). The build integration guide has the capability matrix and all three consumption paths — CMake, Make, and a source manifest for an IDE project.

What we add next is partly up to you

Zephyr and wolfSSL are among those already on the backlog. Every candidate platform is a public issue on GitHub, and a thumbs-up is a vote — demand is how we order the queue. If the platform you need isn’t listed, ask us and we will add it.

How it gets built comes down to one question: can we build and test it ourselves?

• If we can — with freely available tooling, in our CI, on every change — we will consider it for free inclusion. It joins the supported platform list and is maintained and regression-tested like everything else we ship.
• If we can’t — a toolchain behind a licence server, a proprietary SDK, hardware we would have to buy — we will write it for you, or help your team write it, with the cost offset against your licence.

A funded engagement moves a platform up the queue, exactly as votes do. Either way, we would rather a platform became part of the product — supported, documented, and proven against the role contract on every change — than a fork you maintain on your own.

Try it, then licence it

SolidSyslog is feature-complete, with comprehensive automated test coverage across every supported platform, and ready to trial today. It is free to evaluate, and free for non-commercial, personal, educational and government use under the PolyForm Noncommercial License. Shipping it inside a commercial product needs a commercial licence.

Commercial licences start at £5,000 per product line, with discounts across multiple products and company-wide terms available. Maintenance and integration consultancy can be bought alongside. We would rather tell you the number up front than make you ask for it.

If you are working to a CRA or IEC 62443 deadline, talk to us early — we will help you fit it into your roadmap, including additional platforms and integration support.

Talk to us about your product Start integrating →