CERTIoT-6G: Continuous Cybersecurity Certification for IoT Devices in 5G/6G Networks

arXiv:2608.23339v1 [cs.NI] 24 Aug 2026

CERTIoT-6G: Continuous Cybersecurity Certification for IoT Devices in 5G/6G Networks Evangelos Lempesis

Fabio Palmese

Hamed Haddadi

Anna Maria Mandalari

Mulini

Mulini

Mulini Imperial College London

Mulini University College London

Abstract—The massive adoption of Internet of Things (IoT) devices across critical domains such as healthcare, smart cities, industrial automation, and critical infrastructure introduces significant cybersecurity and regulatory challenges. Current and forthcoming European regulations, including the Cyber Resilience Act (CRA) and the NIS2 Directive, require manufacturers, operators, and other organizations to ensure secureby-design devices, continuous vulnerability management, and resilient operation throughout the device lifecycle. Traditional certification mechanisms remain static, manual, and difficult to scale across heterogeneous IoT ecosystems. This paper presents CERTIoT-6G, a Security-as-a-Service (SECaaS) framework that enables automated cybersecurity certification and continuous compliance monitoring of IoT devices operating in 5G and future 6G networks. The framework integrates automated compliance analysis, real-time traffic monitoring, and adversarial testing capabilities. We validate the CERTIoT-6G framework on different IoT device categories operating in an advanced 5G testbed. Evaluation results reveal critical compliance gaps, particularly in traffic encryption and availability under unstable conditions, and demonstrate that the framework produces actionable verdicts mapped to regulatory requirements across heterogeneous device types. Furthermore, we show that the monitoring pipeline has a negligible impact on live 5G traffic. Index Terms—Cybersecurity Certification, IoT security, 5G/6G Networks, Continuous Compliance Monitoring

I. I NTRODUCTION The exponential growth of the Internet of Things (IoT) is reshaping critical sectors including healthcare, smart cities, and industrial automation. Large numbers of heterogeneous connected devices generate continuous data streams that enable advanced monitoring and automation at scale. However, this same proliferation substantially expands the attack surface: vulnerable devices may expose sensitive personal information [1], allow unauthorized access, or serve as entry points for large-scale attacks. As IoT deployments increasingly rely on 5G [2] and future 6G infrastructures, the scale and dynamism of these ecosystems make manual security assessment both impractical and insufficient. European Union legislation has responded by establishing binding cybersecurity obligations for both manufacturers of connected products and organizations operating critical networked systems. The Cyber Resilience Act (CRA) [3] mandates that manufacturers of connected products demonstrate secure-by-design principles, active vulnerability management, and compliance monitoring throughout the device lifecycle, not only at launch time. The NIS2 Directive extends these obligations to operators of

essential services that depend on networked IoT deployments. Together, these frameworks create a regulatory environment in which certification must be continuous, evidence-based, and scalable to large device populations. Existing certification practices, however, remain largely manual and point-in-time. Standards such as ETSI EN 303 645 [4] and its conformance specification ETSI TS 103 701 [5] define the security requirements, yet the testing processes are typically performed once at product launch and do not track the evolving security posture of devices in operation. Recent work has shown that even with standard network security tooling, only 52–70% of ETSI TS 103 701 tests can be automated [6], highlighting the need for continuous monitoring solutions. This paper introduces CERTIoT-6G, a framework that transforms IoT device certification from a static exercise into a continuous, automated service embedded within the 5G network infrastructure. Operating at the User Plane Function (UPF) via Local Breakout (LBO), the framework inspects live device traffic, executes adversarial compliance tests, and produces structured compliance reports mapped to specific CRA and NIS2 requirements, without requiring device software manipulation. We validate the framework on commercial IoT devices operating on a 5G network, uncovering significant compliance gaps and demonstrating that automated, networkembedded certification can produce compliance evidence at scale. The main contributions of this paper are: • A Security-as-a-Service (SECaaS) architecture enabling continuous cybersecurity certification of IoT devices in 5G and future 6G networks. • An automated compliance monitoring pipeline translating regulatory frameworks (CRA, NIS2, ETSI EN 303 645) into network-level compliance tests with per-requirement verdicts. • Integration within an advanced 5G Standalone (SA) testbed, demonstrating real-time traffic monitoring via UPF/LBO. • An early experimental validation across three representative device categories revealing critical gaps in traffic encryption and denial-of-service resilience, with planned extension to a larger and more diverse device population. II. R ELATED W ORK A. IoT Security Measurement and Evaluation Early systematic efforts to evaluate the security of IoT deployments revealed widespread and structural weaknesses.

