Trust Scoring for Edge–Fog–Cloud IIoT Networks Using Deep Learning

Abstract

Trust Management Systems (TMSs) have recently emerged as a behavioural complement to identity-based approaches in Industrial IoT (IIoT) cybersecurity by evaluating node trustworthiness. Deep Learning (DL)-based TMSs offer favourable detection over heuristic and Machine Learning (ML) models. The computational density of DL models introduces a trade-off between inference fidelity and deployment feasibility, particularly in Edge-Fog-Cloud (EFC) IIoT architectures where latency and resources are constrained. This work proposes an EFC architectural framework that relocates DL inference to the Fog layer, reducing Cloud communication latency and Edge resource exhaustion. A lightweight Long Short-Term Memory (LSTM)-based model derives continuous trust scores from header-derived, flow-aggregated features, with inference latency bounded through fixed-size sliding windows and stateless execution. The system is trained and evaluated on CIC-IoT-2023 across Denial-of-Service (DoS), Distributed DoS (DDoS), Mirai, and benign scenarios. System scalability is assessed through ns-3 network simulation under benign conditions, with full-system behaviour further evaluated under benign, DoS, and Mirai scenarios. Offline evaluation achieves F1-score 0.9996, accuracy 0.9997, ROC-AUC 0.9999, and PR-AUC 0.9997. Architectural evaluation yields a mean inference latency of 0.049 ms, a maximum enforcement latency of 0.120 ms, and a 302 kB deployment footprint. System simulation confirms a benign False Positive Rate (FPR) 0.07% and a maximum detection latency of 0.22 ms. DoS achieves recall 0.99999 and FPR 0.00186, and Mirai achieves recall 0.99997 with FPR 0. This demonstrates that DL-based trust inference is achievable on resource-constrained Fog nodes, establishing the work as a viable solution for trust evaluation in EFC IIoT deployments.

1. Introduction

The advent of the Fourth Industrial Revolution (4IR) has been driven by the convergence of Artificial Intelligence (AI), advanced communication technologies, and the large-scale integration of intelligent digital systems into industrial ecosystems, fundamentally transforming how physical processes are monitored, controlled, and optimised [1]. Central to this transformation is the emergence of the Industrial Internet of Things (IIoT) and its vertical extensions such as the Vehicular Internet of Things (VIoT), which enable pervasive sensing, real-time data exchange, and autonomous decision-making across domains including smart manufacturing, transportation, and energy systems [1,2].

Building upon this connectivity, the Fifth Industrial Revolution (5IR) further extends this evolution by emphasising human-centric, resilient, and sustainable system design, integrating human intelligence with machine-driven automation [3]. As a result, modern industrial environments are increasingly characterised by dense and heterogeneous networks of interconnected devices operating within Cyber-Physical Systems (CPSs), where computational intelligence and communication capabilities are tightly integrated with physical processes to enable real-time monitoring, control, and autonomous decision-making in critical systems [2,4].

Traditionally, IIoT systems adopted a centralised two-tier Edge-Cloud (EC) architecture in which resource-constrained Edge devices performed data acquisition and control, while computationally intensive processing and analytics were offloaded to remote Cloud servers [5]. However, this model introduced significant latency and bandwidth constraints, particularly for time-critical industrial applications [5]. Fog computing was formalised as an intermediate paradigm, notably advanced by Cisco, giving rise to the now widely recognised Edge-Fog-Cloud (EFC) architecture [5].

In this hierarchical model, the Edge layer consists of sensors, actuators, and controllers such as Programmable Logic Controllers (PLCs), responsible for real-time data acquisition and control execution; the Fog layer introduces geographically distributed gateway nodes that provide intermediate computational capabilities bridging the Edge and Cloud, enabling latency-sensitive processing, data aggregation, and localised decision-making [6]; and the Cloud layer offers centralised infrastructure for large-scale analytics, long-term storage, and model training [6]. This architectural decomposition enables a trade-off between latency, computational capacity, and scalability, where time-critical operations are handled closer to the Edge and resource-intensive tasks are offloaded to the Cloud [6]. However, the resulting distribution of intelligence across multiple layers introduces additional complexity in maintaining secure, reliable, and trustworthy interactions across heterogeneous and geographically dispersed nodes [5].

Building on this distributed EFC architectural paradigm, the security implications of such multi-layered and heterogeneous systems become a central concern [7]. Cybersecurity in IIoT refers to the set of mechanisms and principles designed to protect industrial CPSs from adversarial interference while ensuring correct, safe, and reliable system operation while recognising that the integrity of computation in CPS environments directly influences physical processes and outcomes [8]. Unlike traditional Information Technology (IT) environments, where security is primarily concerned with protecting data confidentiality and system availability, IIoT security must also account for the physical consequences of cyber actions, as computational decisions are directly translated into real-world effects through tightly coupled sensing, communication, and control processes [9].

Within this context, the attack surface is defined as the total set of entry points and interaction pathways through which an adversary can influence system behaviour. This attack surface is significantly larger in IIoT systems due to the high density of distributed devices and continuous inter-device communication [7]. These characteristics, combined with decentralised decision-making and heterogeneous IIoT intelligence deployment, introduce additional vulnerabilities and expand exposure to adversarial manipulation [9]. Layered architectures such as the EFC paradigm further amplify this effect, as the distribution of computation and data across multiple layers introduces additional complexity in security, increasing system exposure compared to conventional IT infrastructures [7].

Addressing these complexities requires consideration beyond static defences. Consequently, IIoT cybersecurity requires consideration of identity-based mechanisms, which verify the legitimacy of entities within the network, and behaviour-based mechanisms, which evaluate whether those entities act in accordance with expected operational norms during system execution, as reflected in recent security approaches [10,11]. However, these mechanisms alone do not fully address the limitations of traditional security models in IIoT and CPS environments.

CPSs are characterised by tight coupling between computational processes and physical system behaviour, where cyber actions directly influence physical states [8]. In such environments, security violations may propagate beyond data compromise, manifesting as incorrect or unsafe physical actions executed through Industrial Control Loops (ICLs). This is particularly critical in IIoT and CPS settings, where sensor-derived data are continuously integrated into closed-loop control mechanisms and where even syntactically valid but malicious or erroneous inputs can result in unsafe system behaviour [8]. As a result, traditional security models based on the Confidentiality, Integrity, Availability (CIA) triad are insufficient to address the safety and behavioural requirements of CPS and IIoT environments [11]. The existing IoT security literature similarly suggests that these models must be extended with trust and reputation mechanisms to address dynamic and distributed operational contexts [11,12,13].

This limitation motivates a shift towards trust-centric security models in such systems. In this work, trust is defined as a dynamic measure of confidence in the expected behaviour of an entity based on observed interactions over time, informed by the definitions of trust and its characteristics in [10,12,13,14,15]. Hence, trust can be treated as a continuous score in $[0,1]$, where higher scores reflect greater confidence in benign operation and lower scores indicate increasing suspicion of anomalous or malicious activity. Such a formulation complements intrusion detection, extending binary threat identification with a continuous measure of entity reliability. Unlike static security properties, trust is context-dependent and evolves with system conditions and behavioural evidence [16]. In IIoT, trust serves as a higher-level abstraction that bridges traditional cybersecurity mechanisms with system-level assurance. This perspective aligns with prior work showing that trust complements conventional security mechanisms and facilitates reliable system behaviour in IoT environments [12], ensuring not only the protection of data but also the correctness and safety of system behaviour during operation.

While cybersecurity mechanisms in IIoT are commonly classified based on their layers of operation, techniques and functional roles [17], in this work they are categorised into identity-based and behaviour-based mechanisms to provide a consistent classification scheme. These classifications are complementary, as cryptographic and enforcement mechanisms predominantly support identity-based security, while learning-based approaches are typically associated with behaviour-based analysis [11,17].

Identity-based mechanisms often constitute the first line of defence and focus on preventing unauthorised access through authentication and authorisation frameworks, commonly realised through cryptographic primitives such as Public Key Infrastructure (PKI) and X.509 certificate infrastructures along with network enforcement mechanisms such as firewalls. These mechanisms operate primarily at system entry points or communication boundaries, and are designed to ensure that only legitimate entities participate in network interactions. However, their deployment in IIoT environments introduces significant computational and communication overhead, particularly for resource-constrained devices such as PLCs and edge sensors. For example, asymmetric cryptographic operations such as Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC) incur substantial computational cost [18]. Similarly, certificate-based infrastructures introduce scalability constraints in large-scale deployments [19], while secure protocols such as Datagram Transport Layer Security (DTLS) add handshake latency [20] and increase bandwidth usage in resource-constrained networks using technologies such as 6LoWPAN [21]. These limitations have motivated research into more lightweight identity-based mechanisms [19]; however, such approaches primarily operate at the authentication and access-control layer, and as such do not capture runtime behavioural dynamics in which system behaviour may evolve after entities have been admitted to the network.

To address these runtime vulnerabilities, behaviour-based mechanisms operate during system execution to detect deviations from expected operational behaviour after access has been granted. This category includes Intrusion Detection Systems (IDSs) and Intrusion Prevention Systems (IPSs), which monitor system activity for signs of malicious or abnormal behaviour, as well as anomaly detection techniques that form the underlying analytical basis for identifying deviations in system behaviour [22]. Within this broader landscape, Trust Management Systems (TMSs) extend trust assessment by incorporating both observed behaviour and contextual interaction history rather than relying solely on runtime behavioural signals [23]. While TMSs integrate multi-dimensional evidence inclusive of identity and behaviour [11], their efficacy in IIoT is primarily driven by runtime behavioural telemetry due to the high frequency of interaction data [24]. In this context, TMSs act as a hybrid mechanism that complements both identity and behaviour-based approaches. By continuously evaluating entity trustworthiness under dynamic and adversarial conditions, these systems provide higher-level assurance of system-wide integrity.

TMSs have evolved significantly in their underlying inference mechanisms, progressing from simple heuristic models to more advanced data-driven approaches. Early TMS frameworks relied on weighted-sum heuristics such as [25], where trust scores are computed through manually assigned weights across selected features. While computationally efficient, these approaches lack adaptability and struggle to capture complex nonlinear behavioural patterns. Subsequent probabilistic models, including Bayesian-based frameworks such as those reported in [13], introduced statistical reasoning to model trust under uncertainty; however, they often incur significant storage and computational overhead, scaling linearly with both network size and feature dimensionality.

To further address uncertainty and strategic behaviour, more recent approaches have incorporated game-theoretic and evidence-based models [26,27]. While these methods improve robustness in adversarial environments, they introduce additional computational complexity and often exhibit poor scalability in dense IIoT deployments. Predictive models, including Markov-based approaches such as [28], extend this capability by incorporating temporal dynamics but remain constrained by similar scalability limitations.

More recently, Deep Learning (DL)-based approaches have emerged as a promising solution for modelling the high-dimensional and nonlinear behavioural patterns characteristic of modern cyber–physical attacks, achieving superior detection performance compared to traditional methods [29,30]. However, these models introduce significant deployment challenges in IIoT environments [29,31]. Specifically, they present a fundamental trade-off between detection fidelity and system feasibility, as their computational and memory requirements often exceed the capabilities of resource-constrained Edge devices, while alternative Cloud-based deployments introduce stochastic latency and jitter that violate the deterministic timing constraints of ICLs and real-time control systems [32].

