Federated Learning-Based Intrusion Detection System for Edge-Enabled IoT

The rapid growth of the Internet of Things (IoT) has connected billions of devices, from simple home sensors to complex industrial control units [1]. This large number of devices and connections widens the attack surface available to adversaries [2]. Robust intrusion detection systems (IDS) are therefore essential for protecting digital infrastructure, particularly in environments that handle sensitive data such as the financial and military sectors. Most deployed security systems rely on centralized architectures in which data are sent from every connected device to a data center for processing, analysis, and modelling [3]. Such architectures raise connectivity costs, consume backbone bandwidth, and increase concerns about data privacy [4].

To address these challenges, federated learning (FL) has emerged [5]. FL allows multiple clients to train a shared model locally on their own data without transferring that data to a central server [6]. The most widely used FL algorithm is federated averaging (FedAvg), in which the global parameters are obtained by aggregating the locally updated weights [7]. Keeping raw records on the device removes the need to transmit them and therefore reduces their exposure in transit, but it does not by itself provide a formal privacy guarantee; the threat model assumed in this work is stated explicitly in Section 3.8. FL also introduces its own difficulties, including the volume of communication required between the central server and thousands of connected devices, and limited flexibility in adapting to threats that appear at an individual node [8].

Deep learning models also require large datasets to track dynamic changes in traffic patterns [9]. When those data are divided into small per-client shards, such models may generalize poorly [10]. It is therefore necessary to develop a system that can operate under small-sample conditions while keeping raw records on the device.

This paper proposes HFed-IDS, a hierarchical federated intrusion detection system for edge-enabled IoT. Inserting edge aggregators between the IoT devices and the central server reduces the number of model exchanges that traverse the backbone link, while a post-aggregation few-shot fine-tuning stage adapts the converged global model at the device level using a small labelled support set. It should be stated at the outset that this adaptation stage is ordinary supervised fine-tuning: no distribution over tasks is sampled, no episodes are constructed, and no outer-loop objective is optimized. The method is therefore not meta-learning in the sense of Finn et al. [11], and the name used in the previous version of this manuscript, FFS-IDS, has been changed accordingly.

The contributions of this work are the following. (1) A client-edge-cloud hierarchical federated intrusion detection architecture is implemented and evaluated on UNSW-NB15 under a fully specified train/validation/test protocol whose preprocessing statistics are estimated on the training split alone. (2) The proposed system is compared with three baselines that share the same network architecture, the same data partition, and the same held-out test set: a centralized model, flat FedAvg, and hierarchical FedAvg without fine-tuning. (3) Communication cost is accounted cumulatively over all training rounds and is separated into device-to-edge and edge-to-cloud traffic, instead of being quoted for a single model transfer. (4) Per-class precision, recall, and F1 are reported together with a confusion matrix, and the averaging convention is stated explicitly, so that the effect of class imbalance is visible. (5) A leave-one-attack-out study quantifies how well the system adapts to an attack category that was never observed during federated training. (6) Every experiment is repeated over five random seeds and reported as a mean with a standard deviation.

This section presents the methodology of the proposed HFed-IDS. The method combines FedAvg over a client-edge-cloud topology, which trains a compact artificial neural network as a global model, with a lightweight few-shot fine-tuning stage that specializes that global model at the edge.

FedAvg is an algorithm based on federated stochastic gradient descent (FedSGD) [22]. FedSGD is the baseline of FedAvg: a randomly selected client computes a single-batch gradient in each round, and the averaged gradient is sent to the server, which aggregates it and updates the global weights. FedAvg generalizes FedSGD in that each client performs several local update steps and returns the resulting weights rather than gradients [23]. Through this process, multiple clients train collectively on their own data without uploading raw records to a server, which is the principal motivation for FL.

3.1 Problem formulation

The evaluation uses the UNSW-NB15 dataset [24], which is represented as $D=\left\{\left(x_i, y_i\right)\right\}_{i=1}^N$.

Where: $x \in \mathbb{R}^d$ : Features vector. $y \in\{1,2, \ldots, C\}$ : Attack labels, which are shown in Table 1.

