TDT-Pipe: A Security-Aware Architecture for Trustworthy IoT Digital Twins

Abstract

Digital Twins rely on continuous data exchanges between physical assets, Internet of Things devices, communication infrastructures, and software representations. In MQTT-based deployments, however, successful message delivery does not guarantee that a telemetry value is authentic, authorized, fresh, structurally valid, or appropriate for updating the active twin state. This paper presents TDT-Pipe, a security-aware telemetry-to-Digital-Twin pipeline that separates message transport from update admission. The architecture integrates secure publication, registry-based device control, edge validation, provenance generation, controlled state management, quarantine, auditing, and policy-based views. Telemetry messages are protected through payload digests and device-specific HMACs, while validation predicates classify them as verified, suspicious, or untrusted and map each class to apply, quarantine, or reject actions. The formal model links active values to the events that produced them and supports security properties covering authentication, integrity, freshness, replay protection, controlled state modification, audit traceability, and view confinement. A lightweight prototype is used to assess the feasibility of the approach. The evaluation indicates that the proposed validation, provenance, and controlled-admission mechanisms can be integrated into IoT Digital Twin pipelines while keeping the processing overhead limited.

1. Introduction

Digital Twins (DTs) are software representations of physical entities, processes, or environments that are continuously informed by operational data. Unlike static models, DTs are commonly characterized by an ongoing relationship with their physical counterparts, through which measurements, events, and state changes are reflected in the digital representation. Prior work highlights continuous synchronization and data exchange as central characteristics of DT systems and distinguishes digital models, digital shadows, and Digital Twins according to the degree and direction of data integration [1,2]. In this perspective, the practical value of a DT depends on the quality and timeliness of the information connecting the physical and digital domains.

Internet of Things (IoT) technologies provide a natural sensing and communication layer for this connection. Distributed sensors and embedded devices observe the physical environment [3,4] and generate the telemetry used to update the DT. Such deployments commonly involve heterogeneous devices, constrained communication links, multiple data consumers, and asynchronous data flows. MQTT is particularly attractive in this context because its lightweight publish–subscribe model decouples telemetry producers from consumers and allows multiple services to receive data through topic-based subscriptions [5,6,7]. An MQTT broker can therefore connect a large set of sensing devices to DT components without requiring publishers to know which applications will consume their measurements.

This architectural decoupling does not, by itself, make the resulting DT state trustworthy. A message reaching a broker or subscriber may have been generated by an unauthorized source, altered in transit or within an intermediary, published under an inappropriate topic, delayed, duplicated, replayed, or delivered out of order. More generally, IoT ecosystems expose authentication, authorization, integrity, privacy, and trust challenges that arise from device heterogeneity, distributed communication, and the interaction of multiple administrative domains [8,9,10]. Empirical assessments of consumer IoT devices also show that replay weaknesses and deficiencies in authentication and reliability remain relevant in real products [11].

Transport security and broker-side access control are important parts of a protected deployment, but they address only part of the telemetry-to-DT path. In a brokered architecture, transport protection terminates at communication endpoints and does not necessarily provide end-to-end evidence that the subscriber received exactly the message generated by the registered publisher. Moreover, transport delivery does not determine whether the message is fresh, whether it has already been processed, whether its payload satisfies the expected structure, or whether it is authorized to modify a particular DT field. Research on MQTT has consequently considered end-to-end confidentiality, integrity, and accountability mechanisms that complement conventional transport protection [12,13]. These mechanisms demonstrate the importance of protecting or documenting message flows, but a DT additionally requires an explicit admission decision that determines how each delivered message affects its operational state.

The same need arises for provenance and controlled disclosure. A trustworthy DT should make it possible to determine which event produced an active value, why a message was accepted or refused, and which consumers may observe a field or its provenance reference. General provenance models provide concepts for describing entities, activities, agents, and derivations, while accountability mechanisms associate actions with verifiable evidence or responsibility [14,15]. Nevertheless, these concerns are often treated separately from message authentication, replay prevention, semantic validation, quarantine, and DT state modification.

This paper addresses this gap through TDT-Pipe, a security-aware architecture for controlling the complete path from IoT telemetry publication to Digital Twin state update. The key design principle is that message delivery and state admission are distinct operations. A telemetry message is allowed to modify the active DT state only after the Edge Security Gateway has verified the claimed device, topic authorization, payload structure, payload digest, HMAC, sequence number, timestamp, and semantic plausibility. The resulting decision is mapped to one of three explicit actions: verified updates are applied, authenticated updates that raise warning conditions are quarantined, and messages failing mandatory checks are rejected. A provenance record is generated for every processed message, active values remain linked to the events that produced them, and policy-based views restrict the fields and provenance references released to each consumer.

The main contributions of this work are the following:

• a telemetry-to-DT architecture that separates MQTT delivery from application-layer update admission;
• a formal message, registry, and validation model covering source authentication, topic authorization, structural validation, payload integrity, freshness, replay protection, and semantic plausibility;
• controlled DT state management combining active values, provenance references, quarantine, audit history, and field-level consumer views;

The remainder of the paper is organized as follows. Section 2 discusses Digital Twin foundations, IoT and MQTT security, provenance, accountability, and access control. Section 3 introduces the system model and design requirements, and Section 4 presents the proposed architecture. Section 5 formalizes telemetry messages, device profiles, and validation decisions. Section 6 describes the architectural components. Section 7 reports the experimental evaluation, Section 8 presents the security analysis, and Section 10 concludes the paper.

2. Related Work

Research on Digital Twins has established the main definitions, enabling technologies, and application domains of the paradigm [1,16,17]. Manufacturing and modelling studies further refine the distinction between digital models, digital shadows, and Digital Twins, and characterize DT components, roles, values, and implementation challenges [2,18,19,20,21,22]. These contributions clarify what a DT is and why synchronization matters, but they generally stop before the message-level admission question addressed here: whether a delivered telemetry message should be allowed to modify an active twin field.

IoT and DT security studies provide complementary motivation. IoT surveys discuss heterogeneous devices, communication protocols, authentication, authorization, privacy, trust, and policy enforcement as recurring security concerns [5,8,9]. DT-oriented security architectures show how a twin can support supervision of industrial automation systems [23], while empirical analyses of consumer IoT devices expose replay, authentication, and reliability weaknesses that make source and message assumptions fragile [11]. The relevance of lightweight and real-time edge processing also extends to safety-critical industrial IoT monitoring. For example, TinyLSN targets real-time marine pipeline leakage detection with a lightweight IoT-oriented model [24], while distributional knowledge harmonization has been studied for acoustic-emission-based leak pattern recognition across heterogeneous operating conditions [25]. TDT-Pipe takes a narrower operational perspective: it protects the DT update boundary before incoming telemetry can modify a modelled entity.

MQTT-related work addresses the communication layer and message evidence. The OASIS MQTT standard defines the lightweight publish–subscribe protocol widely used for IoT telemetry routing [6], and protocol-specific analyses highlight attacks such as SlowITe against MQTT services [26]. Other work strengthens MQTT exchanges at the message-flow level. MQTT-E introduces end-to-end encryption for publish–subscribe communication through proxy re-encryption [12]. Other MQTT security schemes combine mutual authentication, access-control lists, and message encryption to strengthen the broker-mediated communication path [27]. Blockchain-, Merkle-tree-, and IPFS-based mechanisms support integrity verification, accountability, and non-repudiation for exchanged MQTT messages [13]. These mechanisms are useful foundations, but they do not address the final DT-state transition: after delivery and verification, a message may still be stale, duplicated, structurally invalid, semantically suspicious, or unauthorized for a specific twin field.

Table 1. Functional comparison with representative MQTT and Digital Twin security approaches.

Approach	Boundary	Main Guarantee	Relation to DT Admission
MQTT standard with transport security [6]	MQTT delivery	Broker-mediated publish–subscribe delivery; TLS may be used in deployments.	Delivery security does not decide whether a telemetry value may update a DT field.
MQTT-E [12]	MQTT payload confidentiality	End-to-end confidentiality with proxy re-encryption.	Confidential delivery is complementary to deciding whether the payload should update the DT.
Security-enhanced MQTT scheme [27]	MQTT client–broker path	Mutual authentication, topic access control, and encrypted transmission.	It secures MQTT communication; DT admission and provenance remain outside its scope.
MQTT blockchain/IPFS accountability [13]	MQTT message evidence	Blockchain- and Merkle-based integrity, accountability, and non-repudiation.	It records evidence for MQTT exchanges, but does not define DT quarantine or update effects.
DT trustworthiness architecture [28]	DT platform architecture	Requirements and design guidance for trustworthy DT platforms.	It addresses DT trustworthiness broadly; TDT-Pipe specifies the per-message admission decision.
Blockchain/ABE DT access control [29,30]	DT data access	Fine-grained access control for DT/IoT data using blockchain and ABE.	It protects data sharing after generation; TDT-Pipe decides whether incoming telemetry may become active DT state.
TDT-Pipe	DT update admission	HMACs, freshness, sequence checks, registry authorization, provenance, quarantine, audit, and policy views.	It maps each processed message to apply, quarantine, or reject before the active DT state changes.

summarizes the boundary between representative related approaches and TDT-Pipe. The comparison focuses on functionality because the referenced systems protect different layers, use different cryptographic and storage assumptions, and expose different semantics to applications.

From a performance perspective, the compared mechanisms also introduce different kinds of overhead. Transport-security and broker-level mechanisms mainly add communication and session-management costs; end-to-end encryption schemes add cryptographic processing on the publishing and receiving path; blockchain/IPFS-based approaches introduce additional storage, consensus, or external-verification costs; and ABE-based DT access-control schemes add policy-evaluation and cryptographic data-access costs. By contrast, TDT-Pipe concentrates its overhead at the DT admission boundary, where the dominant costs are payload canonicalization, digest computation, HMAC verification, registry lookup, provenance creation, and audit insertion.

