Digital Twins Could Track Every Security Update Across IoT Device Fleets

Every security patch that flows through an Internet of Things deployment leaves a trail of records scattered across software repositories, signing infrastructure, deployment services, device management platforms and the devices themselves. Researchers at SINTEF have now tested a way to stitch that trail together: extending the digital twin of each device so that it becomes a shared information contract for the entire secure software update lifecycle. In a laboratory evaluation combining a real telemedicine gateway with fleets of up to 500 emulated devices, queries over the digital twins correctly identified vulnerable, updated and failed devices despite injected installation failures, verification failures and temporarily offline gateways.

The work, published in Discover Computing, builds on Eclipse Ditto, an open-source digital twin platform. The authors, Rustem Dautov, Hui Song, Arda Goknil and Adela Nedisan Videsjorden, extend Ditto’s thing model with a SoftwareManagement feature whose desired and reported properties hold one entry per software artefact. Desired properties express deployment intent, written by an assignment engine; reported properties capture what device-side agents actually observe. A mismatch between the two signals that a device has not yet reached its intended configuration, and convergence of the two marks the completion of an update.

The motivation comes from the fragmented reality of IoT software maintenance. In the paper’s running example, a remote patient monitoring gateway running Debian needs an OpenSSL security update fixing CVE-2024-4603, moving the packages openssl and libssl3 from version 3.0.11 to 3.0.14. Answering seemingly simple questions, such as which gateways still run a vulnerable version or whether the update completed on all targeted devices, requires manually correlating records from five heterogeneous systems, each with its own identifiers, data model and interfaces. As fleets and package counts grow, maintaining a coherent view becomes increasingly difficult.

The authors frame the problem as one of interoperability rather than deployment alone. Existing secure software update frameworks, such as the IETF SUIT architecture, TUF and Uptane, secure the artefact, its metadata and its delivery, but assume that one update system owns the process. Update platforms like Azure Device Update already use device twins to coordinate updates within their own scope. The novelty claimed here is using the digital twin as an information contract shared by separately operated lifecycle components, including installation and verification outcomes, and in evaluating what that sharing costs.

The proof-of-concept implementation, called DT-POSSUM, adds a software assignment engine that selects target devices by querying twin properties, a Node.js lifecycle service that subscribes to twin change events and dispatches deployments over MQTT, and three device-side microservices: an Installation Agent wrapping Debian’s apt tooling, a Verification Agent, and a continuously running Monitoring Agent built on Telegraf. Integrity is checked on the device itself, since apt only accepts packages listed in signed repository indices, so a compromised twin platform could at most request genuine, signed versions. The twins reference artefacts rather than contain them, keeping the twins small and leaving distribution to mechanisms designed for it.

The first experiment followed a real OpenSSL update on a Raspberry Pi 3 gateway through 40 alternating upgrades and downgrades. Across 20 measured upgrades, an update took 1705 milliseconds on average from the desired-state write to convergence, with installation and verification on the gateway accounting for 95 percent of that time. Every step through the twin platform stayed below 40 milliseconds, adding roughly 91 milliseconds in total. Ditto’s revision history retained every intermediate state linked by a workflow identifier, allowing the course of a past update to be reconstructed from the twin alone, within the 30-day retention period of the history in the researchers’ configuration.

A scalability experiment measured assignment over populations of registered twins without connected devices, growing from 100 to 10,000. Assignment time grew roughly linearly, from 320 milliseconds for 100 twins to 18.1 seconds for 10,000, of which the search for the roughly 20 percent of vulnerable targets took about 6 seconds and the desired-state writes about 12 seconds. The authors consider 18 seconds acceptable for security updates, since assignment typically happens once per release, but note that a single-node twin platform bounds how quickly updates can be assigned across large fleets.

The most demanding test updated 500 emulated gateways with calibrated failure injection: installation failed on 5 percent, verification on 3 percent, and 10 percent of gateways were offline during the first 60 seconds after assignment. Persistent MQTT sessions queued requests for offline devices, and a reconciliation loop re-dispatched twins that had neither converged nor terminally failed. Once every gateway had reached a final state and the search index had caught up, within about half a second, four queries over the twins returned exactly the gateways recorded by the emulator, with no false positives or false negatives. All gateways reached a final state within about 60 seconds on average.

An extensibility experiment added vulnerability identifiers, a reference to an SPDX software bill of materials, and a new vulnerability annotator component of roughly 110 lines of JavaScript, none of which required changes to the existing platform, lifecycle service or agents. The additions were not free: the extended runs increased the median device completion time for 100 gateways by 546 milliseconds on average, because each annotation write is a further request the twin platform must process. Adding components to a shared twin thus costs nothing in code changes but adds load that grows with the number of twin changes a component reacts to.

The authors are careful about the limits of the evidence. All experiments ran on a single laptop, with no wide-area network latency, one kind of software artefact, one twin platform on one host, and lifecycle components developed by the same team, so the components agree on the twin structure by construction. The correctness of device reports is assumed rather than verified, and remote attestation would be needed to substantiate a compromised device’s claims. The model achieves technical and syntactic interoperability, with semantics fixed by convention rather than a formal reference model. Future work includes evaluating the approach with independently developed components, on embedded hardware in the field and across organisations, scaling out the twin platform, separating write permissions per component, handling conflicting deployment intents and automatic rollback, and integrating microcontroller-class devices through firmware update standards such as SUIT.

Subject of Research: Using digital twins as a shared information model for secure software update lifecycle management in IoT

Article Title: Using digital twins as a shared information model for secure software lifecycle management in IoT

Article References: Dautov, R., Song, H., Goknil, A., & Videsjorden, A. N. (2026). Using digital twins as a shared information model for secure software lifecycle management in IoT. Discover Computing, 29(1), Article 801. https://doi.org/10.1007/s10791-026-10753-2

Image Credits: AI Generated

DOI: 10.1007/s10791-026-10753-2

Keywords: digital twins, IoT, secure software updates, Eclipse Ditto, interoperability, software lifecycle, telemedicine gateways, OpenSSL, device management, fleet updates, digital, twins