Alrawi et al. [7] systematized the attack surface of homebased IoT across firmware, network, application, and cloud components, showing that vulnerabilities span the entire deployment stack. Ren et al. [1] quantified the breadth of personal data exposed through unencrypted or insufficiently protected traffic in consumer IoT devices, findings strongly corroborated by our experimental results. Huang et al. [8] demonstrated that gateway-level traffic collection can yield labeled datasets suitable for large-scale security and privacy analysis of smart-home devices, and Shahid et al. [9] showed that passive traffic features alone are sufficient to identify IoT devices by type and vendor without device-side access. B. Compliance-Oriented IoT Security Frameworks Most directly related to CERTIoT-6G is COPSEC [10], a compliance-oriented framework that automatically probes IoT devices at the network gateway and evaluates them against security guidelines and privacy regulations. COPSEC extracts measurable metrics from standards including ETSI EN 303 645 and ENISA guidelines, applies them through automated network experiments, and reports compliance verdicts. CERTIoT-6G shares COPSEC’s gateway-level measurement paradigm and regulatory grounding, but extends it in three critical directions: it operates within a live 5G network infrastructure, leveraging the UPF and LBO rather than a local WiFi gateway, it incorporates active adversarial testing beyond passive traffic analysis, and it maps each verdict directly to individual CRA and NIS2 requirements for regulatory auditability. C. Automated Security Testing Standards ETSI TS 103 701 [5] defines a conformance assessment methodology for consumer IoT devices against ETSI EN 303 645. While comprehensive, its procedure is designed for manual execution by accredited testing laboratories. Kaksonen et al. [6] investigated the degree to which standard network security tools can automate the 56 test units relevant to network attacks within ETSI TS 103 701, finding 52% coverage with basic tooling and up to 70% with advanced tools, leaving a significant automation gap. CERTIoT-6G addresses this by embedding a curated set of automated compliance tests, covering service exposure, encryption, authentication, data leakage, and resilience directly within the 5G network plane, enabling continuous coverage aligned with CRA requirements. D. IoT Security in 5G and 6G Networks The adoption of cellular connectivity in IoT deployments introduces specific security considerations. Hasan et al. [2] provide a comprehensive survey of threats for 5G-enabled Internet of Medical Things, identifying credential attacks, protocol vulnerabilities, and denial-of-service as primary threats, all of which are exercised by the CERTIoT-6G validation engine. The 3rd Generation Partnership Project (3GPP) system architecture for 5G [11] provides the UPF and LBO mechanisms that CERTIoT-6G exploits to position its monitoring functions at the network edge. As 6G standardisation advances,

Fig. 1. CERTIoT-6G four-engine architecture. The Regulatory Interpretation Engine maps standards to test bindings; the Device Identification Engine autoregisters devices; the Validation Engine runs passive and active tests; the Reporting Engine aggregates verdicts into compliance reports.

AI-native network management is expected to become a core design principle, creating further demand for adaptive compliance services beyond what static certification can provide. E. Positioning of CERTIoT-6G Unlike prior measurement tools that operate on local networks and evaluate devices passively [8], [10], and unlike testing frameworks designed for laboratory execution against a conformance specification [5], [6], CERTIoT-6G operates continuously inside a live 5G network infrastructure. It combines passive monitoring, active adversarial testing, and natural language processing (NLP)-based personal-data detection into a single pipeline that produces machine-readable compliance evidence bound to specific regulatory requirements, a capability not provided by existing tools. III. CERTI OT-6G F RAMEWORK CERTIoT-6G is a SECaaS platform that continuously monitors IoT devices connected to 5G or future 6G networks and verifies their compliance with applicable cybersecurity regulations. Figure 1 illustrates the four functional components and the data flows between them. A. Regulatory Interpretation Engine The interpretation engine decomposes cybersecurity regulations into structured, machine-readable requirement bindings. Frameworks and guidance - including the CRA [3], the NIS2 Directive [12], ETSI EN 303 645 [4], together with ENISA guidelines [13] and NIST recommendations [14] - are mapped to concrete security tests so that each result is bound to one or more specific requirements. The mapping is many-to-many: a single test can provide evidence for multiple requirements, allowing the framework to amortise testing effort across overlapping regulatory obligations. B. Device Identification Engine The identification engine discovers and registers devices as they join the network, relying on passive traffic sniffing. Each time a new device is detected on the network, the identification module is triggered to obtain the required device information:

category, vendor, model, and version. In our case, the identification pipeline is based on the method described in [15]. The first 30 seconds of device traffic after its detection is extracted, and DNS-based statistical features serve as input to a machine learning classifier that determines the device type. The derived device attributes allow the system to associate each device with the appropriate set of compliance checks and enable deviceclass-specific policies without manual onboarding. C. Validation Engine The validation engine instantiates and executes the test suite produced by the Regulatory Interpretation Engine, receiving a structured set of test bindings that associate each compliance check with one or more specific regulatory requirements. The test suite is not automatically generated: each test is defined and validated by security experts with knowledge of both the relevant regulatory requirements and the network-level mechanisms through which those requirements can be violated, ensuring that verdicts are legally defensible and technically grounded. Table I summarizes part of the test suite, derived from a thorough analysis of recent regulations. The table also reports the binding of the tests to the ETSI EN 303 645 standard, from which many of the CRA standards are derived. Tests are executed in two complementary modes: passive traffic monitoring, which observes device behavior without interfering with it, and active security probing, which subjects the device to controlled adversarial activity and measures its response. Passive monitoring. The device traffic is captured using standard tools (e.g., tshark or tcpdump) and classified by application-layer protocol to compute the proportion of encrypted versus cleartext flows. This drives two tests: • Encrypted Traffic: measures what fraction of device flows use a recognised encryption protocol. Devices transmitting part of their data in cleartext are flagged as non-compliant with confidentiality requirements. • Personal Information: captured payloads are scanned by a pre-trained NLP entity-recognition model to detect personally identifiable information (PII) such as names, locations, device identifiers, and similar attributes transmitted without adequate protection. These tests are entirely passive and do not interfere with normal operation of the device. The duration of each test is inherently device-dependent: an adequate observation window is essential for accurate verdicts, since a window that is too short may fail to capture the full range of a device’s communication behavior and produce misleading results. Active probing. The engine executes a sequence of targeted adversarial tests: • Unused Ports: a TCP/UDP port scan enumerates open services and compares them against the services observed in passive captures; ports that are open but absent from legitimate traffic are flagged as unnecessary attack surface. • TLS Interception: an intercepting proxy is inserted between the device and its cloud endpoint to assess whether the

TABLE I CERTI OT-6G T ESTS WITH TARGETED P ROPERTIES AND R EQUIREMENTS

Test

Property

EN 303 645 Req.

Unused Ports (Port) TLS Interception (TLS) Encrypted Traffic (Enc) Dictionary Attack (Dict) Replay Attack (Rep) DoS Attack (DoS) Personal Info (PII) Reliability (Rel)

Attack Surface Confidentiality Confidentiality Authentication Integrity Availability Privacy Resilience

5.6.1 5.1. 5.3, 5.5 5.1, 5.3, 5.5, 5.8 5.1 5.5 5.9.3 5.8 5.9.3