The comparison shows that TDT-Pipe is complementary to communication-layer and data-sharing mechanisms. MQTT-E and related MQTT security schemes protect the exchange between MQTT participants; blockchain-based accountability mechanisms make message exchange verifiable or non-repudiable; and DT access-control frameworks regulate who can access DT data after it exists. By contrast, TDT-Pipe focuses on the admission boundary between a delivered telemetry message and the active DT state. Its novelty is the explicit link between message validation, update decision, DT-state effect, provenance event, quarantine outcome, audit record, and policy-controlled view generation. Therefore, the proposed model does not replace end-to-end encryption, broker hardening, or blockchain accountability; it defines the missing control point that decides whether a delivered telemetry item is allowed to become an active Digital Twin value.

Provenance and access-control literature addresses the evidence and disclosure dimensions of this problem. W3C PROV provides an interoperable vocabulary for entities, activities, agents, and derivations [14]; accountability work studies how actions can be associated with durable evidence [15]; and IoT access-control research and XACML provide models for policy-based resource authorization [31,32]. The contribution of TDT-Pipe is to combine these strands around each telemetry-to-state transition: validation produces a decision, action, reason code, and event identifier; verified messages update the active state; suspicious messages are quarantined; rejected messages remain only in audit history; and consumer views expose only authorized values and provenance references.

3. System Model and Design Requirements

This paper considers an IoT-enabled Digital Twin (DT) in which distributed physical devices publish measurements and status updates used to maintain a synchronized software representation of a monitored environment. The reference instantiation is a smart-building DT composed of rooms, sensors, environmental variables, occupancy states, and energy-related measurements. The proposed model is not tied to a specific building platform: it formalizes the update pipeline that connects IoT telemetry to a DT state and defines the validation conditions under which a telemetry payload is allowed to modify that state.

The core observation behind TDT-Pipe is that transport delivery and DT update admission are different operations. A telemetry message that reaches an MQTT broker is not necessarily a valid update for the DT. Before a physical value changes the DT state, the system verifies the source identity, topic authorization, payload structure, payload integrity, sequence number, timestamp, and semantic plausibility of the update.

3.1. Reference Scenario

The reference scenario consists of a smart building with multiple rooms. Each room may include temperature sensors, humidity sensors, CO₂ sensors, occupancy sensors, door sensors, and energy meters. Devices publish telemetry to topic namespaces associated with the monitored room and metric. The DT maintains the current logical state of the building and exposes controlled views to consumers such as administrators, energy services, automation components, and external analytics services.

For each DT entity e, the system maintains an active-state map $X_e$, a provenance-reference map $A_e$, and a quarantine set ${\mathsf{\Gamma }}_e$. The map $X_e$ contains the latest values admitted into the DT, $A_e$ links each active value to the event that produced it, and ${\mathsf{\Gamma }}_e$ contains authenticated updates that were not admitted because they raised a warning condition.

3.2. Entities

The system includes the following logical entities.

• IoT device: a physical or simulated sensing device that produces measurements or status updates. Each device is identified by a stable identifier d.
• Secure publisher: the publication function associated with the device. It constructs the canonical telemetry message, assigns the sequence number and timestamp, computes the payload digest, and generates the integrity tag.
• MQTT broker: the message-routing component that decouples publishers from consumers. The broker delivers messages, but it does not decide whether a telemetry payload may update the DT.
• Device Registry: the logical authority that stores, for each device, the validation key, authorized topics, topic-specific payload rules, freshness parameters, sequence state, and DT-field mapping.
• Edge Security Gateway: the validation point that subscribes to telemetry topics, evaluates the validation predicates, assigns a decision, and advances the validated sequence state when appropriate.
• Provenance Manager: the component that creates a provenance record for each processed message and associates accepted or quarantined updates with an event identifier.
• Digital Twin State Manager: the component that applies verified updates and stores suspicious updates in quarantine.
• Policy-Based View Generator: the component that exposes field-level views of the DT according to consumer role and purpose.
• Audit Store: the trusted repository that preserves provenance records and the ordered validation history of DT fields.

Table 2. Logical components of TDT-Pipe and their research role.

Component	Responsibility	Security Property
IoT device	Produces physical measurements and status updates.	Source of telemetry data.
Secure publisher	Constructs authenticated and ordered update messages.	Source authentication and payload integrity.
MQTT broker	Routes telemetry messages from publishers to the validator.	Delivery decoupling.
Device Registry	Defines authorized devices, topics, keys, payload rules, and sequence state.	Authentication and authorization basis.
Edge Security Gateway	Assigns a validation decision to each incoming update.	Integrity validation, freshness, anti-replay, and topic enforcement.
Provenance Manager	Creates provenance records and associates events with DT actions.	Traceability and accountability.
DT State Manager	Applies or quarantines updates according to the validation action.	Controlled state modification.
Policy-Based View Generator	Releases different DT fields to different consumers.	Selective disclosure and data minimization.
Audit Store	Preserves validation records and event histories.	Post-incident reconstruction.

summarizes the logical components of TDT-Pipe and their respective roles.

3.3. Threat Surface and Design Requirements

The architecture addresses attacks and faults that may occur between physical sensing and DT state update. These include payload tampering, unauthorized publishing, topic misuse, replay of old messages, stale delivery, unintended modifications before validation, and excessive exposure of DT data to consumers. Physical compromise of a sensor, extraction of its validation key, and complete compromise of trusted infrastructure components are outside the scope of the present model and are discussed as limitations.

The design requirements are the following.

• R1—Source authentication: each update admitted to the DT pipeline must be associated with a registered device and a valid device-specific integrity tag.
• R2—Topic authorization: a device must be able to update only the topic namespaces explicitly assigned to it.
• R3—Payload integrity: any modification of the payload or protected message metadata must be detected before the DT state is modified.
• R4—Freshness and anti-replay: repeated, expired, or out-of-order updates must not overwrite the active DT state.
• R5—Provenance and auditability: each processed update must be associated with a record that supports reconstruction of its claimed source identifier, validation result, and effect on the DT.
• R6—Controlled DT state management: only verified updates may modify the active state, while authenticated but suspicious updates must be quarantined.
• R7—Selective disclosure: consumers must receive only the DT fields and provenance references authorized by their role and purpose.

4. Proposed Architecture

TDT-Pipe is a security-aware pipeline for IoT-based Digital Twins. Its purpose is to make the DT update operation explicit and verifiable. A telemetry message is admitted into the active DT state only after passing a sequence of mandatory validation predicates. Messages that fail at least one mandatory predicate are rejected, while authenticated messages that raise a warning condition are quarantined and recorded for accountability.

4.1. Architecture Overview

Figure 1 reports the logical architecture. IoT devices generate measurements. Secure publishers transform measurements into authenticated update messages. The MQTT broker transports the messages to the Edge Security Gateway. The gateway validates each message using the Device Registry and produces a decision, an action, and a reason code. The Provenance Manager creates the corresponding audit record. Finally, the DT State Manager applies or quarantines the update, while the Audit Store preserves the processing history.

4.2. Why Application-Layer Integrity Is Required

Transport-layer protection is necessary but not sufficient for a trustworthy DT update pipeline. TLS protects a connection between two endpoints during transmission. In a brokered architecture, the device-to-broker TLS session terminates at the broker, while downstream delivery takes place through a separate connection. Therefore, the validation layer requires application-level evidence that the message it receives is the message generated by the registered publisher.

Broker authentication also does not determine whether a payload is authorized for a specific DT field, whether the message is fresh, or whether it has already been processed. A previously valid message may be republished through a new protected connection, and TLS would protect that new transmission without identifying it as a replay. For these reasons, TDT-Pipe binds the payload digest to the device identity, topic, timestamp, and sequence number through a device-specific HMAC.

The Edge Security Gateway must receive the original envelope generated by the publisher. Any transformation performed before validation changes the protected content and causes verification to fail.

4.3. Update Lifecycle

Figure 2 illustrates the validation sequence for an incoming DT update, whose lifecycle consists of seven logical steps.

• An IoT device generates a new measurement or status update.
• The Secure Publisher associates the update with the appropriate MQTT topic, generation timestamp, and sequence number, and computes a digest of the payload.
• The Secure Publisher constructs the protected message and generates its integrity tag using the key associated with the device.
• The MQTT Broker forwards the complete publisher-generated message to the Edge Security Gateway without modifying its protected fields.
• The Edge Security Gateway verifies the device profile, topic authorization, payload structure, payload integrity, sequence number, freshness, and semantic plausibility of the update.
• The Provenance Manager records the source of the message, the validation outcome, the reason for the decision, and the action selected for the Digital Twin. The resulting record is forwarded to the Audit Store.
• Verified and suspicious updates are forwarded to the Digital Twin State Manager for application or quarantine, whereas rejected updates are preserved only in the Audit Store.

5. Formal Update Model

This section defines the telemetry message, the device profile, the integrity material, and the validation rule used by TDT-Pipe.

5.1. Telemetry Message

Let d be the device identifier carried by the message, let $\mathcal{D}$ denote the set of registered and active device identifiers, and let $topic$ be the MQTT topic on which the device publishes. The i-th message generated by d is represented as

$$m_i^d=\langle d,topic,t{s}_i,se{q}_i,payloa{d}_i,p_i,{\tau }_i^d\rangle ,$$

(1)

where $t{s}_i$ is the generation timestamp, $se{q}_i$ is a monotonically increasing sequence number for the device-topic stream, $payloa{d}_i$ is the domain payload, $p_i$ is the digest of the payload, and ${\tau }_i^d$ is the message integrity tag.

Table 3. Logical structure of a telemetry message.

Field	Notation	Meaning
Device identifier	d	Logical identity of the telemetry source.
Topic	$topic$	Namespace identifying the intended DT entity and field.
Timestamp	$t{s}_i$	Claimed generation time of the update.
Sequence number	$se{q}_i$	Monotonic counter used for ordering and replay detection within the device-topic stream.
Payload	$payloa{d}_i$	Measurement or device-status value.
Payload digest	$p_i$	Hash of the canonical payload representation.
Integrity tag	${\tau }_i^d$	HMAC computed over the protected message fields.

