Guide · Fleet Management & Security

Centralised Firmware & Configuration Management for Wayside Assets

A monitoring fleet is only as trustworthy as the software running on its devices — and across hundreds of trackside locations, the question “what exactly is running out there, and who changed it last?” is surprisingly hard to answer once updates are done by hand, site by site. This guide covers how to manage firmware, logic applications, and configuration across a wayside fleet from one authoritative system: signed updates that survive a power cut, staged rollout that contains a bad version, integrity checking so you know what is actually running, device heartbeats for liveness, and the per-device PKI that makes every change authenticated, authorised, signed, and audited.

Why centralised management is the real problem

Putting smart devices at the wayside is the easy part. The hard part shows up a year later, when the fleet has grown to hundreds of controllers, gateways, and sensors spread across the network, each carrying firmware, a logic application, and a set of configuration parameters — and no two of them are quite guaranteed to match. A device replaced after a fault came back with a slightly different firmware build. A parameter was tweaked on a site visit and never written down. A security patch went to the sites someone could reach that month and not the rest. Individually these are minor; in aggregate they are a fleet whose running state nobody can state with confidence.

Centralised management exists to close that gap. Instead of treating each device as a thing you visit, you treat the fleet as a system you operate: one authoritative platform holds the known-good versions, decides which device should be running what, pushes changes in controlled stages, verifies what each device is actually running, and records every change. The goal is not to update more often; it is to always know — and be able to prove — the state of every device, and to change that state safely without a truck roll.

The boundary: managing the overlay, not the safety case

As with everything in this series, draw the boundary first. The firmware and configuration management described here governs the non-vital monitoring and diagnostics overlay — the controllers and gateways that read assets non-intrusively and report them — which is logically separated from, and advisory to, the vital signalling function. Managing that overlay does not by itself touch the signalling safety case.

Where a device runs vital logic, the rules are different and stricter. Any change to vital software is governed by the railway functional-safety regime: EN 50128 for software in control and protection systems, with EN 50126 (RAMS) and EN 50129 (safety-related electronic systems for signalling) framing the system and its safety case. A management platform can support that regime — version control, controlled rollout, an audit trail, evidence of exactly what is deployed where — but it never substitutes for the safety lifecycle, verification, and approval that a vital change demands. The management plane is also a security asset in its own right: it can reach and change many devices, so it must be hardened and governed under railway cybersecurity guidance such as EN 50701, which draws on the IEC 62443 series for industrial automation and control systems.

The four capabilities that matter

Strip away the marketing and competent fleet management comes down to four things done well. Each is simple to state and easy to get wrong.

Capability	The question it answers	What it requires
Versioned, staged rollout	Can I change the fleet without breaking it?	Known-good version store; cohorts; gated stages; rollback
Integrity verification	What is actually running on each device?	Reported version IDs and hashes; drift detection; attested boot
Liveness / heartbeats	Which devices are healthy right now?	Regular signed heartbeat; birth/death state; alarming on silence
Safe remote reconfiguration	Can I change a parameter without a site visit?	Authenticated, authorised, signed changes with rollback and audit

Signed updates that survive a power cut

The first rule of remote firmware is that an update can fail at the worst possible moment — mid-write, during a brownout, or just before the device would have confirmed itself healthy — and the device must still come back. The dependable pattern is a dual-bank, A/B partition layout. The new image is written to the inactive bank while the running bank stays untouched, so an interrupted write never corrupts the version that currently works. On reboot the device verifies the new image's cryptographic signature against a trusted public key before it is allowed to run, and a watchdog plus a self-validation step confirms the new image actually came up and is healthy.

If that confirmation does not arrive within a set window — the image hung, crashed, or the power dropped — the bootloader automatically reverts to the last known-good bank. The device is never left bricked and never left running an image it could not validate. A few further practices harden the mechanism:

• Sign every image and verify the signature on the device against a key anchored in a hardware root of trust, so only firmware the operator authorised will boot.
• Chain to secure boot so the bootloader itself, not just the application, is part of the verified chain and cannot be quietly replaced.
• Enforce anti-rollback with a monotonic version counter, often hardware-backed (for example an eFuse), so an attacker cannot push the device back to an older, vulnerable image.
• Use resumable, chunked transfer so an update over a marginal trackside link can pick up where it left off rather than restarting from zero.
• Describe the update with a signed manifest — the IETF SUIT working group standardises exactly this: a compact, signed description of the image, its version, and how to process it, usable even on constrained devices.

For the broader trust model — protecting the update repository and the signing keys against compromise, not just the image — The Update Framework (TUF) and its automotive profile Uptane are the reference designs worth knowing. They assume that individual keys or servers may be compromised and structure roles and signatures so that no single compromise lets an attacker ship arbitrary firmware to the fleet.

Staged rollout: contain the bad version

Even a perfectly signed, perfectly recoverable update can carry a defect that only shows up in the field. The defence is to never deploy to everything at once. A staged rollout sends a new firmware or configuration version to a small, representative canary cohort first, watches its health and telemetry through a defined soak period, and only widens to the next cohort once the canary is proven stable. A latent defect that would have been a fleet-wide outage becomes a contained, recoverable incident on ten devices.