device validates the server certificate chain and rejects connections through an untrusted intermediary. This verifies the device resilience to Man-in-the-Middle attacks (MITM). • Dictionary Attack: a credential brute-forcing sequence is run against exposed authentication interfaces (e.g., SSH, HTTP); the test checks whether the device enforces rate limiting or account lockout under repeated failed attempts. • Replay Attack: previously captured valid traffic frames are replayed to assess whether the device implements messagefreshness mechanisms (e.g., nonces, sequence numbers) sufficient to reject replayed commands. • DoS Attack and Reliability: a flood attack is directed at the device for a controlled duration; the test records whether the device remains responsive during the attack and measures the time to full service recovery afterwards, combining availability and resilience into a paired verdict. Each test produces a binary verdict as compliant or noncompliant, together with the triggering evidence, and passes the result to the Reporting Engine. D. Reporting Engine The reporting engine generates structured compliance reports and user-friendly web-based alerts when non-compliance is detected. Rather than enforcing network-level mitigations - which may not be feasible for every topology or installation - the engine documents the non-compliance, classifies its severity, and provides actionable remediation recommendations such as closing insecure ports, restricting exposed services, or applying firmware updates, keeping remediation authority with device owners and operators. Each test yields a binary compliant or non-compliant verdict with a humanreadable rationale, a proposed remediation step, and the bound regulatory requirement; results are aggregated into reports that can support certification, audit, and conformity-assessment processes. IV. I NTEGRATION IN 5G T ESTBEDS To validate the proposed solution in a real-world operational 5G testbed, we deploy CERTIoT-6G in the CARL-W testbed at Karlstad University (KAU)1 , leveraging its 5G SA 1 https://6gpath.eu/testbeds/karlstad-university-testbed/

TABLE II C OMPLIANCE VERDICTS ACROSS THE THREE DEVICE CATEGORIES .

Fig. 2. CERTIoT-6G deployment in the KAU CARL-W 5G testbed. IoT devices connect directly to the 5G network as UEs. Traffic is inspected at the analysis VM via LBO; the Mulini cloud is reached over WireGuard VPN.

infrastructure for network-level IoT evaluation [16]. The key integration point is the UPF with LBO [11]. In this configuration, the user-plane traffic generated by the IoT devices is locally steered toward a dedicated analysis virtual machine (VM) before being forwarded to the Internet. This allows the monitoring platform to inspect device communications in-path, close to the network edge, while avoiding unnecessary traversal of remote cloud infrastructure and minimizing additional latency. The deployment architecture is shown in Figure 2. IoT devices attach to the CARL-W 5G SA network as UEs [17]. On the radio side, the testbed relies on the CARL-W Radio Access Network infrastructure, including Ericsson radio dots, indoor radio units, and the gNodeB. User-plane traffic is then carried through the 5G data path and anchored at the locally deployed UPF in Karlstad. Through LBO, selected traffic is steered to the CERTIoT-6G VM deployed in the KAU edge environment before being forwarded to the Internet. This placement allows CERTIoT-6G to inspect live IoT traffic, close to the 5G edge, without requiring modifications to the devices. The VM hosts the remote capture agent and the compliance analysis modules, including protocol classification, personal-data inspection, and the active security tests. Secure connectivity between the Mulini cloud infrastructure and the KAU testbed is maintained through WireGuard VPN tunnels. This enables coordination between the cloud-side management components and the edge-deployed monitoring VM, supporting synchronised monitoring and reporting across both environments. V. E XPERIMENTAL VALIDATION A. Setup and Device Set As an early validation of the framework, three representative IoT devices were selected to cover a range of communication patterns, data sensitivity levels, and service exposure characteristics, belonging to three distinct categories:surveillance, lighting, and environment. These categories reflect typical

Device

TLS

Enc

Port

PII

Rel

Dict

DoS

Rep

Surveillance Lighting Environment

✓ ✗ ✓

✗ ✗ ✗

✓ ✓ ✓

✗ ✓ ✓

✓ ✓ ✓

– ✓ –

✗ ✗ ✓

✓ ✗ ✓

Pass rate

66.7%

0%

100% 66.7% 100% 100% 33.3% 66.7%