summarizes the fields of the telemetry message and their roles.

The canonical representation used by the cryptographic functions is denoted by $\mathsf{can}(·)$. It serializes fields in a deterministic order and with deterministic encodings. This prevents two different encodings from representing the same protected message ambiguously.

Throughout the formal model, the same notation is used for the corresponding message fields and registry parameters. In particular, subscript i identifies the processed message, superscript d identifies the claimed device, and $topic$ identifies the device-topic stream to which the sequence state and payload rules apply.

5.2. Device Profile

Each device d is associated with the registry profile

$$R\left(d\right)=\langle K_d,{\mathcal{T}}_d,{\mathcal{S}}_d,{\mathcal{P}}_d,{\Delta }_d^{warn},{\Delta }_d^{max},{ϵ}_d,s_d,{\mu }_d\rangle .$$

(2)

Here, $K_d$ is the active symmetric validation key of device d; ${\mathcal{T}}_d$ is the set of topics authorized for d; ${\mathcal{S}}_d$ and ${\mathcal{P}}_d$ map each authorized topic to its structurally valid and semantically plausible payload sets, respectively, with ${\mathcal{P}}_d\left(topic\right)\subseteq {\mathcal{S}}_d\left(topic\right)$; ${\Delta }_d^{warn}$ and ${\Delta }_d^{max}$ are the warning and maximum delivery delays; ${ϵ}_d$ is the tolerated future-timestamp offset; $s_d\left(topic\right)$ is the largest sequence number already admitted for the device-topic stream; and ${\mu }_d\left(topic\right)=(e,f)$ maps an authorized topic to field f of DT entity e. The mapping ${\mu }_d$ is defined for every $topic\in {\mathcal{T}}_d$. In a deployment, $K_d$ is associated with lifecycle metadata such as a key identifier, version, validity interval, and status. For compactness, the formal model writes $K_d$ for the currently active key version. The timing parameters are registry-controlled and may be configured per device, or per device class in an implementation, to reflect expected network delay and bounded clock skew.

The timing parameters satisfy

$$0<{\Delta }_d^{warn}<{\Delta }_d^{max},{ϵ}_d\ge 0.$$

(3)

Structural validity is expressed through the predicate

$$\mathsf{PayloadValid}(d,topic,payloa{d}_i)\equiv payloa{d}_i\in {\mathcal{S}}_d\left(topic\right).$$

(4)

Semantic plausibility is evaluated separately through

$$\mathsf{PayloadPlausible}(d,topic,payloa{d}_i)\equiv payloa{d}_i\in {\mathcal{P}}_d\left(topic\right).$$

(5)

For example, a CO₂ message may contain the expected fields, data types, and unit, making $\mathsf{PayloadValid}$ true, while reporting a value outside the operationally plausible range, making $\mathsf{PayloadPlausible}$ false. As a concrete rule-based instantiation, an indoor CO₂ update may be considered plausible when the unit is ppm and the value belongs to an operational range such as $350\le value\le 5000$. Similarly, an indoor temperature update may be considered plausible when the unit is Celsius and the value belongs to a building-specific range such as $10\le value\le 40$. These numerical bounds are deployment parameters rather than universal constants. Values outside these ranges do not necessarily indicate forgery: if the mandatory authentication, freshness, and structure checks succeed, they are classified as suspicious and quarantined rather than silently applied. In the evaluated configuration, $\mathsf{PayloadPlausible}$ is instantiated with topic-specific rule sets stored in the Device Registry. More generally, the predicate can be implemented by static rules, context-dependent thresholds, or dynamic domain models, because the admission logic only requires its Boolean outcome.

5.3. Integrity Material

For each device d, the secure publisher and the validation layer share the symmetric key $K_d$. Let $H(·)$ be a collision-resistant hash function. The payload digest is

$$p_i=H\left(\mathsf{can}\left(payloa{d}_i\right)\right).$$

(6)

The protected message body is

$$c_i^d=\mathsf{can}(d,topic,t{s}_i,se{q}_i,p_i).$$

(7)

The integrity tag is computed as

$${\tau }_i^d={\mathrm{HMAC}}_{K_d}\left(c_i^d\right).$$

(8)

The tag binds the payload digest to the device identity, topic, timestamp, and sequence number. Any unauthorized modification of the payload or of the authenticated metadata is detected either by the payload-digest comparison or by the HMAC verification.

5.4. Validation Predicates and Decision Rule

Let $t_v$ be the validation time at the Edge Security Gateway. Given a message $m_i^d$, the gateway evaluates the following mandatory predicates. In these predicates, $s_d\left(topic\right)$ denotes the stored sequence state before processing the current message.

$$\begin{array}{cc}\hfill C_1\left(m_i^d\right)& \equiv d\in \mathcal{D},\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill C_2\left(m_i^d\right)& \equiv topic\in {\mathcal{T}}_d,\hfill \end{array}$$

(10)

$$\begin{array}{cc}\hfill C_3\left(m_i^d\right)& \equiv \mathsf{PayloadValid}(d,topic,payloa{d}_i),\hfill \end{array}$$

(11)

$$\begin{array}{cc}\hfill C_4\left(m_i^d\right)& \equiv p_i=H\left(\mathsf{can}\left(payloa{d}_i\right)\right),\hfill \end{array}$$

(12)

$$\begin{array}{cc}\hfill C_5\left(m_i^d\right)& \equiv {\tau }_i^d={\mathrm{HMAC}}_{K_d}\left(c_i^d\right),\hfill \end{array}$$

(13)

$$\begin{array}{cc}\hfill C_6\left(m_i^d\right)& \equiv se{q}_i>s_d\left(topic\right),\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill C_7\left(m_i^d\right)& \equiv -{ϵ}_d\le t_v-t{s}_i\le {\Delta }_d^{max}.\hfill \end{array}$$

(15)

In order, these predicates check device registration, topic authorization, structural payload validity, payload-digest consistency, HMAC validity, sequence freshness, and timestamp freshness. The device-registration predicate is evaluated first, since the remaining predicates require the corresponding registry profile. If at least one mandatory predicate is false, the message is classified as Untrusted and cannot modify the active DT state or advance the validated sequence state.

Two warning predicates are evaluated only after all mandatory predicates succeed:

$$\begin{array}{cc}\hfill W_1\left(m_i^d\right)& \equiv t_v-t{s}_i>{\Delta }_d^{warn},\hfill \end{array}$$

(16)

$$\begin{array}{cc}\hfill W_2\left(m_i^d\right)& \equiv \neg \mathsf{PayloadPlausible}(d,topic,payloa{d}_i).\hfill \end{array}$$

(17)

Predicate $W_1$ identifies a message that is admissible but delayed beyond the expected threshold. Predicate $W_2$ identifies a structurally valid and authenticated payload that violates the topic-specific plausibility constraints. Both $C_7$ and $W_1$ compare the device-generated timestamp with the gateway validation time. They therefore rely on a bounded-skew assumption rather than on perfect clock synchronization: ${ϵ}_d$ tolerates limited future-dated timestamps, while ${\Delta }_d^{warn}$ and ${\Delta }_d^{max}$ define the warning and rejection thresholds for delayed messages. If a constrained device exhibits persistent clock drift beyond these configured bounds, valid measurements may be quarantined or rejected until the device is resynchronized or its registry profile is adjusted.

The validation decision is

