After working on IoT products for many years, I have implemented, from scratch, some form of device management platform four or five times.
Even if every connected product context is different, the requirements remain similar: maintain a device inventory, provision credentials, monitor connectivity, collect telemetry, execute remote operations, distribute firmware/software updates, and track deployments across a fleet. This infrastructure is rarely the core of the product, so it is often developed alongside the main application with limited time and resources.
The usual alternatives are to adopt a managed platform, with the architectural dependency this may create, or to build a project-specific backend that progressively becomes production infrastructure. I discussed this trade-off in Owning the Stack: Why IoT Convenience Becomes Expensive Later.
Anchor aims to make this recurring infrastructure reusable and a commodity. Anchor v0.1.0 is now available as the first public release.
What is in v0.1.0
Version 0.1.0 covers the core of device management:
- Devices are grouped by organisation and model.
- Devices are provisioned with credentials.
- Devices are monitored through heartbeats, telemetry, events, and reported software version.
Anchor keeps both the latest state and the underlying event history.
Remote operations are explicit tasks (read, write, or firmware update) with lifecycle states, not fire-and-forget messages. The same operation can target one device or a campaign, while each device retains its own result.
Firmware releases are associated with device models and can define the expected fleet version.
Releases may include SPDX SBOMs; when Grype is installed, Anchor scans them for known vulnerabilities and lets you review their relevance and see which part of your fleet is impacted.
MQTT support and broker independence
The first MQTT integration targets Mosquitto. Anchor connects as an internal client, while Mosquitto delegates device authentication and access-control checks to Anchor; together they handle credentials, topic permissions, telemetry, tasks, and connection state.
Mosquitto is a first convenience choice for v0.1.0; other brokers will require specific integrations. EMQX and AWS IoT are likely candidates. User feedback will determine priority, with the goal of not requiring a redesign of the device application protocol when changing brokers.
CoAP for constrained devices
Anchor also ships a separate CoAP-over-DTLS 1.2 frontend. Devices use per-device PSKs, with optional DTLS Connection IDs, and exchange confirmable CBOR messages for heartbeats, telemetry, task status, and remote operations.
I have used this path in a new LTE-M product, where it performs well for the expected workload. It is usable today.
CoAP is useful where persistent TCP connections are a poor fit for constrained or unstable networks. Anchor does not currently implement LwM2M; that remains on the roadmap, but it is outside this release.
Firmware updates and the device-side chain of trust
Anchor orchestrates firmware delivery: it stores releases, creates FOTA tasks, tracks progress, and compares reported versions with the expected release. It does not make an update secure on its own.
On Zephyr, sysbuild can assemble the application and MCUboot images; signed images and MCUboot’s test, confirm, and revert flow provide authenticity and safe rollback.
The boundary is deliberate: Anchor coordinates the fleet, while each device decides when to update, validates the image, boots it safely, confirms it, and reports the result.
Device management for the Cyber Resilience Act
Anchor was built with the Cyber Resilience Act and its 2027 horizon in mind. It provides the device-management functions needed to add secure firmware updates, scan release SBOMs for known vulnerabilities, and monitor which software vulnerabilities are actually running across a fleet.
Starting with open source
Anchor starts as open-source software under the GNU Affero General Public License v3.0. This is an experiment: the immediate goal is to learn whether it solves the same problem for teams beyond the projects that led to it.
The first phase is about users and feedback before contributors. I want people to install Anchor, connect real or simulated devices, and expose assumptions that are too specific, whether in brokers, protocols, provisioning, or deployment.
Contributions are welcome, but operational feedback is more valuable than growing a community around an architecture that may still change. There is no fixed business model today.
If a company needs help deploying it, integrating a device or broker, reviewing its update architecture, or preparing the system for a larger fleet, I can provide that engineering support through ClunkyMachines. This is a consulting capability around the open-source project, not yet a product model for Anchor itself.
If there is sustained interest, the next step will be to find a model (support, packaged deployment, managed operations, or something else) that lowers the cost of adoption without recreating the lock-in Anchor is intended to avoid.
For the ongoing project overview, documentation and integration support, visit the Anchor project page. If product security and evidence are your immediate concern, explore the CRA Technical Architecture Review.
Why the name “Anchor”?
The name has two meanings. A ship’s anchor provides a stable, safe attachment point; this project is intended to provide the same kind of connection between devices and the infrastructure that operates them.
In French, encore (“again”) sounds close to Anchor. Since this is roughly the fourth or fifth device-management platform I have built, the joke is also accurate.
Try Anchor v0.1.0
Anchor v0.1.0 is available as a prebuilt Linux archive for amd64 and arm64. Download the appropriate archive from the v0.1.0 release page, extract it, and start the server:
ANCHOR_ADMIN_PASSWORD='choose-a-password' ./anchorThe interface is then available at http://localhost:8080. MQTT requires Mosquitto, CoAP uses the included coap-frontend, and Grype is optional unless CVE scanning is needed. This is a technical preview, so APIs, protocol contracts, deployment mechanisms, and other details may change.