IoT deployments in smart-home and smart-city scenarios and present meaningfully different compliance profiles. The devices operated as 5G User Equipment (UE) devices, with their traffic forwarded to the analysis VM via the 5G network and LBO path. Each device was subjected to the full battery of eight compliance tests listed in Table I, where applicable. The Replay Attack test was executed only for devices that expose locally reachable services; the Dictionary Attack test was applied only to devices that present authentication interfaces. Extension of the validation to a larger and more diverse device population is planned for future work. B. Analysis and Key Findings Table II reports the compliance verdict for each device category across all applicable tests (✓ means compliant, ✗ non-compliant, and – not applicable). The last row of the table summarises per-test compliance rates across the three device categories. Despite the small initial device set, the results reveal a clear and consistent disparity between security properties, establishing a baseline picture that motivates the planned broader evaluation. Strengths. All three devices (100%) recovered to full operation after the DoS probing phase (Reliability), and the single device presenting an authentication interface (the smart light) resisted credential brute-forcing (Dictionary Attack 100%). Port hygiene was consistent across all categories: no device exposed unnecessary network services (Unused Ports 100%), confirming that basic attack surface reduction is implemented even at the lower end of the device spectrum. Critical failure: traffic encryption. Encrypted Traffic was the most critical compliance failure as all the tested devices transmitted at least part of their information in cleartext, exposing data to passive eavesdropping. This finding corroborates patterns documented in prior network measurement studies [1], [10] and constitutes a direct violation of many cybersecurity requirements for confidentiality of data in transit. The fact that this failure appears in both a media-rich device (camera) and a lightweight constrained device (lighting) suggests it is not specific to a single device class. Availability and integrity. Only the environmental sensor passed the DoS Attack test, indicating that the camera and lighting device fail to maintain service continuity under flooding conditions, a concern for deployments where availability carries safety implications. For the Replay Attack, the camera and environmental sensor passed, as their services rejected replayed messages, while the lighting device failed, allowing

/DWHQF\PV



%DVHOLQH 0RQLWRUHG

    

-LWWHUPV















%DFNJURXQGWUDIILFUDWH0ESV

%DVHOLQH 0RQLWRUHG

  

%DFNJURXQGWUDIILFUDWH0ESV

Fig. 3. Box plot of the Mean RTT (latency, top) and RTT standard deviation (jitter, bottom) under baseline and monitored conditions across 100 runs.

unauthorized entities to replicate previously sniffed on/off commands. Privacy. Two of three devices (67%) passed the Personal Information test. The surveillance camera transmitted personal data in its network payloads, a foreseeable but potentially non-compliant finding under the mapped confidentiality requirements. Two of three devices (67%) also passed the TLS Interception test: the lighting device accepted traffic relayed through an intercepting proxy, indicating an absent or ineffective certificate validation, while both the surveillance camera and the environmental sensor resisted the man-in-the-middle interception. Device-level summary. The environmental sensor showed the strongest compliance profile, passing six of the seven applicable tests. The surveillance camera showed a mixed profile: strong on TLS and replay integrity, but failing on encryption and privacy, findings directly linked to the nature of the data it handles. The smart light showed the weakest overall compliance, failing TLS interception, encryption, DoS, and replay, which is consistent with the lower security investment typically found in constrained illumination devices. These preliminary results, while limited in sample size, already reveal compliance patterns that are device-class-specific and regulatorily actionable; extending the evaluation to a larger and more diverse device set will determine how representative these patterns are. VI. N ETWORK I MPACT AND F UTURE D IRECTIONS A. Network Impact Evaluation To quantify the overhead introduced by the CERTIoT-6G monitoring pipeline on the live 5G network, we designed