$$\delta \left(m_i^d\right)=\left\{\begin{array}{cc}\text{Untrusted},\hfill & \mathrm{if}\exists j\in \{1,\dots ,7\}:\neg C_j\left(m_i^d\right),\hfill \\ \text{Suspicious},\hfill & \mathrm{if}{\displaystyle {\bigwedge }_{j=1}^7}{C}_j\left(m_i^d\right)\wedge \left(W_1\left(m_i^d\right)\vee W_2\left(m_i^d\right)\right),\hfill \\ \text{Verified},\hfill & \mathrm{if}{\displaystyle {\bigwedge }_{j=1}^7}{C}_j\left(m_i^d\right)\wedge \neg W_1\left(m_i^d\right)\wedge \neg W_2\left(m_i^d\right).\hfill \end{array}\right.$$

(18)

The corresponding action is

$$\alpha \left(m_i^d\right)=\left\{\begin{array}{cc}\text{Apply},\hfill & \mathrm{if}\delta \left(m_i^d\right)=\mathsf{Verified},\hfill \\ \text{Quarantine},\hfill & \mathrm{if}\delta \left(m_i^d\right)=\mathsf{Suspicious},\hfill \\ \text{Reject},\hfill & \mathrm{if}\delta \left(m_i^d\right)=\mathsf{Untrusted}.\hfill \end{array}\right.$$

(19)

We write ${\delta }_i$ and ${\alpha }_i$ for the decision and action returned for message $m_i^d$ when these values are stored in provenance records or passed to downstream components.

For a verified or suspicious message, the gateway advances the validated sequence state by setting

$$s_d\left(topic\right)\leftarrow se{q}_i.$$

(20)

A suspicious message advances the sequence state because it is authenticated, structurally valid, fresh, and newer than the previously processed message, even though its value is quarantined. Sequence gaps are permitted, which prevents permanent stream desynchronization when a message is lost. Messages with $se{q}_i\le s_d\left(topic\right)$ are treated as replayed or out-of-order updates.

Table 4. Decision semantics for DT updates.

Decision	Mandatory Predicates	Warning Predicates	Effect
Verified	All true	None true	Apply the payload to the active DT state, create provenance, and advance $s_d\left(topic\right)$.
Suspicious	All true	At least one true	Store the payload in quarantine, create provenance, keep the active DT value unchanged, and advance $s_d\left(topic\right)$.
Untrusted	At least one false	Not evaluated for state update	Reject the payload, create a rejection record, and keep $s_d\left(topic\right)$ unchanged.

summarizes the validation decisions, their corresponding actions, and their effects on the DT state.

6. Component Design

This section describes the behavior of each architectural component according to the formal model defined above.

6.1. Secure Publisher

The Secure Publisher is the origin of an authenticated device-topic stream. For every new measurement, it increments the local sequence number associated with the publication topic, obtains the generation timestamp, computes $p_i$, builds $c_i^d$, computes ${\tau }_i^d$, and publishes $m_i^d$. The per-topic sequence counters are stored persistently; resetting a counter requires explicit stream reconfiguration.

The publisher does not decide whether a value is operationally plausible. That decision is made by the validation layer using the topic-specific rules stored in the Device Registry. This separation keeps the source-side function limited to source authentication, payload integrity, and ordering evidence.

6.2. MQTT Broker

The broker provides topic-based message delivery. It may authenticate clients and protect transport sessions, but permission to change a DT field is evaluated by the Edge Security Gateway through topic authorization, payload validation, integrity verification, freshness validation, and sequence checking.

The topic is included in the protected body $c_i^d$. Therefore, moving a valid message to another topic causes the HMAC verification to fail or causes the topic-authorization predicate to fail.

6.3. Device Registry

The Device Registry defines the admissible behavior of each telemetry source. The profile $R\left(d\right)$ associates the device with its active validation key, allowed topics, topic-specific payload sets, timing parameters, last admitted sequence number for each authorized topic, and DT-field mapping. The registry is also the natural control point for device and key lifecycle management: a deployment can bind $K_d$ to a key identifier, key version, validity interval, and status value such as active, suspended, or revoked. Predicate $C_1$ is therefore interpreted over the set $\mathcal{D}$ of registered and active devices.

Table 5. Registry profile associated with a device.

Field	Notation	Purpose
Validation key	$K_d$	Verifies the HMAC tag generated by device d.
Key lifecycle metadata	–	Identifies the active key version, validity interval, and status of the device profile.
Allowed topics	${\mathcal{T}}_d$	Defines the topics on which d may publish.
Structural payload rules	${\mathcal{S}}_d\left(topic\right)$	Defines payloads with the expected fields, types, units, and structure.
Plausible payload rules	${\mathcal{P}}_d\left(topic\right)$	Defines structurally valid payloads that satisfy the semantic constraints.
Warning delay	${\Delta }_d^{warn}$	Threshold for classifying an admissible message as delayed.
Maximum delay	${\Delta }_d^{max}$	Upper bound for message freshness.
Future-timestamp tolerance	${ϵ}_d$	Maximum accepted timestamp offset in the future.
Last admitted sequence	$s_d\left(topic\right)$	Largest sequence number already admitted to the device-topic stream.
DT mapping	${\mu }_d\left(topic\right)$	Maps an authorized topic to a DT entity and field.

summarizes the information contained in each device registry profile.

Device onboarding creates a registry profile, provisions the initial validation key through a protected manufacturing, administrative, or enrollment channel, and activates the authorized topics. Key rotation installs a new key version at the Secure Publisher and updates the active registry entry, optionally allowing a short overlap window during migration. Revocation or offboarding changes the profile status or removes the device from $\mathcal{D}$, so subsequent messages fail the registration predicate before HMAC validation can authorize them. Plausibility rules can be derived from sensor specifications, physical constraints, commissioning data, calibration procedures, or operational policies, and then updated in the registry as deployment knowledge evolves. These lifecycle operations can be automated through an external key-management or configuration-management service, but their effect on the update-admission model is captured by the active registry profile used at validation time.

6.4. Edge Security Gateway

The Edge Security Gateway is the admission-control point for DT updates. It implements the decision rule of Section 5.4. Algorithm 1 describes the complete validation procedure.

Algorithm 1 Validation of an incoming telemetry message

Require: Message $m_i^d=\langle d,topic,t{s}_i,se{q}_i,payloa{d}_i,p_i,{\tau }_i^d\rangle$ and validation time $t_v$. Ensure: Decision ${\delta }_i$, action ${\alpha }_i$, and reason code ${\eta }_i$.   1: Retrieve $R\left(d\right)$ from the Device Registry.   2: if $R\left(d\right)$ does not exist then   3:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{UnknownDevice})$.   4: end if   5: if $topic\notin {\mathcal{T}}_d$ then   6:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{UnauthorizedTopic})$.   7: end if   8: if $\neg \mathsf{PayloadValid}(d,topic,payloa{d}_i)$ then   9:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{InvalidPayload})$. 10: end if 11: $p_i^{\prime }\leftarrow H\left(\mathsf{can}\left(payloa{d}_i\right)\right)$. 12: if $p_i^{\prime }\ne p_i$ then 13:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{InvalidDigest})$. 14: end if 15: $c_i^{d\prime }\leftarrow \mathsf{can}(d,topic,t{s}_i,se{q}_i,p_i)$. 16: if ${\tau }_i^d\ne {\mathrm{HMAC}}_{K_d}\left(c_i^{d\prime }\right)$ then 17:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{InvalidTag})$. 18: end if 19: if $se{q}_i\le s_d\left(topic\right)$ then 20:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{ReplayOrOutOfOrder})$. 21: end if 22: if $t_v-t{s}_i<-{ϵ}_d$ or $t_v-t{s}_i>{\Delta }_d^{max}$ then 23:       return $(\mathsf{Untrusted},\text{Reject},\mathsf{InvalidTimestamp})$. 24: end if 25: $delayed\leftarrow (t_v-t{s}_i>{\Delta }_d^{warn})$. 26: $implausible\leftarrow \neg \mathsf{PayloadPlausible}(d,topic,payloa{d}_i)$. 27: if $delayed$ and $implausible$ then 28:       Set $s_d\left(topic\right)\leftarrow se{q}_i$. 29:       return $(\mathsf{Suspicious},\text{Quarantine},\mathsf{DelayedAndImplausible})$. 30: else if  $delayed$ then 31:       Set $s_d\left(topic\right)\leftarrow se{q}_i$. 32:       return $(\mathsf{Suspicious},\text{Quarantine},\mathsf{Delayed})$. 33: else if $implausible$ then 34:       Set $s_d\left(topic\right)\leftarrow se{q}_i$. 35:       return $(\mathsf{Suspicious},\text{Quarantine},\mathsf{ImplausiblePayload})$. 36: else 37:       Set $s_d\left(topic\right)\leftarrow se{q}_i$. 38:       return $(\mathsf{Verified},\text{Apply},\mathsf{ValidUpdate})$. 39: end if

The gateway produces exactly one decision, one action, and one reason code for each processed message. The reason code allows the provenance layer to record why an update was accepted, quarantined, or rejected.

6.5. Provenance Manager

The Provenance Manager receives the message, validation time, gateway identifier, decision, action, and reason code produced by the Edge Security Gateway. Its purpose is to create one provenance record for every processed message.

If the Device Registry contains a mapping for the device and topic, the manager obtains

$$(e_i,f_i)={\mu }_d\left(topic\right).$$

(21)

If no mapping exists, as may occur for an unknown device or unauthorized topic, it assigns $e_i=\perp$ and $f_i=\perp$.

The provenance record is

$$r_i^d=\langle ei{d}_i,d,topic,e_i,f_i,t{s}_i,t_v,se{q}_i,p_i,{\delta }_i,{\alpha }_i,{\eta }_i,g\rangle ,$$

(22)

where $ei{d}_i$ is a unique event identifier and g identifies the validating gateway. The value d is the device identifier claimed by the message; it represents an authenticated source only when the integrity-tag verification succeeds.

The record is forwarded to the Audit Store. For actions Apply and Quarantine, the manager also forwards the original message, $e_i$, $f_i$, $ei{d}_i$, ${\alpha }_i$, and ${\eta }_i$ to the Digital Twin State Manager. Rejected messages are preserved only through their provenance records.

The Provenance Manager therefore creates the event identifier once, records the complete validation outcome, and supplies the information required by both the DT State Manager and the Audit Store.

6.6. Digital Twin State Manager

For each Digital Twin entity e, let ${\mathcal{F}}_e$ denote the set of fields represented by the twin. The Digital Twin State Manager maintains

$$DT\left(e\right)=\langle X_e,A_e,{\mathsf{\Gamma }}_e\rangle ,$$

(23)

where $X_e\left(f\right)$ is the current active value of field f, $A_e\left(f\right)$ is the event identifier that produced the current active value, and ${\mathsf{\Gamma }}_e$ is the set of quarantined updates associated with entity e.

Let $\mathcal{V}$ be the value domain and $\mathcal{EID}$ the set of event identifiers. The maps satisfy $X_e:{\mathcal{F}}_e\to \mathcal{V}\cup \{\perp \}$ and $A_e:{\mathcal{F}}_e\to \mathcal{EID}\cup \{\perp \}$, with $X_e\left(f\right)=\perp$ if and only if $A_e\left(f\right)=\perp$.

If no verified value is available for field f, then

$$X_e\left(f\right)=\perp ,A_e\left(f\right)=\perp .$$

(24)

If ${\alpha }_i=\text{Apply}$, the state manager performs

$$X_{e_i}\left(f_i\right)\leftarrow payloa{d}_i,$$

(25)

and

$$A_{e_i}\left(f_i\right)\leftarrow ei{d}_i.$$

(26)

Multiple authorized device-topic streams may map to the same DT field. In this case, the latest verified update processed by the Digital Twin State Manager replaces the active value, while the Audit Store preserves the events generated by all authorized sources.

If ${\alpha }_i=\text{Quarantine}$, the active value and its provenance reference remain unchanged. The state manager creates

$$q_i=\langle f_i,payloa{d}_i,t{s}_i,ei{d}_i,{\eta }_i\rangle$$

(27)

and adds it to the quarantine set:

$${\mathsf{\Gamma }}_{e_i}\leftarrow {\mathsf{\Gamma }}_{e_i}\cup \left\{q_i\right\}.$$

(28)

Figure 3 summarizes how the validation actions affect the active DT state, the quarantine area, and the audit history. A rejected message does not modify $X_e$, $A_e$, or ${\mathsf{\Gamma }}_e$. A quarantined update never modifies the active state; any later approval must be represented as a new update and a new provenance event. Conversely, discard, retention, or removal of quarantined records is handled as an administrative follow-up action and is recorded through the audit layer rather than by rewriting the original validation decision.

6.7. Policy-Based View Generator

The Policy-Based View Generator derives consumer-specific representations from the internal DT state. Let u be a consumer, $role\left(u\right)$ its authorized role, and $purpose\left(u\right)$ the declared purpose of the request.

For DT entity e, the policy returns two field sets:

$$\left({\mathcal{O}}_u^X\left(e\right),{\mathcal{O}}_u^A\left(e\right)\right)=\mathsf{Policy}\left(role\left(u\right),purpose\left(u\right),e\right),$$

(29)

where ${\mathcal{O}}_u^X\left(e\right)\subseteq {\mathcal{F}}_e$ identifies the active values visible to u, and ${\mathcal{O}}_u^A\left(e\right)\subseteq {\mathcal{O}}_u^X\left(e\right)$ identifies the corresponding provenance references visible to u.

The function $\mathsf{Policy}$ is an abstraction of the authorization decision rather than a new policy language. It can be implemented by a rule-based policy store or by an XACML-compatible pattern in which a Policy Enforcement Point submits the consumer identity, role, purpose, requested entity, requested field, provenance flag, and quarantine-access flag to a Policy Decision Point [32]. Policy rules are versioned and updated through a separate administration function. The generated view can therefore be associated with a policy identifier and policy version in the audit history, while policy updates affect future view-generation decisions without modifying past provenance records.

The resulting view is

$$Vie{w}_u\left(DT\left(e\right)\right)=〈X_e{|}_{{\mathcal{O}}_u^X\left(e\right)},A_e{|}_{{\mathcal{O}}_u^A\left(e\right)}〉,$$

(30)

where the restriction operator selects only the authorized fields, as illustrated by the examples of consumer-specific DT views in

Table 6. Example DT views for a smart-building scenario.

View	Consumer	Exposed Data
Administrative view	Building administrator	All authorized active values and their provenance references; quarantine access is handled separately.
Operational view	Building automation service	Only the active values required for building-control operations.
Energy view	Energy optimization service	Selected environmental and energy-consumption fields, without occupancy or device-level provenance.
Analytics view	External analytics service	A limited subset of non-sensitive active fields, without provenance references or quarantined updates.

. The quarantine set ${\mathsf{\Gamma }}_e$ is excluded from ordinary operational views and is available only through a separate security-analysis authorization.

6.8. Audit Store

The Audit Store is a trusted repository that preserves the provenance records generated by the Provenance Manager. It supports reconstruction of the validation and processing history of DT updates.

For each event identifier, the Audit Store provides

$$\mathsf{GetRecord}\left(ei{d}_i\right)=r_i^d.$$

(31)

For each DT field f of entity e, the Audit Store maintains the ordered sequence

$$\mathsf{History}(e,f)=\langle ei{d}_1,ei{d}_2,\dots ,ei{d}_n\rangle ,$$

(32)

containing the events whose provenance records include $e_i=e$ and $f_i=f$. The sequence is ordered by validation time and event identifier. It may include applied, quarantined, and rejected updates for which a valid DT mapping was available. Events produced by unknown devices or unauthorized topics have $e_i=f_i=\perp$ and remain available only in the global audit history.

The value $A_e\left(f\right)$ identifies only the event that produced the current active value. By contrast, $\mathsf{History}(e,f)$ preserves the complete validation history associated with the field. Since the provenance record stores the payload digest rather than the historical payload value, the Audit Store reconstructs the origin, validation result, and action of each event, but not the previous physical values after they have been overwritten in the active DT state.

7. Experimental Evaluation

This section evaluates the practical cost of the application-layer mechanisms introduced by TDT-Pipe before a telemetry message is admitted into the active Digital Twin (DT) state. The evaluation focuses on five aspects: integrity-protection operations, per-message processing latency, update throughput, memory footprint, and audit persistence. The goal is to isolate the cost of the proposed update-admission logic, rather than to benchmark a complete MQTT deployment. The measured path therefore includes payload canonicalization, digest computation, message authentication, registry-based validation, provenance record creation, audit insertion, and controlled state update.

The workload is synthetic but structured according to the smart-building scenario used throughout the paper. It contains 20 rooms, each exposing five telemetry streams: temperature, humidity, CO₂, occupancy, and energy. This configuration produces 100 registered device-topic streams. For each device, the Device Registry stores the validation key and the authorized topics. For each device-topic stream, it stores the payload rules, sequence state, freshness parameters, plausibility rules, and mapping to the corresponding DT field.

The same Python prototype was executed on two platforms. The first platform is a commodity laptop equipped with an Intel Core i7-7500U CPU at 2.70 GHz, 2 physical cores and 4 logical CPUs, 7.6 GiB of RAM, Ubuntu 20.04 with Linux kernel 5.15, and Python 3.8.10. The second platform is a Raspberry Pi 4 Model B equipped with a Broadcom BCM2711 quad-core ARM Cortex-A72 processor, 8 GB of RAM, and SD-card storage. Cryptographic operations are implemented with the standard Python hashlib and hmac libraries. The laptop provides a commodity reference host, while the Raspberry Pi 4 represents a low-cost edge-gateway platform. The measurements should therefore be read as prototype-level results for a single-process Python implementation, not as an optimized native implementation; nevertheless, running the same code on the Raspberry Pi 4 provides a direct indication of the overhead on constrained edge hardware.

The benchmark generates device identifiers, topic names, timestamps, sequence numbers, registry entries, provenance records, and DT state updates. Unless otherwise stated, registry lookup, validation state, provenance records, and DT state updates are maintained in memory. This choice makes the first four experiments focus on application-layer computation. Audit persistence is evaluated separately using SQLite, so that the cost of non-volatile audit storage can be observed explicitly. Consequently, the latency and throughput measurements do not include MQTT broker delay, network transmission, TLS session handling, physical sensor acquisition, or database-backed DT state management.

All performance experiments use warm-up executions and repeated measurements. Timing results are reported in microseconds (µs) for per-operation and per-message latency, while throughput is reported in processed messages per second. In the integrity-protection microbenchmark, each operation is measured over 9 repetitions, with 5000 iterations per repetition and 1000 warm-up iterations. The per-operation time is obtained by dividing the elapsed time of each repetition by the number of iterations. In the latency experiment, each repetition processes 10,000 messages after a warm-up of 1000 messages, and 5 repetitions are used. In the throughput experiment, each configuration processes 10,000 messages per repetition, with 5 repetitions and a warm-up of 1000 messages for each evaluated mode. Resource usage is measured over 30,000-message workloads. Audit persistence is measured over 3 repetitions of 100 messages for each persistence mode, because the per-message commit configuration is intentionally conservative and much slower than the other configurations. The plots report median values across repetitions. When p95 latency is reported, it is computed inside each repetition from the per-message timings; the value reported in the plot is the median of those p95 values across repetitions.

7.1. Integrity-Protection Operation Cost

The first experiment measures the cost of the integrity-protection operations used by TDT-Pipe. It evaluates three operations: deterministic JSON canonicalization followed by SHA-256 digest computation over the payload, HMAC-SHA256 generation over the protected message body, and HMAC-SHA256 verification. Payload sizes range from 128 B to 32 KB and denote the target size of the synthetic telemetry payload.

Figure 4 shows the same qualitative behavior on both platforms. Payload canonicalization and digest computation increase with payload size because the full payload representation must be serialized and processed by SHA-256. On the laptop, the median digest cost grows from approximately 5.7 µs for 128 B payloads to approximately 181.5 µs for 32 KB payloads. On the Raspberry Pi 4, the same operation grows from approximately 26.3 µs to approximately 422.1 µs. The Raspberry Pi 4 is slower in absolute terms, as expected for an edge-class device, but the scaling behavior is consistent with the laptop measurements.

By contrast, HMAC-SHA256 generation and verification remain almost constant across payload sizes. On the laptop, both operations remain around 11–12 µs. On the Raspberry Pi 4, they remain around 44–45 µs. This is a consequence of the protected message format: the HMAC is computed over a compact body containing the device identifier, topic, timestamp, sequence number, and payload digest, rather than over the complete payload. Payload size therefore has little effect on authentication-tag generation and verification, while canonicalization and digest computation dominate the integrity-processing cost for larger payloads.

7.2. Per-Message Processing Latency

The second experiment measures per-message latency along the main stages of the TDT-Pipe update path. The workload contains valid telemetry messages with 512 B payloads and 100 registered device-topic streams. The measured path is divided into secure publication, gateway validation, provenance record creation, and DT state action.

Figure 5 shows that most of the latency is concentrated in secure publication and gateway validation. On the laptop, these stages require approximately 27.8 µs and 28.7 µs, respectively. On the Raspberry Pi 4, they require approximately 93.6 µs and 97.6 µs. Secure publication includes payload canonicalization, SHA-256 digest computation, protected-body construction, HMAC-SHA256 generation, and message creation. Gateway validation includes the in-memory registry lookup, topic authorization check, structural payload validation, digest recomputation, digest comparison, HMAC recomputation and verification, sequence-number validation, timestamp freshness validation, semantic plausibility checking, and sequence-state update.

The remaining stages are lighter. Provenance record creation requires approximately 5.4 µs on the laptop and 17.6 µs on the Raspberry Pi 4. The DT state action requires approximately 1.2 µs on the laptop and 4.5 µs on the Raspberry Pi 4 for valid updates. The complete measured path has a median latency of approximately 64.3 µs on the laptop and 218.6 µs on the Raspberry Pi 4. The corresponding median p95 values are approximately 80.4 µs and 241.2 µs. The stage distribution is therefore preserved across platforms: secure publication and gateway validation dominate the cost, while provenance creation and active-state update add a smaller overhead.