Across these approaches, a persistent gap remains between high-fidelity trust inference and support for practical deployment in latency-sensitive IIoT environments. The Fog layer offers a natural candidate for bridging this gap, providing intermediate computational capabilities closer to the Edge; however, designing efficient inference mechanisms for resource-constrained Fog nodes remains a non-trivial challenge. Recent Fog-native approaches [16,33] address these constraints through lightweight and distributed architectural designs. Although works such as [33] consider deterministic or latency-aware operation within their target domains, these approaches remain tightly coupled to specific application contexts and do not fully address continuous and flow-based behavioural trust inference in heterogeneous IIoT environments under constrained Fog execution settings.

Table 1 summarises key approaches in the trust management literature, contrasting their inference mechanisms, characteristics, and deployment suitability.

Table 1. Comparison of state-of-the-art trust management and anomaly detection research.

Reference	Model	Dataset	Inference Layer	Deployment Optimisation	Focus
[25]	Adaptive Weighted Sum	IoT Sentinel	Edge	None	Context Filtering
[16]	Hybrid Weighted Sum	Epinions	Fog	None	Context-aware hybrid trust accuracy and stability under adversarial VIoT conditions
[34]	Random Forest + SMOTE	CIC-IoT-2023	Edge	None	Imbalance-Aware Intrusion Detection for Multi-Class IoT Attacks
[27]	DST + Beta Distribution	Synthetic	Edge	None	On-Off Attack Detection
[26]	Game Theory + Random Forest	Synthetic	Edge	None	Noise Robustness
[28]	Markov + Multi-Attribute Ranking	Testbed	Fog	None	Trust Prediction in Data Scarce Environments
[35]	Logistic Regression + Subjective Logic	Simulated	Bidirectional	None	Uncertainty Modelling, Robustness & Sybil Attack Prevention
[36,37]	TPM + Remote Attestation	Simulated	N/A	None	Automated Fog Audit & Certification
[31]	LSTM	Testbed	Cloud	None	Accuracy & Adaptability
[33]	CNN + LSTM + VAE	MIMIC-III + MIT-BIH	Fog	Quantised	Data Integrity in Healthcare
[38]	Attention-based DNN + One-Class SVM	CICIoMT2024 + MQTT-IoT-IDS2020	Edge	None	Feature-Efficient Unsupervised Anomaly Detection In Healthcare
[39]	LSTM	CIC-IoT-2023	Edge	None	IoT Intrusion Detection Across Diverse Attack Patterns
[40]	KNN + Logistic Regression + SGD	CIC-IoT-2023 + CIC-DDoS-2019	Edge	None	Real-Time DDoS Detection in IoT
EF-TMA	LSTM	CIC-IoT-2023	Fog	Graph Optimised	Scalable TMS for Latency-Constrained IIoT Edge-Fog Systems

Convolutional Neural Network (CNN); Dempster–Shafer Theory (DST); Deep Neural Network (DNN); K-Nearest Neighbours (KNN); Long Short-Term Memory (LSTM); Stochastic Gradient Descent (SGD); Support Vector Machine (SVM); Synthetic Minority Oversampling Technique (SMOTE); Trusted Platform Module (TPM); Variational Autoencoder (VAE).

To address the identified limitations in the existing TMS literature, the primary aim of this work is to design a DL-based trust inference model that is feasible for deployment on resource-constrained Fog nodes and that enables scalable and continuous trust scoring across IIoT environments. Existing solutions predominantly focus on isolated model designs rather than end-to-end deployment, leaving practical Fog-native deployment insufficiently explored. To this end, the present paper proposes the Edge-Fog Trust Management Architecture (EF-TMA), a Fog-centric trust evaluation architecture designed to reconcile the trade-off between high-fidelity inference and bounded-latency operation under resource-constrained deployment. The main contributions are as follows:

• A TMS designed to operate within bounded inference latency and memory footprints consistent with resource-constrained Fog hardware deployments as established in the lightweight on-device inference literature, enabling practical deployment without reliance on Cloud offloading.
• A lightweight DL-based trust inference model that derives continuous trust scores from header-derived and flow-aggregated features, enabling fine-grained and interpretable reliability assessment across IIoT network flows.
• A systematic empirical evaluation of EF-TMA within a simulated IIoT network environment, assessing trust inference performance under representative attack scenarios.

The remainder of this paper is structured as follows: Section 2 details the system model and proposed EF-TMA architecture; Section 3 presents the evaluation methodology, detailing the experimental setup, simulation environment, and evaluation criteria; Section 4 presents and discusses the results of the system evaluation; finally, Section 5 concludes the paper and outlines future research directions.

2. System Model

2.1. EF-TMA Architectural Model

The EF-TMA architecture follows a hierarchical EFC paradigm in which computation, monitoring, and control are distributed across three layers, as illustrated in Figure 1. The Edge layer is responsible for sensing and actuation, while the Fog layer performs latency-sensitive processing and trust evaluation. Fog Orchestrators within this layer coordinate resource management, task scheduling, and policy enforcement across Fog nodes. The Cloud layer provides large-scale storage, analytics, and orchestration services.

Figure 1. High-level topology of EF-TMA, comprising $N_E$ Edge nodes, $N_F$ Fog nodes, and $N_C$ Cloud nodes, where E, F, $F_O$, and C denote Edge, Fog, Fog Orchestrator, and Cloud nodes, respectively. The propagation latencies ${\tau }_{\mathrm{pre}}$ and ${\tau }_{\mathrm{dep}}$ are the preprocessing and deployment propagation latencies, as formally defined in Section 2.1.2.

For simplicity, each layer is instantiated with a single node of each type for the remainder of this work, unless stated otherwise; in general, EFC deployments satisfy $N_E\ge N_F\ge N_C$, reflecting the hierarchical aggregation of resources across layers. The internal structure of a representative Fog node is detailed in Figure 2, highlighting the Trust Management Engine (TME) and its interaction with the data plane.

Figure 2. Detailed architecture of a representative Fog node in EF-TMA, illustrating the TME and its constituent components: the Feature Extraction Application $\mathcal{E}(·)$, the Sliding Feature Window Manager $\mathcal{W}(·)$, the Trust Model $\mathcal{M}(·)$, and the Trust Decision Maker. The data flow proceeds from raw packet stream P through feature stream X, windowed representation ${\mathbf{X}}_t$, trust score $T_t$, to policy action ${\Theta }_t$ dispatched to the Fog Orchestrator.

Within each Fog node, a TME operates as a parallel monitoring and decision-support module. Its primary function is to transform raw packet-level telemetry into structured feature representations, aggregate these into temporal windows, and compute a continuous trust score for each observed entity.

To ensure non-intrusive system operation, the TME executes on a decoupled monitoring path that is independent of the primary data forwarding pipeline. This separation ensures that trust computation does not introduce additional latency into packet transmission, thereby preserving line-rate performance in the data plane.

While the primary focus of this work is trust score generation, the EF-TMA architecture is designed to support compatibility with downstream policy enforcement mechanisms. In this architectural framework, trust scores may be mapped to explicit control actions; however, in this study policy enforcement is abstracted and represented using threshold-based decision boundaries. These thresholds are treated as operational constraints rather than fixed deployment policies, allowing the focus to remain on the behaviour of the trust evaluation mechanism itself.

The following subsections formalise the data representations, temporal processing dynamics, and system reliability mechanisms underpinning the architecture.

2.1.1. Functional Data and Trust Modeling

Edge nodes generate raw packet streams on a per-device basis. Let

$$P^{\left(E_j\right)}\triangleq {\left(p_i^{\left(E_j\right)}\right)}_{i\in {\mathbb{Z}}^{+}}=(p_1^{\left(E_j\right)},p_2^{\left(E_j\right)},\dots )$$

(1)

denote the ordered packet stream associated with Edge node $E_j$, where $j\in \{1,\dots ,N_E\}$ indexes the set of Edge nodes and $p_i^{\left(E_j\right)}$ represents the i-th packet generated by that node. These packets are forwarded to the Fog layer. For clarity of notation, the Edge node superscript is omitted in subsequent expressions, and P is used to denote the packet stream of a given Edge node.

Within each provisioned Fog node, a TME is instantiated to evaluate the behavioural trustworthiness of all Edge nodes under its administrative domain. The TME can be implemented as a dedicated physical component or as a logical application-layer service.

The TME operates on features extracted from the incoming packet stream P. A feature extraction application $\mathcal{E}(·)$ maps each packet $p_i$ to a corresponding k-dimensional attribute vector $x_i\triangleq \mathcal{E}\left(p_i\right)$, forming a primary packet-level feature stream

$$X\triangleq {\left(x_i\right)}_{i\in {\mathbb{Z}}^{+}}=(x_1,x_2,\dots ),$$

(2)

where $x_i\in {\mathbb{R}}^k,\forall i\in {\mathbb{Z}}^{+}$ and k signifies the dimensionality of the feature space.

To capture temporal dependencies and flow-level behaviour, the primary feature stream X is processed by a sliding window manager $\mathcal{W}(·)$. This module aggregates packet-level features into flow-level representations over fixed-length windows of maximum size $m\in {\mathbb{Z}}^{+}$. At each discrete time step $t\in {\mathbb{Z}}^{+}$, $\mathcal{W}(·)$ evaluates the L most recent aggregated flow observations, where window length $L=min(t,m)$. This produces the following windowed feature matrix:

$${\mathbf{X}}_t\triangleq \mathcal{W}(x_{t-L+1},\dots ,x_t)=\left[\begin{array}{c}{\tilde{x}}_1\\ {\tilde{x}}_2\\ ⋮\\ {\tilde{x}}_L\end{array}\right]\in {\mathbb{R}}^{L\times k},$$

(3)

where each row ${\tilde{x}}_l\in {\mathbb{R}}^k$, indexed by $l\in \{1,\dots ,L\}$, represents a feature vector modified based on the statistical properties of the current L items in the sequence. These modifications include the calculation of rolling averages where applicable and packet Inter-Arrival Times (IATs) relative to the current window context. Such representations encode the flow-level dynamics and statistics required for trust evaluation. For model consistency, windows where $L<m$ are not evaluated; inference begins once the window is fully populated at $L=m$, ensuring ${\mathbf{X}}_t\in {\mathbb{R}}^{m\times k}$.

The aggregated features are then provided as the input to the trust model, which computes a continuous trust score $T_t$ for each discrete time step t:

$$T_t\in [0,1]\subset \mathbb{R},$$

(4)

thereby representing the behavioural trustworthiness of the corresponding Edge node. The internal structure of the trust model $\mathcal{M}(·)$ is detailed in Section 2.3.

Formally, the composite trust evaluation process is defined as:

$$T_t\triangleq \mathcal{M}\left({\mathbf{X}}_t\right)=\mathcal{M}\left(\mathcal{W}\left({\left(\mathcal{E}\left(p_i\right)\right)}_{i=t-m+1}^t\right)\right),$$