a controlled two-phase experiment in the KAU CARL-W testbed. The goal is to determine whether running the full security test suite alongside production traffic measurably degrades key network quality indicators compared to a clean baseline. Background traffic is generated using iperf3 [18], an open-source network performance tool that operates in a client-server model and supports multi-stream TCP/UDP flows with configurable bandwidth and duration. Its ability to produce controlled, reproducible synthetic loads makes it well suited for isolating the impact of a monitoring tool on ambient network conditions. Phase 1 — Baseline. An iperf3 client generates background traffic toward the testbed server running on the VM using five parallel TCP streams with varying transmission rates (100 Mbps to 750 Mbps total rate) for 60 seconds. Simultaneously, tcpdump captures traffic on the network interface to collect all the iperf3-generated packets, filtering on port 5201 with a snapshot length of 96 bytes to collect header-only traces. During this phase the CERTIoT-6G monitoring tool is completely idle. Phase 2 — Monitored. The same iperf3 session runs continuously in the background while the full CERTIoT6G test suite executes sequentially in the foreground, in the following order: unused ports scan, encrypted traffic analysis, personal information inspection, replay attack, dictionary attack, recovery test, DoS attack, and TLS interception. A single tcpdump capture covers the entire monitored period. In both phases, the captured traces are analyzed offline using tstat, which extracts TCP-level statistics per flow, coupled with the iperf3 server output parameters. Four network quality indicators are compared between the two phases: mean round-trip time (RTT) as a measure of latency impact, standard deviation of the RTT as a measure of delay variation (jitter), packet retransmission rate, and throughput. The full two-phase experiment is repeated 100 times; we report mean values and standard deviation across runs to characterize both central tendency and variability. Figures 3 and 4 present the results. The monitoring framework introduces minimal overhead on the 5G network. Mean RTT and jitter both remain within acceptable bounds, with a maximum observed increase below 10 ms between baseline and monitored conditions. No application-level failures were observed, and TCP retransmission rates remained very low in both phases, with no meaningful difference between baseline and monitored conditions. Measured throughput exactly matched the configured iperf3 transmission rate in all runs, reason for which we omit to report the values. These results confirm that CERTIoT-6G can operate continuously alongside production 5G traffic without materially degrading network quality. B. Benefits to the Certification Lifecycle An analysis of existing platforms for device compliance certification reveals that the process is traditionally performed manually and can require several months for full device compliance certification. Automated compliance assessment

5HWUDQVPLVVLRQUDWH



%DVHOLQH 0RQLWRUHG

    







%DFNJURXQGWUDIILFUDWH0ESV



Fig. 4. Packet retransmission rate under baseline and monitored conditions.

enables scaling to larger device populations, reduces perdevice cost, and compresses compliance decision time from months to under 48 hours, a crucial capability under the CRA, which requires manufacturers to respond to newly discovered vulnerabilities within defined timescales. For example, part of the test suite provided in this work can run and produce the compliance verdict in less than two minutes, highlighting the efficiency of the proposed solution for large-scale implementations. Furthermore, the capability to produce a decision with limited supervision reduces human effort and thus the verification costs. C. Toward AI-Native Compliance Operations The current validation engine relies on deterministic rulebased traffic analysis complemented by a pre-trained NLP model for personal-data detection. As the framework evolves toward future 6G deployments, several components are natural candidates for learning-based extension: (i) anomaly-driven detection to complement fixed classification thresholds under highly dynamic traffic conditions, and (ii) automated mapping of new or amended regulatory text to structured test bindings. We envision this evolution as incremental, preserving the auditable rule-based core while selectively extending it where learning-based methods offer measurable benefit. VII. C ONCLUSION This paper presented CERTIoT-6G, a Security-as-a-Service framework for automated, continuous cybersecurity certification of IoT devices in 5G and future 6G networks. By integrating regulatory interpretation, passive traffic monitoring, active adversarial testing, and structured compliance reporting into a unified pipeline deployed at the 5G UPF, the framework addresses the scalability and continuity gaps that conventional certification cannot bridge in dynamic IoT ecosystems. An early validation across three representative device categories (surveillance, lighting, environment) in the CARL-W 5G SA testbed demonstrated end-to-end compliance monitoring across eight security test categories aligned with the CRA and the NIS2 Directive. Results revealed critical compliance gaps in traffic encryption and DoS resilience, alongside consistent strength in device post-attack recovery, port hygiene, and authentication security. A controlled two-phase network impact evaluation repeated 100 times measured the framework’s