Table 1. Class distribution of the UNSW-NB15 partition used in this study and the sizes of the stratified training, validation, and test splits

3.2 Dataset and experimental protocol

The experiments use the 82,332-record partition of UNSW-NB15 [24-26] whose class distribution is given in Table 1. The previous version of this manuscript did not state how this partition was divided, so the protocol is defined explicitly here. The records are split once, by stratified random sampling, into three disjoint subsets: 70% for training (57,632 records), 15% for validation (12,350 records), and 15% for testing (12,350 records). The per-class sizes of the three subsets are listed in Table 1. Federated clients are formed exclusively from the training split. The validation split is used to monitor convergence and to select the number of local epochs and the number of fine-tuning steps; the test split is used once to produce the numbers reported in Section 4, and never for any tuning decision.

All preprocessing operators, namely the label encoder for the categorical features, the mean imputer, and the standard scaler, are fitted on the training split alone and then applied unchanged to the validation and test splits, so that no statistic derived from evaluation data can influence training. Categorical values that appear only in an evaluation split are mapped to a reserved 'unseen' code instead of triggering a re-fit. Support sets used for few-shot fine-tuning are also drawn exclusively from the training split. The training split is distributed over 10 clients using a Dirichlet label-skew partition with concentration parameter α = 0.5, which is the standard procedure for generating non-independent and identically distributed (non-IID) federated data: for every class, the proportion allocated to each client is drawn from a Dirichlet distribution, so both the class mixture and the shard size differ across clients. The clients are assigned in equal numbers to 2 edge aggregators. The full parameter set is listed in Section 4.1, and every experiment is repeated with the five random seeds 0 to 4, which control the split, the partition, and the weight initialization. The network contains a set of edge aggregators $\mathcal{E}=\left\{e_1, e_2, \ldots, e_M\right\}$ and clients (IoT devices) $\mathcal{C}=$ $\left\{c_1, c_2, \ldots, c_K\right\}$. Each client $c_k$ has its own local dataset $D_k$ of size $n_k$, which contains its own data, and it is different from the other clients. The total number of clients used in experiments is $\mathrm{K}=10$. The federated objective is to learn a set of classifier parameters $\theta$ that minimizes the empirical risk across all clients without sending any raw data to the datacenter. For a new or existing client that holds only a small labelled set, called the support set, $\mathcal{S}=\left\{\left(x_i, y_i\right)\right\}_{i=1}^{K_s}: K_s \ll$ $n_k$, the few-shot adaptation objective is to compute adapted parameters $\theta^{\prime}$ by a few steps of internal gradient steps so that q performs well on the client's held-out records, called the query set.

3.3 System architecture

A hierarchical architecture is proposed for an IoT network organized as IoT devices, edge aggregators, and a central server. Its objective is to combine hierarchical edge aggregation with a post-aggregation few-shot fine-tuning stage performed at the edge. Figure 1 shows the system architecture. Based on the system architecture shown in Figure 1, clients train locally and send model parameter updates to their assigned edge aggregator. Each edge aggregator computes the sample-weighted average of its clients' updates and repeats this local exchange 2 times before forwarding the aggregated edge model to the central server. The server then computes the sample-weighted average of the edge models (FedAvg) and broadcasts the new global model. The distinguishing element of this design is the intermediate aggregation stage at the edge, which is what removes traffic from the backbone link. After federated convergence, a client that holds a small labelled support set can additionally fine-tune the last layers of the global model locally. One property of the scheme should be stated plainly: with full client participation, sample-weighted averaging, and a single edge round per cloud round, hierarchical aggregation is numerically identical to flat FedAvg. The two schemes differ in accuracy only because 2 edge rounds are performed per cloud round, and the benefit claimed here is a communication benefit rather than an accuracy benefit.

11-1.png

Figure 1. The system architecture

3.4 Data preprocessing

Categorical features and class labels are converted to a numerical form with a label encoder fitted on the training split only, which maps each attack type to a numerical representation:

$y_i^{e n c}=L a b e l_{\text {Encoder}}\left(y_i\right)$                   (1)