What separates a real rollout system from a glorified “push to all” button is control at every stage:

• Cohorts you can define — by asset type, region, hardware revision, or risk — so the canary genuinely represents the fleet it precedes.
• Health gates between stages, with explicit pass criteria drawn from heartbeats, error rates, and telemetry, so widening is a decision, not a timer.
• Automatic halt and rollback when a stage regresses, so a bad version stops spreading the moment the numbers turn, without anyone watching a dashboard at 3am.
• A clear record of which cohort is on which version at any moment, so the fleet is never in an unknown intermediate state.

Stage	Typical scope	Gate before proceeding
Canary	A handful of representative devices	Healthy heartbeats and clean telemetry through the soak period
Pilot	One region or asset class	No regression in error rates or rollback events
Broad	Majority of the fleet	Pilot stable; capacity and support ready
Complete	Remainder, including hard-to-reach sites	Broad stage stable; exceptions documented

Knowing what is actually running

A deployment record tells you what you intended each device to run. It does not tell you what each device is running — and in a real fleet those drift apart. A device swapped after a fault, a half-completed update, an undocumented field change, or a rollout that silently failed on a few nodes all produce configuration drift. The fix is to verify the device rather than trust the record.

Each device reports the version identifiers and cryptographic hashes of its running firmware, logic application, and configuration. The platform compares those against the version it believes the device should hold, and any mismatch is raised as an alarm — surfaced deliberately, not discovered during the next incident. Devices with a hardware root of trust can go further with measured or attested boot, where each stage of the boot chain is measured into a secure element and the measurements are checked centrally, so the platform has cryptographic evidence of the boot state rather than a self-reported claim. Paired with a regular signed heartbeat and a birth/death liveness mechanism, integrity checking means the platform always knows two things at once: that a device is alive, and exactly what it is running.

Safe remote reconfiguration

Configuration is firmware's quieter sibling and often the more frequent source of change: a warning time tuned, a threshold adjusted, a logic parameter corrected. Doing that remotely is a large part of the value of a managed fleet, but it carries the same risk as a firmware push and deserves the same discipline. Every configuration change should be authenticated (the platform knows which operator and which device), authorised (the operator is permitted to make that change to that asset), signed (the change is cryptographically attributable and tamper-evident), and audited (recorded immutably, with the before and after state).

The same A/B and rollback thinking applies: a new configuration should be stage-able and reversible, so a bad parameter set can be backed out as cleanly as a bad firmware image. A “golden” reference configuration per asset class gives drift detection something to measure against, and makes it obvious when a device has wandered from the standard. The aim is that a routine parameter change becomes a controlled, recorded, reversible operation from the office — and the site visit returns to being the exception, reserved for genuine physical work.

Secure device identity and per-device PKI

Everything above rests on one foundation: the platform must be certain which device it is talking to before it trusts a heartbeat, accepts an integrity report, or applies a change. That certainty comes from a secure device identity — a cryptographic identity unique to one physical device and infeasible to forge or clone. The established model is IEEE 802.1AR, which defines a manufacturer-installed Initial Device Identifier (IDevID) bound to the hardware, from which the operator provisions a Locally Significant Device Identifier (LDevID) — in practice an X.509 certificate — for use on their own network.

Building the fleet on per-device PKI rather than shared credentials changes what is possible:

• Per-device authentication via mutual TLS, so the platform and the device each prove their identity before any exchange.
• Individual revocation, so a compromised or decommissioned device is revoked on its own without re-keying the entire fleet.
• Attributable change, so every firmware push and configuration edit is tied to a specific authenticated device and a specific authorised operator.
• Hardware-protected keys, with the private key held in a secure element or TPM so the identity cannot be lifted off the device and cloned.

With identities in place, the rule for the whole fleet becomes simple to state and enforce: every device is authenticated, and every change is authorised, signed, and audited. That sentence is the whole security posture of a managed fleet, and per-device PKI is what makes it true rather than aspirational.

What to demand before you buy

Fleet manageability is far cheaper to require at procurement than to retrofit onto devices already in the ground. These are reasonable, testable requirements to put to any wayside-device or platform supplier.

Demand	What good looks like
Fail-safe updates	Dual-bank A/B firmware with signature verification and automatic rollback; a power cut mid-update never bricks a device
Signed images & secure boot	Every image signed and verified against a hardware root of trust, with anti-rollback protection
Staged rollout	Definable cohorts, health-gated stages, and automatic halt/rollback on regression — not push-to-all
Integrity verification	Devices report running version IDs and hashes; drift is alarmed; attested boot where hardware allows
Liveness	Regular signed heartbeat and birth/death state, so silence is detected, not assumed
Secure identity	Per-device certificates (IEEE 802.1AR IDevID/LDevID), keys in a secure element, individual revocation
Authorised, audited change	Every firmware and configuration change authenticated, authorised, signed, and immutably logged
Separation	Management plane isolated from the public internet and from the vital signalling LAN

None of these is exotic, and none is specific to one vendor's hardware. Together they are the difference between a fleet you operate with confidence — knowing what every device runs and being able to change it safely — and a collection of trackside boxes whose state you can only discover by driving out to look. At scale, the second option is not a strategy; it is a slowly accumulating liability.

Frequently asked questions