overhead on mean RTT, jitter, packet retransmissions, and throughput. No application-layer loss was observed in either phase, and the maximum latency increase between baseline and monitored conditions remained below 10 ms, confirming that continuous certification can operate alongside production 5G traffic without material degradation of network quality. Looking forward, the validation will be extended to a larger and more diverse device population to establish statistically robust compliance baselines across device classes and manufacturers. The framework will incorporate AI-native components, adaptive testing, and large language model (LLM)assisted regulatory mapping, consistent with the broader vision of 6G as a natively intelligent infrastructure. ACKNOWLEDGEMENTS This work was partially supported by the EU Horizon Europe Program under Grant No. 101293242 (PIONEERS6G) and the EU Horizon Europe SNS JU project under Grant No. 101139172 (6G-PATH). R EFERENCES [1] J. Ren et al., “Information exposure from consumer IoT devices: A multidimensional, network-informed measurement approach,” in Proc. ACM Internet Meas. Conf. (IMC), 2019, pp. 267–279. [2] M. K. Hasan et al., “A review on security threats, vulnerabilities, and counter measures of 5G-enabled internet-of-medical-things,” IET Commun., vol. 16, no. 5, pp. 421–432, 2022. [3] European Parliament and Council of the European Union, “Regulation (EU) 2024/2847 (Cyber Resilience Act),” 2024, [Online]. Available: https://eur-lex.europa.eu/eli/reg/2024/2847/oj. [4] ETSI, “Cyber security for consumer internet of things: Baseline requirements,” European Telecommunications Standards Institute, Tech. Rep. ETSI EN 303 645 V3.1.3, 2024. [5] ——, “Cyber security for consumer IoT: Conformance assessment,” European Telecommunications Standards Institute, Tech. Rep. ETSI TS 103 701 V2.1.1, 2025. [6] R. Kaksonen et al., “Automating IoT security standard testing by common security tools,” in Proc. ICISSP, 2024, pp. 42–53. [7] O. Alrawi et al., “SoK: Security evaluation of home-based IoT deployments,” in Proc. IEEE Symp. Secur. Privacy (SP), 2019, pp. 1362–1380. [8] D. Y. Huang et al., “IoT inspector: Crowdsourcing labeled network traffic from smart home devices at scale,” Proc. ACM Interact. Mob. Wearable Ubiquitous Technol., vol. 4, no. 2, pp. 46:1–46:21, 2020. [9] M. R. Shahid et al., “IoT devices recognition through network traffic analysis,” in Proc. IEEE Int. Conf. Big Data, 2018, pp. 5187–5192. [10] G. Anselmi et al., “COPSEC: Compliance-oriented IoT security and privacy evaluation framework,” in Proc. ACM MobiCom, 2023. [11] 3GPP, “System architecture for the 5G system (5GS),” 3rd Generation Partnership Project, Tech. Rep. 3GPP TS 23.501 V16.6.0, 2020. [12] European Parliament and Council of the European Union, “Directive (eu) 2022/2555 (nis 2 directive),” pp. 80–152, 2022. [Online]. Available: https://europa.eu [13] ENISA, “Guidelines for securing the internet of things,” European Union Agency for Cybersecurity, Tech. Rep., 2020. [14] K. Megas et al., “NIST cybersecurity for IoT program,” 2024, [Online]. Available: https://www.nist.gov/publications/ nist-cybersecurity-iot-program. [15] A. Ciechonski et al., “Early-stage IoT device identification using passive network traffic analysis,” in Proc. IFIP Networking Conf., 2026, pp. 1–6. [16] M. Rajiullah et al., “CARL-W: A testbed for empirical analyses of 5G and Starlink performance,” in Proc. ACM Workshop 5G Beyond Netw. Meas., Model., Use Cases, 2023, pp. 1–7. [17] G. Caso et al., “A standardized evaluation of QoS/QoE performance in 5G and beyond-5G systems,” IEEE Commun. Standards Mag., pp. 372–379, 2025. [18] Energy Sciences Network (ESnet), “iPerf3: A TCP, UDP, and SCTP network bandwidth measurement tool,” [Online]. Available: https:// github.com/esnet/iperf.

Related documents

• HDCI Net for interpretable cross domain intrusion detection in 6G IoT and critical infrastructure networks.#327123
• HDCI Net for interpretable cross domain intrusion detection in 6G IoT and critical infrastructure networks#142737
• Machine-Learning-Based Vulnerability Detection and Classification in Internet of Things Device Security#133972
• Cumberland Care Homes IoT Network — Cumberland Council — Southern Communications#1180911
• Security in DevSecOps: Applying Tools and Machine Learning to Verification and Monitoring Steps#328758