Earlier this week, we released v0.22.0 of the Golioth Firmware SDK, our sixth and final release of 2025. Alongside our usual bevy of bugfixes and minor improvements, this version introduces support for rotating certificates via Golioth’s integration with external PKI providers, routes logs through Pipelines, and reorganizes our firmware update reference implementation.

Certificate Rotation

We’ve long advocated for the use of certificates and public key infrastructure (PKI) to secure and identify devices. Compared to pre-shared keys (PSKs), the other form of authentication supported by Golioth, PKI provides advantages in scale and security by removing the need to explicitly create and store secrets in Golioth. But PKI comes with additional operational challenges compared to PSKs, which can be especially difficult in an embedded context. Chief among those is the need to periodically rotate certificates on devices in the field. Earlier this week, we announced support for external PKI providers to make certificate rotation easier than ever.

In this release of the Golioth Firmware SDK, we’ve added a new service that allows devices to upload a certificate signing request (CSR) to Golioth, where we’ll forward it on to your PKI provider and then send down the resulting signed certificate back to the device. There’s a new example in the SDK that shows how it all works. In this example, we take an existing key stored in the filesystem and create a CSR in standard x.509 format using mbedTLS, but the SDK is agnostic to how keys and CSRs are created and stored. For example, you could generate a new key-pair in a secure element on the device, exporting only the CSR while the private key remains in secure storage. We’ll have more to share on secure elements in the new year.

Logs Through Pipelines

Traditionally, the Golioth Firmware SDK has delivered device logs emitted by customer firmware directly to the Golioth Logs service. With this release, logs are now delivered to Golioth Pipelines by default, allowing users to transform and route logs to the destination of their choice, including the Golioth Logs service. The interaction with the logging service in the SDK is unchanged – either using the GLTH_LOGx macros or plugging into the platform’s logging subsystem.

To preserve logging functionality for existing projects, users will need to either enable CONFIG_GOLIOTH_LOG_LEGACY in the SDK configuration, or add a pipeline to route logs to the destination of their choice, such as this one that sends logs to the Golioth Logs service:

filter:
  path: "/logs"
  content_type: application/cbor
steps:
  - name: step-0
    transformer:
      type: cbor-to-json
      version: v1
    destination:
      type: logs
      version: v1

You can read more about sendings logs through Pipelines here.

Firmware Update Reference

Golioth OTA makes it easy to send the right artifacts to devices in the field. Once the artifacts get there, the device will need to do something with them, but what exactly is heavily dependent on the specific application running on that device. The SDK has long included a reference firmware update implementation that looks for updates to a single firmware image, and downloads and applies the update using the platform’s default storage partitions and bootloader. For many users, this is all the functionality they need and they can use this implementation as is. Users with more complex application structures, such as AI models, multiple MCUs or graphical assets, can build their own update mechanism leveraging the Golioth OTA service.

To better reflect the reference nature of the firmware update implementation in the SDK, we’ve moved it out of the core SDK and into the samples. This change also allows us to remove abstractions in the reference implementation and instead use platform-specific API calls, making the sample more useful as a instructional tool.