7.3. Pipeline Throughput

The third experiment evaluates the throughput of the in-memory update path. Throughput is computed as the number of processed messages divided by the elapsed processing time. Two configurations are compared. The first is a direct-update baseline, where a received payload is mapped to the corresponding DT field and applied directly. The second is the full TDT-Pipe pipeline, which includes secure publication, validation, provenance record creation, audit insertion, and controlled state update.

Figure 6 shows that the direct-update baseline remains approximately constant as payload size increases. On the laptop, the baseline ranges from approximately $3.8\times {10}^5$ to $4.1\times {10}^5$ messages/s. On the Raspberry Pi 4, it remains close to $1.0\times {10}^5$ messages/s. This behavior is expected because the baseline does not inspect, canonicalize, hash, or authenticate the payload content; it mainly performs in-memory mapping and assignment operations.

The full TDT-Pipe pipeline exhibits the expected decreasing trend as payload size increases. On the laptop, the median throughput decreases from approximately 16.6k messages/s for 128 B payloads to approximately 6.4k messages/s for 8 KB payloads. On the Raspberry Pi 4, it decreases from approximately 5.0k messages/s to approximately 2.5k messages/s over the same payload-size range. The decrease is mainly caused by the increasing cost of canonicalizing and hashing larger payloads, as observed in Figure 4. The HMAC cost remains comparatively stable, while the payload digest cost grows with the amount of data to be processed.

The gap between the baseline and TDT-Pipe quantifies the cost of enforcing application-layer integrity, freshness validation, anti-replay protection, topic authorization, semantic admission control, provenance creation, audit insertion, and controlled DT state management. Although this overhead is substantial relative to a minimal in-memory assignment, the protected pipeline still processes thousands of messages per second on both platforms. The result supports the feasibility of the approach for moderate-rate edge telemetry workloads, while also showing the expected capacity reduction on constrained hardware.

7.4. Memory Footprint

The fourth experiment evaluates the memory footprint of the benchmarked process. The workload processes 30,000 messages for 512 B and 8 KB payloads under both the direct-update baseline and the full TDT-Pipe pipeline. During the processing loops, single-process CPU utilization remains close to one fully used core on both platforms. Since this value is nearly constant and does not distinguish the configurations, the resource comparison focuses on peak resident set size (RSS), which captures the memory footprint of the Python process during the workload.

Figure 7 shows consistent memory usage across the two platforms. For 512 B payloads, the direct-update baseline uses approximately 81 MB of peak RSS, while the full TDT-Pipe pipeline uses approximately 97 MB. For 8 KB payloads, peak RSS increases to approximately 299–301 MB for the baseline and 315–317 MB for the full pipeline. The additional memory associated with TDT-Pipe is therefore approximately 16 MB in the evaluated workloads. This increase is mainly due to the message metadata, provenance records, validation results, and audit entries maintained by the protected path.

7.5. Audit Persistence Cost

The fifth experiment evaluates the cost of persisting audit records. This experiment complements the in-memory measurements above, because practical non-repudiation and accountability requirements normally require audit and provenance records to be stored on non-volatile media. The in-memory configuration therefore represents a volatile reference case, while the SQLite configurations represent database-backed audit insertion. Three configurations are compared: in-memory audit append, SQLite insertion with a batch commit every 100 records, and SQLite insertion with one commit per processed message. The last configuration is intentionally conservative and represents a worst-case synchronization policy.

Figure 8 shows that audit persistence can dominate the end-to-end cost when records are forced to durable storage. On the laptop, in-memory audit append reaches approximately 9.8k messages/s, SQLite with batch commits reaches approximately 235 messages/s, and SQLite with per-message commits reaches approximately 3 messages/s. On the Raspberry Pi 4, in-memory audit append reaches approximately 4.6k messages/s, SQLite with batch commits reaches approximately 2.0k messages/s, and SQLite with per-message commits reaches approximately 70 messages/s.

These values should be interpreted as storage-dependent measurements rather than as a general indication that one platform is faster than the other. The laptop used in the experiment is equipped with a conventional hard disk, whereas the Raspberry Pi 4 uses SD-card storage. SQLite performance is strongly affected by the storage medium, filesystem, cache behavior, journaling configuration, and commit policy. The important observation is therefore not that one platform is universally faster for persistence, but that durable audit storage introduces a deployment-dependent bottleneck. Batching audit commits substantially improves throughput compared with forcing a synchronization for every message, and should be preferred when the application can tolerate bounded buffering of audit records.

7.6. Discussion

The experimental results lead to four main observations. First, HMAC-SHA256 generation and verification remain stable across payload sizes because they process the compact protected body rather than the complete payload. Payload canonicalization and digest computation scale with payload size and become the dominant integrity-processing cost for larger telemetry messages.

Second, secure publication and gateway validation are the principal contributors to per-message latency. For 512 B payloads, the complete measured path requires approximately 64.3 µs on the laptop and 218.6 µs on the Raspberry Pi 4. The Raspberry Pi 4 is slower in absolute terms, but the stage-level distribution remains similar. This indicates that the proposed processing model scales predictably from a commodity host to a constrained edge platform.

Third, the protected pipeline maintains throughput in the thousands of messages per second on both platforms. The laptop processes approximately 6.4k–16.6k protected updates/s across the evaluated payload sizes, while the Raspberry Pi 4 processes approximately 2.5k–5.0k protected updates/s. These values are lower than the direct-update baseline, as expected, but they quantify the cost of the additional security, provenance, freshness, anti-replay, authorization, and controlled-admission mechanisms.

Fourth, persistent audit storage is the most deployment-sensitive component. In-memory evaluation is useful for isolating application-layer computation, but durable audit insertion depends strongly on the storage backend and synchronization policy. The SQLite results show that per-message durable commits can severely reduce throughput, whereas batched commits provide a more practical trade-off between persistence cost and audit durability. For deployments with stricter non-repudiation requirements, the storage backend and commit policy should therefore be selected as part of the system design rather than treated as an implementation detail.

Finally, the evaluation should be interpreted as a prototype-level assessment of the update-admission path. Broker scheduling, network delay, TLS session management, and physical sensor acquisition are outside the measured path and remain part of future deployment-level validation.

8. Security Analysis

This section analyzes the security guarantees provided by TDT-Pipe. The analysis first specifies the assumptions under which the guarantees hold and the symbolic verification model used to support the main correspondence claims. It then describes the effects of the three possible validation actions and proves the main properties concerning active-state safety, authentication, integrity, freshness, controlled state modification, audit traceability, and view confinement.

8.1. Security Assumptions

The adversary may observe, inject, modify, delay, replay, reorder, or remove telemetry messages transmitted between a Secure Publisher and the Edge Security Gateway. The communication path and the MQTT broker may therefore deliver arbitrary messages to the gateway.

For each non-compromised device d, the adversary is assumed not to know the validation key $K_d$. HMAC is assumed to be unforgeable without knowledge of the key. The hash function $H(·)$ is assumed to provide collision and second-preimage resistance, and the canonical representation $\mathsf{can}(·)$ is assumed to be deterministic.

The Device Registry, Edge Security Gateway, Provenance Manager, Digital Twin State Manager, Policy-Based View Generator, and Audit Store are assumed to be trusted and to execute the operations defined by the model correctly. The stored sequence state $s_d\left(topic\right)$ is assumed not to be rolled back.

Under these assumptions, a valid HMAC shows that a message was generated by an entity holding the key associated with the claimed device identifier. It does not guarantee that the corresponding physical sensor is uncompromised or that the reported measurement is physically correct.

8.2. Effects of Message Processing

A primed symbol denotes the value of a state component after processing message $m_i^d$. Every processed message produces one provenance record $r_i^d$, which is appended to the audit history $\mathcal{H}$:

$${\mathcal{H}}^{\prime }=\mathcal{H}|\langle r_i^d\rangle ,$$

(33)

where | denotes sequence concatenation.

The remaining changes depend on the action selected by the Edge Security Gateway.

• Apply.

The action is Apply only when all mandatory predicates are true and both warning predicates are false. Let

$${\mu }_d\left(topic\right)=(e_i,f_i).$$

(34)

The sequence state of the corresponding device-topic stream is updated as

$$s_d^{\prime }\left(topic\right)=se{q}_i$$

(35)

The active value and its provenance reference are updated as

$$X_{e_i}^{\prime }\left(f_i\right)=payloa{d}_i$$

(36)

and

$$A_{e_i}^{\prime }\left(f_i\right)=ei{d}_i.$$

(37)

All other sequence-state entries, active values, and provenance references remain unchanged. The quarantine sets are also unchanged.

• Quarantine.

The action is Quarantine when all mandatory predicates are true but at least one warning predicate is true. The sequence state is updated as

$$s_d^{\prime }\left(topic\right)=se{q}_i.$$

(38)

The active values and their provenance references remain unchanged:

$$X^{\prime }=X\mathrm{and}{A}^{\prime }=A.$$

(39)

The quarantine record is added to the quarantine set associated with the mapped entity:

$${\mathsf{\Gamma }}_{e_i}^{\prime }={\mathsf{\Gamma }}_{e_i}\cup \left\{q_i\right\}.$$

(40)

All other quarantine sets remain unchanged.

• Reject.

The action is Reject when at least one mandatory predicate is false. No operational state is modified:

$$s_d^{\prime }\left(topic\right)=s_d\left(topic\right),X^{\prime }=X,A^{\prime }=A,{\mathsf{\Gamma }}^{\prime }=\mathsf{\Gamma }.$$

(41)

The only effect of the rejected message is the insertion of its provenance record into the Audit Store.

8.3. Security Properties

Property 1