(5)

where the sequence is zero-padded such that $\mathcal{E}\left(p_i\right)=\mathbf{0},\forall i\le 0$, though in practice $\mathcal{M}(·)$ is only evaluated for $t\ge m$. This formulation captures the end-to-end transformation of raw network observations into a quantifiable trust metric.

The resulting trust score is consumed by a trust decision module, which maps $T_t$ to an active policy action based on predefined thresholds:

$${\Theta }_t\triangleq \left\{\begin{array}{cc}\mathrm{Permit},\hfill & T_t\ge \theta ,\hfill \\ \mathrm{Throttle}/\mathrm{Verify},\hfill & \alpha \le T_t<\theta ,\hfill \\ \mathrm{Block},\hfill & T_t<\alpha \hfill \end{array}\right.,$$

(6)

where $\theta$ and $\alpha$ are upper and lower decision thresholds, respectively, satisfying $0\le \alpha <\theta \le 1$.

The selected action is communicated to a Fog Orchestrator, which is responsible for enforcing the policy across distributed Fog nodes. This enables coordinated and consistent trust-based control in systems characterised by hierarchical communication. By centralising enforcement at the orchestration layer while retaining local trust evaluation at the Fog nodes, EF-TMA achieves a balance between scalability, responsiveness, and global policy consistency. The Fog Orchestrator lies outside the system boundary of the TME, as illustrated in Figure 2. While the Fog Orchestrator is responsible for policy enforcement and cross-node coordination, its internal processing, such as policy aggregation across distributed Fog nodes, is deployment-specific and is not formally modelled in this work. Consequently, the Fog Orchestrator is modelled as a passive sink, receiving dispatched policy actions without performing additional processing.

2.1.2. Temporal Dynamics and Asynchronous Enforcement

In IIoT networks, the time required for DL inference may exceed the IATs of high-speed packet streams. To ensure non-blocking operation and maintain line-rate throughput without stalling the ingress data flow, EF-TMA implements asynchronous policy enforcement.

This architectural choice decouples the Policy Decision Point (PDP), where trust scores are calculated via DL inference, from the Policy Enforcement Point (PEP), where forwarding decisions are executed. By offloading the PDP logic, EF-TMA prevents inference-induced latency from bottlenecking the PEP’s data plane throughput, adhering to the functional separation of control and enforcement planes established in the NIST SP 800-207 Zero Trust Architecture (ZTA) framework [41].

In EF-TMA, packet-level enforcement follows a one-step delayed policy, where the decision applied to packet $p_t$ is based on the trust state computed from prior observations up to $p_{t-1}$.

The Enforcement Latency ($\delta$) is defined as the temporal difference between the arrival of telemetry data and the deployment of the updated trust score to the Fog node’s enforcement mechanism:

$$\delta \triangleq {\tau }_{\mathrm{pre}}+{\tau }_{\inf }+{\tau }_{\mathrm{dep}},$$

(7)

where ${\tau }_{\mathrm{pre}}$ denotes the preprocessing time required for feature extraction and normalisation of incoming telemetry data (including any associated buffering and queuing overhead prior to feature construction), ${\tau }_{\inf }$ represents the inference time taken by the AI model to process the feature vector during the forward pass, and ${\tau }_{\mathrm{dep}}$ corresponds to the deployment time required to propagate the updated trust score to the Fog node’s decision logic, including dispatch, routing, and integration into downstream enforcement components.

This latency $\delta$ introduces a bounded enforcement delay, resulting in a finite vulnerability window during which newly arriving packets are evaluated using a previously computed (i.e., stale) trust policy. This trade-off is inherent to non-blocking trust enforcement, and enables line-rate data plane performance required for real-time IIoT deployments.

It is important to distinguish between enforcement latency and detection latency. The former ($\delta$) represents the system-level delay associated with queuing, feature processing, inference, and policy deployment, and is incurred for all observations. In contrast, detection latency (${\tau }_{\det }$) is defined as the elapsed time between the onset of malicious behaviour and its identification by the model. Let $t_{\mathrm{atk}}$ denote the time at which malicious behaviour begins, and $t_{\det }$ the time at which the model first identifies the attack. The detection latency is then given by:

$${\tau }_{\det }\triangleq t_{\det }-t_{\mathrm{atk}}.$$

(8)

Decoupled architectures must balance stringent latency constraints [4] against the characteristic security-performance conflicts inherent in real-time monitoring [42].

The policy enforcement logic follows a non-blocking $(t+1)$ dependency model:

1.

Upon arrival of packet $p_t$, the current trust policy ${\Theta }_{t-1}$ is applied immediately.

2.

Simultaneously, $p_t$ triggers feature extraction and inference within the TME.

3.

The resulting trust score $T_t$ is asynchronously deployed, becoming the active policy ${\Theta }_t$ for packet $p_{t+1}$.

The active trust policy evolves as

$${\Theta }_t=\mathcal{G}(T_t,{\Theta }_{t-1}),$$

(9)

where $\mathcal{G}$ denotes the update function and ${\Theta }_t$ is the policy action defined in Section 2.1.1.

This decoupling transforms trust evaluation into a streaming pipeline, ensuring that inference latency does not directly impact packet forwarding decisions. The characteristics of the inference process are further detailed in Section 2.3.

2.1.3. Fog-Layer Fault Tolerance

A key limitation of Fog-centric architectures is the potential introduction of a Single Point of Failure (SPoF) at the TME, analogous to the centralisation risk identified in Fog-layer authentication infrastructure [37]. In EF-TMA, this risk is mitigated through orchestrator-assisted state replication.

Each Fog node $F_q$, where $q\in \mathcal{Q}\triangleq \{1,\dots ,N_F\}$, independently evaluates trust within its local subnet; however, not every Fog node is required to host a TME instance, as deployment is governed by the administrative and resource constraints of the given subnet. To ensure fault tolerance, the per-flow runtime state required to resume trust evaluation is periodically synchronised with a control-plane orchestrator responsible for global policy management and load balancing. Because the TME performs stateless sliding-window inference (Section 2.3), recovery requires only the most recent windowed feature matrix ${\mathbf{X}}_{t,j}$, the active trust policy ${\Theta }_{t,j}$, and the interaction history ${\iota }_{t,j}$, where t denotes the current time step and j indexes the Edge node $E_j$ under the TME’s administrative domain. This state is maintained independently for each Edge node managed by the TME instance running on the given Fog node.

In the event of a failure at Fog node $F_q$, a secondary node $F_r$, where $r\in \mathcal{Q}\setminus \left\{q\right\}$, can resume TME functionality from the most recent synchronised window ${\mathbf{X}}_{t-\Delta ,j}$, where $\Delta \in {\mathbb{Z}}^{+}$ denotes the number of discrete time steps elapsed since the last successful synchronisation. In practice, t may be expressed as a wall-clock timestamp synchronised to a global reference clock, ensuring temporal continuity across Fog nodes during failover.

By delegating state consistency to the orchestration layer, EF-TMA avoids the convergence delays and signalling overhead associated with peer-to-peer synchronisation mechanisms. This design aligns with hierarchical control paradigms employed in Software-Defined Networking (SDN) and Multi-access Edge Computing (MEC) as defined in [43]. To mitigate the introduction of a secondary SPoF, the orchestration layer operates as a high-availability cluster, leveraging node redundancy to improve control-plane availability [37] and ensuring that the temporal trust formulation defined in Equation (5) remains consistent across node failover events.

2.1.4. Model Lifecycle and Redeployment

Given the resource constraints of Fog nodes, model retraining is performed centrally at the Cloud layer, which serves as the primary infrastructure for large-scale analytics and storage within EF-TMA. Upon retraining, the updated model is exported to Open Neural Network Exchange (ONNX) format for portability and graph optimisation, as described in Section 3.1.1, and distributed to Fog nodes by the Fog Orchestrator.

To ensure continuity of active monitoring during redeployment, EF-TMA supports a hot-swap mechanism in which the updated model is loaded into a staging instance on the target Fog node while the current model remains active. Once the staged model is ready, the TME switches atomically to the new instance, ensuring no disruption to the active monitoring pipeline. The integrity of Cloud-to-Fog model distribution requires attestation of Fog node integrity prior to deployment. This can be realised through existing Fog audit and certification schemes such as those proposed in [36,37], which are compatible with the EFC deployment context of EF-TMA.

Emerging approaches such as federated learning represent a promising alternative to centralised retraining [5,9], enabling collaborative model updates across distributed Fog nodes without routing raw traffic data to the Cloud.

2.2. Security Model

2.2.1. Threat Model

We define a behavioural adversary $\mathcal{A}$ that possesses valid cryptographic credentials but seeks to degrade the ICL. Given the direct-observation architecture of EF-TMA, the threat model emphasizes telemetry-driven attack vectors rather than indirect or reputation-based manipulation.

To ensure realism and reproducibility, the adversary behaviour is modeled using canonical network-layer attacks, specifically Denial-of-Service (DoS), Distributed Denial-of-Service (DDoS), and botnet-driven attacks such as Mirai.

1.

DoS: $\mathcal{A}$ generates sustained or intermittent high-rate traffic from a single node, with transmission rate $R_{attack}\gg R_{benign}$, in order to exhaust local or downstream resources. This attack manifests in telemetry as elevated packet transmission rates, increased packet loss, and rising inter-arrival jitter due to buffer saturation. The objective is to degrade network responsiveness and induce instability in the control loop.

2.

DDoS: $\mathcal{A}$ coordinates multiple compromised nodes to simultaneously transmit malicious traffic toward a target node or gateway. Unlike DoS, the distributed nature results in a more gradual and harder-to-isolate degradation pattern. Telemetry features affected include aggregate throughput, Packet Delivery Ratio (PDR), and congestion-induced latency $\delta$ at the fog gateway. This vector evaluates the system’s ability to detect spatially distributed anomalies across multiple nodes.

3.

Mirai-like Botnet Behaviour: $\mathcal{A}$ models a compromised IoT device participating in a botnet (e.g., Mirai), exhibiting coordinated yet adaptive malicious behaviour. This includes periodic scanning, burst-based traffic generation, and command-and-control driven attack synchronization.

The attack is characterized by temporal bursts resembling on–off patterns, irregular packet timing (jitter injection), and mixing both benign and malicious traffic in order to evade detection.

This vector is designed to evaluate the system’s ability to capture temporal dependencies and burst dynamics within the windowed observation horizon.

2.2.2. Security Features

To detect the adversarial behaviours defined by $\mathcal{A}$, the feature extraction function $\mathcal{E}$ must map the raw packet stream P to a set of discriminative attributes. Given the stringent latency constraints and the necessity for line-rate non-blocking processing established in Section 2.1, Deep Packet Inspection (DPI) is computationally prohibitive. DPI is also increasingly limited by the prevalence of encrypted traffic, which has motivated a broader shift toward header-derived features for detection [44].

Beyond these constraints, comprehensive analyses of IoT security paradigms [45] and recent benchmarking of large-scale IoT attack topologies [46] demonstrate that the deterministic nature of IIoT traffic renders statistical network-flow features highly discriminative for anomaly detection without payload inspection. The recent IoT anomaly detection literature [38] has further demonstrated that minimalist header-derived features are sufficient to achieve favourable performance. Consequently, EF-TMA relies exclusively on lightweight telemetry derived from the header fields of the Network and Transport layers.

These header-derived metrics are continuously extracted to form the primary feature vector $x_i$, capturing the physical and behavioural footprint of the transmitting node. The available feature space encompasses three primary categories aligned with the threat model:

1.

Temporal Dynamics: To capture the timing characteristics of volumetric attacks such as Mirai-like botnet floods and flooding-based DoS/DDoS attacks, precise timing metrics offer discriminative value. Such behaviours produce timing distributions that deviate from those typical of legitimate flows [47]. The primary metric is the IAT, calculated as $\Delta t_i=t_i-t_{i-1}$, where $t_i$ is the arrival timestamp of packet $p_i$.

2.

Volumetric and Size Characteristics: Flooding-based DoS/DDoS attacks alter the spatial footprint of the data stream in ways that are observable from packet header metadata, including raw payload length (bytes) and header length variations. Such header-derived features have been shown to support intrusion detection without reliance on payload inspection [44], which is particularly relevant in IIoT settings where attack patterns deviate from the payload size distributions of benign sensor telemetry.

3.

Protocol and Flow Indicators: Header flags and connection states provide discriminative features for detecting reconnaissance scanning and state-exhaustion attacks, as protocol- and flow-level indicators have been shown to support effective intrusion detection in IoT networks [48]. This category encompasses the protocol composition of flows (e.g., TCP, UDP, ICMP), the counts and ratios of TCP control flags (e.g., SYN, ACK, RST), and ICMP message-type distributions. Patterns such as a high frequency of SYN packets without corresponding ACKs are characteristic of half-open connection behaviour, and indicate potential adversarial intent prior to establishing a successful connection [49].

These feature categories define the observational scope of the Fog node’s monitoring pipeline. As defined in Section 2, each packet (or flow-level aggregation) is represented by a k-dimensional feature vector constructed from header-derived metrics spanning temporal, volumetric, and protocol-level characteristics. In the context of the security model, these features capture the behavioural signatures associated with adversarial activity, enabling the DL trust model $\mathcal{M}(·)$ to distinguish between benign and malicious communication patterns. The specific feature composition used for model training and evaluation is detailed in Section 2.3.2.

2.3. AI Model

2.3.1. Dataset Selection and Sampling Strategy

While the EF-TMA architecture supports diverse IIoT traffic profiles, this work focuses on sensing and telemetry data. Characterised by periodic transmissions and low payload variability, as shown later in Section 3.3.1, this traffic exhibits quasi-deterministic patterns. This inherent predictability provides a tightly controlled baseline for the TME, where deviations serve as highly reliable indicators of anomalous behaviour.

To represent this environment, several publicly available benchmark datasets were considered for evaluating EF-TMA, including BoT-IoT [50], TON-IoT [51], and UNSW-NB15 [52]. However, these datasets each have limitations relative to EF-TMA’s target setting: UNSW-NB15 captures enterprise rather than IIoT traffic; BoT-IoT relies on a small synthetic device set; and TON-IoT, while heterogeneous, was produced before the wave of Mirai variant and large-scale IIoT botnet activity captured by the 105-device physical testbed of CIC-IoT-2023 [46].

The CIC-IoT-2023 dataset was selected for its comprehensive coverage of IIoT-specific protocols, its inclusion of recent attack vectors, and its distinguishing property of having all attacks executed by malicious IoT devices targeting other IoT devices within an extensive physical topology. This attack origination model aligns with EF-TMA’s threat assumptions, in which compromised IIoT endpoints may themselves act as attack sources, a scenario not exercised by datasets in which the attacks originate from external computer systems [46]. Its use in recent related work (Table 1) further supports reproducibility and comparability of results.

The dataset provides precomputed flow-level features derived from packet captures. For training and evaluation, non-relevant fields are filtered, numerical attributes are normalised, and flows are arranged into temporally ordered sequences. In operational deployment, EF-TMA consumes flow records aggregated in real time from live packet streams; the temporal aggregation defined in Section 2.1 mirrors this behaviour, ensuring consistency between training-time and inference-time representations.

The CIC-IoT-2023 dataset exhibits substantial class imbalance. When attack categories are condensed into a single malicious class for binary classification, benign traffic constitutes only approximately 2.4% of all flows, with malicious traffic accounting for the remaining 97.6% [46]. The malicious class is itself internally imbalanced: DDoS flows alone represent roughly 73% of the dataset, and the flood-based categories (DDoS, DoS, and Mirai combined) account for approximately 96% of all flows.

To prevent the classifier from over-predicting the malicious class and its dominant flood-based subclasses, balanced random undersampling was applied at the sequence level, producing a 1:1 benign-to-malicious ratio in the training set. Sequence windows were constructed before subsampling in order to preserve flow ordering within each retained window. Synthetic oversampling techniques and random duplication were avoided, as the former can produce feature combinations that are not physically realisable, which is particularly problematic where temporal coherence forms part of the discriminative signal, while the latter encourages memorisation rather than generalisation. The test set was left unmodified to preserve the natural class distribution so that the performance metrics reflect realistic deployment conditions.

Due to the scale of the full CIC-IoT-2023 dataset, which contains over 46 million flow records, direct processing of the entire corpus was computationally impractical for the experimental setup. Since the primary focus of this work is the architecture rather than exhaustive model optimisation, the subset was constructed by selecting the first four source files per attack subtype and the benign class as listed in the CIC-IoT-2023 repository, applying a 75/25 file-level train/test split [38,40]. Files were assigned to training and test sets prior to any processing, ensuring that temporal windows are constructed independently within each assigned set. Once constructed, training windows were pooled and shuffled at the window level for batching, preserving the internal window order while ensuring that no window spanned records across the train/test boundary. Following sequence construction and balanced random undersampling, the final dataset used for model development comprised 1,936,698 training sequences and 2,803,815 testing sequences. The test set exceeded the training set in size, as the 1:1 undersampling strategy substantially reduced the training set relative to the naturally imbalanced test set.

2.3.2. Feature Selection

The feature mapping function $\mathcal{E}(·)$ introduced in Section 2.1 is instantiated using lightweight, header-derived, and statistical network features. These features were selected to align with the EF-TMA design constraint of avoiding payload inspection, thereby ensuring low computational overhead and compatibility with privacy-preserving deployments.

An initial candidate feature set was derived from packet-level telemetry and temporal statistics, as described in Section 2.2.2. To reduce redundancy and improve statistical robustness, feature selection was performed using Spearman rank correlation analysis and variance-based filtering, removing highly correlated and low-information attributes. The resulting feature set, summarised in Table 2, captures three behavioural dimensions: (i) temporal dynamics, (ii) statistical traffic characteristics, and (iii) protocol-level indicators.

Table 2. Feature set used in EF-TMA.

Feature	Description
IAT	Inter-arrival time between consecutive packets, capturing temporal burstiness and jitter behaviour in network flows.
Rate	Packet transmission rate within a sliding window, representing communication intensity per flow.
Average Size	Average packet size within a flow window, reflecting typical payload characteristics of the communication stream.
Header Length	Length of packet headers, capturing protocol overhead variations and structural traffic differences.
Variance	Statistical variance of packet sizes within a window, used to detect irregular or adversarial traffic fluctuations.
TTL	TTL field value, used to infer routing consistency and potential spoofing or anomaly behaviour.
TCP	Proportion of TCP packets within a flow window.
UDP	Proportion of UDP packets within a flow window.
ICMP	Proportion of ICMP packets within a flow window, often indicative of scanning or diagnostic traffic.

By focusing exclusively on flow-observable characteristics rather than payload content, the resulting feature representation supports efficient and scalable trust evaluation in high-throughput environments.

2.3.3. Feature Normalisation

Due to the heterogeneous nature of network telemetry, the extracted features exhibit significant variation in scale, units, and statistical distribution. Without appropriate transformation, features with large numerical magnitudes or heavy-tailed distributions may dominate the learning process, resulting in biased model behaviour and unstable optimisation.

To address this, a composite normalisation function $\mathcal{N}:{\mathbb{R}}^k\to {\mathbb{R}}^k$ is defined and applied to each feature vector $x_i$, producing a transformed representation ${\widehat{x}}_i$. The transformed representation is defined as:

$${\widehat{x}}_i\triangleq \mathcal{N}\left(x_i\right)=\mathcal{S}\left(\mathcal{L}\left(x_i\right)\right),$$

(10)

where $\mathcal{L}(·)$ denotes a selective logarithmic scaling operator and $\mathcal{S}(·)$ denotes a standardisation operator. Both transformations are applied element-wise to the feature vector components.

Let $\mathbf{m}\in {\{0,1\}}^k$ denote a feature selection mask, where $m_j=1$ indicates that the j-th feature is subjected to logarithmic scaling and $m_j=0$ indicates that the feature is left unchanged. The logarithmic transformation is defined element-wise as

$${\left[\mathcal{L}\left(x_i\right)\right]}_j\triangleq m_j·log(1+{\gamma }_j{x}_{i,j})+(1-m_j)x_{i,j},$$

(11)

where ${\gamma }_j\in {\mathbb{R}}^{+}$ is a feature-specific scaling factor and $log(·)$ denotes the natural logarithm. This formulation preserves the original scale of non-selected features while ensuring that only statistically appropriate features are compressed. Feature selection for logarithmic scaling is performed offline based on statistical profiling of the training dataset.

Following logarithmic scaling, features are standardised to ensure zero mean and unit variance. For each feature component j, the standardised value is computed using z-score normalisation [53] as:

$${\left[\mathcal{S}\left(x_i\right)\right]}_j={\displaystyle \frac{x_{i,j}-{\mu }_j}{{\sigma }_j}},$$

(12)

where ${\mu }_j$ and ${\sigma }_j$ denote the mean and standard deviation of the j-th feature computed over the entire training dataset ${\mathcal{D}}_{train}$. The statistics are calculated as follows, with $|{\mathcal{D}}_{train}|$ representing the cardinality of the training set:

$${\mu }_j={\displaystyle \frac{1}{|{\mathcal{D}}_{train}|}}\sum _{x_i\in {\mathcal{D}}_{train}}{x}_{i,j},$$

(13)

$${\sigma }_j=\sqrt{{\displaystyle \frac{1}{|{\mathcal{D}}_{train}|}}\sum _{x_i\in {\mathcal{D}}_{train}}{(x_{i,j}-{\mu }_j)}^2}.$$

(14)

These statistics are fixed after training and reused during inference to ensure deterministic feature transformation. This transformation improves numerical stability and mitigates activation saturation in the neural network. The resulting feature vector ${\widehat{x}}_i$ provides a scale-invariant representation of network behaviour for subsequent temporal aggregation and trust inference. Specifically, ${\widehat{x}}_i$ serves as the row input to the windowed feature matrix ${\mathbf{X}}_t$ defined in Section 2.1.1, where ${\tilde{x}}_l\triangleq {\widehat{x}}_{t-L+l},\forall l\in \{1,\dots ,L\}$.

In practical IIoT deployments, however, traffic patterns may evolve over time due to changes in workload, device behaviour, or emerging attack strategies. This phenomenon, commonly referred to as concept drift, may gradually reduce model performance if left unaddressed. In such cases, periodic re-calibration of the normalisation statistics or incremental re-training of the model may be required. These extensions are considered outside the scope of this work and are identified as future research directions.

2.3.4. Model Architecture

IIoT network traffic exhibits strong temporal dependencies in which node behaviour evolves through ordered packet flows rather than through independent and identically distributed (i.i.d.) observations [38,45]. Thus, trust evaluation requires sequence-aware models capable of capturing both short-term feature variations and long-term behavioural drift. While architectures such as Temporal Convolutional Networks (TCNs) offer advantages in parallelism and gradient stability [54], recurrent models, particularly LSTMs, remain more common in the literature for network anomaly detection due to their explicit gating mechanisms that retain historical context across extended sequences [22]. Building on these observations, EF-TMA employs a stacked LSTM architecture to capture complex hierarchical temporal patterns in flow-level telemetry, consistent with recent advancements in the LSTM literature [55].

The forward-pass pipeline of the proposed trust inference model is illustrated in Figure 3. At each macroscopic time step t, the model receives as input a windowed feature matrix ${\mathbf{X}}_t\in {\mathbb{R}}^{m\times k}$ representing k-dimensional telemetry aggregated over a sliding temporal window of size m. The following equations describe a single forward pass at fixed t; intermediate quantities shown in Figure 3 are indexed by t, but are omitted from the equations for clarity.

Figure 3. Forward-pass pipeline of the EF-TMA AI trust model. The windowed feature matrix ${\mathbf{X}}_t\in {\mathbb{R}}^{m\times k}$ is processed through two stacked LSTM layers followed by a Multi-Layer Perceptron (MLP) head, producing the trust score $T_t\in [0,1]\subset \mathbb{R}$.

This sequence is processed by the first recurrent layer, which generates an intermediate hidden state $h_l^{\left(1\right)}\in {\mathbb{R}}^{d_h}$ at each within-window position $l\in \{1,\dots ,m\}$:

$${\left\{h_l^{\left(1\right)}\right\}}_{l=1}^m={\mathrm{LSTM}}^{\left(1\right)}\left({\mathbf{X}}_t\right).$$

(15)

To extract higher-order temporal abstractions, this intermediate sequence ${\left\{h_l^{\left(1\right)}\right\}}_{l=1}^m$ is fed into a second LSTM layer. Unlike the first layer, which returns the full sequence, the second LSTM layer is configured to output only the final hidden state $h_m^{\left(2\right)}\in {\mathbb{R}}^{d_h}$ at position $l=m$. This final state encodes the behavioural context contained within the bounded temporal window:

$$h_m^{\left(2\right)}={\mathrm{LSTM}}^{\left(2\right)}\left({\left\{h_l^{\left(1\right)}\right\}}_{l=1}^m\right).$$

(16)

The recurrent hidden and cell states are initialised independently for each inference window, and are not propagated across successive macroscopic time steps; consequently, temporal dependencies are modelled only within the bounded observation horizon defined by the sliding window length m. As such, the system relies on stateless sliding-window recurrent inference.

The temporal representation $h_m^{\left(2\right)}$ is then passed through a fully connected feed-forward MLP block for feature projection and nonlinear mapping. As denoted in Figure 3, the first linear transformation projects the hidden state into an intermediate vector $y_1$:

$$y_1=W_1{h}_m^{\left(2\right)}+b_1.$$

(17)

This is followed by a Rectified Linear Unit (ReLU) activation function to introduce nonlinearity, producing the activated vector a:

$$a=\mathrm{ReLU}\left(y_1\right).$$

(18)

A second linear layer then maps the activated features to the final output logits $y_2$:

$$y_2=W_{2}a+b_2,$$

(19)

where $W_1,W_2$ and $b_1,b_2$ represent the trainable weight matrices and bias vectors of the respective linear layers.

Finally, to generate a bounded and probabilistic trust metric, the scalar logit $y_2$ is passed through a Sigmoid activation function. The output represents the model’s predicted probability of the entity belonging to the trustworthy class in a binary classification setting (1 = trustworthy, 0 = malicious):

$$T_t=\widehat{y}=\sigma \left(y_2\right)={\displaystyle \frac{1}{1+e^{-y_2}}}.$$

(20)

Although the underlying learning task is framed as binary classification, the sigmoid output is not thresholded into a hard label at this stage; instead, the continuous probability $T_t\in [0,1]\subset \mathbb{R}$ is retained and interpreted directly as the trust score. While the sigmoid output is formally a classification probability [39,56], its interpretation as a trust score follows directly from the model input. Each inference window aggregates observed behavioural evidence, and the output quantifies its degree of conformance to the benign behavioural profile. This is consistent with the definition of trust adopted in Section 1 as a dynamic measure of confidence in the expected behaviour of an entity that is re-evaluated at each time step as new observations enter the window.

The continuous trust score $T_t$ can be equivalently decomposed into a tuple $(D_t,C_t)$ with $D_t\in \{0,1\}$ and $C_t\in [0,1]\subset \mathbb{R}$, comprising a binary trust decision and an associated confidence measure. The binary decision component $D_t$ is obtained by thresholding the trust score about the decision boundary at $0.5$:

$$D_t=\left\{\begin{array}{cc}\lceil T_t\rceil ,\hfill & T_t>0.5\left(\mathrm{trustworthy}\right)\hfill \\ \lfloor T_t\rfloor ,\hfill & T_t\le 0.5\left(\mathrm{malicious}\right).\hfill \end{array}\right.$$

(21)

Ties at $T_t=0.5$ are resolved conservatively in favour of the malicious class, reflecting the asymmetric risk profile of TMSs in which the cost of misplaced trust outweighs the cost of unwarranted distrust. The confidence component $C_t$ quantifies the strength of this decision as the normalised distance of $T_t$ from the decision boundary:

$$C_t={\displaystyle \frac{|T_t-0.5|}{0.5}}=|2T_t-1|,$$

(22)

where $C_t=0$ corresponds to maximum uncertainty ($T_t=0.5$) and $C_t=1$ corresponds to maximum confidence ($T_t\in \{0,1\}$). This decomposition allows downstream components to act on either the continuous score, the discrete decision, or a confidence-weighted combination of the two. In this way, EF-TMA is able to transform hierarchical temporal abstractions into a single quantifiable trust metric that is continuously evaluated against the determined decision thresholds defined within the policy action ${\Theta }_t$, as shown in Equation (6).

Beyond the forward-pass formulation, the behaviour of EF-TMA is shaped by a set of architectural and training hyperparameters that determine model capacity, regularisation, and convergence dynamics. These choices are summarised in Table 3, with the motivation provided in the discussion that follows.

Table 3. Architectural and training hyperparameters of the configured EF-TMA AI model.

	Hyperparameter	Value
Architecture	Input feature dimension (k)	9
	Sequence length (m)	10
	LSTM layers	2 (stacked)
	Hidden state size ($d_h$)	64
	Inter-layer dropout	0.2
	Activations	ReLU (hidden), Sigmoid (output)
Training	Optimiser	Adam
	Loss function	Binary cross-entropy with logits
	Learning rate	$1\times {10}^{-3}$
	Batch size	128
	Epochs	20
	Gradient clipping	${\parallel \nabla \parallel }_2\le 1.0$

The architectural choices in Table 3 balance representational capacity against the latency and memory constraints established in Section 2.1. A sequence length of $m=10$ aligns with the per-attack aggregation window adopted in the CIC-IoT-2023 evaluation methodology [46], providing sufficient temporal context to capture burst dynamics characteristic of flood-based attacks while keeping the per-inference cost bounded. A hidden state size of $d_h=64$ was selected as the smallest power-of-two value that preserved discriminative performance across a held-out validation split, avoiding the diminishing returns and increased memory footprint of larger configurations. An inter-layer dropout was applied between LSTM layers for regularisation.

Training employed the Adam optimiser with binary cross-entropy loss, which is well-suited to the bounded sigmoid output and provides stable convergence under class-balanced sampling. Gradient clipping at ${\parallel \nabla \parallel }_2\le 1.0$ mitigates the exploding-gradient behaviour known to affect recurrent architectures during the early stages of training. The remaining training hyperparameters were selected through standard practice and empirically confirmed to yield convergence within 20 epochs without overfitting.

The model was trained offline on the curated dataset and subsequently deployed to Fog nodes in inference mode, with model parameters and normalisation statistics held fixed at deployment time. The resulting parameter footprint and dimensions are summarised in Table 4.

Table 4. Layer dimensions and parameter counts for the configured EF-TMA AI model. LSTM parameter counts follow PyTorch’s convention of two bias vectors per gate.

Layer	Input Dimension	Output Dimension	Activation	Parameters
LSTM 1	$10\times 9$	$10\times 64$	–	19,200
LSTM 2	$10\times 64$	64	–	33,280
Linear 1	64	32	ReLU	2080
Linear 2	32	1	Sigmoid	33
Total				54,593

With 54,593 trainable parameters stored at single-precision (32-bit floating-point), the expected parameter storage footprint ($S_{\mathrm{params}}$) is given by:

$$S_{\mathrm{params}}=\mathrm{54,593}\times 4\mathrm{B}=\mathrm{218,372}\mathrm{B}\approx 218\mathrm{kB}.$$

(23)

This footprint fits comfortably within the typical memory budget of industrial Fog nodes while retaining the representational capacity required for behavioural trust inference.

2.3.5. Complexity Discussion

In industrial contexts, Fog nodes hosting the TME must ensure that computational overhead does not scale with traffic volume or node density, as this allows for predictable performance as the network grows. EF-TMA enforces a fixed per-inference cost within the TME, yielding a deterministic service rate. By coupling this fixed service rate with bounded queuing and finite caching capacities, the maximum computational backlog of the node is structurally capped. Together, these constraints ensure bounded end-to-end timing and memory behaviour across the system, which would be difficult to recover if introduced downstream of an unbounded inference stage.

The time complexity of a single trust inference is governed by the forward pass of the underlying LSTM network. At each timestep, the LSTM computes four gating operations (input, forget, output, and candidate cell state), each involving an input-to-hidden projection of complexity $O(d_h·k)$ and a hidden-to-hidden projection of complexity $O\left(d_h^2\right)$, where k is the per-timestep input dimension and $d_h$ is the hidden state size. Consequently, the computational cost per time step is $O(d_h^2+d_h·k)$.

This formulation is consistent with established analyses of LSTM computational complexity, which show that the per-timestep cost scales proportionally with the number of model parameters [56]. For a sliding input window of length m, the total per-inference complexity $T_{\inf }$ becomes:

$$\begin{array}{cc}\hfill T_{\inf }& =O\left(m·(d_h^2+d_h·k)\right).\hfill \end{array}$$

(24a)

Since the hyperparameters m, $d_h$, and k are fixed in EF-TMA, the per-inference computational time remains constant with respect to network scale N:

$$\begin{array}{cc}\hfill T_{\inf }& =O\left(1\right).\hfill \end{array}$$

(24b)

Inference is performed over fixed-size sliding windows without preserving hidden states across windows in order to remove temporal state dependence and avoid unbounded accumulation of historical information. This stateless formulation bounds the effective computational context and enforces a fixed-cost execution model. Consequently, this enables predictable end-to-end timing behaviour in latency-sensitive Industrial Control Systems (ICSs).

The memory footprint of the TME comprises model parameters and runtime state. The LSTM parameter memory footprint $S_{\mathrm{LSTM}}$ corresponds to the total number of learned weights and biases across all gates [56], and is characterised by:

$$\begin{array}{cc}\hfill S_{\mathrm{LSTM}}& =O\left(d_h^2+d_h·k\right).\hfill \end{array}$$

(25a)

Since $d_h$ and k are fixed after training, the model parameter memory remains constant with respect to network scale N:

$$\begin{array}{cc}\hfill S_{\mathrm{LSTM}}& =O\left(1\right).\hfill \end{array}$$

(25b)

Runtime memory is dominated by the TrustProvider cache, which maintains per-flow metadata. In an unconstrained setting, this would scale linearly as $O\left(N\right)$ with the number of active entities. Since inference contributes only constant memory overhead, runtime behaviour is dominated by cache growth. EF-TMA applies a fixed-capacity Least Recently Used (LRU) eviction policy, limiting the effective cache memory footprint ($S_{\mathrm{cache}}$) to $O\left(\kappa \right)$, where $\kappa$ is a predefined capacity independent of N. With $S_{\mathrm{cache}}$, $S_{\mathrm{LSTM}}$, and other runtime components explicitly bounded, the total TME memory footprint ($S_{\mathrm{total}}$) is evaluated as $O\left(1\right)$ with respect to the network scale N.

3. Evaluation Methodology

To evaluate EF-TMA, a three-tier evaluation strategy is adopted that mirrors the architectural decomposition of the system, as illustrated in Figure 4.

Figure 4. Three-tier evaluation strategy for EF-TMA: the deep learning model is evaluated in isolation, the Fog TMS pipeline is evaluated under integration with the simulation runtime, and the full Edge-Fog network behaviour is exercised under benign and adversarial traffic scenarios.

The strategy proceeds from the innermost component outward: (i) AI model performance is characterised in isolation to establish its intrinsic discriminative capability; (ii) architectural performance quantifies the latency and resource behaviour of the deployed inference pipeline under integration with the simulation runtime; and (iii) full-system evaluation exercises the complete TMS under benign and adversarial Edge-Fog network traffic, incorporating the threat model defined in Section 2.2. The methodology and relevant metrics for each tier are described in the following subsections, with results presented in Section 4.

3.1. AI Evaluation Methodology

3.1.1. Implementation and Tooling

The trust classifier is implemented in PyTorch (v2.10) and trained as defined in Section 2.3. Training is conducted on the host system detailed in Section 3.2.1, leveraging an Nvidia RTX 5070 GPU for accelerated training. Inference is executed exclusively on CPU for both evaluation and deployment, reflecting typical resource constraints of Fog-tier hardware.

To enable integration with the C++-based ns-3 simulation environment, the trained PyTorch model is exported to the ONNX format. ONNX provides a runtime-portable representation loaded directly by the simulation pipeline through the ONNX Runtime C++ Application Programming Interface (API). This avoids inter-process boundaries between the simulator and the inference engine. In addition to enabling portability, the ONNX export introduces graph-level optimisations such as operator fusion and constant folding during model conversion and runtime execution. Both the native PyTorch model and the exported ONNX model are evaluated for inference latency and on-disk size, with the comparison reported in Section 4; the ONNX artifact is used for all subsequent architectural and integrated evaluations.

The classification metrics defined in Section 3.1.2 are computed on a held-out test set disjoint from the training and validation data using scikit-learn (v1.8). This separation of training, validation, and evaluation data ensures that reported metrics reflect the model’s generalisation performance rather than memorisation of training samples.

3.1.2. Evaluation Criteria

To evaluate the predictive capability of the trust model, standard classification metrics are used, including Accuracy, Precision, Recall, and F1-score. Let $TP$, $TN$, $FP$, and $FN$ denote true positives, true negatives, false positives, and false negatives, respectively. Although the trust score $T_t$ naturally places the benign (trustworthy) class as positive, evaluation metrics follow the standard IDS and anomaly detection convention in which the malicious class is treated as the positive class. Therefore, detection is framed in terms of $1-T_t$, ensuring comparability with related literature, where a low $T_t$ corresponds to a positive (malicious) detection.

Accuracy quantifies the overall proportion of correctly classified samples and provides a coarse summary of model performance, but can be misleading under class imbalance because a model predicting only the majority class may achieve high accuracy without discriminating between classes:

$$\mathrm{Accuracy}={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}.$$

(26)

Precision quantifies the reliability of positive classifications, expressing the fraction of samples flagged as malicious that are truly malicious. Recall quantifies coverage of the malicious class, expressing the fraction of true malicious samples that are successfully identified. These two metrics capture distinct error modes: low precision indicates a high rate of FP predictions, resulting in unnecessary enforcement actions, whereas low recall indicates missed attacks. Separately, the False Positive Rate (FPR) captures the fraction of benign samples incorrectly flagged as malicious, and is characterised through ROC-AUC analysis.

$$\mathrm{Precision}={\displaystyle \frac{TP}{TP+FP}}$$

(27)

$$\mathrm{Recall}={\displaystyle \frac{TP}{TP+FN}}$$

(28)

$$\mathrm{FPR}={\displaystyle \frac{FP}{FP+TN}}$$

(29)

F1-score is the harmonic mean of precision and recall, balancing both error modes in a single scalar. The harmonic mean penalises imbalance between the two quantities; thus, a high F1-score requires both precision and recall to be high simultaneously.

$$\mathrm{F}1‐\mathrm{score}=2·{\displaystyle \frac{\mathrm{Precision}·\mathrm{Recall}}{\mathrm{Precision}+\mathrm{Recall}}}$$

(30)

Detection performance is further evaluated using threshold-independent metrics, namely, the Receiver Operating Characteristic Area Under Curve (ROC-AUC) and the Precision-Recall Area Under Curve (PR-AUC). ROC-AUC summarises the trade-off between recall/True Positive Rate (TPR) and FPR across all classification thresholds, where a value of $1.0$ indicates perfect separation and $0.5$ corresponds to random classification. PR-AUC summarises the trade-off between precision and recall under the same threshold sweep, and is particularly informative for imbalanced datasets in which negative samples dominate, as is typical in network intrusion detection.

3.1.3. Methodological Approach

The trust model is evaluated through an offline pipeline that isolates predictive performance from the architectural and integration overheads characterised in Section 3.2. This separation ensures that classification metrics reflect the intrinsic discriminative capability of the model $\mathcal{M}(·)$ defined in Section 2.3 independent of simulation-induced variability such as channel fading or queueing effects.

Evaluation is conducted on a held-out test partition disjoint from the training data, as discussed in Section 2.3.1. Partitioning is performed at the source-file level rather than at the record level, as record-level random splitting would induce optimistic bias through sequence leakage. The normalisation statistics $({\mu }_j,{\sigma }_j)$ fitted during training persist and are reused without modification in order to transform the test partition, ensuring that no information from the test set influences the feature representation.

In contrast to the training partition, the test partition retains its natural class distribution. The balanced sampling applied during training serves the optimisation objective and is not appropriate for evaluation, as it would obscure the model’s behaviour under deployment-realistic class proportions. Therefore, the reported metrics characterise generalisation under the empirical imbalance of CIC-IoT-2023 rather than under artificially symmetric conditions.

At evaluation time, the trained model is placed in inference mode with gradient tracking disabled; inference is executed on CPU in order to reflect Fog-tier deployment conditions rather than the GPU-accelerated environment used during training. Each test-set window is forward-propagated to produce a scalar logit, which is mapped to a continuous trust score $T_t\in [0,1]$ via the sigmoid activation in Equation (20).

The classification metrics defined in Section 3.1.2 are computed over the full set of test windows, and fall into two groups. Threshold-dependent metrics (Accuracy, Precision, Recall, and F1-score) are evaluated at the fixed decision boundary of $T_t=0.5$, consistent with the trust decomposition defined in Equations (21) and (22). Threshold-independent metrics (ROC-AUC and PR-AUC) are computed as the area under the ROC and Precision–Recall curves traced out as the decision threshold is swept across the range of trust scores, characterising classifier behaviour across the full range of operating points.

3.2. Architectural Evaluation Methodology

3.2.1. Simulation Environment

All architectural and full-system experiments were conducted using ns-3 (v3.46.1). As a discrete-event network simulator, ns-3 models communication behaviour, protocol dynamics, and traffic characteristics, with any device-level resource constraints abstracted away. This enables evaluation of the TMS within a networked environment where traffic is transmitted through a network stack rather than being replayed from static dataset records.

Experiments were conducted on a host system equipped with an AMD Ryzen 7-9700X CPU, Nvidia RTX 5070 GPU, and 32 GB DDR5-7200 MHz RAM. The simulation environment was deployed on Ubuntu 24.04 LTS, virtualized via VMware Workstation 25.0.1 on a Windows 11 host. Inference was configured for CPU-only execution, consistent with a Fog-tier deployment model. To minimise I/O-induced latency during packet tracing, all simulation data were processed on a WD SN850X PCIe Gen-4 NVMe SSD.

3.2.2. Evaluation Criteria

The architecture’s system-level performance is characterised by four metrics: inference latency, enforcement latency, detection latency, and model size.

Inference latency (${\tau }_{\inf }$) is measured as the elapsed time for a single forward pass of the trained model, defined in Section 2.1.2.

End-to-end enforcement latency ($\delta$), defined in (7), captures the total delay between packet observation and policy enforcement.

Detection latency (${\tau }_{\det }$), defined in (8), measures the delay between attack onset and model identification.

Model size ($S_{\mathrm{mod}}$) is defined as the storage footprint of the deployed inference model, and is reported as the on-disk size of the deployed inference artifact in bytes.

3.2.3. Methodological Approach

Architectural metrics are measured through instrumentation of the ONNX-based inference pipeline integrated into the ns-3 simulation environment. Inference latency is measured per forward pass using the ONNX Runtime’s built-in timing API and reported as the mean across 100 inference cycles; enforcement and detection latencies are measured via instrumented timestamps within ns-3. Scalability behaviour is evaluated by varying the number of simulated Edge nodes from 1 to 200 under a fixed benign traffic profile, with each configuration averaged across 3 runs to mitigate sampling variance.

3.3. Full-System Evaluation Methodology

3.3.1. Simulation Parameters

IIoT traffic in the simulation environment is produced by parameterised stochastic generators with distributions calibrated against the CIC-IoT-2023 dataset. Rather than replaying dataset traces directly, which constrains evaluation to fixed packet sequences and limits scenario flexibility, or alternatively using purely synthetic models such as ns-3’s OnOffApplication which abstract away feature realism, the proposed generators preserve the empirical distributional properties of dataset traffic while allowing controlled scenario composition.

Benign traffic is generated by the BenignApp module, which models per-flow packet arrivals as a bounded exponential process with per-flow rate parameters drawn from the inter-quartile range of the benign IAT distribution in CIC-IoT-2023. Packet sizes follow a bimodal distribution capturing the dataset’s characteristic split between small control packets and larger data payloads, and Time-To-Live (TTL) values are assigned in proportion to the dataset’s empirical TTL histogram. A periodic rate-drift mechanism is applied to model the slow variation in sensor reporting intervals observed in real IIoT deployments.

Adversarial traffic is generated by the MaliciousApp module, which supports attack-specific traffic profiles calibrated against the corresponding labelled subset of CIC-IoT-2023. The DoS profile produces fixed-size packets at deterministic inter-arrival times to model volumetric flooding behaviour, while the Mirai profile implements the attack_udp_plain payload pattern with stochastic inter-arrival times drawn from a log-normal distribution and packet sizes drawn from a Gaussian distribution. Both profiles are constrained to clamped ranges reflecting the dataset’s observed minimum and maximum values in order to prevent unphysical excursions during stochastic sampling.

Specific parameter values for both generators are listed in Table 5.

Table 5. Simulation parameters for traffic generation (calibrated from subsampled CIC-IoT-2023 dataset).

Component	Parameter	Value	Source
BenignApp	IAT distribution	Exponential	Coefficient of variation
	IAT mean (per flow)	$[2.16,12.79]$ ms	P25–P75
	IAT clamp	$[0.05,3.0]\times \mu$	Per-flow bounds
	Packet size (small)	$[66,156]$ B	Empirical
	Packet size (large)	$[201,2111]$ B	Empirical
	TTL weights (64/128/255)	$52/38/10\%$	Empirical
MaliciousApp	DoS packet size	60 B	Min. UDP datagram
	DoS IAT	50 $\mathrm{\mu }\mathrm{s}$	Fixed
	Mirai IAT distribution	Log-normal	KS best fit
	Mirai IAT parameters	$\mu =ln\left(216\mathrm{\mu }\mathrm{s}\right),\sigma =0.812$	Empirical
	Mirai IAT clamp	$[10,1000]$$\mathrm{\mu }\mathrm{s}$	Dataset bounds
	Mirai size distribution	Gaussian	KS best fit
	Mirai size parameters	$\mu$ = $547,{\sigma }^2$ = 1200	Empirical
	Mirai size clamp	$[60,1750]$ B	Dataset bounds
Channel	Propagation model	Nakagami-m ($m=1$)	Worst-case NLoS
	Error rate model	YansErrorRateModel (AWGN-based)	ns-3 PHY abstraction
	Mobility model	Constant position	Static IIoT

Additive White Gaussian Noise (AWGN); Non-Line-of-Sight (NLoS).

To emulate realistic wireless channel conditions, the Nakagami-m propagation model is adopted. Setting $m=1$ reduces the model to Rayleigh fading, representing a worst-case NLoS environment with stochastic packet loss and signal fluctuations. This configuration provides a rigorous test for distinguishing environmental degradation from malicious activity, ensuring that the TMEs response to adversarial traffic cannot be trivially attributed to ideal-channel assumptions.

The baseline scenario uses static nodes with a constant position mobility model, isolating the TMEs behavioural response to traffic-level variation rather than to mobility-induced channel dynamics.

3.3.2. Threat Scenarios

The integrated evaluation of EF-TMA comprises three controlled network scenarios implemented within the ns-3 simulation environment, corresponding to the threat model defined in Section 2. Because the predictive performance of the underlying classifier is characterised independently in Section 4.1, these scenarios are not used to re-assess standalone classification accuracy; instead, their role is to evaluate the integrated behaviour of the EF-TMA pipeline under the simulated network environment, including feature extraction, inference, and enforcement. The three scenarios considered are as follows:

1.

Benign baseline: Calibrated IIoT traffic with no adversarial activity, used to characterise nominal TME behaviour and establish a reference for false-positive analysis.

2.

DoS (UDP Flood): A single source emits a high-rate and fixed-size UDP flood representative of a saturation attack against the fog node. This scenario tests the TMEs response to traffic that lies far outside the benign feature distribution.

3.

Mirai (UDP Plain): A single compromised source emits attack-phase Mirai traffic, representing a botnet member acting under command and control instruction. This scenario tests the TMEs response to a feature-mimicking adversary with per-packet characteristics that overlap substantially with the benign distribution.

The two adversarial scenarios are deliberately constrained to UDP-based attack variants. The Mirai payload contains no TCP-based component within the CIC-IoT-2023 dataset, and the corresponding DoS variant (UDP Flood) is selected to match this protocol profile. Holding the transport protocol constant across both adversarial scenarios isolates the discriminative effect of attack character (that is, volumetric saturation versus mimicry) from that of attack protocol. This ensures that any observed difference in detection performance reflects TMEs sensitivity to feature distribution rather than to protocol-level artifacts.

Although DDoS traffic is included in the CIC-IoT-2023 dataset and evaluated during the offline AI model assessment in Section 3.1, it is not simulated as a distinct full-system scenario. The TME operates solely on traffic observed by its local Fog node; therefore, it cannot infer whether anomalous traffic forms part of a coordinated distributed attack. Detection of coordinated DDoS campaigns requires cross-node correlation of trust signals, which falls within the responsibility of the Fog Orchestrator rather than the TME. As the Fog Orchestrator lies outside the system boundary evaluated in this work, orchestrator-level DDoS correlation is beyond the scope of this evaluation and is left as future work.

Each adversarial scenario follows a three-phase temporal structure consisting of a 10-s benign baseline phase, a 10-s attack phase, and a 10-s post-attack recovery phase, with the same source emitting calibrated benign traffic in the flanking phases. This structure isolates the TMEs response to a controlled regime change in feature space without confounding factors such as source-address variation or topology change, and enables direct comparison of detection latency, sustained classification, and recovery behaviour across attack types.

4. Performance Evaluation

This section presents the results of the three-tier evaluation strategy defined in Section 3, beginning with the AI model in isolation, proceeding to the deployed architectural pipeline, and concluding with the full system under simulated network scenarios.

4.1. AI Model Evaluation

Table 6 positions EF-TMA within the operational performance range of representative trust-based decision models for IoT security reported in the literature.

Table 6. Performance comparison of the EF-TMA AI model against representative baseline models.

Reference	F1	Accuracy	Precision	Recall	ROC-AUC	PR-AUC
[26]	0.995	0.998	1.000	0.990	–	–
[33]	0.904	0.962	0.910	0.890	0.930	–
[35]	0.95	0.95	0.94	0.96	–	–
[31] †	0.89	0.92	–	–	–	–
[34] ★	0.9896	0.9901	0.9898	0.9901	–	–
[39] ★†	0.9859	0.9875	0.9866	0.9875	–	–
[40] ★	0.99442	0.99997	0.99058	0.99828	–	–
EF-TMA ★†	0.9996	0.9997	0.9953	0.9964	0.9999	0.9997

^★ Evaluated on CIC-IoT-2023 dataset; ^† Model employing an LSTM-based architecture.

The proposed model demonstrates strong discriminative capability across the benign and attack scenarios outlined in Section 2.2.1, achieving an F1-score of 0.9996, accuracy of 0.9997, and ROC-AUC of 0.9999. The model additionally reports PR-AUC, which is rarely provided in prior work but is particularly informative under the class imbalance characteristic of IIoT traffic.

To support meaningful interpretation, particular attention is given to studies evaluated on the CIC-IoT-2023 dataset, as these share a common source distribution and attack taxonomy. Additional consideration is given to studies employing LSTM-based architectures, as they belong to the same model family. Entries satisfying one or both of these criteria are denoted in Table 6, with studies satisfying both criteria providing the closest available basis for comparison. Full reproducibility across all entries remains a direction for future study, as reported implementations using like-model families [31,39] specify base architecture and training hyperparameters but omit sufficient detail for reconstruction.

While different studies have variations in model design, attack modelling, and data preparation, the objective here is to show that EF-TMA performs consistently with established approaches. The metrics in Table 6 supports this position, since EF-TMA’s classification performance falls within or above the ranges reported by comparable approaches across standard binary classification metrics, with its uniform performance across all reported measures supporting the robustness of the underlying classification behaviour.

4.2. Architecture Evaluation

In addition to AI model evaluation, it is important to evaluate the computational and system-level performance of the deployed inference pipeline within the EF-TMA architectural framework, including inference execution, detection responsiveness, and enforcement delay. The execution characteristics of the native PyTorch and optimised ONNX runtime models are evaluated in this section along with end-to-end pipeline latency metrics, using benign traffic. ONNX was used both as an optimisation mechanism to reduce inference latency for real-time deployment and as an interoperable model representation enabling portability across runtimes and platforms, as described in Section 3.1.1.

The ONNX model achieves a 6.49× reduction in inference latency (0.318 ms to 0.049 ms), demonstrating the effectiveness of runtime optimisation for real-time deployment. This improvement comes at the cost of a 1.39× increase in on-disk model size (218 kB to 302 kB, inclusive of ONNX opset metadata). The measured PyTorch model size of 218 kB is consistent with the theoretical parameter storage footprint $S_{\mathrm{params}}$ given in Equation (23), confirming the analytical estimate of model storage requirements prior to deployment. The deployment model remains within the sub-megabyte range typical of edge-deployable models [57]. The model retains its compact parameter footprint of 54,593  trainable parameters, as established in Section 2.3.4.

Using the ONNX model, detection latency (${\tau }_{\det }$) and enforcement latency ($\delta$) as defined in Section 3 are measured as 0.081 ms and 0.120 ms, respectively. Although the additional processing stages introduce measurable overhead relative to model inference, the total system latency remains below 0.2 ms, supporting near-real-time operation. While EF-TMA targets Fog-tier rather than microcontroller-class hardware, this latency profile is consistent with the operational ranges documented for lightweight on-device ML and TinyML deployments (0.18–300 ms) [57]. Inference latency in particular falls below the lower end of this range, supporting the practical feasibility of fog-resident trust evaluation.

The hardware profile used in this evaluation is representative of an upper-tier Fog node rather than a resource-constrained edge device. The relative performance relationships characterised here, such as the PyTorch versus ONNX latency reduction and the inference-to-enforcement overhead ratio, are expected to remain consistent across hardware tiers. Profiling on lower-end Fog hardware such as single-board computers is identified as a direction for future work. Such evaluation is more appropriately conducted within a physical deployment study, as simulation overheads would confound hardware-level latency measurements.

To validate that system-level performance remains stable under scaling conditions, an examination of latency behaviour as node count increases is performed, as illustrated in Figure 5. The experiment deliberately omits explicit queuing, buffering, dispatch, and caching mechanisms in order to isolate the TME inference component.

Figure 5. Latency metrics with increasing number of nodes (up to 200 nodes).

Inference latency remains approximately constant across the tested range, with a maximum deviation of 0.03 ms, confirming that inference latency is successfully bounded and consistent with the theoretical constant-time complexity $O\left(1\right)$ established in Equation (24b). In contrast, enforcement latency, defined in Equation (7), increases with node count, indicating that scaling overhead is successfully shifted to surrounding system components (e.g.  queuing, dispatch, and caching). These effects can be mitigated using established optimisation techniques in future work.

4.3. Full-System Evaluation

The full-system evaluation investigates the system performance under full network simulation, including both benign and adversarial traffic scenarios. The evaluation proceeds from the benign baseline scenario, which characterises nominal TME behaviour and establishes a false-positive reference, to the two adversarial scenarios that probe response to volumetric and mimicry-based attacks, respectively.

4.3.1. Benign Traffic

To establish a behavioural baseline for the TME, the system was evaluated under a 30-second simulation containing exclusively benign IoT traffic generated by the calibrated BenignApp model (Table 5). This configuration serves as the reference scenario for subsequent adversarial evaluations. As illustrated in Figure 6, the trust score remains predominantly above the threshold $\alpha =0.5$. This confirms that the TME correctly classifies legitimate traffic as benign throughout the evaluation window, with no sustained periods of misclassification.

Figure 6. Trust score evolution over a 30-second benign-only simulation.

Two isolated transient dips are observed, briefly crossing the threshold at approximately $t\approx 1$ s and $t\approx 17$ s, reaching minima of $0.35$ and $0.31$, respectively. These events are tightly confined to single inference windows, with immediate recovery to the high-trust regime. These deviations are attributed to stochastic variability in the benign traffic generator and the inherent sensitivity of window-based aggregation near the decision boundary. Specifically, short-term fluctuations in flow composition yield feature vectors that temporarily approach the decision boundary, producing isolated sub-threshold outputs.

The scores in Figure 6 correspond to raw per-window inference outputs without temporal postprocessing. Reporting these raw outputs exposes the intrinsic classification variance under realistic traffic conditions. In practical deployments, applying a temporal smoothing mechanism such as an adaptive exponential moving average would reduce sensitivity to single-window fluctuations. This introduces a configurable trade-off between detection responsiveness and suppression of false positives that is tailored to the target environment’s operational requirements.

Quantitatively, the TME achieves a FPR of 0.07% across the evaluation window, with a mean trust score of 0.9973 and a standard deviation of 0.0287 over 3069 samples. In accordance with the criteria defined in Section 3.1.2, this high mean trust and sparsity of deviations confirm a stable classification baseline. Minimising this FPR establishes a high precision ceiling and ensures optimal ROC-AUC performance. Crucially, because false positives translate directly to unwarranted enforcement actions, this 0.07% rate guarantees minimal disruption to the legitimate ICL. These results validate the calibration of both the benign traffic model and the decision threshold as stable baselines.

4.3.2. DoS/DDoS Traffic

Following the three-phase structure described in Section 3.3.2, the volumetric DoS scenario uses an attacking node configured per Table 5 (UDP Flood profile). Figure 7 presents the trust score trajectory across the full simulation window. During the benign baseline phase, the TME behaves consistently with the benign reference scenario (Figure 6), classifying traffic as trusted with only sporadic single-window fluctuations.

Figure 7. Trust score evolution under a three-phase DoS scenario: benign baseline ($t\in [0,10]\mathrm{s}$), UDP DoS flood attack ($t\in [10,20]\mathrm{s}$), and post-attack recovery ($t\in [20,30]\mathrm{s}$).

At attack onset ($t=10$ s), the trust score collapses to zero within a single inference window and remains saturated at the lower bound of the trust range for the attack duration. The immediacy and persistence of this response are consistent with the feature distribution of the simulated UDP flood, which exhibits a highly distinct signature relative to benign traffic. As configured in Table 5, the UDP flood generates fixed packet sizes and minimised IATs. In the model’s input space, this manifests as a near-zero variance and out-of-distribution feature vector, driving the immediate saturation of the classifier. This separability indicates that volumetric attacks occupy a distinct region of the aggregated feature space, resulting in consistent classification under the current decision boundary.

Post-attack ($t=20\mathrm{s}$), the trust score quickly recovers to the high-trust profile. The isolated sub-threshold fluctuations observed in the post-attack phase mirror stochastic variations arising from feature-level jitter in the benign traffic generator and transient queueing effects in the network simulation rather than from persistent phase-transition artifacts. These effects are consistent with the small FPR observed in the benign-only scenario, and do not indicate persistent misclassification.

The system achieves a recall of 0.99999 (two missed detections out of 199,977 attack-phase observations) and an FPR of 0.00186. Precision is 0.99998, yielding an F1-score of 0.99999 across 201,131 flow-level observations. Combined with a detection latency of ${\tau }_{\det }=0.22\mathrm{ms}$, these results confirm that the EF-TMA pipeline provides both reliable and low-latency detection of volumetric UDP flood attacks.

4.3.3. Mirai Botnet Traffic

To evaluate detection performance against a feature-mimicking adversary, a Mirai UDP Plain attack scenario was simulated using the same three-phase structure as the DoS evaluation. The Mirai UDP Plain generator produces traffic with payload sizes and transmission rates that lie within the support of the benign distribution. The generator parameters are listed in Table 5.

Figure 8 presents the trust score trajectory across the simulation window. The benign baseline phase behaves consistently with previous scenarios, maintaining a near-unity trust score with only minor stochastic fluctuations. Upon attack onset at $t=10$ s, the trust score collapses abruptly and remains persistently suppressed below the threshold $\alpha =0.5$ for the duration of the attack phase, closely mirroring the response observed under the volumetric DoS scenario.

Figure 8. Trust score evolution under a three-phase Mirai UDP Plain scenario: benign baseline ($t\in [0,10]\mathrm{s}$), Mirai attack ($t\in [10,20]\mathrm{s}$), and post-attack recovery ($t\in [20,30]\mathrm{s}$).

This sustained suppression is primarily attributable to systematic deviations in packet header characteristics that persist across inference windows despite Mirai UDP Plain’s feature-mimicry design. Although the generator preserves benign-like payload sizes and transmission rates, the aggregated flow-level representation captures consistent anomalies in header size distributions and TTL values relative to the benign baseline. Inspection of the Mirai UDP Plain samples within the training dataset reveals that TTL values exhibit minimal variance, in contrast to the diverse TTL distribution present in the benign traffic class. Similarly, header size characteristics of the Mirai-labelled flows deviate measurably from those of legitimate IIoT benign traffic within the dataset. These header-layer features provide a stable discriminative signal that the classifier reliably exploits across successive windows, yielding the persistent low-trust response observed in Figure 8.

Following attack cessation at $t=20$ s, the system exhibits an immediate and clean recovery to the high-trust baseline. The brief fluctuations throughout the evaluation are attributable to a stochastic perturbation in the traffic generators, and are identical in nature to those observed in the previous scenarios (Figure 6 and Figure 7). This confirms that the TME achieves a memoryless state transition upon anomaly cessation and avoids penalising the node during recovery.

These results demonstrate that EF-TMA achieves robust detection of Mirai UDP Plain despite its feature-mimicry design, with the trust score remaining persistently suppressed throughout the attack phase. Detection is driven not by rate elevation but by systematic header-layer anomalies, principally header size and TTL distributions, that the flow-level aggregation pipeline captures consistently across windows. Nevertheless, the model’s sensitivity to TTL and other header values highlights a residual vulnerability of purely per-window statistical aggregation to high-fidelity mimicry attacks that more carefully randomise header-layer characteristics. This motivates future investigation into complementary detection mechanisms such as graph-based or cross-flow representations that exploit broader temporal and structural correlations to further harden the system against evolving adversarial profiles.

The system achieves a recall of 0.999967 (one missed detection out of 30,686 attack-phase flow-level observations) and an FPR of 0.00000, with zero false positives recorded across 1671 benign observations. Precision is 1.000000, yielding an F1-score of 0.999984 across 32,357 total flow-level observations. These results confirm that EF-TMA achieves robust detection of Mirai UDP Plain despite its feature-mimicry design, with detection driven not by rate elevation but by systematic header-layer anomalies, principally header size and TTL distributions, that the flow-level aggregation pipeline captures consistently across windows. Nevertheless, the model’s sensitivity to TTL and header characteristics highlights a residual vulnerability of purely per-window statistical aggregation to mimicry attacks and heterogeneous traffic profiles that may randomise header-layer features. This motivates future investigation into complementary detection mechanisms such as graph-based or cross-flow representations that exploit broader temporal and structural correlations, which could further harden the system against evolving adversarial profiles.

5. Conclusions

The proliferation of DL-based TMSs in IIoT has highlighted a persistent tension between detection fidelity and practical deployment feasibility. Resource constraints and latency requirements inherent to EFC architectures render direct Edge deployment of DL inference infeasible, while Cloud-based alternatives introduce stochastic latency incompatible with the deterministic timing demands of ICLs. Existing solutions have predominantly focused on model design in isolation, leaving Fog-native end-to-end deployment insufficiently explored. To address this, EF-TMA is proposed as a Fog-centric trust evaluation framework in which a lightweight stacked LSTM model derives continuous trust scores from header-derived, flow-aggregated features via stateless sliding-window inference.

Offline evaluation on the CIC-IoT-2023 benchmark demonstrated strong discriminative capability (F1-score 0.9996, accuracy 0.9997, ROC-AUC 0.9999, and PR-AUC 0.9997) under realistic class imbalance conditions. Architectural evaluation of the deployed ONNX-optimised model confirmed a mean inference latency of 0.049 ms and a maximum end-to-end enforcement latency of 0.120 ms, with inference cost scaling as $O\left(1\right)$ across 1 to 200 simulated Edge nodes. The model remained within the sub-megabyte (302 kB) memory budgets typical of industrial Fog nodes. Full-system ns-3 simulation confirmed robust detection under both threat profiles: DoS UDP flood (recall 0.99999, FPR 0.00186) and Mirai UDP Plain (recall 0.999967, FPR 0), with benign traffic achieving an FPR of 0.07% and a maximum detection latency of 0.22 ms.

Several limitations of the current work warrant acknowledgment. Detection efficacy is conditioned on the presence of consistent anomalous structure within the aggregated feature window. While both evaluated attack profiles exhibit such structure (through out-of-distribution volumetric features or persistent header-layer deviations, respectively), an adversary that adapts header characteristics to match the benign distribution would reduce the discriminative margin available to per-window inference. At the architectural level, individual Fog nodes observe only their local subnet and lack global visibility into coordinated distributed attacks; interactions between Fog nodes and the Fog Orchestrator, including orchestrator-level latency and cross-node policy aggregation, are outside the scope of this work. Additionally, the simulation was conducted on upper-tier Fog hardware; profiling on resource-constrained devices has not been conducted.

Future work will first focus on profiling EF-TMA on resource-constrained Fog hardware within a physical deployment study. Broader directions include prototyping EF-TMA in VIoT environments, expanding the threat model to incorporate adaptive adversarial behaviours, and evaluating robustness under broader real-world traffic distributions. Complementary detection mechanisms such as graph-based or cross-flow representations represent a promising avenue for improving resilience against header-adaptive threats. Further extensions include federated learning, stratified subclass rebalancing, enhanced hyperparameter tuning, formal security analysis, and strengthening orchestrator-level cross-node correlation for coordinated attack detection.