Enhancing IoT Security: A Study of Secure Authentication and Onboarding Mechanisms in Connected Devices

Enhancing IoT Security: A Study of Secure Authentication and Onboarding Mechanisms in Connected Devices Master en Ciberseguridad Trabajo Fin de Master Autor: Pedro Ruzafa Alcázar Tutor/es: Antonio Skarmeta Gómez Sara Nieves Matheu García 26 de Mayo de 2025 Enhancing IoT Security: A Study of Secure Authentication and Onboarding Mechanisms in Connected Devices Autor Pedro Ruzafa Alcázar Tutor/es Antonio Skarmeta Gómez DIIC Sara Nieves Matheu García DIIC Master en Ciberseguridad Murcia, 26 de Mayo de 2025 Declaración firmada sobre originalidad del trabajo D./Dña. Pedro Ruzafa Alcázar, con DNI 23833808N, estudiante de la titulación de Master en Ciberseguridad de la Universidad de Murcia y autor del TF titulado “Enhancing IoT Security: A Study of Secure Authentication and Onboarding Mechanisms in Connected Devices”. De acuerdo con el Reglamento por el que se regulan los Trabajos Fin de Grado y de Fin de Máster en la Universidad de Murcia (aprobado C. de Gob. 30-04-2015, modificado 22-04-2016 y 28-09-2018), así como la normativa interna para la oferta, asignación, elaboración y defensa delos Trabajos Fin de Grado y Fin de Máster de las titulaciones impartidas en la Facultad de Informática de la Universidad de Murcia (aprobada en Junta de Facultad 27-11-2015) DECLARO: Que el Trabajo Fin de Master presentado para su evaluación es original y de elaboración personal. Todas las fuentes utilizadas han sido debidamente citadas. Así mismo, declara que no incumple ningún contrato de confidencialidad, ni viola ningún derecho de propiedad intelectual e industrial Murcia, a 26 de Mayo de 2025 Fdo.: Pedro Ruzafa Alcázar Autor del TF Abstract The proliferation of connected devices and the widespread adoption of Internet of Things (IoT) technologies have introduced a paradigm shift in how networks, systems, and physical infrastructures operate. From smart homes and industrial automation to critical infrastructures such as energy and healthcare, IoT devices now form the backbone of cyber-physical systems. However, their explosive growth has brought significant challenges in terms of lifecycle security, particularly during the onboarding and post-deployment phases. These stages are critical: onboarding is the point at which trust must be established, while lifecycle security ensures that devices behave according to defined policies and remain protected against evolving threats. In traditional IoT deployments, onboarding typically requires manual procedures such as scanning QR codes, entering pre-shared keys, or configuring access credentials manually through web interfaces or vendor-specific platforms. These approaches are inherently insecure and unscalable. They introduce operational friction and are highly prone to misconfiguration, especially in environments where large numbers of devices must be deployed quickly. Moreover, these methods lack interoperability and often lead to vendor lock-in, limiting the flexibility and long-term sustainability of IoT solutions. Beyond the initial deployment, the absence of standardized post-onboarding policy enforcement mechanisms has proven to be a significant weakness. Devices are frequently deployed with default or loosely configured access rules, leaving them vulnerable to abuse, misrouting, or unintended lateral movement within networks. Existing access control solutions are either too generic—failing to consider the specific behavior profile of each device—or too complex to deploy at scale, especially in constrained environments with limited computational or administrative resources. To address these challenges, this work presents an integrated and standards-based security framework for connected devices, combining secure onboarding, automatic policy enforcement, and dynamic threat mitigation. The architecture is composed of three core components: •FIDO Device Onboard (FDO) [1]: A protocol developed by the FIDO Alliance to enable secure, zero-touch onboarding of devices. FDO uses asymmetric cryptography, vouchers, and a rendezvous-based architecture to securely transfer device ownership at deployment time without requiring prior trust relationships or manual configuration. •Manufacturer Usage Description (MUD) [2][3]: A framework standardized by the IETF in RFC 8520, which allows device manufacturers to publish a formal description of the intended network behavior of their devices. MUD policies are expressed in a structured format and can be retrieved and enforced automatically by network managers, enabling fine-grained access control tailored to each device type. viii •Threat MUD [2]: An extension proposed and implemented in this work that enables dynamic security policy updates in response to new vulnerabilities or threats. Threat MUD files describe additional restrictions or changes that must be applied to devices affected by a specific threat, and are distributed through Cyber Threat Intelligence (CTI) integration. This architecture creates a unified lifecycle security model that begins with secure onboarding (FDO), transitions into policy enforcement (MUD), and evolves into threat-responsive behavior (Threat MUD). By integrating these components, devices are not only onboarded securely but also governed automatically according to predefined policies, and protected dynamically as new security challenges arise. To validate the proposal, a complete prototype was implemented using open-source tools and technologies. The onboarding workflow was developed using the official pri-fidoiot implementation maintained by the FIDO Alliance. The MUD and Threat MUD components were developed in Python, using REST interfaces to emulate real-world interactions with policy managers and network enforcers. A containerized testbed was created using Docker, replicating all the roles in the architecture: device emulator, manufacturer, rendezvous server, owner server, MUD file server, policy manager, and enforcement layer. This modular design enabled precise measurements and repeatable experiments. Multiple metrics were evaluated to assess the integration, automation, and responsiveness of the proposed lifecycle security framework. The aim was not to evaluate enforcement scalability or rule processing complexity, but rather to validate the correctness and efficiency of integrating FDO, MUD, and Threat MUD into a cohesive and automated workflow: •Onboarding time: This metric captures the duration from the start of the FDO process (TO1) until the ownership is transferred and the MUD URL is extracted and forwarded to the MUD Manager. Results consistently showed that onboarding was completed in under 600 milliseconds. This confirms that extending the FDO flow to include metadata exchange with MUD infrastructure introduces negligible overhead, making it suitable even for constrained environments or large-scale provisioning scenarios. •Policy retrieval and coordination latency: Once the MUD URL is forwarded, the system retrieves the MUD file, validates its digital signature, and triggers automated translation and dispatch to the orchestrator. While the enforcement phase involves applying basic rule sets (only two rules per MUD in this work), the pipeline itself— particularly the automated handoff between services—was validated to complete in approximately 374 milliseconds. This highlights the seamless orchestration and integration rather than the performance of bulk policy application. •Threat response time: The Threat MUD mechanism demonstrated that upon reception of a threat alert (in the form of a Threat ID), the system could retrieve, validate, and propagate updated mitigation rules to the enforcement layer in less than 100 milliseconds. While the rule complexity remained minimal, the emphasis here is on validating the reactive capability of the architecture and its ability to incorporate dynamic security updates without human intervention. These results confirm that the full lifecycle—from onboarding to behavior definition and dynamic threat reaction—can be orchestrated in an automated and timely manner. The ix architecture proves its viability as a standards-based, regulation-ready framework capable of securing IoT devices from deployment through operational life, with integration as the primary enabler. Additionally, the implementation was benchmarked against alternative solutions including manual provisioning, TPM-based onboarding, Wi-Fi EasyConnect (DPP)[4], and proprietary cloud-based IoT platforms. These comparisons revealed that the proposed architecture not only achieves comparable or superior security guarantees but also exceeds in terms of automation, standards compliance, and lifecycle coverage. Beyond performance, the design philosophy emphasizes interoperability and future extensibility. All components are loosely coupled, communicate over open protocols, and rely on established standards such as RFC 8520 (MUD)[3] and the FDO protocol specification[1]. This ensures compatibility with existing network infrastructure and opens the door to further integration with Software-Defined Networking (SDN), threat feeds such as MISP, and compliance automation platforms. In the context of upcoming regulatory requirements, particularly the European Union’s Cyber Resilience Act (CRA)[5], this work provides a concrete foundation for secure-by-design and secure-by-default principles. By making onboarding cryptographically verifiable, enforcing behavior constraints based on manufacturer intent, and enabling proactive response to emerging threats, the architecture supports traceable and auditable device security from the point of manufacture to runtime operation. The proposed model also highlights an architectural shift in how IoT security should be approached: rather than relying solely on reactive measures (e.g., patching, firmware updates), the emphasis is placed on proactive control, formal behavior descriptions, and dynamic adaptation at the network level. This paradigm is not only more scalable but also more suitable for constrained environments where device software cannot always be updated or trusted. To conclude, this thesis contributes a functional, reproducible, and standards-based framework for secure onboarding and lifecycle security in connected devices. It combines cuttingedge technologies, aligns with regulatory expectations, and demonstrates significant improvements in automation, performance, and resilience compared to traditional methods. The results and lessons learned from this work provide a strong foundation for future research in IoT security orchestration, as well as for practical implementations in industry, smart environments, and critical infrastructure protection. Listings 4.1 Launching pri-fidoiot with Docker Compose . . . . . . . . . . . . . . . . . . . 22 4.2 SampleMUDfile.................................. 24 4.3 Example MUD rule in JSON format . . . . . . . . . . . . . . . . . . . . . . . 26 4.4 Translated iptables rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1 Introduction The exponential growth of connected devices and the proliferation of the Internet of Things (IoT) are transforming industries, homes, and critical infrastructures. These devices are increasingly deployed in environments with limited physical or administrative control, making them attractive targets for cyber threats. Despite advances in hardware and cloud platforms, fundamental aspects of device onboarding, configuration, and lifecycle security remain weakly standardized, often relying on manual processes, vendor-specific logic, or static credentials. In this context, it is important to distinguish between two closely related concepts: Onboarding refers to the initial process through which a device is securely introduced into an IoT environment. This involves establishing trust, exchanging credentials, and ensuring that the device can communicate securely with its intended owner or management infrastructure. Traditionally, onboarding required manual configuration, including the provisioning of pre-shared keys or certificates, which often resulted in weak security guarantees and poor scalability. Bootstrapping, on the other hand, can be seen as a broader and more continuous process. While onboarding is usually a one-time action, bootstrapping encompasses not only the initial authentication but also the automated configuration and secure policy enforcement that follow. It ensures that once the device is authenticated, it is also correctly integrated into the network’s access control and management architecture. In this sense, secure bootstrapping covers both the establishment of trust and the application of constraints and policies that define what a device is allowed to do. This situation introduces considerable challenges for operators, manufacturers, and regulators. From a security perspective, improper onboarding can lead to unauthorized access, rogue devices, and lateral movement within networks. From an operational standpoint, the lack of automation increases deployment time and cost. Furthermore, most IoT devices are constrained in computational and memory resources, making it difficult to embed traditional endpoint protection mechanisms. Therefore, security must be introduced at the network and architectural level from the moment a device is first introduced into a system. This work is particularly relevant in the context of increasing regulatory demands for IoT security, including the European Union’s Cyber Resilience Act (CRA), which mandates secure development, deployment, and maintenance of connected products. To address these issues, this work explores the integration of three complementary technologies: •FIDO Device Onboard (FDO)[6][1]: A secure and standardized protocol for zerotouch onboarding of IoT devices, enabling ownership transfer with minimal configuration or prior trust between device and operator. •Manufacturer Usage Description (MUD)[3]: A network-layer policy framework allowing manufacturers to define and publish the intended communication behavior of 2Introduction their devices, enabling automated access control enforcement after onboarding. •Threat MUD[2]: An extension to the MUD framework that allows dynamic updates to access policies in response to detected vulnerabilities or threats, closing the loop between cyber threat intelligence and network-level mitigation. This work is motivated by the need to address three critical security gaps that persist in IoT deployments: the absence of a standardized, secure, and automated onboarding mechanism; the lack of device-specific policy enforcement immediately after deployment; and the inability to dynamically mitigate vulnerabilities as they are discovered during the device’s operational lifetime. The proposed solution addresses these challenges by combining secure onboarding through FDO, access control enforcement based on manufacturer-declared behavior via MUD, and dynamic, threat-driven mitigation using Threat MUD. This integrated architecture enables device security that is not only automated and scalable, but also adaptive and resilient—essential attributes in increasingly interconnected and risk-prone IoT environments. By adopting standard protocols and focusing on automation and lifecycle resilience, this thesis aims to contribute a practical and scalable solution to one of the most pressing security challenges in modern connected environments. The primary goal of this work is to design, implement, and evaluate a modular architecture that enables secure onboarding and lifecycle-aware security for IoT devices, integrating FDO, MUD, and Threat MUD mechanisms. This main objective addresses the need for automation, scalability, and dynamic policy adaptation in the context of increasingly connected environments, where manual provisioning and static configurations are no longer sufficient. To achieve this, the following specific objectives have been defined: 1. Analyze the limitations of traditional onboarding and policy enforcement mechanisms in IoT environments, and identify key gaps in automation, standardization, and threat response. 2. Integrate the FDO protocol into a testbed to demonstrate secure and zero-touch onboarding, including the delivery of metadata such as MUD URLs. 3. Implement an automatic policy enforcement system using MUD, capable of retrieving, validating, and translating MUD files into enforceable access control rules at the network layer. 4. Extend the MUD framework with Threat MUD capabilities, allowing for the dynamic update of policies in response to emerging vulnerabilities through a simulated cyber threat intelligence (CTI) channel. 5. Develop a functional and reproducible test environment, using containerized components that simulate all relevant roles (manufacturer, rendezvous, owner, enforcer). 6. Evaluate the performance and responsiveness of the architecture, measuring onboarding latency, rule translation overhead, threat mitigation time, and comparing these to traditional approaches. 3 7. Demonstrate the feasibility of the architecture under real-world conditions, emphasizing automation, standards compliance, and alignment with current regulatory initiatives such as the EU Cyber Resilience Act (CRA). These objectives guide the development and validation of a cohesive, standards-based approach to secure onboarding and lifecycle protection for IoT, with a focus on automation, policy accuracy, and adaptive threat mitigation. This work has been developed within the scope of the European research project DOSS (Secure-by-Design IoT Operation with Supply Chain Control), which aims to enhance the security and trustworthiness of IoT ecosystems by integrating secure-by-design principles across the entire device lifecycle—from manufacturing to operation and decommissioning. The contribution of this thesis directly aligns with the objectives of DOSS by addressing secure onboarding through FDO, behavior-based access control via MUD, and dynamic threat mitigation using Threat MUD. The integration and evaluation of these mechanisms in a unified architecture demonstrate a practical approach to automating device provisioning and policy enforcement. Moreover, the work serves as a foundational implementation to support future demonstrations and validations within DOSS, particularly in environments where supply chain integrity and lifecycle policy automation are critical. This memory is separated into abstract, resume, and the next six chapters: This document is structured in six chapters. Chapter 1 introduces the context of the Internet of Things security landscape, highlighting the motivation and objectives of this work. Chapter 2 reviews the state of the art, exploring existing solutions for secure onboarding, access control, and dynamic threat mitigation, with a focus on standards such as FDO, MUD, and recent proposals related to Threat MUD. Chapter 3 presents the analysis of the problem and the specific goals to be achieved, along with the methodology used to design and validate the proposed architecture. Chapter 4 describes the system design and implementation in detail, including the integration of open-source components, the communication flow between modules, and the testbed configuration. Chapter 5 reports the experimental results, providing quantitative evaluations of onboarding latency, policy enforcement time, and mitigation effectiveness, as well as comparisons with traditional approaches. Finally, Chapter 6 concludes the work, summarizing the key contributions and outlining future lines of research and possible improvements to the proposed framework. 2 State of art As the number of connected devices continues to grow, establishing secure, scalable, and automated initialization processes has become a cornerstone of IoT security. Two key concepts emerge in this context: onboarding and bootstrapping. Although they are closely related, each addresses a different phase in the secure integration of devices into a networked ecosystem. This section reviews the state of the art in secure onboarding and lifecycle security for IoT systems, focusing on the technical challenges and emerging standards that address different stages of the device lifecycle. Securely integrating IoT devices into network environments involves complex issues across both the onboarding and post-deployment phases, compounded by heterogeneous device capabilities, constrained resources, the absence of unified standards, and evolving cyber threats. Before detailing concrete solutions, it is essential to understand the risks and limitations that compromise security at these stages. Two particularly promising approaches are examined: the FDO protocol, which automates and secures the onboarding process through cryptographic ownership transfer, and the MUD framework, which supports post-onboarding access control and adaptive policy enforcement. Together, these technologies form a foundation for scalable, standards-based, and threat-aware IoT security. 2.1 Security Challenges in IoT Onboarding The onboarding and lifecycle management of IoT devices present multiple security challenges that impact device integrity, data privacy, and network security. Recent research highlights several critical security concerns that must be addressed to ensure the robustness of IoT ecosystems [7, 8, 9]. •Lack of standardized onboarding protocols. The diversity of IoT device manufacturers and the absence of widely accepted onboarding standards result in fragmented security practices. Traditional onboarding approaches often rely on pre-shared keys or manual configurations, making them vulnerable to attacks [7]. Some frameworks, such as the Eclipse Arrowhead project, introduce automated and secure onboarding mechanisms for System of Systems (SoS) environments to mitigate these risks [7]. •Weak authentication mechanisms. Many IoT devices employ inadequate authentication techniques, such as default credentials or weak cryptographic methods, which can be easily exploited. The FDO protocol attempts to address this by introducing Ownership Vouchers and cryptographic attestation, but concerns remain regarding its reliance on potentially weak elliptic curves (SECP256r1/SECP384r1) and centralized trust models [8]. •Supply chain vulnerabilities. A major challenge in IoT onboarding is the risk of compromise at different points in the supply chain. Trust delegation from manufacturers 6State of art to distributors and retailers introduces multiple attack vectors, including malicious tampering or key exposure. The ASOP protocol proposes an alternative that applies zero-trust principles and post-quantum cryptography (CRYSTALS-Kyber) to mitigate these risks [8]. •Insecure communication channels. Many IoT devices operate over insecure or poorly configured communication protocols, exposing them to man-in-the-middle attacks and eavesdropping. Research highlights the importance of mutual authentication and encryption during onboarding, particularly in industrial environments where compromised communication can have severe operational consequences [7]. •Scalability issues in secure device management. As IoT networks expand, managing security at scale becomes increasingly complex. The heterogeneity of devices, each with unique security requirements, makes centralized management difficult. Studies suggest that a service-oriented architecture (SoA)-based approach, such as the Eclipse Arrowhead framework, can improve scalability and interoperability while maintaining strong security postures [7]. •Lifecycle management and secure decommissioning. IoT security must extend beyond the onboarding phase to include secure lifecycle management and decommissioning. Improperly decommissioned devices may still retain sensitive credentials or configuration data, posing persistent security risks. Automated onboarding procedures should incorporate certificate revocation mechanisms and secure key disposal to prevent unauthorized access post-deployment [7]. Recent research in secure onboarding protocols, such as ASOP and FDO, aim to mitigate these challenges, but concerns remain regarding centralized trust, supply chain security, and cryptographic robustness [7, 8]. The integration of post-quantum cryptography and decentralized trust models presents a promising direction for future work. Furthermore, ensuring the secure deployment of IoT devices in real-world environments requires continuous policy enforcement and dynamic response mechanisms. Secure deployment implies that once a device is authenticated and integrated into the network, its behavior remains constrained to a defined set of legitimate operations. This is especially relevant in contexts where unauthorized communication or unexpected behavior could pose significant risks to operational continuity or data confidentiality. The MUD framework emerges as a foundational tool in this space, enabling the automatic enforcement of access control policies based on manufacturer-provided specifications. In parallel, the growing regulatory landscape in Europe—particularly with the upcoming CRA—is reinforcing the need for built-in security mechanisms across the entire device lifecycle. The CRA introduces binding obligations for manufacturers to provide secure-by-design products, enforce strict access control policies, and ensure continued vulnerability management post-deployment. These regulatory pressures underscore the importance of integrating solutions like FDO and MUD, not only from a technical perspective but also as part of compliance and risk management strategies. This broader context serves as a key motivation for the current research, which explores how the combination of secure onboarding and policy enforcement can meet both security and regulatory expectations in IoT deployments. 2.2. Overview of the FIDO Device Onboard (FDO) Protocol 7 2.2 Overview of the FIDO Device Onboard (FDO) Protocol The FIDO Device Onboard (FDO) protocol [6] is a security framework designed to simplify and strengthen the process of introducing IoT devices into their operational environments. FDO addresses long-standing challenges associated with secure onboarding, particularly those related to manual provisioning, pre-shared secrets, and inflexible manufacturingto-deployment pipelines. Rather than relying on static credentials embedded during production, FDO allows device credentials and ownership to be assigned during deployment using a principle known as late binding [1]. At the core of FDO is a cryptographic mechanism based on ownership vouchers. These digitally signed tokens are issued by the manufacturer and passed down through the supply chain, enabling the final device owner to assert control securely and verifiably. The device, upon first boot, contacts a rendezvous server included in the voucher metadata. This rendezvous server serves as an intermediary, redirecting the device to the appropriate owner service without requiring pre-established configuration. Ownership is then transferred through a sequence of authenticated exchanges that include cryptographic key negotiation, attestation, and encrypted provisioning data delivery. Figure 2.1: FDO Onboarding Process Sequence Diagram As we can see in Figure 2.1 FDO incorporates multiple ownership transfer protocols, each serving a specific function in securely transitioning a device from manufacturer to owner: • Device Initialize Protocol (DI) - Establishes initial device credentials during manufacturing. • Transfer Ownership Protocol 0 (TO0) - Registers the device owner with a Rendezvous Server. 14 State of art governing how these files should be created or what trust anchors should be used to verify their authenticity. This creates potential risks in environments where malicious or incorrect threat policies could be injected into the network infrastructure. In addition, the enforcement of dynamically updated policies requires a reliable and secure communication channel between CTI platforms, MUD managers, and enforcement points. Any compromise or misconfiguration along this chain could result in delays, incorrect policy application, or even denial of service due to overly aggressive policy blocking. Furthermore, the effectiveness of Threat MUD relies heavily on timely intelligence and manufacturer support. If vendors fail to publish Threat MUD updates for known vulnerabilities, affected devices may remain exposed even in well-managed networks. Another limitation is operational: frequent or aggressive policy updates could introduce instability in large-scale deployments, particularly if updates are not properly validated or tested. Network administrators must also manage potential conflicts between existing MUD rules and new threat-based directives, ensuring that the overall policy set remains coherent and does not inadvertently block legitimate services. In summary, Threat MUD represents a promising evolution of the MUD framework, adding essential capabilities for dynamic threat mitigation. However, to realize its full potential, future work is needed to address standardization gaps, ensure trustworthy update mechanisms, and provide integration guidelines that minimize operational risk while maximizing security responsiveness. Despite these challenges, Threat MUD represents a major advancement in IoT security, providing an automated, intelligence-driven approach to mitigating device vulnerabilities. 3 Targets analysis and methodology 3.1 Targets analysis The analysis focuses on evaluating the security and operational effectiveness of integrating FIDO Device Onboard (FDO) for secure onboarding and Manufacturer Usage Description (MUD) for lifecycle security. The study aims to assess vulnerabilities, limitations, and potential improvements in secure device provisioning, policy enforcement, and lifecycle protection. Technical Scope The scope of the analysis includes five main components: 1. The FIDO FDO onboarding process, using the official pri-fidoiot implementation. 2. A custom Python-based MUD framework for enforcing access control policies. 3. Threat MUD extensions for dynamic security updates based on real-time threat intelligence. 4. Integration of both systems in a testbed of simulated IoT devices. 5. Security evaluation throughout the device’s lifecycle, from onboarding to policy adaptation. Each of these components is examined individually and in combination, with a particular focus on interoperability, scalability, and resilience to attacks. Onboarding Security Assessment A core objective of this study is to analyze the security of the onboarding process using FIDO FDO. The FDO protocol aims to remove traditional onboarding weaknesses by introducing cryptographic ownership delegation. Instead of configuring a device during manufacturing with static credentials or predefined cloud endpoints, FDO allows ownership to be assigned later, during deployment. This concept, known as ”late binding”, reduces risks in the supply chain and simplifies device integration in varied environments. Security in FDO is established through a sequence of ownership transfer protocols (TO0, TO1, TO2), verified by digital signatures and certificates. The analysis in this work evaluates the resistance of this process to common attacks such as impersonation, man-in-the-middle, and replay. Particular attention is given to the use of ownership vouchers and the trust assumptions placed on the rendezvous server. The following aspects will be evaluated: 16 Targets analysis and methodology • Resistance to man-in-the-middle (MitM) attacks during ownership transfer. • Strength of cryptographic mechanisms, including elliptic curve-based authentication and ownership voucher verification. • Potential replay attack scenarios exploiting unsecured ownership handshakes. • The effectiveness of rendezvous server authentication and redirection mechanisms. Lifecycle Security and MUD Policy Enforcement Beyond onboarding, the study assesses the ability of MUD to enforce security throughout the device lifecycle. Key aspects include: • Ability to restrict unauthorized network access through predefined MUD policies. • Effectiveness of dynamic policy updates via Threat MUD to mitigate new vulnerabilities. • Scalability of policy enforcement across multiple devices in an enterprise or industrial IoT environment. Integration Challenges and Limitations The research also identifies challenges in integrating FDO with MUD, including: •Interoperability issues: Differences in how FDO and MUD define security policies and enforce access control. •Latency concerns: The impact of onboarding and policy retrieval on device activation time. •Policy conflicts: Potential inconsistencies between predefined MUD rules and dynamic Threat MUD updates. 3.2 Methodology This section presents the research methodology used to analyze the integration of FIDO Device Onboard (FDO) for secure onboarding and Manufacturer Usage Description (MUD) for lifecycle security. The objective is to evaluate the security and operational effectiveness of combining these frameworks, addressing their strengths and limitations. 3.2.1 Research Approach The study follows an experimental research approach, focusing on: • Implementing FIDO Device Onboard (FDO) for secure onboarding using the opensource repository pri-fidoiot provided by the FIDO Alliance [6]. 3.2. Methodology 17 • Developing a custom Python-based MUD framework, which will be responsible for defining and enforcing security policies post-onboarding. • Conducting security evaluations to identify vulnerabilities and analyze the integration challenges of FDO and MUD. 3.2.2 Evaluation Metrics To assess the security and performance of the integration, the following evaluation metrics will be used: • Onboarding security. Evaluating the strength of FDO’s authentication mechanisms, including ownership vouchers and cryptographic binding. • Bootstrapping time. Measuring the time required for device registration and ownership transfer. • Policy enforcement effectiveness. Testing the ability of the MUD implementation to restrict unauthorized network activity. • Scalability. Assessing how well the integrated system handles multiple simultaneous device onboardings and policy applications. • Lifecycle security. Analyzing the ability of MUD to enforce security updates, network restrictions, and policy adjustments dynamically. 3.2.3 Experimental Setup The experiments will be conducted in a controlled testbed to evaluate the secure onboarding and lifecycle security mechanisms. Testbed Environment The experimental setup consists of: • IoT devices. Simulated IoT endpoints representing constrained devices, deployed in a sandboxed environment. • FIDO FDO Server. A deployment of the pri-fidoiot implementation, acting as the onboarding infrastructure. • Rendezvous Server. A component used by FDO to establish device ownership transfers securely. • MUD Manager (Custom Implementation). A Python-based MUD server responsible for retrieving and enforcing MUD policies. • MUD Policy Storage. A database maintaining predefined and dynamically updated MUD policies. • Threat MUD Integration. An extension that enables dynamic policy updates in response to new vulnerabilities. 18 Targets analysis and methodology Onboarding and Security Policy Enforcement Workflow The workflow for integrating FIDO FDO and MUD-based lifecycle security consists of the following steps: 1. The IoT device initiates onboarding using FIDO FDO, contacting the Rendezvous Server to retrieve ownership credentials. 2. The device establishes trust with the FDO Server, and ownership transfer is completed. 3. Upon successful onboarding, the FDO Server provides the device MUD URL to the MUD Manager, which retrieves its security policy. 4. The MUD Enforcer applies access control rules based on the policy, restricting network interactions. 5. If a security threat is detected, a Threat MUD File is generated and distributed dynamically via the MUD Manager. 6. The updated MUD policy is enforced, ensuring continuous lifecycle security. Security and Performance Testing Security evaluations will include: • Evaluating the effectiveness of MUD in preventing unauthorized communications. • Measuring the impact of Threat MUD updates on security enforcement and device response times. • Probe the effectiveness integration of FDO and MUD workflow. 3.2.4 Expected Contributions The integration of FIDO FDO and MUD aims to establish a secure, automated, and adaptive IoT security framework. This research will: • Demonstrate the feasibility of combining onboarding and policy enforcement for improved IoT security. • Identify the strengths and limitations of FDO and MUD in real-world deployment scenarios. • Provide insights into enhancing MUD with dynamic threat response capabilities. 4 Design and Implementation This section presents the full technical implementation of the secure onboarding and lifecycle policy enforcement system proposed in this work. Building on the foundations explored in previous sections—specifically the onboarding mechanisms offered by FDO and the behavioral policy enforcement of MUD, this section details how both are integrated into a coherent and operational security framework. The implementation connects all phases of the device lifecycle, from manufacturing to deployment, onboarding, and continuous policy governance. 4.1 System Architecture Overview Figure 4.1: Complete Architectural flow for FDO, MUD and Threat MUD The complete system implementation is structured around two sequential and complementary phases: the secure onboarding and static policy enforcement phase using FDO and MUD, and the dynamic policy update phase enabled by Threat MUD. These phases cover the full security lifecycle of an IoT device, from the initial moment it is deployed and trusted, to its ongoing protection against emerging threats. Figure 4.1 illustrates the full architecture and the division between onboarding and adaptive security operations. 4.1.1 Phase 1: Secure Onboarding and Policy Enforcement (FDO + MUD) The first phase begins with the manufacturer provisioning the device during the FDO DI stage. This includes embedding cryptographic credentials and a reference to a rendezvous 20 Design and Implementation server. Additionally, the manufacturer hosts the MUD file describing the device’s expected communication behavior on a dedicated MUD File Server. Once the device is deployed, it initiates onboarding by contacting the Rendezvous Server (FDO TO1). Meanwhile, the operator or owner registers its ownership intent and corresponding Owner Server endpoint during FDO TO0. The rendezvous phase completes with the device obtaining the Owner Server’s IP, initiating the secure ownership transfer protocol (FDO TO2), which involves mutual authentication and provisioning of deployment-specific metadata. After successful onboarding, the Owner Server sends the MUD URL associated with the device to the MUD Manager. The MUD Manager is responsible for retrieving the MUD file and verifying its digital signature to ensure its authenticity. Upon validation, the policy is parsed and translated into enforceable network rules, which are applied by the Domain Orchestrator. This step ensures that the device is only permitted to communicate in accordance with its declared behavior, as defined by the manufacturer. 4.1.2 Phase 2: Threat MUD and Dynamic Policy Response While MUD provides a static and manufacturer-defined policy baseline, real-world security demands require the ability to update these policies in response to evolving threats. The second phase introduces the Threat MUD mechanism, which enables the injection of dynamic policies when vulnerabilities are discovered after deployment. When a new threat is identified—either by the manufacturer or an external threat intelligence source—the information is first processed through a CTI platform such as MISP. The manufacturer then generates a Threat MUD file containing updated access control rules or mitigation actions, such as blocking known malicious domains or enforcing protocol restrictions. This file is published on a Threat MUD File Server along with a digital signature. The Threat MUD Manager, operating within the owner domain, receives the threat event (step 2) and retrieves the Threat MUD file and its signature from the manufacturer (step 4). Once the signature is validated (step 5), the policy is forwarded to the Threat MUD Enforcer (step 6), which applies the updated rules within the network infrastructure. As in the MUD case, the Threat MUD file is also converted into an actionable policy and shared with the Domain Orchestrator to ensure consistent policy interpretation across domains and systems (step 7). This integration allows the system to adapt dynamically to new risks without requiring manual reconfiguration, preserving automation and minimizing reaction time. Together, these two phases offer a layered and resilient security model. FDO provides strong trust anchors for initial onboarding, MUD enforces manufacturer-declared behavior, and Threat MUD introduces reactivity and adaptability—forming a continuous security chain that protects the device throughout its lifecycle. 4.2 FDO Implementation – Secure Onboarding The foundation of this architecture is built upon the FDO protocol, which provides a standardized and secure method for zero-touch onboarding of IoT devices. The goal of the onboarding phase is to securely transfer ownership of a device from the manufacturer to the 4.2. FDO Implementation – Secure Onboarding 21 operator, while embedding critical information needed for subsequent security enforcement— such as the MUD URL. Figure 4.2 illustrates the main stages of this onboarding process. It begins during the Device Initialization (DI) phase, where the manufacturer provisions the device with cryptographic credentials, a reference to the rendezvous server, and—in this implementation—a preconfigured MUD URL. By embedding the MUD URL at this stage, the device can later inform the owner about its intended network behavior in an automated and verifiable way. Once deployed, the device connects to the rendezvous server to begin the ownership transfer process. This involves FDO TO1, during which the device identifies itself and requests the endpoint of its designated Owner Server. In parallel, the operator has already registered with the rendezvous server via FDO TO0, declaring its willingness to assume ownership of the specific device. In the final step of the onboarding process (FDO TO2), the device and Owner Server establish mutual trust through cryptographic exchanges. During this stage, the ownership voucher is validated and the device receives deployment-specific instructions. Crucially, the Owner Server also receives the MUD URL that was injected during the DI phase. This ensures that, immediately after onboarding, the owner can fetch the corresponding MUD file and enforce behavioral constraints without requiring manual intervention or additional device-side configuration. This design leverages the modularity of FDO to not only automate secure onboarding but also serve as a transport channel for conveying post-deployment security metadata—such as the MUD reference. By integrating this information early in the lifecycle, the transition from onboarding to policy enforcement becomes seamless and robust. Figure 4.2: FDO onboarding flow with MUD URL delivery during ownership transfer Reference Implementation: pri-fidoiot To realize the onboarding workflow described above, the open-source reference implementation of FDO provided by the FIDO Alliance was used 1. 1https://github.com/fido-device-onboard/pri-fidoiot 22 Design and Implementation The services were launched using the official docker-compose.yml provided in the repository. Configuration files were customized to inject the MUD URL into the device metadata during DI. Additionally, cryptographic keys were pre-generated using the tools bundled in the project, and the ownership vouchers were signed with the Manufacturer’s key and stored in the appropriate registry for retrieval during the onboarding session. A minimal reproducible setup was defined with the following command: Listing 4.1: Launching pri-fidoiot with Docker Compose 1git clone https://github.com/fido-device-onboard/pri-fidoiot.git 2cd pri-fidoiot/pri-fidoiot/component-samples/demo/aio 3docker compose up --build 4cd pri-fidoiot/pri-fidoiot/component-samples/demo/device 5docker compose up --build This commands initializes the full onboarding stack: Manufacturer, Rendezvous, Owner, and Device services. Once running, the simulated device initiates onboarding, and the MUD URL is transmitted as part of the TO2 payload. The Owner Server then passes this URL to the MUD Manager for policy retrieval and enforcement, as described in the next section. 4.3 MUD Policy Enforcement Figure 4.3: FDO-based onboarding and MUD policy enforcement flow Once the device has been successfully onboarded through the FDO protocol and the ownership has been transferred to the operator, the next critical step is to establish runtime control over the device’s network behavior. This is achieved through the MUD framework, which enables 4.3. MUD Policy Enforcement 23 the automatic retrieval and enforcement of security policies defined by the manufacturer. These policies constrain the device’s network activity to what is strictly necessary for its legitimate operation. The MUD integration begins at the end of the FDO TO2 phase, when the Owner Server receives the MUD URL associated with the device. This URL, which was injected during the Device Initialization phase by the manufacturer, points to a JSON-formatted MUD file hosted on a MUD File Server under the manufacturer’s control. The Owner Server forwards this URL to the MUD Manager, which is responsible for orchestrating the policy enforcement workflow. The MUD Manager performs several key functions. First, it retrieves the MUD file and its associated digital signature. Authenticity and integrity are then verified using the manufacturer’s public key. This validation step is crucial to prevent malicious actors from substituting or tampering with the policy definitions. Once verified, the MUD file is parsed according to the IETF RFC 8520 schema. The MUD file contains definitions for allowed communication behaviors. These are typically expressed in terms of permitted protocols, DNS names, and ports. For example, a smart sensor may be permitted to contact only a specific cloud endpoint over HTTPS, while being blocked from accessing local or peer-to-peer services. These policy elements are then translated into actionable policy. This allows the policy to be integrated into a higher-level orchestration framework, referred to here as the Domain Orchestrator. The orchestrator maintains a global view of active device policies and enables auditing, conflict resolution, and lifecycle management at a system-wide level. In this implementation, a simplified Domain Orchestrator is used to directly generate and apply iptables commands based on the parsed MUD entries. This approach supports rapid prototyping and validation of enforcement logic while maintaining a clear path to integration with more scalable enforcement engines (e.g., via SDN controllers or enterprise firewalls). The combination of policy validation, rule generation, and centralized orchestration ensures that the device is immediately placed under a set of strict behavioral constraints that reflect the manufacturer’s intended operation. This significantly reduces the attack surface of the device and prevents unauthorized or anomalous communications from occurring—even in the event of partial device compromise. By delegating enforcement to infrastructure-level components and automating the entire retrieval and validation pipeline, the system aligns with the principles of zero-trust networking and least privilege. More importantly, it enables seamless transition from onboarding to continuous security enforcement, ensuring that device behavior is predictable, auditable, and bounded from the first moment of deployment. 4.3.1 Interpreting a MUD File The MUD file used in this implementation corresponds to a Siemens IoT device model 10294230 and is hosted at the specified URL . This file follows the IETF MUD specification (RFC 8520) [3] and serves as the basis for defining the legitimate communication behavior expected from the device. Unlike in previous architectural versions, the MUD Manager in this implementation no longer acts as the enforcer. The key elements defined in the file are: •Metadata: The file declares general information such as mud-version,last-update, 30 Design and Implementation metadata—such as the device’s MUD URL—is delivered to the owner’s domain. This metadata becomes the entry point for the next stage: policy enforcement. As soon as onboarding is complete, the MUD Manager retrieves the MUD file and applies the manufacturer-defined policies to control the device’s network behavior. These rules are enforced immediately, narrowing the attack surface by allowing only the communications explicitly declared as necessary. This aligns the deployment with least privilege and zerotrust principles from the outset. The architecture then extends beyond initial policy enforcement by incorporating Threat MUD, which enables dynamic response to security events. When a threat affecting a specific device or firmware version is identified, the CTI system triggers the generation and distribution of a Threat MUD file containing updated mitigation actions. The Threat MUD Manager receives the threat notification, retrieves the corresponding file, validates its authenticity, and seamlessly updates the policy enforcement layer. This feedback loop ensures that policy enforcement remains relevant and responsive throughout the device’s lifecycle. The Domain Orchestrator plays a central coordinating role. It collects the policies from both MUD and Threat MUD processes, maintains a unified view of the active rules across all devices, and supports auditing, compliance checking, and conflict resolution. In this way, local enforcement decisions remain autonomous and efficient, while global oversight and traceability are preserved. Taken together, the architecture supports the secure onboarding and operation of IoT devices under changing threat conditions. Devices are automatically trusted at deployment, governed according to known-good behavior, and protected against emerging threats without requiring firmware updates or user intervention. This continuous security posture provides a scalable and standards-based model for deploying and managing secure-by-design IoT infrastructures. 5 Evaluation This section presents the evaluation of the proposed lifecycle security architecture, focusing on three main aspects: (1) the security pipeline, which includes onboarding and MUD policy enforcement; (2) the dynamic security response provided by Threat MUD; and (3) the overall end-to-end performance and integration of the entire system. Each aspect is evaluated using real execution times extracted from the implemented testbed, with emphasis on automation, modularity, and latency. The evaluation is not centered on testing the scalability of enforcement rules in a large environment. Instead, the experiments use minimal but realistic configurations (specifically, for constrained devices like IoT environments) to validate the full integration of FDO, MUD, and Threat MUD in a controlled scenario. This allows us to focus on the management of the workflow and the interoperability between components, which is the core contribution of this work. 5.1 Test-bed To validate the proposed architecture and measure its performance, a dedicated testbed was developed, simulating a realistic but controlled environment in which onboarding, policy enforcement, and threat mitigation operations could be observed and measured. The testbed includes the full lifecycle security pipeline: the onboarding infrastructure using FDO, the MUD policy enforcement infrastructure, and the dynamic policy update mechanism via Threat MUD. All components were deployed using lightweight containers and executed on a single server to ensure timing consistency and facilitate rapid iteration. Figure 5.1 illustrates the architecture of the testbed used to validate the integration of FDO and MUD during the device registration process in an organizational IoT environment. The depicted sequence represents the point where devices, having already undergone the DI (Device Initialization) step at the manufacturer’s site, are onboarding into the organization’s network via the FDO protocol. Hardware Environment The experiments were conducted on a Linux workstation with the following characteristics: • CPU: AMD Ryzen 7 7800X3D @ 4.2GHz • RAM: 64 GB DDR5 • Storage: 1 TB NVMe SSD • Operating System: Ubuntu 22.04.3 LTS (64-bit) under WSL2 32 Evaluation All services were hosted locally using Docker containers to ensure process isolation while avoiding external network-induced noise in measurements. Software Stack The system was implemented using a mix of open-source components and custom services: •FDO Implementation: pri-fidoiot (FIDO Alliance) 1for onboarding and ownership transfer. •MUD Manager: Developed in Python, using Flask for the REST interface and direct generation of iptables rules for enforcement. •Threat MUD Manager: Python-based microservice capable of parsing Threat IDs received via POST messages and retrieving the corresponding Threat MUD file. •CTI Simulator: A minimal threat simulator component that mimics the MISP behavior by sending a POST request to the Threat MUD Manager with a Threat ID. •Domain Orchestrator: A simplified Orchestrator that collects and logs all enforced policies in a centralized structure for inspection and visualization. Network Simulation Each device lifecycle was simulated in a self-contained Docker network, with isolated subnets representing the manufacturer domain, the rendezvous server, and the owner domain. This allowed precise emulation of protocol flows between: •Manufacturer Server →Device: Credential and metadata injection via FDO DI. •Device →Rendezvous Server: Discovery of the Owner Server (FDO TO1). •Device →Owner Server: Secure ownership transfer and metadata delivery (FDO TO2). •Owner Server →MUD Manager: MUD URL notification and policy retrieval. •CTI →Threat MUD Manager: Threat alerts via HTTP POST and mitigation activation. Metrics and Instrumentation To capture execution times and enforce policy validations, logging hooks were embedded at the boundaries of each protocol phase. Timestamps were extracted at: • Onboarding request initiation and ownership voucher confirmation (FDO TO0–TO2). • MUD file retrieval, signature validation, and rule injection. 1https://github.com/fido-device-onboard/pri-fidoiot 5.2. MUD Rule Enforcement and Translation Latency 33 Figure 5.1: Test-bed architecture • Threat MUD POST receipt and policy update confirmation. Logs were processed using Python scripts to compute averages, distribution, and comparative visualizations included in Section 5. This modular testbed provided an accurate and reproducible environment for validating the architectural claims and performance characteristics of the proposed secure onboarding and policy lifecycle system. 5.2 MUD Rule Enforcement and Translation Latency This section analyzes the performance of the MUD enforcement phase after the FDO onboarding completes. Once the device finishes the TO2 step, the Owner Server extracts the MUD URL and initiates a POST request to the MUD Manager, which triggers the retrieval, parsing, and translation of the MUD file. This request introduces a slight delay, but as it involves only a single HTTP POST transaction, its contribution to the overall delay is negligible. It is important to clarify that each MUD file used in this evaluation defines only two rules: one for outbound traffic and one for inbound traffic. This decision was made deliberately to reduce noise in timing measurements and to shift focus toward validating the interoperability between FDO and the policy manager. Consequently, the results shown here are not meant to demonstrate scalability in terms of rule complexity or quantity. Instead, the emphasis lies in showing that the complete FDO-to-MUD policy application process works reliably and within latency thresholds suitable for constrained environments. 34 Evaluation Figure 5.2: Total Time from FDO TO1 to MUD Policy Applied The first evaluation focuses on measuring the total time required to securely onboard a device and apply its MUD policy. This corresponds to the time between the start of the TO1 phase and the completion of the policy application triggered by the MUD Manager. The experiment was performed over a batch of 20 simulated devices, each configured with a unique MUD file containing two ACL rules defining permitted communication behaviors. Figure ?? shows the total measured time required to complete the entire lifecycle—from the start of the FDO process (TO1) through the successful application of the MUD policy. The results across a set of 20 distinct device executions demonstrate an average end-to-end completion time of approximately 838 ms, with a median value of 840 ms. Individual device times ranged between roughly 600 ms and slightly above 1000 ms, indicating some variability primarily attributable to container scheduling overhead and minor network latency fluctuations within the Docker environment. The lifecycle latency is further broken down into two distinct phases in Figure ??: the onboarding phase (FDO TO1→TO2) and the policy enforcement phase (MUD retrieval, translation, and enforcement). Here, we observe that the onboarding phase completes in approximately 256 ms, while the subsequent policy enforcement phase averages around 374 ms. The enforcement phase includes the slight additional latency introduced by forwarding the MUD URL through a single HTTP POST request from the Owner Server to the MUD Manager. This HTTP transaction introduces minimal delay and does not significantly impact overall performance, demonstrating the feasibility of adding integration points between FDO and external management components with negligible latency penalty. Figure 5.4 offers a detailed breakdown of the execution times for each phase of the lifecycle 5.2. MUD Rule Enforcement and Translation Latency 35 Figure 5.3: End-to-End Lifecycle Security: Execution Time by Phase (Average) security process across individual devices. Specifically, it distinguishes clearly between the onboarding phase (FDO TO1→TO2, represented in blue) and the MUD policy enforcement phase (MUD Received at MUD Manager→Policy Applied, represented in orange). The results indicate some variability in execution times across different devices, reflecting minor fluctuations in system load, resource availability, and Docker container scheduling. Despite this variability, the onboarding phase remains relatively consistent across devices, generally around 200–300 ms. Conversely, the policy enforcement phase exhibits greater variability, ranging approximately from 100 ms up to 700 ms. This variability in the enforcement phase primarily stems from the operations involved in retrieving, parsing, translating, and also some network latency within Docker environment. Device-specific observations also highlight instances such as Device1 and Device5, which present noticeably higher enforcement times compared to the rest. These instances could be attributed to transient container resource constraints or temporary network delays within the testbed environment. Nevertheless, even in these more delayed cases, the total lifecycle completion remains comfortably within sub-second latency, indicating a robust and reliable integration pipeline capable of rapid onboarding and policy enforcement. Overall, this per-device analysis underscores the consistent performance of the onboarding process (FDO), while also highlighting areas where minor optimizations in the policy enforcement pipeline could further stabilize response times across varying deployment conditions. Table 5.1 presents a comparative analysis between the proposed FDO and MUD-based approach and other relevant state-of-the-art onboarding and policy enforcement solutions. The results clearly highlight that the solution developed in this work (FDO + MUD) achieves rapid onboarding and immediate policy enforcement, with an onboarding time of approximately 256 ms and a policy enforcement delay of about 374 ms per MUD, which is 36 Evaluation Figure 5.4: End-to-End Lifecycle Execution Time by Device and Phase Table 5.1: Comparison of Onboarding and Policy Enforcement Times Approach / Solution Onboarding Time Policy Enforcement Time FDO + MUD ~256 ms ~374 ms Wi-Fi EasyConnect [4] Seconds Not integrated ASOP [8] 1.5–2.0 s Not explicitly measured ONOS SDN Controller [10] N/A ~320 ms per rule 5.3. Threat MUD Evaluation and Response 37 187 ms per Rule. This positions our solution as highly competitive, significantly outperforming the onboarding latency of alternative approaches such as the ASOP protocol, which reports onboarding times in the range of 1.5–2.0 seconds, and Wi-Fi EasyConnect, which only provides qualitative timing data on the order of seconds without explicit integration of subsequent policy enforcement. Regarding policy enforcement, the closest comparable solution is the ONOS SDN Controller, which achieves enforcement latencies of around 320 ms per rule. While the ONOS solution demonstrates a similar enforcement latency, it does not directly incorporate onboarding within its scope. Thus, the advantage of our proposed architecture lies not only in its comparable enforcement speed but also in its seamless integration of secure onboarding with immediate enforcement, providing an end-to-end lifecycle security solution in under one second. Overall, the comparison underscores the efficacy and efficiency of the proposed architecture, emphasizing its strengths in integrating and automating secure onboarding and rapid policy enforcement within a unified, standards-compliant framework. 5.3 Threat MUD Evaluation and Response This section details the evaluation of the Threat MUD component, emphasizing the responsiveness and integration capabilities of dynamic threat mitigation within the lifecycle security architecture. Similar to the previous evaluation, the primary aim here is to demonstrate correct operational integration rather than to evaluate the scalability or complexity of the rule enforcement. Therefore, each Threat MUD file tested includes only two straightforward mitigation rules (one inbound and one outbound). This simplification facilitates clear timing measurements and keeps the focus firmly on integration and process automation. Threat notifications were simulated using controlled HTTP POST requests containing unique threat identifiers. Upon receiving these notifications, the Threat MUD Manager automatically retrieves the corresponding Threat MUD file, validates its authenticity, translates the included mitigation rules into iptables commands, and finally propagates these rules to the enforcement point. Figure 5.5 provides the execution times for processing each distinct threat notification. Results indicate consistent responsiveness, with measured times ranging from 63 ms to 85 ms and a median response time of 67 ms, reflecting high predictability and reliability in threat response across different scenarios. The mean value across all evaluated threats was approximately 70 ms, reaffirming that the architecture provides a rapid and effective security response that meets real-time operational requirements. The cumulative latency measured at each step is shown in Figure 5.5, with results obtained from 5 different threats. The full process from threat detection to enforcement was completed in under 100 milliseconds, demonstrating that the proposed system is capable of reacting to emerging threats in near real-time, without requiring manual intervention or static patching logic. A critical aspect evaluated was the ability to integrate Threat MUD dynamically and seamlessly into the existing MUD infrastructure without requiring manual intervention or significant additional overhead. The Threat MUD Manager was developed to leverage existing 38 Evaluation Figure 5.5: Threat MUD Phase Execution Time per Threat MUD management procedures, allowing straightforward incorporation of new threat-related metadata. The architecture demonstrated an efficient mechanism to automatically handle threat-driven policy updates, highlighting its adaptability to dynamic threat intelligence environments. The most notable integration challenge at the project’s inception was the lack of a standardized mechanism within the existing FDO or MUD specifications to incorporate threatspecific metadata dynamically. To address this, the Threat MUD extension was designed to operate independently yet remain fully compatible with the standard MUD architecture. This required defining clear interactions and data flows between the Threat MUD Manager, orchestrator, and enforcement points. Ensuring compatibility and seamless transitions between MUD policies and dynamic threat-driven policies constituted a significant design and implementation achievement of this work. To contextualize the performance of the Threat MUD extension, lets compares the process latency from the threat received until applied rules against other state-of-the-art dynamic security systems. Table 5.2 compares enforcement delays of the Threat MUD mechanism developed in this work against other contemporary threat mitigation systems. The results clearly highlight the exceptional responsiveness of the Threat MUD solution, achieving enforcement delays consistently below 100 ms. This low latency in the process is mainly attributed to the fully automated pipeline designed for rapid threat metadata retrieval, validation, translation, and enforcement. By comparison, the ONOS SDN Controller—commonly considered a high-performance 5.4. End-to-End Lifecycle Security Summary 39 Table 5.2: Comparison of Enforcement Delays for Threat Mitigation Systems Solution Enforcement Delay Notes / Source Threat MUD <100 ms Fully automated mitigation pipeline, including rule translation ONOS SDN Controller [10] ~320 ms Intent insertion latency using flow rules in SDN AWS IoT Device Defender [11] >1.5 s <5 s Uses cloud-based IAM and alert-toaction model via Lambda Manual Security Response Minutes–Hours Human-in-the-loop firewall or DNS rule updates enforcement solution—exhibits approximately 320 ms of delay, significantly higher than the Threat MUD approach. The AWS IoT Device Defender, leveraging cloud infrastructure and a Lambda-based alert-to-action model, introduces considerably longer delays, typically ranging from 1.5 to 5 seconds. Lastly, traditional manual security responses, which require human intervention for firewall or DNS rule updates, result in latency ranging from several minutes up to hours. The comparison underscores that the Threat MUD approach developed in this work offers substantial advantages in automated threat response speed and integration simplicity, making it especially suitable for environments requiring immediate reaction to emerging threats. 5.4 End-to-End Lifecycle Security Summary To evaluate the overall effectiveness of the proposed system, the onboarding, policy enforcement, and threat response stages were executed in sequence, simulating the full lifecycle of an IoT device under active security management. The measurements capture the cumulative latency introduced at each phase and reflect the responsiveness of the system under normal and adverse conditions. As shown in Figures 5.5 and 5.3, the entire process from secure onboarding using FDO, through MUD-based policy application, to dynamic response with Threat MUD—completes in approximately 800 milliseconds. Each component contributes predictably to the lifecycle, and the design allows for fully autonomous execution once the device is deployed. The FDO onboarding step accounts for just less than 300 milliseconds, followed by 374 milliseconds for MUD policy retrieval, validation, and enforcement. In the case of a threat, the Threat MUD component can complete detection to enforcement within another 100 milliseconds. Compared to conventional alternatives, which require human intervention, firmware updates, or manual firewall rule changes, the automated lifecycle management presented here is significantly faster and inherently scalable. Beyond latency metrics, the system achieves a high degree of policy fidelity and compliance with best practices such as zero-touch deployment, least privilege, and threat-informed These results demonstrate that the integration of FDO, MUD, and Threat MUD provides not 46 Bibliography [12] Alejandro Molina Zarca, Jorge Bernal Bernabe, Ruben Trapero, Diego Rivera, Jesus Villalobos, Antonio Skarmeta, Stefano Bianchi, Anastasios Zafeiropoulos, and Panagiotis Gouvas. Security management architecture for nfv/sdn-aware iot systems. IEEE Internet of Things Journal, 6(5):8005–8020, 2019. doi: 10.1109/JIOT.2019.2904123.