(Active-state safety). For every entity e and field f, if an active value exists, then its provenance reference identifies a verified update whose action was Apply and whose digest matches the active value.

More precisely, if

$$X_e\left(f\right)\ne \perp ,$$

(42)

then there exists an event identifier $ei{d}_i$ such that

$$A_e\left(f\right)=ei{d}_i,$$

(43)

and the record

$$r_i^d=\mathsf{GetRecord}\left(ei{d}_i\right)$$

(44)

satisfies

$$e_i=e,f_i=f,{\delta }_i=\mathsf{Verified},{\alpha }_i=\text{Apply},$$

(45)

and

$$p_i=H\left(\mathsf{can}\left(X_e\left(f\right)\right)\right).$$

(46)

Proof. 

The proof proceeds by induction on the number of processed messages.

Before the first message is processed, each active field is either empty or has been initialized with a value already satisfying the property. Therefore, the property holds initially.

Assume that the property holds after processing a finite number of messages. Consider the next message.

If its action is Apply, the Provenance Manager creates record $r_i^d$ with decision Verified, action Apply, event identifier $ei{d}_i$, and mapping $(e_i,f_i)$. Predicate $C_4$ guarantees that

$$p_i=H\left(\mathsf{can}\left(payloa{d}_i\right)\right).$$

(47)

The Digital Twin State Manager then assigns

$$X_{e_i}^{\prime }\left(f_i\right)=payloa{d}_i$$

(48)

and

$$A_{e_i}^{\prime }\left(f_i\right)=ei{d}_i.$$

(49)

The newly active value is therefore linked to the record of the same verified and applied update. Its digest also satisfies

$$p_i=H\left(\mathsf{can}\left(X_{e_i}^{\prime }\left(f_i\right)\right)\right).$$

(50)

All other active fields remain unchanged and continue to satisfy the induction hypothesis.

If the action is Quarantine, neither X nor A is modified. Therefore, all active values and their provenance references remain unchanged and continue to satisfy the property.

If the action is Reject, neither X nor A is modified. A rejected message cannot introduce a new active value or replace an existing one.

Since the property is preserved in all three cases, it holds after any finite sequence of processed messages.    □

Property 2

(Authentication and topic authorization). Every message assigned either Apply or Quarantine is associated with a registered device, uses an authorized topic, and has a valid device-specific HMAC.

Formally,

$${\alpha }_i\in \{\text{Apply},\text{Quarantine}\}$$

(51)

implies

$$d\in \mathcal{D},topic\in {\mathcal{T}}_d,{\tau }_i^d={\mathrm{HMAC}}_{K_d}\left(c_i^d\right).$$

(52)

Proof. 

An Apply or Quarantine action is produced only after all mandatory predicates succeed. Predicates $C_1$, $C_2$, and $C_5$ respectively verify device registration, topic authorization, and the HMAC. Therefore, all three stated conditions hold.

Because the topic is included in the protected body $c_i^d$, moving a valid message to another topic changes the authenticated content. The original HMAC is then invalid. Moreover, the Device Registry uses the mapping ${\mu }_d\left(topic\right)=(e,f)$ to identify the specific Digital Twin entity and field associated with the authorized device-topic stream. Therefore, an applied message can modify only that mapped field.    □

Property 3

(Payload and metadata integrity). Every message assigned either Apply or Quarantine has a payload matching its transmitted digest and a valid HMAC protecting the digest and the security-relevant metadata.

Formally,

$$p_i=H\left(\mathsf{can}\left(payloa{d}_i\right)\right)$$

(53)

and

$${\tau }_i^d={\mathrm{HMAC}}_{K_d}\left(\mathsf{can}(d,topic,t{s}_i,se{q}_i,p_i)\right).$$

(54)

Proof. 

An Apply or Quarantine action requires both $C_4$ and $C_5$ to be true. Predicate $C_4$ establishes that the received payload produces the received digest. Predicate $C_5$ establishes that the device identifier, topic, timestamp, sequence number, and payload digest match the protected body used to generate the HMAC.

Changing the payload without changing $p_i$ causes $C_4$ to fail. Changing the payload together with $p_i$, or changing any protected metadata, requires a new valid HMAC. Under the assumed unforgeability of HMAC, an adversary that does not know $K_d$ cannot produce that tag except with negligible probability.    □

Property 4

(Replay and freshness safety). A message can be applied or quarantined only if it is newer than the greatest previously admitted message of the same device-topic stream and its timestamp falls within the accepted interval.

Therefore,

$${\alpha }_i\in \{\text{Apply},\text{Quarantine}\}$$

(55)

implies

$$se{q}_i>s_d\left(topic\right)$$

(56)

and

$$-{ϵ}_d\le t_v-t{s}_i\le {\Delta }_d^{max}.$$

(57)

Proof. 

An Apply or Quarantine action requires predicates $C_6$ and $C_7$ to be true. Predicate $C_6$ requires the received sequence number to be greater than the stored sequence state. Predicate $C_7$ requires the timestamp to fall within the configured interval.

After an applied or quarantined message, the gateway sets

$$s_d\left(topic\right)\leftarrow se{q}_i.$$

(58)

The stored sequence state therefore never decreases. A later message carrying the same or a smaller sequence number fails $C_6$ and is rejected. Similarly, a message that is expired or excessively future-dated fails $C_7$ and is rejected without modifying the sequence state or the active DT state.    □

Property 5

(Controlled state modification). Only an Apply action can modify the active value map X or the provenance-reference map A.

A Quarantine action satisfies

$$X^{\prime }=X\mathrm{and}{A}^{\prime }=A,$$

(59)

while a Reject action satisfies

$$s_d^{\prime }\left(topic\right)=s_d\left(topic\right),X^{\prime }=X,A^{\prime }=A,{\mathsf{\Gamma }}^{\prime }=\mathsf{\Gamma }.$$

(60)

Proof. 

The result follows directly from the three message-processing rules. The Apply rule assigns a new payload and event identifier to $X_{e_i}\left(f_i\right)$ and $A_{e_i}\left(f_i\right)$. The Quarantine rule changes only the sequence state, the corresponding quarantine set, and the audit history. The Reject rule changes only the audit history.

Consequently, a suspicious value cannot overwrite an active value, and a rejected value cannot affect any operational state. A quarantined value can become active only through a later message that is processed as a new Apply event.    □

Property 6

(Audit traceability). Every processed message produces one provenance record. Every active value is linked to the event that produced it, and every quarantined value is linked to its quarantine event.

Proof. 

By construction, the Edge Security Gateway produces exactly one decision, one action, and one reason code for each processed message. The Provenance Manager uses this information to create one record $r_i^d$ with a unique identifier $ei{d}_i$ and appends it to the Audit Store.

For an applied message, the DT State Manager sets

$$A_{e_i}\left(f_i\right)=ei{d}_i.$$

(61)

The active value is therefore linked to the record that produced it. For a quarantined message, the event identifier is stored in

$$q_i=\langle f_i,payloa{d}_i,t{s}_i,ei{d}_i,{\eta }_i\rangle .$$

(62)

Rejected messages are not associated with an active or quarantined value, but their records remain available in the global audit history. Hence, the validation decision and its effect can be reconstructed for every processed message.    □

Property 7

(View confinement). A consumer can receive only the active fields and provenance references selected by the applicable policy.

The released view is

$$Vie{w}_u\left(DT\left(e\right)\right)=〈X_e{|}_{{\mathcal{O}}_u^X\left(e\right)},A_e{|}_{{\mathcal{O}}_u^A\left(e\right)}〉.$$

(63)

Moreover,

$${\mathcal{O}}_u^A\left(e\right)\subseteq {\mathcal{O}}_u^X\left(e\right).$$

(64)

Proof. 

The restriction operator removes every entry whose field is not contained in the selected field set. Therefore, $X_e{|}_{{\mathcal{O}}_u^X\left(e\right)}$ contains no active value outside ${\mathcal{O}}_u^X\left(e\right)$, and $A_e{|}_{{\mathcal{O}}_u^A\left(e\right)}$ contains no provenance reference outside ${\mathcal{O}}_u^A\left(e\right)$.

Since ${\mathcal{O}}_u^A\left(e\right)\subseteq {\mathcal{O}}_u^X\left(e\right)$, a provenance reference cannot be exposed when the corresponding active field is not visible. The quarantine set ${\mathsf{\Gamma }}_e$ is not included in the ordinary view. The property holds provided that the policy is correctly configured and the Policy-Based View Generator remains trusted.    □

8.4. Symbolic Verification with ProVerif

To complement the manual security arguments, we modeled the security-critical part of TDT-Pipe in ProVerif. ProVerif is a symbolic verifier for cryptographic protocols in the applied pi calculus and is commonly used to analyze secrecy and correspondence properties under a Dolev–Yao adversary [33]. Similar modeling practice has been used for large-scale protocol analyses such as TLS 1.3, which separate claims across symbolic, computational, and implementation-oriented artifacts and make clear which guarantees are supported by each abstraction [34]. The complete ProVerif files and execution scripts are available in a public GitHub repository: https://github.com/vincenzodeangelisrc/TDT-Pipe (accessed on 20 August 2026).

The ProVerif analysis abstracts the cryptographic operations symbolically. The payload digest, the protected canonical body, and the HMAC are represented as constructors over bitstrings. The protected_body constructor assumes an unambiguous and consistently implemented canonical encoding; the correctness of the concrete serialization and canonicalization procedure is outside the symbolic model. The MQTT path is modeled as public and controlled by the attacker; hence, the adversary can observe, inject, modify, drop, reorder, and replay messages. The device validation keys for non-compromised devices are private names. The Sensor-to-Secure-Publisher channels are private, which captures the explicit assumption that the local sensor-to-publisher link is trusted. The Device Registry is represented by two registered device-topic streams, each associated with its own validation key and authorized topic. This finite registry is a representative instance of the general rule defined in Section 5.2: the gateway first enforces the registered device-topic association and then verifies payload-digest consistency and the HMAC over the protected body.