The next preprocessing step is imputation, which replaces missing values with a summary statistic, here the mean. Datasets typically contain observations with missing values for one or more variables. The main options for handling missing data are [27]: (1) Exclude observations (rows) that contain any missing values, but this process may result in the loss of information that could be important and useful to the model during the training process. (2) Exclude any variable (column) that contains missing values, but this procedure may also result in the loss of predictive variables that significantly affect model performance. (3) Fill in missing entries with estimated values. This process represents the best procedure for filling in missing values because it avoids the loss of information that could affect performance results. The proposed methodology uses the simpleImputer () function to fill in missing values with the arithmetic mean of the values of the variable in which the missing value appears [28]. Assume that $\tilde{x}_i$ denotes the imputed vector, so:

$x_{i, j}=\left\{\begin{array}{l}x_{i, j}  {\ if\ } x_{i, j} {\ observed } \\ \mu_j {\ if\ } x_{i, j}  {\ missing }\end{array}\right.$              (2)

where,

$x_{i, j}$: Represents the value of attribute j in row i.

$\mu_j$: Mean of values in j attribute.

Standardization is the process of scaling data so that all values fall within a specified range, with the mean being 0 and the standard deviation being 1 [29]. This technique is widely used in data preprocessing to ensure that data points across different variables can be compared on the same scale to prevent variables with larger numerical ranges from dominating variables with smaller ranges. The formula for standardization is as follows:

$x_{i, j}=\frac{x_{i, j}-\mu_j}{\sigma_j}$                  (3)

where, $\sigma_j$ is the standard deviation of values in j attribute.

Figure 2 shows the data preprocessing and feature standardization pipeline.

11-2.png

Figure 2. The data preprocessing and feature standardization pipeline

3.5 Model architecture

The model is a compact multilayer perceptron (MLP) [30] network $f_\theta(x)$ with a small parameter count, chosen so that it can be trained and transmitted efficiently on edge devices. The forward mapping is shown in the following Eq. (4):

$f_\theta(x)=W_3 \sigma\left(W_2 \sigma\left(W_1 \sigma+b_1\right)+b_2\right)+b_3$              (4)

where,

$W_i$: The learned linear layers.

$\sigma$: The RELU activation function.

The proposed model consists of an input layer, two hidden layers, and an output layer. The first hidden layer contains 30 neurons and the second contains 16 neurons, and dropout with probability 0.2 is applied after each hidden layer to limit overfitting. With 42 input features and ten output classes, the network holds 1,956 trainable parameters, which is 7.64 KB when serialized as 32-bit floating-point values. This small parameter count is what makes the model inexpensive to communicate and suitable for deployment on edge devices. Figure 3 shows the model block diagram, while Figure 4 shows the full detailed system architecture. The identical architecture is used for every model compared in Section 4, including the centralized baseline, so that the comparison isolates the training scheme.

11-3.png

Figure 3. The model block diagram

3.6 Federated learning mechanism

At each global round $t$, a subset of clients performs local training, starting from the global parameters $\theta^t$. When local training completes, the clients return the updated parameters $\theta_k^{t+1}$. The server then computes the sample-weighted average $\theta^{t+1}$ for all $\theta_k^{t+1}$.

$\theta^{t+1}= Weighted\ Average \left(\theta_k^{t+1}\right)$                    (5)

When using edge aggregators, the server calculates the average of the edge models instead of all the client models.

Assume that the edge $e$ aggregates clients in set $\mathcal{C}_e$ with total samples $n_e=\sum_{k \in \mathcal{C}_e} n_k$. The edge state $\theta_e$ is computed as shown in Eq. (6):

$\theta_e= Weighted\ Average \left(\theta_k\right)$                   (6)

and the server update is:

$\theta^{t+1}= Weighted\ Average \left(\theta_e\right)$                  (7)

$\sum_k \theta_k \sum_e \theta_e$ hierarchical edge aggregation reduces central communication by reducing the number of messages that traverse the backbone link to the data center. Within one cloud round, each of the 10 clients exchanges its update with its edge aggregator once per edge round, so the device-to-edge traffic grows with the number of clients and with the number of edge rounds, whereas only the 2 edge aggregators exchange a model with the data center, so the backbone traffic grows with the much smaller number of edges. The cumulative cost of a complete training run, separated by link type, is derived and quantified in Section 4.7.

11-4.png

Figure 4. The full detailed system architecture

Figure 5 shows the FL mechanism with hierarchical edge aggregation. In the example of Figure 5, the number of model exchanges on the backbone link to the server is reduced from four to two.

11-5.png

Figure 5. The federated learning (FL) mechanism with hierarchical edge aggregation

3.7 Few-shot fine-tuning for adaptation

The stage described below is supervised fine-tuning of a converged global model on a small labelled support set. It is deliberately not described as meta-learning: no distribution over tasks is sampled, no episodes are constructed, and no outer-loop objective is optimized. The term few-shot refers only to the size of the support set.

Given global parameters $\theta$, the inner update for a client is shown in the following Eq. (8):

$\theta^{\prime}=\theta-\alpha \nabla_\theta \mathcal{L}_S(\theta)$              (8)

where,

$\mathcal{L}_{\mathcal{S}}$: The loss on support set.

$\alpha$: The inner learning rate.

$\nabla_\theta$: The gradient of the loss function with respect to the model parameters $\theta$.

This update is applied to the last two linear layers of the network, with the earlier layers frozen, for 500 full-batch steps at learning rate 0.01. Restricting the update in this way was necessary in practice: updating the whole network on a handful of samples caused catastrophic forgetting of the classes that were already well modelled, while updating only the output layer proved too restrictive to encode a previously unseen class. Both variants were compared on the validation split, and the two-layer variant was selected. Figure 6 shows the few-shot adaptation flow for federated intrusion detection.

11-6.png

Figure 6. The few-shot adaptation flow for federated intrusion detection

Adaptation is performed after federated convergence. The global model supplies a strong initialization, so specialization for an individual client requires only a small number of labelled samples and avoids a full retraining cycle. As quantified in Sections 4.5 and 4.6, this adaptation trades overall accuracy for a substantial gain in recall on rare and previously unseen attack classes. It is therefore presented as a mechanism for extending coverage to such classes, not as a way of improving aggregate accuracy.

3.8 Evaluation metrics and threat model

The confusion matrix is the basic tool used to assess the quality of a classifier [31]. Figure 7 shows the confusion matrix in general.

11-7.png

Figure 7. The confusion matrix in general

The confusion matrix is used to derive accuracy, precision, recall, and F1 score. Because the dataset is strongly imbalanced, the averaging convention matters and is therefore stated explicitly: weighted averages are computed over the ten classes with weights proportional to class support, whereas macro averages give every class the same weight regardless of its frequency. Both are reported throughout Section 4. Weighted averages are dominated by the Normal and Generic classes and consequently track accuracy closely, while macro averages expose the behaviour on the minority classes; reporting only one of the two would give a misleading picture of an intrusion detection system. The values reported in the previous version of this manuscript were weighted averages.

Threat model and privacy scope. The system assumes an honest-but-curious server and honest-but-curious edge aggregators: every participant follows the protocol but may inspect whatever it receives. Under this model, keeping raw traffic records on the device removes the need to transmit them and therefore removes the corresponding exposure. No formal privacy guarantee is claimed. In particular, the system implements neither differential privacy [32] nor secure aggregation [33], and it is well established that model updates alone can leak information about the underlying training data through gradient inversion and membership inference attacks [34, 35]. The privacy claims made in this paper are therefore limited to data minimization, meaning that raw records never leave the device. Integrating secure aggregation and a differentially private optimizer, and measuring the resulting utility cost, is left to future work.

$Precision=\frac{T P}{T P+E P}$            (9)

$Re c all=\frac{T P}{T P+E N}$                (10)

$Accuracy =\frac{T P+T N}{T P+T N+F P+F N}$           (11)

$F 1\ Score=2 \times \frac{ {Precision} { × } {Recall}}{ {Precision}+ {Recall}}$                  (12)