The ProVerif validation uses three complementary models, each with a distinct purpose.

• The main pipeline model represents the complete symbolic actor chain: Sensor, Secure Publisher, untrusted MQTT broker/channel, Edge Security Gateway, Provenance Manager, and DT State Manager. It includes two registered streams, one unauthorized topic, per-stream symbolic locks around the sequence-state check-and-insert operation, and private channels from the gateway to the downstream managers.
• A bounded atomic-replay model isolates the sequence-state behavior for two gateway inputs. It represents the already accepted device-topic-sequence triple explicitly for the second input and checks whether an exact reuse of that triple can produce a second gateway acceptance under a sequential gateway abstraction. The same model also checks that exact replay inputs can reach the rejection branch and that a distinct second valid update can still be accepted.
• A bounded honest-execution model is used only as a reachability sanity check. It verifies that both registered streams can reach gateway_accept. This model is not used as an adversarial security proof. It provides an independent sanity check that the device-specific validation conditions are satisfiable and that the corresponding direct honest flows can reach gateway_accept. Because it is a simplified model, it does not establish reachability in the replicated main pipeline model.

The main pipeline model verifies the following symbolic properties. First, the private validation keys of the two non-compromised devices remain secret. Second, gateway acceptance implies a prior secure publication of the same device, topic, payload, sequence value, and timestamp. ProVerif proves this authentication correspondence in the non-injective form, meaning that accepted messages originate from matching secure publications, without claiming global injective authentication for the replicated gateway process. Third, a message on the modeled unauthorized topic cannot be accepted. Fourth, under the private Sensor-to-Secure-Publisher assumption, every accepted payload is linked to a corresponding sensor-measurement event. Fifth, provenance and DT-state processing events can only originate from gateway-validated telemetry. This last property is expressed from the downstream managers back to the gateway validation event, so it is a safety property: it states that downstream processing is not triggered by unvalidated data. It does not claim eventual durable storage or eventual DT-state application for every accepted message.

The reachability sanity model gives the expected ProVerif result not event(...) is false for both registered device-topic streams. In other words, the negation of gateway acceptance is false in the bounded honest execution, so both modeled honest flows are reachable. These checks are reported separately from the adversarial properties because reachability is not itself a security guarantee.

Replay protection requires a more careful interpretation. In the formal update model, replay resistance is enforced by the monotonic sequence predicate and by updating the stored sequence state only after successful validation. In the ProVerif pipeline model, this behavior is represented symbolically by a seen table and by per-stream locks that make the check-and-insert operation atomic for each device-topic stream. Because global injective correspondence over a replicated gateway and mutable sequence state is stronger than what the main symbolic abstraction is intended to establish, replay is checked in a separate focused model.

The bounded atomic-replay model checks the following representative property: after one valid update has been accepted, an exact reuse of the same device-topic-sequence triple cannot produce a second acceptance in the modeled two-input sequential execution. ProVerif proves this safety property through the negated gateway_second_accept event query in which the current second input is constrained to reuse the stored device, topic, and sequence values. The repeated variables in the query encode equality between the current and stored stream identifiers. The model also includes reachability checks to avoid a vacuous interpretation of this result. ProVerif finds traces reaching replay_rejected for both registered streams, which shows that exact replays are represented and are routed to the rejection branch. It also finds a trace reaching gateway_second_accept for a distinct valid second update, showing that the model does not reject every second input indiscriminately. Together, these results show that, in the bounded two-input sequential abstraction, an exact replay can reach the replay-filtering branch but cannot produce a second acceptance, whereas a distinct valid update can still be accepted.

9. Discussion and Limitations

TDT-Pipe focuses on the update-admission boundary between delivered telemetry and active Digital Twin state modification. Several deployment mechanisms are therefore complementary to the model rather than embedded directly in it. First, the paper assumes that device validation keys are provisioned before telemetry validation and remain secret for non-compromised devices. In a practical deployment, key provisioning, protected storage, rotation, revocation, and device onboarding/offboarding are lifecycle operations of the Device Registry, possibly integrated with an external key-management service, PKI-assisted enrollment, secure elements, TPM/TEE support, or manufacturing-time provisioning. These operations do not change the validation predicates themselves, but they determine which device profiles, topics, and key versions are active at a given time. For deployments with hundreds or thousands of devices, this lifecycle automation is necessary for scalability; the present model specifies how the active registry state is enforced at update admission, but it does not prescribe a complete enterprise key-management protocol.

The monotonic sequence mechanism has a similarly explicit scope. It assumes that each Secure Publisher maintains a persistent per-topic counter and that the gateway maintains persistent per-stream sequence state. Lost messages do not permanently desynchronize the stream, because sequence gaps are accepted as long as the next received value is greater than the stored value. Exceptional cases such as device reboot with counter loss, counter exhaustion, or long offline periods require an explicit recovery action rather than silent acceptance of lower sequence numbers. A deployment can handle these cases by using non-volatile counters, large sequence spaces, stream epochs or key versions, administrative resynchronization, or device re-enrollment through the Device Registry. Such recovery actions update the active registry state and should be recorded in the audit trail.

A stronger limitation arises when a device key is extracted. Since the proposed telemetry format uses symmetric message authentication, possession of the validation key is equivalent to possession of the corresponding device’s authentication capability. An adversary holding that key can generate cryptographically valid messages for the device identity. The gateway can still enforce topic authorization, payload-structure checks, timestamp and sequence validation, semantic plausibility rules, quarantine, and audit traceability, but it cannot cryptographically distinguish the legitimate Secure Publisher from an attacker holding the same key. Mitigations include secure elements, protected key storage, trusted execution environments, remote attestation, rapid key revocation, and anomaly-detection or operator-review workflows for suspicious authenticated streams. The Edge Security Gateway and Device Registry are also part of the trusted computing base because they store validation material, authorization profiles, and sequence state. Their protection is therefore an important deployment concern: a compromise of these components may affect the validation of several device streams and should trigger containment and recovery procedures. Practical hardening measures include hardware-backed key storage, trusted execution environments, encrypted key stores, least-privilege separation between registry and validation services, audit-protected administrative operations, remote attestation where available, and rapid re-keying after a suspected breach. These mechanisms complement the proposed update-admission model and reduce the operational risk associated with trusted edge components.

Quarantine management is also treated as a controlled holding state rather than as the main contribution of the paper. The role of TDT-Pipe is to ensure that suspicious but authenticated telemetry does not silently modify the active DT state and that sufficient evidence is preserved for later inspection. The subsequent disposition of quarantined records is deployment-specific. For example, an operator or a domain-specific validation service may confirm the record and release a corrected update, discard it as anomalous, retain it for forensic analysis, or remove it according to a retention policy. These follow-up actions should be recorded as additional audit events and should not rewrite the original validation decision. Thus, the safety-relevant property addressed by the proposed model is the separation between initial admission and active-state modification; the design of a complete quarantine case-management workflow, including storage quotas, review deadlines, escalation rules, and deletion policies, is complementary to the proposed update-admission architecture.

Similarly, the Policy-Based View Generator specifies the information needed for field-level view confinement, but a complete policy administration interface is deployment-specific. The proposed model requires policy decisions to be explicit, versioned, and auditable, so that changes in access rules affect future views without altering historical provenance or audit records.

The timestamp predicates also assume bounded clock misalignment between the Secure Publisher and the Edge Security Gateway. In constrained IoT deployments, clock drift, intermittent synchronization, reboot events, or long offline periods may increase the difference between the device timestamp and the gateway validation time. If this difference exceeds the configured tolerance, the system may produce conservative false positives by quarantining or rejecting measurements that are authentic but temporally misaligned. This behavior is intentional from a safety perspective, because the gateway should not silently apply telemetry whose freshness cannot be established. Practical mitigations include NTP/PTP synchronization when available, registry-level clock-skew profiles for device classes, bounded adaptive tolerance based on observed drift, heartbeat or resynchronization messages, and administrative review before relaxing freshness parameters for a stream.

Finally, semantic plausibility is represented as a rule-based predicate in the evaluated device profile. This keeps the admission decision simple and transparent for fields with known physical constraints or admissible operating ranges. The same interface can also support richer deployments: time-varying operating regimes can integrate adaptive thresholds, learned plausibility models, context-aware rules, or human-in-the-loop review into the admission structure. In that case, TDT-Pipe provides the validation, quarantine, and provenance framework, while the domain-specific plausibility model supplies the decision logic used by the corresponding predicate.

10. Conclusions

This paper presented TDT-Pipe, a security-aware architecture for controlling the path from IoT telemetry publication to Digital Twin state update. The proposal starts from the observation that MQTT delivery and DT admission are different operations: a broker can route a message successfully even when the message is unauthorized, modified, replayed, stale, structurally invalid, or unsuitable for automatic application. TDT-Pipe therefore introduces an explicit validation boundary between the communication layer and the active DT state.

The architecture combines a protected telemetry format, device-specific registry profiles, mandatory and warning predicates, provenance generation, controlled state management, quarantine, audit storage, and policy-based views. Each message binds its payload digest to the device identifier, topic, timestamp, and sequence number through a device-specific HMAC. The validation result is mapped deterministically to an Apply, Quarantine, or Reject action. This design connects message-level verification with the exact effect produced on the Digital Twin and preserves an event identifier for active and quarantined values.

The experimental evaluation provides a validation of the feasibility of the approach. The results suggest that source validation, integrity protection, provenance creation, audit insertion, and controlled state admission can be combined within an IoT Digital Twin pipeline with promising performance characteristics.

Overall, TDT-Pipe provides a unified foundation for trustworthy MQTT-fed Digital Twins by linking communication evidence, admission decisions, provenance, and state-management semantics. It complements existing work on Digital Twin architectures, IoT security, MQTT integrity, and provenance by defining not only whether a message is valid, but also whether and how that message is allowed to affect the active digital representation.