Manna SafeioD: A Framework and Roadmap for Secure Design in the Internet of Drones

Abstract

With the increasing adoption of advanced drone technologies across diverse fields, the Internet of Drones (IoD) has emerged as a novel mobility paradigm, particularly enhancing Intelligent Transportation Systems (ITS) in urban environments. Despite its significant potential, the IoD faces substantial challenges due to inherent resource constraints such as limited computational power and energy capacity, which hinder the implementation of robust cybersecurity solutions. These limitations expose IoD networks to various security vulnerabilities and privacy threats, necessitating an exhaustive analysis and understanding of these risks. In this paper we introduce SafeIoD, a comprehensive security framework designed to establish standardized procedures for proactive risk identification in Internet of Drones (IoD) devices. It involves sequential steps to determine the trustworthiness of devices subjected to these certification. Therefore, SafeIoD seeks to ensure a basic security level before implementation in a real scenario, where the network devices are evaluated in regards to the specific security requirements. Validation through experimental testing with 15 participants across four IoD deployment scenarios and one military certification case demonstrated the framework’s effectiveness: the tool achieved 73% user satisfaction rating, successfully identified an average of 3.0 security requirements per device, and provided specific lightweight cryptographic algorithm recommendations for 62.2% of elicited requirements. In a tactical military scenario simulation, the framework accurately predicted risk propagation patterns, with COOJA network simulations confirming that implementation of framework-recommended protocols reduced successful attack propagation from 60% to below 5% of the network.

1. Introduction

The rapid advancement of unmanned aerial vehicle (UAV) technology has facilitated the emergence of the Internet of Drones (IoD), a promising mobility paradigm significantly contributing to the advancement of Intelligent Transportation Systems (ITS), particularly within urban environments [1,2]. The IoD constitutes a layered network architecture orchestrating drone operations in regulated airspace, integrating UAVs, Zone Service Providers (ZSPs), regulatory bodies, and wireless communication infrastructures [3]. This architecture supports critical drone-to-drone (D2D) and drone-to-infrastructure (D2I) communication, utilizing advanced communication technologies such as Automatic Dependent Surveillance—Broadcast (ADS-B), cellular networks, and specialized low-altitude air traffic management protocols.

The utilization of these platforms has experienced exponential growth annually, encompassing applications in transportation logistics, artistic and entertainment domains, surveillance operations, precision agriculture, and numerous other sectors. According to Gartner’s market intelligence analysis, the commercial drone sector is projected to achieve revenues of $129 billion by 2026, underscoring the increasingly critical role of unmanned systems in the contemporary technological ecosystem.

Security is one of the significant challenges to be addressed in this unique scenario to avoid attacks from different sources [1,4,5]. Since civilian drones are in the airspace, a range of attack methods can be more harmful than grounded mobile networks, as extensively discussed in this work. For instance, drone vandalism can harm a person’s life, where the damaged drone may fall on a person’s head. In the same way, jamming can isolate a group of drones from the entire network, hindering an ITS service such as traffic monitoring. Furthermore, airspace is susceptible to novel attacks which are unprecedented on grounded networks.

The primary vulnerability vector in IoD architectures resides in wireless communication infrastructure which, by nature, is inherently prone to transmission errors, communication losses, and service interruptions. These failure modes are extensively documented in the literature on MANETs (Mobile Ad-Hoc Networks) and FANETs (Flying Ad-Hoc Networks) [6]. The high mobility characteristics of drone platforms, as emphasized by [5], significantly amplify scenario complexity, given that fleet coordination and data exchange must maintain extremely precise operational parameters. Additional critical considerations include energy consumption constraints and computational resource limitations. Drone platforms may lack sufficient computational resources to implement sophisticated cryptographic protocols, as demonstrated by studies such as [7,8], which reveal that contemporary cryptographic systems can be readily compromised under resource-constrained conditions. Efficient resource allocation must therefore be employed to optimize energy consumption, both in terms of data communication overhead and drone routing optimization.

Consequently, information security and IoD device protection can be considered the most valuable assets for organizations, highlighting the necessity for methodologies capable of ensuring the security of such assets, including user information, trajectory data, and sensitive organizational intelligence.

Concurrently, researchers and information security professionals have sought to develop techniques for detecting and mitigating various attack types. These techniques range across monitoring mechanisms, control policies, prevention methodologies, and detection systems. Within this context, the necessity emerges for developing a methodology for evaluation, certification, and monitoring of IoD architectural devices, capable of measuring, identifying, and analyzing the security posture of processes, controls, assets, systems, and networks. The Manna SafeIoD Framework seeks to address an existing gap in the real-world implementation of the IoD concept, specifically answering the fundamental question: “How can we ensure that devices possess the minimum security level required to operate within different domains without compromising human safety or the architectural integrity itself?” This response is essential for secure implementation. Along this research trajectory, the present work proposes a systematic methodology for device risk analysis as well as the criteria and necessary steps for implementing certification entities that seek to evaluate and authorize devices for real-world deployment.

1.1. Problem Statement and Motivation

There exists widespread consensus within the academic community that cyberattacks constitute a serious threat to IoD architectural implementation, with numerous proposals addressing this challenge [9]. However, it is not uncommon for evaluations of different threats to rely more heavily on inferential analysis rather than empirical validation of their severity, based on concrete evidence demonstrating actual damages and impacts. Typically, vulnerability assessment methodologies fail to consider the attack environment or adversarial perspectives. Consequently, obtained results are, at minimum, incomplete, necessitating more precise viewpoints for such evaluations.

The lack of methodological rigor in current literature-based methodologies can be addressed through the development of cybersecurity certifications for IoD systems. Certifications aim to define evaluation methods for information system components to establish criteria for measuring whether specific devices meet minimum security requirement sets for market deployment authorization. Additionally, these frameworks establish clear monitoring processes to guarantee compliance with established requirements based on certified scenarios and certification entities. Ref. [10] defines NIST SP 800-37 [11] cybersecurity certification as a comprehensive assessment of technical security operations and controls within an information system to determine correct implementation of security mechanisms meeting minimum requirements. An exemplary requirement includes ensuring that two devices can perform mutual authentication for message exchange [12].

Although security standardization and certification are fundamental for guaranteeing IoD device protection, the current literature remains deficient in works addressing this specific thematic area. However, the utilization of certifications for IoT devices can serve as an initial reference framework. In recent years, IoT device security has been extensively explored, encompassing diverse technologies ranging from physical devices to Internet infrastructure. As defined by ISO/IEC 20924:2024 [13], the IoT paradigm aims for connectivity among any physical objects that can be instrumented with sensors and actuators, connected primarily through wireless technologies.

The increasing utilization of IoT devices has led to a need to develop security certifications which promote a trustworthy digital ecosystem. The Security Compliance Frame-work [14] provides best practices for device evaluation processes considering the complete data lifecycle. Similarly, the IoT Trust Framework [15] describes principal strategic aspects for defining security levels associated with data in IoT devices. Beyond the cited works, governmental initiatives for creating methodologies and certifications can be identified: in the United States, the NIST (National Institute of Standards and Technology) [16] describes cybersecurity risk management processes. In the European Union, ENISA (European Union Agency for Network and Information Security) [17] seeks to establish and coordinate the creation of cybersecurity certification frameworks. In Japan, JISEC (Japan Information Technology Security Evaluation and Certification Scheme) [18] aims to evaluate security system functionalities in general IT products.

Despite generic certifications—such as JISEC and the IoT Trust Framework—for IoT presenting high maturity levels, the presented methods and procedures fail to consider various particular aspects of IoD systems. Therefore, it becomes necessary to define specific certification frameworks tailored to this architectural paradigm.

1.2. Goals and Contributions

The need to define a secure design framework for the IoD ecosystem is crucial from both civilian and military points of view. Drones in an IoD network can operate in hostile environments and must therefore be protected from possible threats. Furthermore, devices need to be classified concerning the level of the security system, in order to operate in civil and military missions.

Given the context, motivations, and nature of the research problem, this study’s main objective is to propose the development of a homogeneous and global framework for carrying out secure design processes, enabling the analysis and release of IoD devices for use in a real environment.

The Manna SafeIoD is a security framework designed to facilitate the development and implementation of secure IoD devices. This framework provides essential technical guidance to help industry stakeholders build robust and secure IoD environments. The proposed framework is organized into four core modules, each responsible for delivering a specific set of security functions:

• A threat assessment methodology that accounts for operational context variability and environmental factors specific to IoD deployments.
• A novel and clear definition of procedures for device risk analysis.
• Security control establishment and certificate validation processes.
• A CLI-based tool that provides a simple interface for interacting with the framework.

Beyond the framework implementation, this work provides the following scientific contributions:

• Mathematical Formalism and Threat Modeling: We introduce a formal mathematical representation of IoD attacks, clearly defining the entities involved, attack behaviors, and related security aspects. This approach establishes a general model applicable to various attack scenarios, supporting rigorous analysis concerning model correctness, computational complexity, and systematic vulnerability assessments.
• Integrated Taxonomy of Attacks: We propose a unified attack taxonomy based on three critical dimensions: the primary threat source, the attack behavior, and associated privacy and security issues. This taxonomy comprehensively categorizes threats into Communication Threats, Environment Threats, and Drone Threats, providing a foundational framework for future research and threat mitigation strategies.

To systematically evaluate the effectiveness of the proposed framework, this research addresses the following questions:

• RQ1 (Security Requirements Elicitation): Can the Manna SafeIoD framework effectively generate context-appropriate security requirements for heterogeneous IoD components, and to what extent can it recommend suitable lightweight implementations?
• RQ2 (Risk Assessment Validity): Does the risk propagation model accurately predict attack propagation patterns in IoD network topologies, and do the computed risk scores correlate with observed security outcomes?
• RQ3 (Cross-Context Applicability): Can the framework adapt its certification workflow to diverse operational contexts—spanning resource-constrained civilian devices to mission-critical military deployments—while maintaining acceptable usability for practitioners with varying security expertise?

1.3. Paper Organization

This survey is organized as shown in Figure 1. First, Section 2 describes the related works of the main certification methods. Section 3 presents the background knowledge required to understand the IoD ecosystem, including drone architecture and comparative analysis with traditional mobile networks. Then, in Section 4, we develop our comprehensive threat modeling methodology, presenting the taxonomy of threat actors and detailed classifications of natural, physical, and cyber-threats. In Section 5, we introduce the Manna SafeIoD framework definition, detailing its four core modules: context establishment, risk assessment, maturity reporting, and security requirements engineering. Section 6 describes the framework implementation, presenting the software architecture, command-line interface, risk calculator algorithm, and output interface. Section 7 presents our experimental validation, including usability testing. Finally, in Section 8, we discuss the evaluation findings, identify limitations, and outline future research directions. We conclude the paper by summarizing our contributions to IoD security certification.

2. Related Works

Despite the widespread adoption of drones, current hardware designs still exhibit vulnerabilities that may be exploited for data theft, route tracking, or denial-of-service purposes. Drones expose five primary attack surfaces that can be targeted by malicious actors: hardware, communication channels, control stations, pilots, and backend servers [19].

In recent years, the discussion surrounding security aspects has received substantial attention from both academia and industry. Ref. [20] presented a comprehensive survey on potential attacks targeting three core components of the IoD architecture: communication, computing power, and control subsystems. They also discussed the impact of such attacks on data security and privacy. Ref. [5] argued that recent literature on attacks clearly shows how relatively easy it will be to construct highly effective tools aimed at data degradation in smart city scenarios involving IoD systems.

The prevailing perception is that the consequences of security failures are even more critical in IoD environments, due either to the execution of critical operations by the devices, the vast volume of data exchanged over the network, or both [9]. Attacks such as jamming [21], spoofing [22], and hijacking [23] are among the most studied in the literature, given their potential to exhaust or circumvent device and infrastructure resources, leading to service disruption and, therefore, system unavailability.

Considering the implementation of a secure IoD network in smart city contexts, ref. [24] applied threat tree modeling to identify and classify known vulnerabilities in multi-drone systems. The author concluded that ensuring the security of IoD deployments requires accounting for device reliability across communication, mobility, and traceability dimensions.

Ref. [25] introduced DRAT, an automated penetration testing framework for Wi-Fi-enabled drones. The tool integrates resources that allow for the orchestration of different testing levels. However, despite its technical capabilities, DRAT focuses solely on commercial drones and does not address the unique requirements of IoD environments. Foundational works such as [26] showed that, since the early days of computing, systems have been subjected to various forms of testing to identify vulnerabilities. Nevertheless, more recent studies like [27] highlighted the continuing challenges in standardizing security evaluations. These authors argue that current methodologies often provide ambiguous and inconsistent techniques for assessing security posture in computing devices.

Ref. [28] proposed a risk analysis methodology for commercial drones based on the STRIDE model [29], enabling security evaluations across integrity, confidentiality, availability, and authorization dimensions. Their approach integrates penetration testing and digital forensic techniques. Although not exhaustive in its testing scope, its primary contribution lies in the definition of objective procedures and criteria to guide the scope and depth of testing. It is important to note, however, that the testing procedures presented in this work do not consider the broader context of the Internet of Drones.

The specific characteristics of an IoD environment—such as the integration of monitoring tools and techniques, and the lifecycle complexity of devices—make the definition of a cybersecurity certification process particularly challenging. However, it is possible to identify essential elements within leading cybersecurity certification schemes that are applicable to the IoD domain. These include the establishment of clear security criteria, the execution of vulnerability assessments and testing, and ensuring the regular update of device software and hardware.

According to [30], any cybersecurity certification must address three fundamental characteristics: target, context, and audience. These dimensions are inspired by the ECSCF the European Cybersecurity Certification Framework—used to guide certification classification within the European Union.

Figure 2 presents the scope of each of these three characteristics. Broadly speaking, the Target refers to the product, component, or service being certified. In an IoD context, this may include drones, ZSPs, cloud systems, gateways, and other infrastructure. The Context concerns the environment in which the certification process is conducted, which should faithfully represent the operational conditions to which the device will be exposed. A precise definition of the context contributes to a detailed set of security requirements, ultimately leading to more robust devices. Finally, the Audience refers to the stakeholder—whether regulatory body, user, or integrator—for whom the certification serves as a statement of compliance with security standards.

The following subsections present four of the most prominent cybersecurity certification schemes currently used in the market. Two of these are industry-defined [31,32], while the remaining two were designed within academic research initiatives [33,34].

2.1. Common Criteria

The Common Criteria (CC) refers to the international standard ISO/IEC 15408 [35] for cybersecurity certification [31]. CC ensures that IT devices are specified and evaluated in a methodical, repeatable manner and at a level of assurance appropriate to their intended operational environment. Within this certification framework, assets—designated as TOE (Target of Evaluation)—are assessed based on a tailored set of security requirements that correspond to the implementation type [12]. Devices may be certified at one of seven EAL (Evaluation Assurance Levels), where Level 1 represents basic assurance and Level 7 denotes the highest degree of security validation.

The work by [36] explored the implementation of EAL2-level requirements on IoT devices, specifically smart TVs. The authors argue that while EAL1 is often recommended for IoT, its baseline requirements are insufficient to counteract the broad spectrum of existing threats, thus necessitating the adoption of EAL2. Their study emphasizes the importance of incorporating security throughout all layers of IoT device development in order to ensure adequate protection against evolving attack vectors.

Although CC is a well-established certification framework, its application to IoT systems is limited, as noted by [37]. The substantial documentation requirements and implementation overhead pose significant barriers in this domain, which is characterized by unique challenges when compared to conventional information systems. Additionally, CC certifies only a specific version of a product in a defined configuration. This implies that each update or reconfiguration may require a complete re-certification process. This is especially problematic in the IoT context, where devices are frequently updated and modified, thereby demanding recurring certifications for each new version [38].

2.2. ICSA Labs

The IoT Security Testing Framework, defined by [32], establishes a set of security testing requirements for IoT systems. These requirements encompass aspects such as encryption, communication, authentication, physical and cyber-security, and real-time monitoring. A system that complies with all criteria is deemed suitable for deployment in real environments without compromising network functionality or security.

To address the constant evolution and updating of IoT devices, ICSA Labs incorporates frequent iterative updates into its certification process. This approach aims to tackle the inherent dynamism of the IoT landscape. To manage the device lifecycle effectively, ICSA Labs requires a contractual commitment from vendors, ensuring that device certifications are periodically reviewed and updated. Furthermore, random product assessments are conducted to enhance the robustness and credibility of the certification process.

According to [33], after the evaluation phase, if a product fails to meet the certification criteria, the responsible entity is granted a short remediation window to address the identified issues. Should the product fail to achieve compliance within this timeframe, the ICSA Labs certification is revoked. The certification must be renewed annually, with the entire process repeated from scratch. It is important to note that this process is conducted solely by entities authorized by ICSA, and that both the evaluation approach and criteria are not standardized, potentially varying between laboratories.

2.3. ARMOUR

The ARMOUR certification framework emerged as part of a European Union initiative designed to fulfill the security requirements of IoT devices. It is structured as an automated testing framework that incorporates benchmarks and formal evaluation processes. As argued by [33], its design adheres to the guidelines of the European Cyber Security Organisation (ECSO) and follows the standards set forth by the EU Cyber Security Certification Framework (ECSCF), which aim to harmonize certification practices across EU member states. In addition to the ECSO-prescribed components, ARMOUR introduces elements tailored to the specific security context of IoT devices.

The certification process consists of six phases, the final of which involves continuous device monitoring. It begins with a contextual assessment of the environment in which the device will operate, followed by a threat identification and modeling step based on the European Institute for Security Evaluation Standards’ risk analysis methodology [39]. For each identified vulnerability, targeted tests and mitigation strategies are applied. Ultimately, the device enters a continuous monitoring phase, during which new evaluations are triggered under two conditions: the discovery of a new vulnerability or the release of a firmware update.

As noted by [40], one of the defining features of this certification scheme is its labeling mechanism. A QR code is affixed to each certified device, linking to a webpage that displays the current certification status. This page may also provide context-specific results, such as assessments tailored to domestic deployment scenarios.

However, one limitation of the ARMOUR certification is that its vulnerability database is not publicly accessible. This lack of transparency raises concerns about the comprehensiveness and reliability of the evaluation procedures conducted during certification.

2.4. DSPSMA

In an effort to address the existing gaps found in the various cybersecurity certification schemes available on the market, ref. [34] proposed the Dynamic Security and Privacy Seal Model (DSPSMA). This model introduces a real-time monitoring process to be used in conjunction with existing certification frameworks.

The authors present a two-phase audit process. The first phase involves certification, which is flexible and allows for the integration of multiple existing standards. The application of these standards is assessed in accordance with the European Union’s regulatory landscape, including its electronic privacy directives such as the GDPR (General Data Protection Regulation). The integration of multiple normative standards helps to minimize blind spots in certification, since each framework has its limitations and can complement the others when combined.

The second phase involves continuous monitoring, ensuring that the certification remains valid over time. If a device receives an update that introduces known vulnerabilities, a violation alert is sent to the vendor for remediation. Should the vulnerability remain unresolved, the certification is automatically revoked.

One of the most innovative aspects of this certification architecture is the use of blockchain technology for log storage. The blockchain preserves the historical records of each certification event and guarantees the authenticity and integrity of the data. As future work, the authors propose the development of custom certification metrics specific to this dynamic model.

2.5. SORA

Focused on UAVs, the article [41] presented The Specific Operations Risk Assessment (SORA)—a risk assessment methodology developed by the Joint Authorities for Rulemaking on Unmanned Systems (JARUS). The European Union Aviation Safety Agency has adopted this process.

The author proposes a methodology that employs a 10-step process to evaluate risks associated with drone operations in the Specific category—operations that fall between the low-risk Open category and the high-risk Certified category. SORA classifies risks into two primary dimensions: the Ground Risk Class (GRC), which evaluates the risk of a drone striking persons or property on the ground, and the Air Risk Class (ARC), which assesses the probability of mid-air collisions with manned aircraft. The combination of GRC and ARC determines the Specific Assurance and Integrity Level (SAIL). Each SAIL level prescribes a set of Operational Safety Objectives (OSOs) that must be satisfied with appropriate levels of robustness—defined as the combination of integrity (safety gain) and assurance (demonstration method) [42].

One of SORA’s notable strengths is its context-adaptive approach: the methodology requires operators to define a detailed Concept of Operations (ConOps) that specifies the operational environment, drone characteristics, crew qualifications, and emergency procedures. This contextual assessment enables tailored risk evaluation rather than one-size-fits-all certification.

However, despite its widespread adoption and methodological rigor, SORA presents significant limitations when considered for IoD cybersecurity certification. First, SORA is fundamentally oriented toward operational safety rather than cybersecurity its risk dimensions (GRC and ARC) address physical hazards such as collisions and ground impact, but do not incorporate threat modeling for cyber attacks, including jamming, spoofing, or hijacking. Second, SORA does not provide mechanisms for security requirements engineering—for example, deriving technical security controls from identified threats. Consequently, while SORA represents the most mature UAV-specific risk assessment framework currently available, it addresses concerns complementary to, but distinct from, the cybersecurity certification gap targeted by the present work.

2.6. GCACS-IoD

In the context of IoD-specific security solutions, ref. [43] proposed GCACS-IoD, a certificate-based generic access control scheme designed to secure communication within IoD environments. The framework addresses two fundamental authentication scenarios: inter-drone (D2D) communication between UAVs operating in the same or adjacent flying zones, and drone-to-ground station (D2GSS) communication. GCACS-IoD employs Elliptic Curve Cryptography (ECC) to achieve computational efficiency suitable for resource-constrained drones while providing anonymity and resistance to replay, impersonation, and man-in-the-middle attacks.

However, subsequent cryptanalysis by [44] revealed critical vulnerabilities in the original design, demonstrating that the private key of the trusted Control Room could be disclosed, enabling attackers to compromise the entire IoD network through malicious drone deployment and impersonation attacks. The authors proposed an improved version, iGCACS-IoD, which addresses these weaknesses through enhanced key management and formal verification. While GCACS-IoD and similar IoD authentication protocols represent important contributions to securing drone communication, they focus exclusively on specific security mechanisms—predominantly authentication and key agreement—rather than providing comprehensive methodologies for device certification, risk assessment, or security requirements engineering.

2.7. Other Certification Processes

In addition to the previously described certifications, some countries enforce specific regulatory processes for authorizing commercial use of IT and IoT devices. To ensure compliance with the General Data Protection Regulation (GDPR), the European Union issues a European Privacy Seal. This process involves manual audits conducted by certified experts [45].

In Singapore, the Security Accreditation Committee is responsible for issuing mandatory cybersecurity certifications for IT products supplied to government agencies. Similarly, in Germany, the Independent Centre for Privacy Protection (ULD) certifies IoT products as well as software, hardware, and services used by German authorities [46].

In the United States, the CTIA (The Wireless Association) defines a certification process for devices operating with Wi-Fi LTE technology [47]. The certification evaluates compliance with requirements in several security categories, including authentication, encryption, update management, and threat monitoring.

Table 1. Comparative Analysis of Cybersecurity Certification Frameworks Against IoD Requirements.

Certification	IoD Specific	Context Adaptive	Risk Assess.	Risk Propag.	Threat Model	Sec. Req. Eng.	Maturity Levels	Lifecycle Coverage	Tool Support	Open Access
Common Criteria	–	–	○	–	◐	◐	●	○	–	●
ICSA Labs	–	–	●	–	◐	○	●	◐	–	–
ARMOUR	–	○	◐	–	◐	○	●	◐	◐	–
DSPSMA	–	○	◐	–	◐	–	○	◐	○	○
SORA	○	◐	◐	–	○	–	●	○	–	●
GCACS-IoD	●	–	◐	–	–	◐	–	–	–	○
Manna SafeIoD	●	●	●	●	●	●	●	●	●	●

Legend: ● = Fully Supported; ◐ = Partially Supported; ○ = Limited Support; – = Not Supported.

summarizes and compares the discussed certification schemes in terms of their adherence to key components proposed by this thesis, such as IoD Focus, risk assessment, vulnerability analysis, auditing, and public access.

3. Background

There is a consensus regarding the precarious nature of security in environments populated by UAVs [48]. While mitigation strategies have been proposed for challenges in similar domains, such as IoT, UWSN and VANETs [14,49], the IoD sector faces a unique set of constraints. These include a notable absence of advanced protective features and a susceptibility to attacks that are both simple to execute and easy to scale [50]. Addressing these deficiencies requires the adoption of more robust, practical solutions designed to embed security fundamentals into the core of IoD systems.

3.1. IoD Environments

The Internet of Drones (IoD) is described by Gharibi et al. [1] as an architecture for airspace coordination. More broadly, it is recognized as a service-oriented network where drones act as bridges to other systems like the Internet and VANETs [51,52].

Distinct from other mobile paradigms such as WSNs, UWSNs, or cellular networks (compared in

Table 2. Comparative analysis of IoD attributes versus traditional mobile networks.

Characteristic	IoD	Cellular	Vehicular (VANET)	WSN	UWSN
Node Velocity	Rapid (>15 m/s)	Low mobility (<5 m/s)	Variable (Urban: ≈8 m/s; Highway: >20 m/s)	Quasi-static (Dependent on host)	Slow (Driven by water currents)
Mobility Pattern	Mission-dependent (3D)	Stochastic/Random	Constrained by road infrastructure	Mostly Random	Dictated by fluid dynamics
Verticality (Altitude)	Significant variation	Negligible	Negligible	Negligible	Significant variation
Topology Dynamism	High	High	High	Low	Low
Computational Capacity	Moderate	High	High	Limited	Limited
Power Limitations	Critical	Moderate	Relaxed	Critical	Critical

), the IoD presents unique architectural challenges. Its primary differentiator is the unrestricted mobility of nodes, which navigate airspace at high speeds with variable altitudes. Coupled with the energy constraints inherent to battery-powered embedded systems, this environment creates a complex security landscape. Consequently, ensuring the security of users and nodes in such a dynamic setting requires specialized solutions beyond traditional network approaches.

To establish a robust foundation for the Manna SafeIoD framework, it is imperative to formalize the nomenclature used throughout this research. We clarify the distinction between fundamental IoD mechanics and security-related constructs. Consequently, we adopt the following operational definitions regarding the IoD ecosystem:

• UAV Node (Drone): Defined as an aerial unit compliant with specific hardware and software protocols required to join the network. Beyond simple flight capabilities, this node must possess the computational resources to execute network tasks securely;
• Zone Service Provider (ZSP): While Gharibi et al. [1] originally coined this term for grounded airspace management, we expand its scope. In our framework, a ZSP represents any infrastructure entity—such as a Ground Control Station (GCS)—responsible for orchestrating navigation, enforcing policies, and guaranteeing Quality of Service (QoS) for connected nodes;
• Drone-as-a-Service (DaaS): This concept encapsulates the functional role of the UAV within the IoD. It signifies a paradigm where the drone acts as a service provider node, collaborating with other entities to fulfill specific user demands;
• Service Consumer (IoD User): The entity requesting services from the aerial network. Consumers range from human operators and government bodies to automated endpoints in external networks (e.g., a node in a VANET). Understanding the consumer’s profile is crucial for tailoring privacy levels;
• Operational Context (IoD Scenario): Refers to the physical and logical environment of deployment, such as dense urban centers or remote agricultural fields. Each context imposes unique constraints and security requirements that the IoD architecture must address.

3.2. Domain-Specific Implementations and Market Trends

The academic and industrial communities have increasingly treated drone technology as a sophisticated, layered mobile network rather than merely isolated devices. This shift has accelerated the adoption of DaaS across diverse sectors, including the Internet of Things (IoT) and Smart Cities initiatives. Such integration promises to reshape both urban and rural landscapes, offering tangible benefits to social welfare. Comprehensive surveys [51,53,54] have already cataloged the primary domains of DaaS. We synthesize these domains below, focusing on their operational characteristics and data implications:

• Disaster Management and Response: UAVs are critical assets for public safety during crises like tsunamis, floods, or hostile attacks [55]. In these scenarios, the primary function is the real-time transmission of high-bandwidth data (video feeds) to command centers to aid decision-making;
• Environmental Sensing: Functioning as airborne IoT nodes, drones extend the range of data acquisition networks. They are pivotal for tasks such as atmospheric pollution analysis and wildfire detection [56]. These units typically carry specialized payloads, including LIDAR, scatterometers, and spectrometers, to aggregate data from ground sensors or perform direct measurements;
• Infrastructure Integrity Assessment: In sectors like civil engineering and industrial manufacturing, UAVs provide a safer alternative for inspecting physical assets. By utilizing directed video streams and sensor telemetry, they allow experts to monitor hazardous industrial zones or construction progress remotely [57];
• Intelligent Transportation Support: Drones serve as a complementary layer to terrestrial traffic management [58,59]. They assist in identifying congestion, accidents, and road hazards. Furthermore, through integration with Vehicular Ad Hoc Networks (VANETs), aerial nodes can broadcast alerts to drivers. This application requires the handling of sensitive information, including license plates and driver behavior patterns;
• Public Security and Crowd Control: For civil surveillance, aerial units offer a vantage point for monitoring large gatherings or riots [60]. The architecture typically involves continuous video uplink to a central monitoring station to assess crowd dynamics;
• Smart Farming: Precision agriculture utilizes UAVs to optimize inputs and maximize yields, proving to be a time-efficient solution for modern farming [55]. Similarly to infrastructure monitoring, this domain relies heavily on visual and spectral sensors to assess crop health and soil conditions;
• Last-Mile Logistics: Although still facing regulatory hurdles, aerial delivery (e.g., Amazon Prime Air) represents a growing sector for transporting goods and medical supplies [61]. Security is paramount here, as the network must process precise geolocation data and customer details while ensuring safe path planning;
• Aerial Network Extension: A novel application involves using drones as flying base stations to enhance wireless coverage or throughput for ground users. In this configuration, the UAV becomes a critical infrastructure node, relaying massive amounts of user-generated traffic [62];
• Renewable Energy Infrastructure: IoD systems have become instrumental in the global energy transition, enabling efficient inspection and maintenance of solar farms, wind turbines, and power grid infrastructure [63]. Equipped with thermal imaging and LiDAR sensors, drones can detect panel defects, blade cracks, and transmission line anomalies in real-time, reducing inspection time by up to 70% compared to manual methods while eliminating worker exposure to hazardous conditions [64]. The market for drones in power generation and distribution is projected to reach USD 4.4 billion by 2030, reflecting the sector’s critical dependence on IoD for predictive maintenance and operational resilience [65].

4. IoD Threat Modeling

Threat modeling [24] represents a systematic approach that encompasses identifying principal assets within a system and analyzing threats to these assets. According to [66], an asset constitutes anything of value to an organization. Within the IoD context, examples of critical assets include drone platforms, Zone Service Providers (ZSPs), cloud infrastructure providers, communication channels, navigation systems, payload systems, and mission-critical data repositories.

For this analysis, we employ the attack tree methodology to represent the threat modeling of IoD architecture. This approach, originally proposed in [24] and subsequently refined for cyber–physical systems [67], provides a structured framework for decomposing complex attack vector scenarios into manageable analytical components.

An attack vector within an IoD context consists of three fundamental entities: the malicious agent, the IoD device, and the actual target. This triadic relationship forms the foundation for understanding attack propagation in distributed drone networks as show

Table 3. Fundamental Entities in IoD Attack Vectors.

Entity	Description
Malicious Agent	Adversarial actor seeking to identify exploitable vulnerabilities. Ranges from nation-state actors with electronic warfare capabilities to opportunistic criminals using readily available attack tools.
IoD Device	Most vulnerable component serving as entry point. Encompasses drones, communication links, ground control stations, and supporting infrastructure with inherent resource constraints.
Actual Target	Critical system or asset the attacker ultimately seeks to compromise, including critical infrastructure, sensitive data repositories, or command systems beyond the immediate drone network.

.

4.1. Threat Actors

An attack constitutes an offensive action with malicious intent, such as stealing, altering, disabling, or destroying information through unauthorized access to computer systems [53]. The interconnective capabilities present in the IoD architecture, combined with their inherent processing constraints and energetic limitations, provide sufficient conditions that enable numerous attack vectors against systems and services [68].

To comprehensively evaluate threat landscapes in IoD environments, we categorize three distinct types of threat actors based on their capabilities, access levels, and operational constraints, as presented:

• Privileged Insider: Government officials, institutional personnel, maintenance technicians with direct physical access to drones/ZSPs. Can bypass technical controls through physical access and insider knowledge.
• Proximate External: Malicious hackers, unauthorized surveillance entities operating within service zone range. Enable RF attacks, signal interception, and electronic warfare techniques.
• Unintentional: Wildlife collisions, adverse weather, electromagnetic interference from legitimate sources. Non-malicious but can significantly impact operations and mask malicious activities.

4.2. Threat Classification

Drones and their associated IoD infrastructure are vulnerable to several categories of threats, which can be systematically classified into three primary types based on their origin, manifestation, and impact vectors:

• Natural Threats: Within the realm of IoD security, environmental vulnerabilities present pressing concerns that extend beyond traditional cybersecurity paradigms. Drones traversing airspace encounter various natural elements that can affect their operations, creating exploitable conditions for malicious actors. Environmental threats include meteorological phenomena such as wind shear, microbursts, electromagnetic storms, and atmospheric conditions that can disrupt navigation and communication systems. Neglecting these environmental factors provides attackers with opportunities to exploit adverse conditions, using weather patterns or aerial wildlife as cover for malicious activities, thereby disrupting IoD operations and compromising security postures [9].
• Physical Threats: Drones are inherently susceptible to physical attacks stemming from human intervention and environmental obstacles. These attacks encompass vandalism through deliberate damage or destruction of drone platforms [53], theft involving unauthorized appropriation of drone assets [69], and various forms of eavesdropping including ground-based signal interception and payload monitoring [70]. Physical threats pose substantial privacy and operational risks within the IoD ecosystem, causing direct harm to devices while exhibiting destructive behavior that can compromise mission integrity and data confidentiality.
• Cyber Threats: These threats exploit various network elements including drones, communication links (drone-to-drone and drone-to-infrastructure), cloud data storage systems, and ground control infrastructure. Cyber attacks often occur stealthily without causing immediate physical damage, making detection and attribution challenging. These threats are categorized into passive attacks such as automatic drone detection systems [71] and traffic analysis attacks [72], and active attacks including jamming techniques [73], various spoofing methods [74], hijacking attempts [23], and both software [75] and hardware exploitation techniques [76].

Figure 3 depicts the root of the attack tree, which serves as the focal point for all potential threats impacting an IoD system. These threats undergo iterative expansion, creating hierarchical subsets of threats represented as descendant nodes. To construct the tree, the attacks are subdivided into domains as described in

Table 4. Threat Categories in IoD Systems.

Category	Sub-Category	Description
Communication	Constrained-peer	D2D comms under energy/computational limits preventing robust security
	Non-constrained	Traditional vulnerabilities + mobile platforms/dynamic topology
Environment	Within-zone	Restricted movements; attackers exploit flight patterns/airspace constraints
	Inter-zone	Zone transitions via gates; vulnerabilities during handoff/boundary crossings
Provider	ZSP-related	Ground-based control system vulnerabilities
	Cloud-related	Targets: metadata, performance characteristics, operational parameters, ACL
Drone	Dual-role	Both attack victims and tools; compromised units attack other components

.

4.3. Cyber Attack Taxonomy

Considering the unique characteristics of IoD environments, cyber attacks represent the most critical threat category due to their potential for causing catastrophic damage to individual drones or entire network infrastructures. The sophisticated nature of modern cyber attacks, combined with the increasing connectivity of IoD systems, creates attack surfaces that extend far beyond traditional network security perimeters.

These attacks can be systematically classified into six primary categories, each representing distinct attack methodologies with specific technical characteristics and mitigation requirements:

• Jamming Attacks: These constitute denial-of-service attacks targeting communication channels between drones and ground control systems or other network components. Jamming attacks disrupt radio frequency communications, making coordination between drones and ground control stations difficult or impossible. In such scenarios, affected drones lose situational awareness, navigation capabilities, and command reception, potentially resulting in mission failure or catastrophic incidents [21]. Advanced jamming techniques may employ frequency-hopping or adaptive algorithms to overcome anti-jamming countermeasures.
• Spoofing Attacks: These exploit vulnerabilities in data links between drones and ground control systems, enabling interception and manipulation of unencrypted or poorly protected signals to mislead drone navigation systems. Spoofing attacks can target various systems including GPS receivers, altimeters, and communication protocols, potentially resulting in loss of accurate positional information, trajectory deviation, or complete drone theft [5]. Sophisticated spoofing attacks may combine multiple signal sources to create convincing false environments that are difficult to detect.
• Hijacking Attacks: These involve transmission of unauthorized ground control signals designed to usurp legitimate control authority and force drones to respond to attacker commands. Hijacking attacks can result in complete loss of drone control, unauthorized mission redirection, or deliberate destruction through commands such as emergency shutdown during flight [53]. Advanced hijacking techniques may exploit authentication weaknesses or session management vulnerabilities to establish persistent unauthorized control.
• Flooding Attacks: These attacks aim to overwhelm networks and individual services with massive volumes of data packets, preventing drones from accessing critical network services. Flooding attacks are categorized into Denial of Service (DoS) attacks targeting individual components [77] and Distributed Denial of Service (DDoS) attacks leveraging multiple attack sources to amplify impact [78]. In IoD contexts, flooding attacks may specifically target bandwidth-constrained communication links or resource-limited drone processing capabilities.
• Wormhole Attacks: These represent sophisticated routing-based attacks where malicious actors strategically position compromised drones or infrastructure components to create unauthorized communication tunnels. In wormhole attacks, two malicious nodes establish covert communication channels that bypass normal network routing protocols. Node A intercepts data packets in geographical area X and transmits them to Node B, which replays them in a different location, creating false proximity relationships and enabling various secondary attacks. Related attack variants include selective forwarding [79] and black-hole attacks [80] that share similar methodological foundations.
• Hardware/Software Exploitation: Both drone platforms and ground control systems are vulnerable to various forms of malicious software including malware [81], trojan horse programs [82], keyloggers, and side-channel attacks [83]. These exploits may be embedded during manufacturing processes or introduced through subsequent software updates or maintenance procedures. In IoD environments, successful exploitation can result in complete loss of operational security, unauthorized access to confidential mission data, or persistent compromise of communication channels that enables long-term surveillance or sabotage activities.

The evolution of IoD technologies continues to introduce new attack vectors and amplify existing vulnerabilities. The integration of artificial intelligence, machine learning, and autonomous decision-making capabilities in modern drone systems creates additional attack surfaces that adversaries may exploit. Future threat modeling efforts must account for these emerging technologies and their associated security implications to ensure protection of IoD deployments.

5. Manna SafeIoD Framework Definition

As discussed in [66], the IoD constitutes a complex cyber–physical system (CPS) integrating heterogeneous hardware, software, and communication components. While methodologies for secure design exist for general CPS and embedded systems [84,85,86], they fall short in addressing the contextual and environmental dynamism inherent to IoD deployments. This gap underscores the necessity for a tailored secure-by-design framework methodology specific to IoD.

The definition of an efficient IoD device evaluation framework must take into consideration three main aspects:

• Standardization: The utilization of drones is not confined to a specific region or country; therefore, certification should be standardized to provide a harmonized process across different contexts, domains, and countries.
• Context: Effective certification requires assessing the operational context of the device, including its intended use, expected data flows, and environmental constraints. This assessment is particularly difficult because the final application scenario is frequently unknown at the time of manufacturing.
• Environment: IoD systems and devices operate in physical environments with variable conditions that can affect their level of security. Therefore, the maturity of a device may vary depending on the deployment aspects to which it may be exposed. At the end of the initial certification process, the device may be evaluated against a set of security requirements, but the initial tested configuration and maturity level may be affected due to software updates, changes in system configuration, or the need to be used in different operational contexts. Considering that software updates and patches are quite frequent due to the discovery of new vulnerabilities, it is necessary to define a lightweight recertification process design to reflect the changes introduced in the devices.

Given the aforementioned characteristics, there is currently no suitable methodology tailored specifically for the IoD environment. This gap serves as one of our motivations to develop and introduce an evaluation security framework dedicated to this particular context. Figure 4 illustrates the diagram of the proposed evaluation methodology named Manna SafeIoD.

We have developed a straightforward methodology, the security assessment process represents the core of the methodology, integrating the context establishment, security risk assessment, security requirements and monitoring and review. These activities are described in more detail in the remainder of this section.

5.1. Context Establishment

This step is intended to provide a understanding of the deployment conditions, limitations, and operational contexts in which the IoD component is utilized. This phase draws upon best practices in security requirements engineering for cyber–physical systems [44] and governance frameworks [18], ensuring that the certification reflects real-world scenarios and evolving threat landscapes.

To accurately characterize the deployment and operational context, the following dimensions are analyzed:

• Deployment Environment: Detailed characterization of the physical and geographical environment, including:
  • Type of setting: indoor/outdoor, urban/rural, controlled/uncontrolled airspace.
  • Physical constraints: signal interference, electromagnetic exposure, terrain.
  • Environmental factors: wind, precipitation, temperature extremes.
• Mission Operation Type: Definition of the intended mission profile, including:
  • Purpose: surveillance, inspection, delivery, data collection.
  • Tasks: payload delivery, sensing operations, communication relays.
• Regulatory Environment: Mapping of applicable legal and regulatory obligations:
  • National/international aviation regulations (e.g., FAA, EASA, ANAC).
  • Cybersecurity frameworks and data protection laws (e.g., GDPR, LGPD (Brazilian GRDP), ISO/IEC 27001 [87]).
  • Domain-specific standards for communication and safety.
• Deployment and Maintenance Processes: Full lifecycle documentation:
  • Initial installation, configuration routines, and security onboarding.
  • Firmware updates, patch cycles, and preventive maintenance.
  • Roles and responsibilities of operational personnel.
• Contingency Procedures: Preparedness for failure and emergencies:
  • Protocols for link loss, GNSS spoofing, battery depletion.
  • Emergency return, shutdown, or recovery protocols.
  • Redundant communication mechanisms and fallback strategies.

Given that individual components possess unique architectural footprints and functional interfaces, they inevitably present different attack surfaces. Therefore, the characterization of the system must be performed through a multi-layered abstraction approach. This process involves collecting detailed metadata regarding the cyber-security context of every entity, from the edge (drones) to the core infrastructure (ZSPs and gateways).

5.2. Risk Assessment

The primary objective of the security assessment phase is to derive a quantifiable metric that reflects the security posture of the device under analysis. This procedure is structured into three fundamental activities:

• Threat Enumeration: This phase entails the systematic discovery of potential adverse events, mapping their origins and probable repercussions. The enumeration is data-driven, utilizing inputs such as device manufacturing specifications, operational mission profiles, and connectivity interfaces. This step is directly grounded in the IoD threat modeling previously established.
• Risk Quantification: Following identification, this process assigns a magnitude to the risk associated with the Target of Evaluation (ToE). Recognizing that quantification often suffers from subjectivity, our approach mitigates imprecision by employing a specialized expert system to standardize the estimation using industry-standard metrics (CVSS).
• Acceptability Analysis: The final stage involves benchmarking the calculated risk levels against pre-established security thresholds. This determines whether the residual risk falls within the tolerance levels defined by stakeholders or regulatory compliance frameworks.

To mathematically model the systemic risk within the Manna SafeIoD framework, we employ a graph-theoretic approach. While our logic draws inspiration from the propagation models by Li et al. [88], we adapt the dynamics to the specific volatility of ad hoc aerial networks. Rather than a biological infection metaphor, we formulate risk as a function of lateral movement potential within a directed graph $G(V,E)$, where V denotes the nodes (UAVs, ZSPs, Gateways) and E represents the active logical or physical links.

The IoD ecosystem is heterogeneous, comprising drones, ground stations, and cloud providers. The Manna SafeIoD indicators are engineered to be category-agnostic, obviating the need for distinct calculation engines for each hardware type. We classify threat sources into two vectors: (1) Physical vulnerabilities inherent to the hardware, and (2) Cyber threats residing in the firmware/software.

A critical concept in our model is the Risk Propagation Source. A module containing a threat capable of triggering a security incident endangers not only itself but its neighbors. In the mesh architecture, a directed path from node i to j is defined as a sequence of hops. If a route exists such that $i\to$ x → $\mathrm{z}\cdots \to j$, we denote the connection relationship as $\lambda (i,j)$. The cumulative link relationship is the product of individual hops: $\lambda (i,j)=\lambda (i,x)\lambda (x,z)\dots \lambda (s,j)$. The set of all valid paths from i to j is denoted by $\mathrm{\Lambda }$. This assumption holds for the static topology snapshot during operation [89].

Consequently, we introduce the Transmission Factor. This metric acknowledges that a threat on node i propagates through the network, threatening connected assets to varying degrees based on the strength and nature of the link. The assessment workflow is executed as follows:

• Phase 1 (Module Characterization): We treat every IoD entity as an abstract module. We define the multi-set of threat severity levels for a module as $\Theta$ (Equation (1)). To establish a baseline, we select the threat with the maximum CVSS score (${\mu }_{score}$) as the primary risk indicator (Equation (2)).

  $$\Theta =\left\{{\theta }_0,\dots ,{\theta }_n\right\},\mathrm{where}:{\theta }_k\in [0.0,10.0]$$

  (1)

  $${\mu }_{score}=max(\Theta )$$

  (2)
  The baseline risk estimation (${\mathcal{E}}_{risk}$) for a single module is derived using Equation (3), which functions as a ratio of the threat magnitude ($\omega$) against the effectiveness of security controls.

  $${\mathcal{E}}_{risk}=\omega \times {\displaystyle \frac{{\mu }_{score}}{\mathrm{Security}\mathrm{Controls}}}\times \mathrm{Impact}$$

  (3)
  We map this numerical value to a qualitative severity scale:

  $${\mathrm{Risk}}_{\mathrm{Level}}=\left\{\begin{array}{cc}\mathrm{Negligible}\hfill & {\mathcal{E}}_{risk}=0.0\hfill \\ \mathrm{Low}\hfill & 0.1\le {\mathcal{E}}_{risk}\le 3.9\hfill \\ \mathrm{Moderate}\hfill & 4.0\le {\mathcal{E}}_{risk}\le 6.9\hfill \\ \mathrm{High}\hfill & 7.0\le {\mathcal{E}}_{risk}\le 8.9\hfill \\ \mathrm{Critical}\hfill & 9.0\le {\mathcal{E}}_{risk}\le 10.0\hfill \end{array}\right.$$

  (4)
• Phase 2 (Adjacency Analysis): We calculate the transmission potential between direct neighbors. This yields the coefficient ${\psi }_{x\to y}$, representing the probability of risk propagating from module x to y. This is computed by weighting the estimated risk of the neighbor (${\mathcal{E}}_{risk,y}$) against the specific threat relationship of the link.
• Phase 3 (Path Aggregation): We determine the Total Transmission Coefficient. This involves identifying all valid propagation paths $\Lambda$ from a source i to any target j. The coefficient ${\Omega }_j$ is the aggregate of sequential transmission probabilities (${\psi }_{x\to y}$) along these routes.
• Phase 4 (Event Probability): A threat $\theta$ detected on module i represents a probability, not a certainty. We calculate both the likelihood ${\rho }_i\left(\theta \right)$ and the potential impact ${\mathcal{K}}_i$ of the security event.
• Phase 5 (Systemic Integration): Finally, the global risk ${\mathcal{R}}_{sys}$ contributed by a source i is computed by integrating the local estimation, network transmission coefficients, and event probability.

Formalization of Systemic Propagation

To synthesize a complete network view, we must estimate how the risk from a specific target module cascades through the system. Let i be the potential source of compromise and j be any affected downstream node. The aggregated susceptibility coefficient for j is expressed as:

$${\Omega }_j=\left\{\begin{array}{cc}\sum _{\lambda \in \Lambda }{\Psi }_{\lambda (i,j)}\hfill & i\ne j\hfill \\ 1\hfill & i=j\hfill \end{array}\right.$$

(5)

Here, ${\Omega }_j$ signifies the total susceptibility of module j, while ${\Psi }_{\lambda (i,j)}$ represents the coefficient for a specific path ${\lambda }_{(i,j)}$ within the set $\Lambda$. For a multi-hop path $\lambda (i,j)=\lambda (i,x)\lambda (x,y)\dots \lambda (s,j)$, the path coefficient is the product of intermediate link coefficients: ${\Psi }_{\lambda (i,j)}={\psi }_{i\to x}·{\psi }_{x\to y}\cdots {\psi }_{s\to j}$. While precise node enumeration is challenging in dynamic operations, the Context Establishment phase provides the boundary conditions for this estimation.

We further refine the model by incorporating the probability ${\rho }_i\left(\theta \right)$ and the consequent kinetic or cyber effects ${\mathcal{K}}_i$ of threats exploiting specific vulnerabilities. The impact calculation is defined as:

$${\mathcal{K}}_i=\sum _{k=1}^T\left[{\nu }_i\left({\theta }_k\right)·{\rho }_i\left({\theta }_k\right)\right]=\sum _{k=1}^T\left\{{\nu }_i\left({\theta }_k\right)·\left[{\gamma }_1+{\gamma }_2{\Delta }_i\left({\theta }_k\right)\right]\right\}$$

(6)

In this formulation, ${\nu }_i\left({\theta }_k\right)$ quantifies the inherent Asset Value impacted by threat ${\theta }_k$ on module i. This parameter is calibrated based on the mission criticality defined in the Context Establishment phase (ranging from $0.1$ for auxiliary logging to $1.0$ for flight control systems).

The probability function ${\rho }_i\left({\theta }_k\right)$ is a composite metric derived from two dimensions:

• Inherent Threat Severity (${\mathcal{T}}_{\mathit{i}}$): Derived from the CVSS Base Score of the vulnerability.
• Security Gap (${\mathbf{\Delta }}_{\mathit{i}}$): Represents the residual vulnerability after applying controls, calculated as ${\mathbf{\Delta }}_{\mathit{i}}\left({\mathit{\theta }}_{\mathit{k}}\right)=\mathbf{1}-{\displaystyle \frac{\mathrm{Implemented}\mathrm{Controls}}{\mathrm{Required}\mathrm{Controls}}}$.

The coefficients ${\gamma }_1$ and ${\gamma }_2$ act as weighting factors that calibrate the risk assessment strategy, where ${\gamma }_1+{\gamma }_2=1$. The probability of the incident occurring, ${\rho }_i\left({\theta }_k\right)$, is derived via:

$${\rho }_i\left({\theta }_k\right)={\gamma }_1{\mathcal{T}}_i\left({\theta }_k\right)+{\gamma }_2{\Delta }_i\left({\theta }_k\right)$$

(7)

The selection of weights ${\gamma }_1$ and ${\gamma }_2$ is critical for the scientific validity of the model, as it determines the framework’s sensitivity to unmitigated threats versus inherent vulnerability severity. We define three standard calibration profiles for example:

• Balanced Profile (${\mathit{\gamma }}_{\mathbf{1}}=\mathbf{0.5},{\mathit{\gamma }}_{\mathbf{2}}=\mathbf{0.5}$): Assigns equal importance to the existence of a known threat and the lack of mitigation. This is the default setting for general IoD certification.
• Threat-Centric Profile (${\mathit{\gamma }}_{\mathbf{1}}=\mathbf{0.8},{\mathit{\gamma }}_{\mathbf{2}}=\mathbf{0.2}$): Used in high-threat environments (e.g., military zones) where the mere presence of a high-severity vulnerability (high CVSS) drives the risk score, regardless of partial mitigations.
• Control-Centric Profile (${\mathit{\gamma }}_{\mathbf{1}}=\mathbf{0.2},{\mathit{\gamma }}_{\mathbf{2}}=\mathbf{0.8}$): Used in controlled environments where the focus is strictly on compliance gaps; risk is primarily driven by the absence of mandatory controls.

The final derivation aggregates the estimated risk ${\mathcal{E}}_{risk}$ across all modules to present the total systemic risk ${\mathcal{R}}_{sys}$:

$${\mathcal{R}}_{sys}=\sum _{j=1}^J{\mathcal{K}}_i·{\mathcal{E}}_{risk,j}·{\Omega }_j={\mathcal{K}}_i\sum _{j=1}^J{\mathcal{E}}_{risk,j}·{\Omega }_j$$

(8)

5.3. Maturity Report

As specified by ECSCF [17], devising a security certification must consider the unique structure of each use case and designate an appropriate category for each assurance level, referred to herein as maturity.

Manna SafeIoD will grant certification based on the overall risk assessment of the device. This certification will indicate the security level of the tested device and its suitability for the designated mission type. The device’s security level will be determined using a security maturity scale, which categorizes devices into distinct levels across various domains, as illustrated in Figure 5.

• Level 0 (Do not fly) —Denotes the complete absence of security safeguards. Devices in this category face extreme exposure to threats and fail to comply with the essential security standards necessary for safe deployment.
• Level 1 (Operational necessity only) —Denotes that the device incorporates basic security protocols and meets minimum operational requirements, rendering it eligible for certification. However, additional security measures identified during modeling threat must be implemented within the stipulated timeframe to maintain certification.
• Level 2 (Safe to fly) —Indicates advanced security protocols and full compliance with basic and critical mission requirements. The evaluation process reveals no critical threats to the target system.

The certifying entity will establish the minimum overall risk threshold for each mission type. This study aims to establish an open-source methodology, granting each entity the autonomy to define criteria. However, as a general model, we suggest the following classification:

$$Ris{k}_{\mathrm{Maturity}}=\left\{\begin{array}{cc}\mathrm{Level}0\hfill & 90\le Ris{k}_{\mathrm{overall}}\le 100\hfill \\ \mathrm{Level}1\hfill & 70\le Ris{k}_{\mathrm{overall}}\le 89\hfill \\ \mathrm{Level}2\hfill & 00\le Ris{k}_{\mathrm{overall}}\le 69\hfill \end{array}\right.$$

(9)

Device certification hinges on its maturity adequacy. Failure to meet this requirement will result in denial of certification. Nonetheless, the assessment report will outline the indispensable security prerequisites for achieving the minimum required security level for the specified operation.

For devices meeting the minimum acceptable standards, issuance of a preliminary flight authorization report is recommended. This report will detail the requirements for achieving a higher security level.

As a result of the security evaluation process, a cybersecurity label is generated. It is important to emphasize that this labeling approach must consider the specific context of the scenario being assessed and the certification procedure itself. Based on the Common Criteria (CC) methodology, three primary factors are taken into consideration for inclusion in the designation:

• Target of Evaluation (TOE): Within the framework of CC, a TOE encompasses a collection of software, firmware, and/or hardware, potentially accompanied by associated guidance. In our context, the TOE also encompasses the protocol under examination and the testing environment.
• Protection Profiles (Levels of Security): In this case designated as levels 0, 1, and 2, these profiles delineate the level of security corresponding to the risk posed by the scenario being evaluated.
• Certification entity: Consists of the device’s certification authority.

This label could include a digital representation (e.g., NFC tag or a QR code) for ease of access to the latest version of the certificate.

5.4. Security Requirements

The purpose of this step is define the method to certifying entity identify security requirements satisfactorily. As mentioned previously, there is currently no comprehensive security requirements engineering framework available for IoD environments [4], since the nature of IoD is quite different from classical software systems due to the heterogeneity and adaptability characteristics of the IoD that result from the addition of the physical layer.

We extend on the basis of Requirements Engineering (RE) methodologies by integrating key security elements such as asset identification, security goals definition, threat modeling, and risk assessment—each adapted to reflect the unique operational context of IoD, including layered control, autonomous coordination, and decentralized zone management. Central to this process is the adoption of the misuse case technique, as introduced by [90], which complements traditional use case modeling by capturing scenarios that intentionally violate expected system behaviors. Our proposal is based on five activities, as presented in detail in Figure 6.

• Qualify Mission Type This initial phase consolidates information derived from the Context Establishment and Risk Assessment phases. This classification informs subsequent security decisions by aligning them with the level of exposure, autonomy, and communication dependencies inherent to the mission.
• Identify Threats In this activity, we systematically identify threats applicable to the IoD system. Threats are categorized into three primary domains: Communication Threats, Environment Threats, Drone-Specific Threats. Each identified threat contributes to shaping the security posture required. Threat categorization should be performed based on the context presented in Section 4
• Identify Endpoint Hardware IoD systems depend on various physical endpoints, including base stations, routers, embedded controllers, and smart gateways. This phase focuses on cataloging and validating the hardware components within the IoD infrastructure, emphasizing the use of authenticated and certified components to reduce supply chain attacks and physical compromise.
• Identify Sensor Data Given that drones interact with the physical world primarily through sensors and actuators, this activity identifies the characteristics of all sensing components (e.g., cameras, altimeters, LIDARs, GPS receivers).
• Elicit Security Requirements The final activity synthesizes all prior analyses to elicit formalized security requirements.

Table 5. Workflow Process for Security Requirements in IoD Systems.

Activity	Input	Technique	Output
Qualify Mission Type	Operational profile, context model, mission objectives	Classification heuristics, risk correlation	Categorized list of IoD mission types and associated critical assets
Identify Threats	Mission types, preliminary asset list	Misuse cases, threat modeling	Structured list of threats (communication, environment, drone-specific)
Identify Endpoint Hardware	Drone architecture, control station infrastructure, vendor documentation	Device profiling, authentication validation	Verified list of hardware endpoints and trusted vendors
Identify Sensors data	Types of onboard sensors, communication channels (e.g., RF, LTE, 5G)	Protocol analysis, communication stack mapping	List of sensor types and their associated transmission protocols
Elicit Security Requirements	Output of all preceding activities step 1 to step 4	Structured analysis based on mandatory categories	Finalized list of security requirements

illustrates the way in which the proposed process is applied to the IoD, which explains the input, technique, output and name of the activity. Each activity contributes to a collective whole, and its results can be used for both the preceding and succeeding activities. Where applicable, it is also recommended to follow the security standards (e.g., ISO/IEC 27000 [91], ISO/IEC 27001). The certifying entity needs to review each activity and may propose changes if and where required. Having completed the sequence of prescribed activities, the entity will be able to obtain a set of the desired security requirements.

Considering the complexity of the IoD architecture, our proposal is based on eight categories of security requirements, as shown in

Table 6. Standard security requirements.

Category	Requirement	Refs
Authentication	Lightweight Authentication Schemes	[92]
	Data Integrity and Authenticity	[93]
	Key Distribution and Management	[94]
	Mutual Authentication	[95]
	Non-Repudiation	[96]
Access Control	Fine-grained	[97]
	Privacy-preserving	[98]
	Environment transparency	[99]
	Secure Certificate	[100]
Network Security	Network isolation	[101]
	Timeliness	[102]
	Availability (jamming, DoS, etc.)	[103]
	Overhead minimization	[104]
	Mobile transmission security	[105]
	Security policy enforcement	[106]
	Blockchain approach	[107]
Data Security	Anomalization techniques	[108]
	Data flow control	[109]
	Secure external data storage	[110]
	Data loss mitigation	[97]
	Data encryption	[2]
Resilience	Continuous operation	[111]
	Operation intermittent	[111]
Monitoring	Threat detection and response	[112]
	Handle heterogeneous sources	[113]
	Infrastructure monitoring	[114]
Physical Security	Side-Channel detection	[115]
	Fault injection detection	[116]
	Encryption Engines	[117]
	Firmware Protection	[118]
	Hardware-Based Roots of Trust	[119]
Regulation	Security policy enforcement	[106]
	Protection legislation compliance	[120]
	Standard compliance	[106]

, which must be implemented to obtain certification. The level of complexity in each category may vary depending on the type of mission to which the module will be subjected. Therefore, based on threat modeling, it is up to the certified entity to define the specific requirements for each module. The mandatory categories are detailed below.

• Authentication: In the domain of the IoD, the security requirements for authentication and integrity are paramount, given the context of communication between different devices at different layers and protocols. Specifically in the context of UAVs, due to resource constraints as described by [79], authentication schemes must be extremely lightweight to minimize computational overhead and data transfer requirements, ensuring efficient and secure communication between drones, ZSPs and other systems [92]. The verification of data integrity and authenticity is equally critical, ensuring that critical information, such as configuration files or flight plans, has not been tampered with by unauthorized parties [121].
• Access Control: IoD ecosystems are predominantly characterized by latency-sensitive operations, where stakeholders demand instantaneous telemetry from aerial nodes. However, providing unmediated, real-time access to UAVs creates a significant attack surface. Without rigorous data governance, a single compromised node could serve as a pivot point, jeopardizing the integrity of the entire network topology. Consequently, implementing granular access control protocols is mandatory. This is particularly critical in multi-layered architectures where distinct interaction privileges are required—for instance, differentiating between end-to-end transport permissions and service-layer application access [44].
• Network Security: The IoD ecosystem, being large and densely connected, requires proper network connection mechanisms to maximize the positive impact of the technology. If the network fails, all other security measures are compromised, affecting the entire IoD ecosystem. As highlighted [122], unsecured internet connections, particularly over WiFi and wireless networks, are frequently used for communication within the UAV network. Several works highlight the use of 5G [105] and 6G [107] mobile networks for the efficient implementation of IoD networks. In this context, it is necessary to think about encompassing the drone’s behavior in adverse situations, the confidentiality of communication between network nodes, and privacy. For instance, in a critical application, drones equipped with sensors collect data, which is then transmitted to a central server for analysis. Ensuring the security of this wireless communication is crucial to prevent unauthorized access to sensitive data, thereby safeguarding intellectual property and operational secrets.
• Data security: While legacy industrial control systems typically prioritize availability and integrity to mitigate economic loss, the Smart City paradigm necessitates a rebalancing of security objectives. The IoD introduces a complex triad of conflicting requirements. First, the heterogeneity of the fleet imposes strict resource constraints, demanding lightweight security mechanisms. Second, the mission-critical nature of UAV operations mandates rigorous protection standards despite these hardware limitations. Finally, the massive volume of high-frequency telemetry raises significant privacy concerns. As highlighted by Solangi et al. [123], uncontrolled data streams allow for the reconstruction of granular user profiles. Consequently, implementing robust data anonymization and obfuscation strategies is essential to reconcile operational efficiency with privacy preservation.
• Resilience: In the context of IoD, resilience is defined as the system’s capacity to sustain operational continuity even when partially subverted. Security mechanisms must facilitate the survival of critical functions despite the compromise of individual nodes. For example, if a UAV’s primary communication link is neutralized, the architecture should autonomously reroute tasks or activate auxiliary channels to prevent service disruption. Following the taxonomy proposed by Laszka et al. [124], we achieve this via three pillars: redundancy (provisioning spare components to absorb faults), diversity (utilizing heterogeneous technologies to limit common-mode vulnerabilities), and hardening (reinforcing individual elements against direct exploitation).
• Monitoring: Continuous behavioral analysis is the cornerstone of detecting malicious activities, typically implemented through Intrusion Detection Systems (IDSs). Within the IoD domain, this requirement bifurcates into two essential capabilities: pervasive infrastructure visibility and the agility to mitigate both known signatures and emergent zero-day threats. This surveillance is particularly critical given the heterogeneous nature of drone networks, which often integrate legacy hardware. Since these older components may lack support for modern security patches, real-time monitoring serves as the primary compensatory control against the exploitation of unpatched vulnerabilities.
• Physical Security: Establishing a root of trust often relies on hardware, as physically subverting silicon is significantly more resource-intensive and costly than software exploitation. Consequently, a secure hardware foundation is essential for embedded device integrity. Conversely, the physical layer presents unique risks; the existence of manufacturing backdoors or unsecured legacy debug interfaces (e.g., JTAG) can bypass software defenses, effectively compromising the entire device stack from the bottom up.
• Regulation and standard: To safeguard citizen privacy and national security, adherence to jurisdictional legal frameworks is mandatory. In our analysis, the device must demonstrate compliance with a constellation of statutes, including the Cybersecurity recommendations for 5G Networks, the General Data Protection Regulation (GDPR) for data sovereignty, and the aviation-specific mandates of the NIS Directive. Furthermore, alignment with the Electronic Communications Code and relevant Cyber Security Laws—which govern the certification of devices and applications—is essential, as these regulations directly influence the architectural validity of the Drone Internet.

5.5. Certification Monitoring and Review

The proposed certification methodology encompasses the entire operational lifespan of an IoD node.

• Manufacturing Phase: The genesis of the device’s lifecycle lies in the manufacturing stage. This critical phase involves hardware assembly, firmware provisioning, and the initial configuration required for deployment in IoD environments. It is at this juncture that our framework is applied to execute the certification process, ensuring the device undergoes a rigorous conformity assessment based on Secure-by-Design principles. As articulated by Sequeiros et al. [125], this paradigm dictates that security attributes must be ingrained and optimized throughout the SDLC. Consequently, protection mechanisms are not merely added at the end but are actively monitored from initial requirements engineering and architectural design through to implementation and final validation. Figure 7 depicts the strategic integration of the framework within this design workflow.
  After the manufacturing the bootstrapping phase usually includes a set of processes by which an IoD device joins a network in a specific domain; e.g., surveillance [126], rescue [127], delivery [128]. During this phase, the device is configured for a specific context and the context information should be embedded label (which should be up-to-date).
• Operation: During the operation phase, the device delivers its intended functionality in the target environment. In this stage, continuous monitoring is essential to detect threats that may not have been identified during the initial certification—particularly emerging threats such as zero-day vulnerabilities. The Manna SafeIoD framework does not prescribe a specific mechanism for active vulnerability detection; rather, it is the responsibility of the certifying authority to define and implement appropriate monitoring procedures. These procedures must be explicitly stated on the certification label and transparently communicated to the IoD device’s manufacturer or supplier. Upon detection of a new threat, the manufacturer may determine that a software or hardware update is required. If such updates introduce substantial changes—particularly those affecting the device’s security posture—the device may be required to undergo a new certification cycle, and its existing security level or label may be suspended or revoked. To ensure compliance with operational security requirements, the device shall be subject to active runtime monitoring via the Manna SafeIoD governance architecture, detailed in the following section.
• Decommissioning: When the IoD device is no longer needed by the consumer or reaches the end of its life cycle and is no longer supported by the provider, a series of decommissioning processes must be executed. These include revoking certification for the device model, securely erasing all consumer and product-related files, both from the device and the certifying servers, revoking any cryptographic materials, and disassociating the device from consumer accounts, if the consumer still maintains an account with the provider.

6. Manna SafeIoD Framework Implementation

Aligned with the theoretical foundations discussed earlier, this section introduces the process used to develop a minimum viable prototype (MVP) of the framework, enabling the design and implementation of secure IoD devices and smart applications, as outlined in Section 3.

The subsections that follow provide an overview of the framework’s structure and describe the modules contained within each SafeIoD component. We also summarize the implementation of the command-line tool that supports user interaction with the framework.

Figure 8 presents the high-level software architecture of the proposed system. The annotated elements correspond to the conceptual stages defined previously in Figure 4, establishing a clear relationship between the theoretical model and its practical realization.

The proposed architecture consists of five functional modules: (1) the Establishing Context module, which provides the user interface for data acquisition through questionnaires; (2) the Risk Assessment and Security Requirements module, responsible for analyzing user responses, calculating risk levels, and selecting appropriate security requirements; (3) the Certification Database, which manages persistent storage of devices, requirements, certifications, and monitoring data; (4) the Administrative Interface, enabling system configuration, environment management, updates, and user account administration; and (5) the Output Interface, which generates comprehensive maturity reports based on the assessment results.

6.1. Establishing Context (User Interface)

The Establishing Context module represents the initial step of the Manna SafeIoD certification workflow, guiding users through the systematic characterization of deployment conditions and operational requirements. As illustrated in Figure 9, this module is implemented through a Command-Line Interface (CLI) that structures the context elicitation process into a hierarchical questionnaire system.

Upon successful authentication, users are presented with a main menu offering five primary functionalities: (1) Start Establishing Context—initiating the core secure design or certification process; (2) Environment Details—managing deployment environment configurations; (3) Standalone Requirements Elicitation—enabling manual selection of security requirements for advanced users; (4) Checklist Guideline Implementation—providing requirement checklists based on previous assessments; and (5) Best Practices Guidelines—offering domain-specific security recommendations. The context establishment workflow follows a structured interrogation methodology. Initially, users must specify the application domain and declare whether the IoD system is in its early development phase (secure design pathway) or represents an existing operational system (certification pathway). This distinction enables the tool to adaptively tailor the subsequent questioning sequence and assessment criteria. The questionnaire employs a conditional branching logic to optimize information gathering while minimizing user burden. Core questions systematically address the following dimensions:

• Device Classification: Type and category of IoD component under evaluation (drone, ZSP, gateway, ground control station).
• Mission Profile: Target operation type and criticality level.
• Data Handling Characteristics: Information storage requirements, data sensitivity classification (normal, sensitive, critical), and cloud integration dependencies.
• Network Topology: Type and frequency of interactions with Zone Service Providers (ZSPs) and other network entities.
• Regulatory Context: Applicable regulatory frameworks and compliance requirements (e.g., ANAC, FAA, EASA, GDPR, LGPD).
• Threat Exposure: Physical and cyber threat landscape, including potential adversarial access scenarios.

Below are tables with the formal definition of the type of each of the data captured in this phase.

The mission profile captures operational context through a structured questionnaire.

Table 7. Mission Profile Input Schema.

Field	Type	Valid Values	Description
domain	Enum	{Agriculture, Surveillance, Delivery, Inspection, Emergency, Military, Other}	Application domain
phase	Enum	{Development, Operational}	System lifecycle phase
device_type	Enum	{Drone, ZSP, Gateway, GCS, Cloud}	IoD component category
mission_criticality	Integer	[1–5]	1 = Low, 5 = Critical
data_sensitivity	Enum	{Non-Sensitive, PII, Critical}	Data classification level
stores_data	Boolean	{true, false}	Local data storage capability
cloud_integration	Boolean	{true, false}	Cloud service dependency
zsp_interaction	Enum	{None, Periodic, Continuous}	ZSP communication frequency
regulatory_framework	List[Enum]	{FAA, EASA, ANAC, GDPR, LGPD, ISO27001, MIL-STD}	Applicable regulations
environment	Enum	{Indoor, Urban, Rural, Maritime, Military}	Deployment environment
airspace_class	Enum	{Controlled, Uncontrolled, Restricted}	Airspace classification

defines the complete input schema with valid ranges and data types.

Each IoD component is characterized by technical attributes that influence threat applicability and security control feasibility.

Table 8. Device Specification Input Schema.

Field	Type	Valid Values	Description
device_id	String	UUID format	Unique device identifier
manufacturer	String	Free text	Device manufacturer
model	String	Free text	Device model designation
firmware_version	String	Semantic versioning	Current firmware version
comm_protocols	List[Enum]	{WiFi, LTE, 5G, LoRa, ADS-B, MAVLink}	Supported protocols
sensors	List[Enum]	{GPS, Camera, LIDAR, Altimeter, IMU, Thermal}	Onboard sensors
compute_class	Enum	{Constrained, Moderate, High}	Computational capability
has_tpm	Boolean	{true, false}	Hardware security module presence
has_secure_boot	Boolean	{true, false}	Secure boot capability
encryption_support	List[Enum]	{AES-128, AES-256, ChaCha20, ECC, RSA}	Supported cryptographic algorithms

defines the device specification structure.

The IoD network is represented as a directed graph $G(V,E)$ with the JSON structure defined in Algorithm 1.

The questionnaire implements intelligent filtering mechanisms whereby subsequent questions are conditionally presented based on prior responses. For instance, if a user indicates that the device will not store information, data-related questions are automatically bypassed, streamlining the assessment process. All user inputs are processed by the Input Generator component, which performs data extraction, normalization, and validation. The extracted context parameters are then persisted in the system database, enabling session continuity and allowing users to resume incomplete assessments. Simultaneously, this structured context data feeds directly into the Risk Assessment module, where it informs threat modeling, risk calculation, and security requirement selection processes as defined in Section 5.

Algorithm 1 Network Topology JSON Schema

{

"topology_id": "string (UUID)", "nodes": [  {         "node_id": "string (UUID)",         "device_spec": "<Device Specification Object>",         " mission_profile": "<Mission Profile Object>"  } ], " edges": [  {          "source": "string (node_id)",          "target": "string (node_id)",          "protocol": "enum (WiFi|LTE|5G|LoRa|Wired)",          "encrypted": "boolean",          "bidirectional": "boolean",          "trust_level": "float [0.0-1.0]"  } ]

}

6.2. Risk Calculator

The Risk Assessment and Security Requirements module constitutes the analytical core of the Manna SafeIoD framework, operationalizing the theoretical risk assessment methodology detailed in Section 5.2. This module receives structured context data from the Establishing Context module and executes a multi-stage risk calculation process that culminates in the selection of appropriate security requirements and the determination of device maturity levels.

The module comprises two primary sub-components: (1) the User Response Analyzer, which processes and normalizes input data from the context questionnaire, extracting relevant security parameters such as mission criticality, data sensitivity classification, deployment environment characteristics, and regulatory constraints; and (2) the Risk Calculator, which implements the mathematical risk propagation model to compute device-level and system-level risk metrics.

The Risk Calculator implements a graph-based risk propagation algorithm that treats the IoD ecosystem as a directed graph $G=(V,E)$, where vertices V represent IoD modules (drones, ZSPs, gateways, cloud services) and edges E represent communication or dependency relationships between modules. Algorithm 2 presents the core risk assessment procedure.

Algorithm 2 IoD Risk Assessment and Propagation

Require: Context parameters C, IoD topology graph $G(V,E)$, threat database $\mathcal{T}$ Ensure: Overall system risk $R_{system}$, module risk vector $\mathbf{R}$, security requirements $\mathcal{SR}$

1: $\mathbf{R}\leftarrow \varnothing$   2: $\mathcal{SR}\leftarrow \varnothing$   3: for each module $i\in V$ do   4:       $D{T}_i\leftarrow \mathrm{IdentifyThreats}(i,C,\mathcal{T})$   5:      ${max}_{cvss}\leftarrow max\left(\{cvss\left(t\right):t\in D{T}_i\}\right)$   6:       $S{C}_i\leftarrow \mathrm{CountSecurityControls}(i,C)$   7:       $I_i\leftarrow \mathrm{CalculateImpact}(i,C)$   8:       $m{t}_i\leftarrow \mathrm{GetModuleType}\left(i\right)$   9:       $R_i\leftarrow m{t}_i\times {\displaystyle \frac{{max}_{cvss}}{S{C}_i}}\times I_i$ 10:       $\mathbf{R}\left[i\right]\leftarrow R_i$ 11: end for 12: $\mathbf{C}\leftarrow \mathrm{InitializeContagionMatrix}\left(\right|V\left|\right)$ 13: for each edge $(i,j)\in E$ do 14:       $C_{i\to j}\leftarrow \mathrm{CalculateThreatCoefficient}(i,j,D{T}_i,D{T}_j)$ 15:       $\mathbf{C}\left[i\right]\left[j\right]\leftarrow C_{i\to j}$ 16: end for 17: for each module $j\in V$ do 18:       ${\mathcal{L}}_j\leftarrow \mathrm{FindAllPaths}(G,V,j)$ 19:       $C_j\leftarrow 0$ 20:       for each path $l\in {\mathcal{L}}_j$ do 21:             $C_l\leftarrow 1$ 22:             for each edge $(u,v)\in l$ do 23:                $C_l\leftarrow C_l\times \mathbf{C}\left[u\right]\left[v\right]$ 24:             end for 25:             $C_j\leftarrow C_j+C_l$ 26:      end for 27: end for 28: for each module $i\in V$ do 29:       $F_i\leftarrow 0$ 30:       for each threat $t\in D{T}_i$ do 31:             $t{h}_i\left(t\right)\leftarrow \mathrm{GetThreatValue}(t,i)$ 32:             $S_i\left(t\right)\leftarrow \mathrm{CalculateNonCorrelation}(t,i,S{C}_i)$ 33:             $P_i\left(t\right)\leftarrow w_1·T_i\left(t\right)+w_2·S_i\left(t\right)$ 34:             $F_i\leftarrow F_i+t{h}_i\left(t\right)·P_i\left(t\right)$ 35:       end for 36: end for 37: $R_{system}\leftarrow {\sum }_{j\in V}{F}_j·\mathbf{R}\left[j\right]·C_j$ 38: for each module $i\in V$ do 39:       $category\leftarrow \mathrm{ClassifyRisk}\left(\mathbf{R}\right[i\left]\right)$ 40:       ${\mathcal{SR}}_i\leftarrow \mathrm{SelectRequirements}(category,C,D{T}_i)$ 41:       $\mathcal{SR}\leftarrow \mathcal{SR}\cup {\mathcal{SR}}_i$ 42: end for 43: return$R_{system}$, $\mathbf{R}$, $\mathcal{SR}$

The algorithm operates in five distinct phases, corresponding to the theoretical steps outlined in Section 5.2:

Phase 1: Module-level risk estimation. For each IoD component, the algorithm identifies applicable threats from the threat database $\mathcal{T}$ based on device type, firmware characteristics, and operational context. The maximum CVSS score is extracted and combined with the count of implemented security controls and the calculated impact value to produce the estimated risk $R_i$ for module i according to Equation (3).

Each threat entry follows the structure defined in

Table 9. Threat Entry Schema.

Field	Type	Description
threat_id	String	Unique threat identifier (e.g., IOD-COMM-001)
category	Enum	{Communication, Environment, Drone, Provider, Physical, Cyber}
subcategory	String	Specific threat classification (e.g., Jamming, Spoofing)
cvss_base	Float [0.0–10.0]	CVSS v3.1 Base Score
cvss_vector	String	CVSS vector string (e.g., AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
applicable_devices	List[Enum]	Device types vulnerable to this threat
applicable_protocols	List[Enum]	Protocols through which threat manifests
mitigating_controls	List[String]	Security control identifiers that mitigate this threat
propagation_factor	Float [0.0–1.0]	Likelihood of lateral propagation ($\psi$ coefficient base)

.

Table 10. Sample Threat Database Entries.

Threat ID	Category	Subcategory	CVSS	Applicable Devices	Mitigating Controls	Prop. Factor
IOD-COMM-001	Communication	GPS Spoofing	8.1	Drone, GCS	SC-AUTH-003, SC-NET-007	0.3
IOD-CYBER-003	Cyber	Firmware Tampering	9.0	Drone, ZSP, Gateway	SC-PHY-004, SC-PHY-005	0.7
IOD-PHYS-002	Physical	Deauthentication Attack	7.5	Drone, GCS	SC-NET-002, SC-NET-006	0.5

illustrates representative entries from the threat database.

Phase 2: Inter-module contagion coefficient calculation. For each communication or dependency edge in the topology graph, the algorithm computes the threat transmission coefficient $C_{i\to j}$, representing the degree to which a compromised module i can propagate risk to its neighbor j. This calculation considers the overlap between threat vectors, protocol vulnerabilities, and access control mechanisms at the interface boundary.

Phase 3: Total infection coefficient computation. Using Dijkstra-based path enumeration [129], the algorithm identifies all directed paths from potential risk sources to each module in the system [130]. The total infection coefficient $C_j$ for module j is computed by summing the products of contagion coefficients along each path, as formalized in Equation (5).

Phase 4: Impact and probability estimation. For each module, the algorithm calculates the cumulative impact factor $F_i$ by aggregating the weighted probabilities of security events across all identified threats. The probability $P_i\left(t\right)$ incorporates both the intrinsic exploitability of threat t and the effectiveness of existing security measures, as defined in Equations (6) and (7).

Phase 5: System-level risk aggregation and requirement selection. The overall system risk $R_{system}$ is computed by integrating module risks, impact factors, and infection coefficients according to Equation (8). Subsequently, each module’s risk classification (None, Low, Medium, High, Critical) determines the set of mandatory security requirements ${\mathcal{SR}}_i$ from the eight categories defined in Table 6. The union of all module-specific requirements forms the comprehensive security requirement set for the entire IoD deployment, as formalized in Algorithm 2.

The Risk Calculator module persists all computed metrics to the Certification Database, enabling traceability and supporting the subsequent generation of maturity reports and compliance documentation. The selected security requirements are forwarded to the Security Requirement Selector component, which structures them according to the stakeholder-specific format and regulatory framework identified during context establishment.

6.3. Security Requirements Generator

The Security Requirements Generator module implements the elicitation approach described in Section 5.4. For background and an in-depth discussion of IoD security requirements, refer to [9,131,132]. This module takes as input the normalized context attributes and the risk indicators produced by the Risk Assessment module, and translates them into concrete security requirements derived from the eight mandatory categories described in Table 6. Its internal design is composed of three cooperating subcomponents that together execute the full requirement selection and consolidation workflow.

• User Response Analyzer: This component performs multi-level analysis on user responses, distinguishing between binary indicators (yes/no answers), categorical classifications (e.g., mission type: surveillance, delivery, inspection), and sensitivity gradations (e.g., data classification: normal, sensitive, critical). The analyzer implements a rule-based inference engine that correlates user inputs with the five security requirement elicitation activities presented in Figure 6. The extracted parameters are normalized and encapsulated in a structured requirements context object $RC=\{mission,threat\_exp,hardware,data,architecture\}$, which serves as input to the Security Requirements Selector component.
• Security Requirements Selector implements a constraint-based mapping algorithm that systematically selects appropriate security requirements from a curated repository aligned with the eight mandatory categories: Authentication, Access Control, Network Security, Data Security, Resilience, Monitoring, Physical Security, and Regulation (as defined in Table 6).
  Algorithm 3 formalizes the selection procedure. The algorithm iterates through the eight security categories, applying context-aware filters and risk-based prioritization to construct a tailored requirement set ${\mathcal{SR}}_i$ for each module i in the IoD ecosystem.
  The requirement database $\mathcal{RDB}$ maintains a structured repository of security requirements sourced from established standards (ISO/IEC 27001, NIST Cybersecurity Framework), domain-specific best practices [106], and peer-reviewed IoD security research (as cataloged in Table 6). Each requirement entry includes metadata specifying applicable IoD component types (drone, ZSP, gateway, cloud service), implementation complexity ratings, and interdependencies with other requirements.
• Requirements Aggregator: consolidates individual module requirements into a comprehensive, system-level security specification. When multiple modules generate overlapping requirements (e.g., mutual authentication between drone and ZSP appears in requirements for both components), the aggregator merges them into unified, bidirectional requirements while preserving module-specific implementation details. he aggregator identifies cross-module dependencies using a directed acyclic graph (DAG) representation [133]. For instance, if Module A requires encrypted communication channels and Module B mandates key management infrastructure, the aggregator ensures both requirements are present and properly sequenced in the implementation roadmap. The aggregator also persists the complete requirement provenance chain—linking each requirement to its originating threat, risk score, context parameter, and applicable security standard—enabling full traceability throughout the certification lifecycle.

Algorithm 3 Security Requirements Selection

Require: Requirements context $RC$, module risk vector $\mathbf{R}$, threat set $DT$, requirement database $\mathcal{RDB}$ Ensure: Module-specific security requirements $\mathcal{SR}$

1: $\mathcal{SR}\leftarrow \varnothing$   2: $categories\leftarrow \left\{\mathrm{Auth},\mathrm{Access},\mathrm{Network},\mathrm{Data},\mathrm{Resilience},\mathrm{Monitor},\mathrm{Physical},\mathrm{Regulation}\right\}$   3: for each module i in IoD topology do   4:       $risk\_clas{s}_i\leftarrow \mathrm{ClassifyRisk}\left(\mathbf{R}\left[i\right]\right)$   5:       ${\mathcal{SR}}_i\leftarrow \varnothing$   6:       for each category $cat\in categories$ do   7:             $base\_reqs\leftarrow \mathrm{GetBaseRequirements}(cat,\mathcal{RDB})$   8:             $filtered\_reqs\leftarrow \mathrm{ApplyContextFilters}(base\_reqs,RC,i)$   9:             $prioritized\_reqs\leftarrow \mathrm{PrioritizeByRisk}(filtered\_reqs,risk\_clas{s}_i)$ 10:             $threat\_reqs\leftarrow \mathrm{MapThreatsToRequirements}(D{T}_i,cat,\mathcal{RDB})$ 11:             $regulatory\_reqs\leftarrow \mathrm{GetRegulatoryRequirements}(RC.jurisdiction,cat)$ 12:             $merged\_reqs\leftarrow prioritized\_reqs\cup threat\_reqs\cup regulatory\_reqs$ 13:             ${\mathcal{SR}}_i\leftarrow {\mathcal{SR}}_i\cup \mathrm{RemoveDuplicates}(merged\_reqs)$ 14:       end for 15:       ${\mathcal{SR}}_i\leftarrow \mathrm{ValidateCompleteness}({\mathcal{SR}}_i,risk\_clas{s}_i)$ 16:       $\mathcal{SR}\leftarrow \mathcal{SR}\cup \left\{(i,{\mathcal{SR}}_i)\right\}$ 17: end for 18: return $\mathcal{SR}$

Security controls are defined in a structured repository $\mathcal{SC}$ that maps to the eight requirement categories from Table 6. Each control entry specifies implementation characteristics and effectiveness metrics as detailed in

Table 11. Security Control Schema.

Field	Type	Description
control_id	String	Unique identifier (e.g., SC-AUTH-001)
category	Enum	One of eight security categories from Table 6
name	String	Human-readable control name
description	String	Implementation description
effectiveness	Float [0.0–1.0]	Normalized mitigation effectiveness
compute_overhead	Enum	{Low, Medium, High}—resource requirements
applicable_devices	List[Enum]	Compatible device types
mitigates_threats	List[String]	Threat IDs this control addresses
implementation_alg	String	Recommended algorithm (e.g., AES-256-GCM)

.

Table 12. Sample Security Control Entries.

Control ID	Category	Name	Eff.	Overhead	Mitigates	Algorithm
SC-AUTH-001	Authentication	Lightweight Mutual Auth.	0.85	Low	IOD-COMM-001, IOD-CYBER-001	ECDH-Curve25519
SC-NET-002	Network Security	Encrypted C2 Channel	0.90	Medium	IOD-PHYS-002, IOD-COMM-003	AES-256-GCM
SC-PHY-004	Physical Security	Secure Boot	0.95	Low	IOD-CYBER-003, IOD-CYBER-004	RSA-2048 + SHA-256

presents representative security control definitions.

6.4. Output Interface

The Output Interface module constitutes the presentation layer of the Manna SafeIoD framework, responsible for synthesizing assessment results into stakeholder-appropriate deliverables that support the complete device lifecycle from manufacturing through decommissioning.

For IoD systems undergoing secure-by-design evaluation during the manufacturing phase, the Output Interface generates comprehensive security specification documents structured to guide implementation teams throughout the Software Development Life Cycle (SDLC). These deliverables provide a roadmap to security requirements implementation. Guideline to monitoring and active quality The secure design output additionally includes mission-type-specific cryptographic protocol recommendations, encompassing key exchange mechanisms for point-to-point drone-ZSP communication, digital signature schemes for firmware integrity verification, and secure boot architecture guidelines aligned with hardware capabilities extracted during context establishment. Visual representations of secure communication flows, trust boundary delineations, and defense-in-depth layering strategies tailored to the identified IoD topology complete the specification package, embodying the Security-by-Design paradigm illustrated in the BPMN workflow of Figure 7.

For operational IoD devices or systems undergoing certification evaluation, the Output Interface produces formal maturity reports aligned with the three-level classification scheme detailed in Section 5.3. The certification report opens with a compliance assessment summary that comprehensively evaluates the device’s conformity with security requirements for the specified mission type, documenting all satisfied, partially satisfied, and unsatisfied requirements with supporting evidence traced back through the risk assessment phase.

For devices achieving suboptimal maturity levels, the report includes a prioritized gap analysis enumerating specific deficiencies that prevent higher certification, along with a remediation roadmap specifying required security enhancements ordered by criticality and implementation complexity.

6.5. System Components

The CLI is implemented in GoLang and supports cross-platform execution on Windows and Linux operating systems. The modular architecture enables parameter customization to optimize performance and facilitates feature extensibility, such as integration of additional risk metrics or alternative threat modeling databases. A PostgreSQL database maintains all framework data, including user credentials, assessment requests, and computed security metrics.

6.6. Modular Architecture and Scalability

A fundamental design principle of the Manna SafeIoD framework is its modular architecture, which enables flexible deployment across heterogeneous IoD certification scenarios.

6.6.1. Architectural Modularity Benefits

The framework decomposes the certification process into four independently deployable modules: Context Establishment (Module A), Risk Assessment (Module B), Security Requirements Engineering (Module C), and Certification Monitoring and Review (Module D). This decomposition yields three primary advantages:

Capacity Adjustment through Module Composition. Certifying entities can instantiate only the modules required for their specific use case. For lightweight pre-deployment assessments, a minimal configuration comprising Modules A and B suffices to generate preliminary risk scores without full security requirements elicitation. Conversely, comprehensive certification for mission-critical military applications activates all four modules with enhanced parameter configurations.

Enhanced Maintenance Convenience. Each module maintains well-defined interfaces and can be updated independently without affecting adjacent components. When new threat categories emerge (e.g., novel GPS spoofing variants), only Module B’s threat database requires modification. Similarly, regulatory framework updates (e.g., new EASA directives) propagate exclusively through Module C’s requirements repository. This isolation minimizes the regression testing scope and accelerates patch deployment cycles, which is critical for maintaining certification validity in rapidly evolving threat landscapes.

Horizontal and Vertical Scalability. The framework supports both scaling dimensions. Horizontal scalability enables parallel processing of multiple certification requests by instantiating additional module replicas behind a load balancer, which is essential for certification authorities managing large device fleets.

6.6.2. Practical Configuration Examples

To illustrate modular adaptability, we present three representative deployment configurations aligned with distinct operational conditions.

Configuration 1: Resource-Constrained Civilian Drone (Agricultural Monitoring). For a single agricultural monitoring UAV operating in rural, uncontrolled airspace with minimal data sensitivity, the certifying entity deploys a streamlined configuration as shown in

Table 13. Module Configuration for Resource-Constrained Agricultural UAV.

Module	Status	Configuration Parameters
A (Context)	Active	Simplified questionnaire (12 questions); single-device topology
B (Risk Assessment)	Active	Threat database subset (environmental + basic cyber); ${\gamma }_1=0.5$, ${\gamma }_2=0.5$ (balanced profile)
C (Requirements)	Partial	Categories limited to: Authentication, Network Security, Resilience
D (Monitoring)	Inactive	Deferred to operational phase

.

This configuration completes certification in approximately 15 minutes with minimal computational resources, producing a focused requirement set of 8–12 security controls appropriate for the constrained platform.

Configuration 2: Multi-Drone Urban Delivery Fleet. For a commercial delivery operator deploying 50 drones across urban zones with PII-handling capabilities and continuous ZSP interaction, the configuration is expanded as detailed in

Table 14. Module Configuration for Urban Delivery Fleet.

Module	Status	Configuration Parameters
A (Context)	Active	Full questionnaire; multi-node topology graph (50 UAVs + 3 ZSPs + 2 gateways)
B (Risk Assessment)	Active	Complete threat database; network propagation analysis enabled; ${\gamma }_1=0.3$, ${\gamma }_2=0.7$ (control-centric profile)
C (Requirements)	Full	All eight categories active; GDPR/LGPD regulatory mapping enabled
D (Monitoring)	Active	Continuous vulnerability tracking; 90-day recertification cycle

.

This configuration requires approximately 1 h for initial certification but provides comprehensive coverage including systemic risk propagation analysis across the fleet topology.

Configuration 3: Military Tactical ISR Deployment. For the tactical scenario described in Section 7.1.5, maximum security assurance necessitates full module activation with enhanced parameters as specified in

Table 15. Module Configuration for Military Tactical ISR.

Module	Status	Configuration Parameters
A (Context)	Active	Extended questionnaire including adversarial capability assessment; classified mission profile
B (Risk Assessment)	Active	Military threat extensions; ${\gamma }_1=0.8$, ${\gamma }_2=0.2$ (threat-centric profile); mandatory propagation simulation
C (Requirements)	Full	All categories + MIL-STD-882E mapping; mandatory hardware roots of trust
D (Monitoring)	Active	Real-time threat intelligence integration; 30-day recertification cycle; incident response protocols

.

6.6.3. Module Interdependency Management

While modules operate with defined interfaces, certain interdependencies govern valid configurations. Module B (Risk Assessment) requires prior completion of Module A (Context Establishment) to obtain topology and mission parameters. Module C (Security Requirements) can operate in standalone mode for manual requirement selection but produces optimized outputs when fed risk indicators from Module B. Module D (Monitoring) presupposes successful completion of the initial certification cycle (Modules A → B → C) to establish baseline security postures against which deviations are detected, as illustrated in Figure 10.

These dependencies are enforced through the framework’s orchestration layer, which validates configuration coherence before execution and provides diagnostic feedback when invalid module combinations are requested. The orchestration layer implements a finite state machine that tracks certification progress and ensures compliance with the workflow constraints illustrated in Figure 4.

Table 16. Valid Module Configurations and Use Cases.

Module A	Module B	Module C	Module D	Configuration Type	Primary Use Case
●	●	–	–	Minimal Assessment	Preliminary risk screening
●	●	●	–	Standard Certification	Initial device certification
●	●	●	●	Full Lifecycle	Production deployment with monitoring
–	–	●	–	Standalone Requirements	Manual security requirements selection
●	●	–	●	Continuous Assessment	Runtime monitoring without full recertification

Legend: ● = Module is active in the configuration; – = Module is not used.

summarizes the valid module configurations and their corresponding use cases.

The modular architecture thus provides certifying entities with the flexibility to balance certification rigor against resource constraints, adapting the framework’s analytical depth to match the specific requirements of each IoD deployment scenario.

7. Experimental Setup

To assess the practical applicability of the Manna SafeIoD framework, we designed a series of usability-oriented experiments focused on validating whether the implemented components behave consistently with the conceptual methodology introduced in Section 5. The overall structure of the evaluation was inspired by the experimental procedures adopted in prior works on IoT and UAS security assessment, particularly the test design strategies presented by Samaila et al. [134] and the operational task modeling described by Santiago [135]. While these studies target different domains, their methodological insights provided a foundation for shaping our own evaluation protocol.

In our setup, we formulated representative usage tasks that simulate common operational scenarios in which users would interact with the SafeIoD tool. These tasks were constructed to mirror realistic decision-making processes and to enable assessment of the framework’s ability to generate consistent outputs under varied contextual conditions. After completing the scenarios, the outputs and tool behavior were analyzed using three performance metrics described in the following subsections. These metrics allowed us to examine the internal coherence of the framework, the usability of the generated requirements, and the responsiveness of the implemented modules.

7.1. Usability Testing Setup

To evaluate both the functionality of the tool’s modules and the usability of the overall workflow, we developed five test scenarios inspired by methodological approaches found in the literature, particularly in [134]. Two scenarios targeted software-based implementations, in order to validate the core operations of Manna SafeIoD and assess its ability to recommend secure coding practices. Two additional scenarios focused on hardware-oriented configurations, simulating typical industrial setups used in UAV device development. The final scenario examined a combined hardware–software configuration to evaluate the end-to-end certification process.

These scenarios were designed to reflect diverse operational conditions: resource-constrained platforms, where the number of security requirements must be carefully minimized, and mission-critical environments—such as military applications—where broader and more stringent requirements are expected. A group of participants executed the scenarios, allowing us to observe tool behavior under realistic usage conditions. The subsections that follow describe each scenario in detail.

7.1.1. Software Implementation Test Scenario for Drone Firmware

This scenario considers a developer responsible for implementing firmware or onboard applications on a constrained UAV platform who must select suitable lightweight security algorithms. The goal is to ensure that the chosen controls comply with mission-specific security requirements and the characteristics of the operating environment.

7.1.2. Software Implementation Test Scenario for Cloud Application Based for ZSP Integration

This scenario represents another software-oriented request, where a developer is implementing a cloud-based traffic-analysis service that integrates with the ZSPs. The application, which is designed to operate in the service layer of the IoD architecture, runs on a single-board computer or on an edge-computing platform. In this context, the developer queries the framework to obtain the security requirements applicable to this IoD service.

7.1.3. Hardware Implementation Test Scenario for UAV Security Modules

This scenario involves a developer working on an IoD device that incorporates Application-Specific Integrated Circuits (ASICs) or specialized security co-processors. The developer requests guidance on which hardware-based security mechanisms to achieve the required maturity level for the specified mission type.

7.1.4. Hardware Implementation Test Scenario for Reconfigurable UAV Hardware

This scenario involves a hardware engineer designing an IoD system using an FPGA-based architecture who seeks to determine the hardware security controls and implementation directives necessary to meet the security expectations associated with the mission profile and the desired maturity level.

7.1.5. Certification Process Test Scenario with Military Application

This scenario aims to demonstrate the certification process of the proposed framework for military application. The scenario presented in the work [135] is used as the basis for the case. During the process of acquiring drones for tactical operations, an evaluation of a drone module was requested through Manna SafeIoD. The tactical environment to which the device will be subjected is exemplified in Figure 11. Tactical Units Module-j, Module-1, Module-2, Module-4, provide ISR support with UASs from Groups 1 and 2 and communication through ZSPs Module-3,. Module-j is operating the COTS Drone-A and has a current NAVAIR Q-VAR on file. Through the methodology proposed here, we must certify whether the Drone-i device is suitable for operation in the described scenario.

The subject of our analysis, Drone-i, features a quadcopter fuselage integrating a 1080p camera payload and a five-hour flight autonomy. Regarding its security posture, three specific vulnerabilities were identified. We addressed the first two—a forced Telnet login bypass and an unprotected Telnet interface—through a combination of patching and network hardening. Conversely, the third flaw involves susceptibility to deauthentication management frames. This remains an active risk, as the proprietary C2 software lacks the necessary encryption capabilities to prevent such attacks [135]. This specific configuration serves as the baseline input for our framework’s execution.

7.2. Results Overview

The usability evaluation was performed on a Cloud Linux environment (Debian 13.0), where the Manna SafeIoD tool was deployed. For the first four scenarios, we invited a group of 15 volunteers to interact with the system. The participants, aged between 18 and 37, included researchers from computer science and electronics disciplines as well as professionals working in industry. To preserve anonymity and encourage participation, the forms collected only general demographic categories rather than PII (personally identifiable information).

Participants were asked to provide basic profile information, including their age group, self-assessed familiarity with security topics, and background in IoD/IoT or hardware-related fields. They also rated the perceived ease of using the tool. The system automatically recorded the time taken to process each request and the set of security requirements produced by the framework.

To ensure consistency in the participant profiling, we established standardized categorical brackets for each dimension of the assessment. The demographic and technical attributes were structured as follows: Age was segmented into four deciles (18–29 through 50–59), coded as A through D. Professional roles were classified into three distinct domains: Programmers (P), Computer Engineers (C), and Electronics Engineers (E).

Regarding the qualitative metrics—specifically Security Experience, Proficiency Level, and the perceived Simplicity of Use—we utilized a five-point scale (labeled A to E). To facilitate quantitative analysis, these qualitative grades were mapped to a normalized numeric scale ranging from 0 to 10 with 2.5 intervals (where A represents 0.0 and E represents 10.0). The complete dataset resulting from this evaluation is detailed in

Table 17. Performance evaluation form as completed by subjects (Tests 1–4).

S/No.	Request ID No.	Age Range	Security Experience	Field of Expertise	Proficiency Level	Simplicity of Use	Completion Time (s)
1	MSI221	A	B (2.5)	E	E (10.0)	D (7.5)	118.45
2	MSI242	C	C (5.0)	P	C (5.0)	D (7.5)	76.32
3	MSI236	B	C (5.0)	P	C (5.0)	D (7.5)	84.67
4	MSI244	A	B (2.5)	P	C (5.0)	D (7.5)	79.88
5	MSI223	C	D (7.5)	P	E (10.0)	E (10.0)	31.24
6	MSI124	A	B (2.5)	C	D (7.5)	C (5.0)	112.89
7	MSI643	C	C (5.0)	P	C (5.0)	C (5.0)	88.76
8	MSI111	B	A (0.0)	P	C (5.0)	D (7.5)	78.45
9	MSI887	B	A (0.0)	C	C (5.0)	D (7.5)	106.12
10	MSI007	C	B (2.5)	P	E (10.0)	D (7.5)	71.56
11	MSI121	A	A (0.0)	E	C (5.0)	D (7.5)	119.34
12	MSI232	B	B (2.5)	P	E (10.0)	D (7.5)	81.92
13	MSI298	C	C (5.0)	P	C (5.0)	C (5.0)	58.41
14	MSI321	A	B (2.5)	E	C (5.0)	D (7.5)	115.67
15	MSI432	A	B (2.5)	C	D (7.5)	D (7.5)	109.88

.

The summary of the final results shown in

Table 18. Security Requirements and Algorithm Selection for IoD Devices (Tests 1–4).

S/No.	Request ID	Security Requirements	Security Mechanisms	Recommended Algorithms
1	MSI221	Data Confidentiality—Mutual Authentication—Network Isolation	Encryption, Authenticated encryption, Secure channels	ChaCha20-256, ACORN
2	MSI242	Data Confidentiality—Message Integrity—irmware Protection	Encryption, Hash function, Hardware security	Clefía128/192, PHOTON-256
3	MSI236	Message Integrity—Non-repudiation—Infrastructure Monitoring	Hash function, Digital signature, Intrusion detection	PHOTON-128/16/16
4	MSI244	Data Confidentiality—Lightweight Authentication—Mobile Transmission Security	Encryption, MAC, Secure protocols	AES-128, ACORN, DTLS-PSK
5	MSI223	Fine-grained Access Control—Data Flow Control—Privacy-preserving	Attribute-based encryption, Access control matrix, Anonymization	Differential privacy
6	MSI124	Data Confidentiality—Data Integrity—Continuous Operation	Encryption, Authenticated encryption, Redundancy protocols	Grain_v1-128, CLOC-AES
7	MSI643	Message Integrity—Mutual Authentication—Threat Detection	Hash function, Key exchange, Anomaly detection	PHOTON-128/16/16, ECDH-Curve25519
8	MSI111	Data Confidentiality—Message Integrity—Secure Certificate Management	Encryption, Hash function, PKI infrastructure	PRESENT-80, SipHash-128, X.509
9	MSI887	Message Integrity—Data Integrity and Authenticity—Side-Channel Detection	Hash function, MAC, Hardware countermeasures	Keccak-f[1600], Deoxys
10	MSI007	Data Confidentiality—on-repudiation—Standard Compliance	Encryption, Digital signature, Regulatory framework	AES-192, EdDSA-Ed25519, ISO 27001
11	MSI121	Lightweight Authentication—Key Distribution—Network Isolation	Authentication protocol, Key management, Network segmentation	VPN/Firewall
12	MSI232	Data Confidentiality—Message Integrity—Availability (DoS protection)	Encryption, Hash function, Rate limiting	Trivium, PHOTON-128/16/16
13	MSI298	Message Integrity—Secure External Data Storage—Overhead Minimization	Hash function, Cloud encryption, Compression	SPONGENT-128, AES-256-GCM
14	MSI321	Data Confidentiality—Mutual Authentication—Hardware Roots of Trust	Encryption, Authentication protocol, TPM/Secure element	PRESENT-128, Challenge-response
15	MSI432	Message Integrity—Data Integrity and Authenticity—Security Policy Enforcement	Hash function, Authenticated encryption, Policy engine	PHOTON-80/20/16, SILC-AES

. The framework successfully identified and categorized 45 distinct security requirements across the 15 test cases, with an average of 3.0 requirements per device request. Data Confidentiality and Message Integrity emerged as the most frequently selected requirements, appearing in 12 (80%) and 11 (73.3%) test cases respectively, reflecting their fundamental importance in IoD security architectures. Mutual Authentication requirements appeared in 6 cases (40%), predominantly in scenarios involving drone-to-ZSP or drone-to-gateway communications. Advanced requirements such as Hardware Roots of Trust, Side-Channel Detection, and Fine-grained Access Control appeared less frequently (1–2 cases each, 6.7–13.3%), typically associated with high-criticality missions or resource-rich hardware platforms.

The framework demonstrated varying degrees of success in recommending concrete algorithm implementations across different requirement categories. Of the 45 total requirements identified, the framework successfully recommended specific lightweight algorithms for 28 requirements (62.2%), while 17 requirements (37.8%) resulted in “*No matching algo found!” notifications. This indicates areas where the current algorithm database requires expansion to comprehensively support IoD-specific constraints.

For Test 5 (Section 7.1.5), the evaluation was conducted by the authors of this research. To validate the operational efficacy of Certification Manna SafeIoD in a simulated military mission scenario, we constructed a testbed environment utilizing the COOJA network simulator, an established open-source platform built upon the Contiki operating system [136]. While COOJA has traditionally served the wireless sensor network and IoT research communities, we adapted its capabilities to simulate the complex dynamics of IoD environments, specifically modeling the interactions between UAV nodes, ZSPs, and our distributed monitoring infrastructure based on the proposal of [137].

The framework was applied to evaluate the Drone-i platform for tactical Intelligence, Surveillance, and Reconnaissance (ISR) operations within a multi-module military network architecture. The tactical deployment comprises four operational units (Module-j, Module-1, Module-2, Module-4) providing ISR support through UAV Groups 1 and 2, coordinated via ZSP infrastructure (Module-3).

Device Profile and Vulnerability Assessment. The Drone-i platform consists of a quadcopter configuration equipped with a 1080p camera payload and 5-h flight endurance. The Context Establishment phase identified three critical vulnerabilities with varying mitigation statuses:

• V1—Forced Telnet Authentication Bypass (CVSS 8.0): Partially mitigated through vendor-provided security patches;
• V2—Unprotected Telnet Service (CVSS 7.5): Mitigated via MAC filtering and SSID obfuscation;
• V3—Deauthentication Attack Susceptibility (CVSS 9.0): Unmitigated due to C2 software lacking encryption capabilities.

Risk Assessment Results. Applying the Manna SafeIoD risk propagation methodology, the framework computed a device-level risk score of 4.2 (Medium category) based on the maxCVSS value of 9.0, implemented security controls, and impact severity. The analysis incorporated contagion coefficient calculations across the tactical network topology, revealing that the unmitigated deauthentication vulnerability poses a critical propagation risk to adjacent modules, particularly Module-3 (ZSP) and Module-j.

The system-level risk aggregation, accounting for infection paths through the directed network graph $G=(V,E)$ with permission relationships $a_{i-j}\in [0.0,1.0]$, yielded an overall risk score of 75, placing the deployment in Maturity Level 1 (Operational Necessity Only).

Security Requirements and Certification Outcome. The Security Requirements Generator module mapped the identified threats to mandatory requirements across all eight security categories (Table 6).

Table 19. Security Requirements for Military Tactical ISR Deployment (Test 5).

Category	Security Requirements	Security Mechanisms	Recommended Algorithms
V1—Auth Bypass	Data Confidentiality—Mutual Authentication—Key Distribution	Encryption, Authentication protocol, Key management	AES-256, Challenge-Response, ECDH-P256
V2—Unprotected Service	Network Isolation—Access Control—Service Hardening	Network segmentation, Port filtering, Secure configuration	VPN/IPsec, Firewall rules, MAC filtering
V3—Deauth Attack	Mobile Transmission Security—Availability—Jamming Protection	Encrypted C2 channels, Anti-jamming, Frequency diversity	AES-GCM, Spread spectrum
ISR Data Protection	Data Integrity—Non-repudiation—Secure External Storage	Hash function, Digital signature, Cloud encryption	PHOTON-256/32/32, EdDSA-Ed25519, AES-256-GCM
Mission Continuity	Resilience—Continuous Operation—Fault Tolerance	Failover protocols, Redundancy, Autonomous RTH	Path diversity, GPS backup
Network Monitoring	Infrastructure Monitoring—Threat Detection—Anomaly Detection	IDS deployment, Network analysis, Behavior monitoring	SNMP, Pattern matching
Access Management	Fine-grained Access Control—Privacy-preserving—Environment Transparency	Role-based access, Mission-level permissions, Audit logs	ACL matrices, Syslog
Physical Assets	Tamper Detection—Hardware Roots of Trust—Firmware Protection	Tamper-evident seals, Secure element, Secure boot	TPM 2.0, UEFI Secure Boot
Communication Security	Timeliness—Overhead Minimization—Secure Certificate	Low-latency protocols, Compression, PKI infrastructure	DTLS-PSK, LZ4 compression, X.509 certs
Data Flow Control	Data Loss Mitigation—Data Flow Control—Anonymization	Redundant storage, Traffic shaping, PII protection	RAID-1, QoS policies, Differential privacy
Tactical Network	Blockchain Approach—Decentralized Trust—Security Policy Enforcement	Distributed ledger, Smart contracts, Policy engine	Hyperledger Fabric,
Regulatory Compliance	Standard Compliance—Protection Legislation—Security Auditing	Military standards, ITAR compliance, Audit trails	MIL-STD-882E, ISO 27001, NIST SP 800-53
Side-Channel Protection	Side-Channel Detection—Encryption Engines—Fault Injection Detection	Power analysis countermeasures, HW crypto, Integrity checks	AES-NI, CRC-32

presents the comprehensive security requirements elicited for the tactical ISR deployment scenario, along with corresponding security mechanisms and recommended lightweight algorithms suitable for the Drone-i platform’s resource constraints.

The maturity report concluded that Drone-i achieves conditional certification (Level 1) with mandatory remediation requirements. The framework successfully identified 39 specific security requirements spanning all 8 mandatory categories, with 64% (25/39) successfully matched to lightweight cryptographic implementations or established protocols suitable for UAV resource constraints. Critical gaps requiring immediate attention include: (1) encrypted C2 communication implementation within 90 days to mitigate V3, (2) deployment of real-time intrusion detection for deauthentication attacks, (3) tamper-detection mechanisms for physical security, and (4) quarterly recertification cycles to validate security posture in evolving tactical environments.

The framework’s ability to comprehensively map vulnerabilities to actionable requirements across regulatory (MIL-STD-882E, ITAR), technical (AES-256, TPM 2.0), and operational (failover, monitoring) dimensions demonstrates its effectiveness for military certification scenarios where multi-domain security assurance is paramount.

Validation Through COOJA Simulation. To empirically validate the risk propagation model, a representative network topology was simulated using the Contiki-based COOJA environment [137].

Table 20. COOJA Simulation Parameters for Tactical Scenario.

Parameter	Value
Network Topology
Total nodes	12
Module-j (Gateway)	1 node (central coordination)
Module-1 (UAV Group 1)	4 UAV nodes (ISR operations)
Module-2 (UAV Group 2)	4 UAV nodes (ISR operations)
Module-3 (ZSP)	1 node (airspace coordination)
Module-4 (Ground Station)	2 nodes (operator interface)
Topology type	Hierarchical mesh with ZSP coordination
Deployment area	500 m × 500 m
Node placement	Randomized within operational zones
Radio Channel Parameters
Transmission range	100 m
Interference range	120 m
Transmission success ratio	95% (nominal)
Reception success ratio	95% (nominal)
Path loss exponent	3.5 (urban environment)
Protocol Stack
MAC protocol	ContikiMAC (duty cycle: 8 Hz)
Routing protocol	RPL (IPv6 Routing Protocol for LLNs)
Transport	UDP
Application	Custom C2 telemetry (10 packets/s)
Attack Simulation
Attack type	Deauthentication (V3)
Attack initiation	$t=60$ s after simulation start
Attack duration	Continuous until simulation end
Attacker nodes	2 (positioned at network periphery)
Attack rate	50 deauth frames/s
Experimental Design
Simulation duration	600 seconds per run
Number of runs	30 per scenario
Random seeds	Unique per run (range: 1–30)
Warm-up period	60 s (excluded from analysis)
Measurement window	540 s

details the simulation parameters used for validation.

Figure 12 illustrates the attack propagation dynamics observed during simulation experiments. The results confirmed that exploitation of the unmitigated deauthentication vulnerability propagates through Module-3 to compromise 60% of the tactical network within 180 seconds of simulated operational time, validating the framework’s contagion coefficient predictions. Implementation of the recommended encrypted C2 protocol reduced successful attack propagation to below 5%, demonstrating the effectiveness of the elicited security requirements. Figure 13 and Figure 14 demonstrate the complete Manna SafeIoD certification workflow for the Testbed 5.

7.3. Research Limitations

This subsection provides a critical assessment of the limitations inherent to the Manna SafeIoD framework.

7.3.1. Simulation and Experimental Validation Constraints

COOJA employs idealized radio propagation models that do not fully capture the complex electromagnetic characteristics of aerial environments. Real IoD deployments experience significant signal degradation due to multipath fading, Doppler effects from UAV mobility, and atmospheric absorption—phenomena that may substantially alter attack propagation dynamics. The 60% network compromise rate observed in unmitigated scenarios represents a simulation-derived estimate that requires validation against physical testbeds.

The simulation employed a static network topology during each experimental run, whereas operational IoD networks exhibit continuous topological changes due to UAV mobility, zone transitions, and dynamic mesh reconfiguration. The risk propagation model’s contagion coefficients (${\psi }_{x\to y}$) were computed under steady-state assumptions that may not hold during rapid topology evolution.

The framework has not been validated against physical IoD hardware platforms. Performance metrics such as certification completion time and computational overhead of risk calculations were measured on conventional computing infrastructure rather than resource-constrained embedded systems that would host certification agents in production deployments.

7.3.2. Participant Study

The participant pool (n = 15) provides limited statistical power for detecting subtle usability differences across user profiles. While sufficient for preliminary validation, this sample size precludes robust subgroup analysis (e.g., comparing security experts versus novices) and limits confidence interval precision for satisfaction metrics.

The four civilian test scenarios were carefully constructed to exercise specific framework capabilities. Real-world certification requests may present ambiguous or incomplete contextual information that challenges the questionnaire’s conditional logic in ways not captured by the controlled evaluation protocol.

7.3.3. Framework Scope Boundaries

The framework assumes that hardware and firmware components presented for certification are authentic. Supply chain attacks involving counterfeit components, pre-installed backdoors, or compromised manufacturing processes are not addressed by the current threat enumeration methodology.

While the framework supports multiple regulatory frameworks (FAA, EASA, ANAC, GDPR, LGPD), it does not resolve conflicts arising from simultaneous compliance requirements across jurisdictions with incompatible mandates.

8. Evaluation and Future Works

Protecting an IoD system is an extensive task that requires proficient knowledge across various domains. The aim of this research was to provide a solid foundation to assist new researchers in the process of secure design for IoD devices, as well as to provide subsidies that are effective in an equipment certification process for real-world deployment.

For this reason, all described processes aim to be modular and extensible. The framework can be extended or adopted by other methodologies to provide a link for IoD security analysis. Additionally, during the development and evaluation of the framework, some interesting research directions were identified.

8.1. Simplicity of Use

When assessing the overall usability of a certification tool, its operational efficiency often has a stronger impact on user acceptance than the perceived simplicity of its interface. For this reason, the current implementation adopts a command-line interface (CLI), which is better suited for automation workflows, scripted execution, and integration into continuous certification processes.

To compensate for the absence of a graphical interface and to support a smoother user experience, the CLI incorporates several assistance features. These include dynamic question filtering—so users are only asked about parameters relevant to their context—automatic validation hints that prevent unsupported values, and conditional prompts that reveal more detailed configuration options only when the mission profile requires deeper threat analysis. Together, these mechanisms keep the interaction lightweight while ensuring that users receive guidance appropriate to their operational scenario.

Table 17 demonstrates that 73% (11/15) of participants rated the tool as “easy” (7.5), with zero participants rating it as difficult or very difficult. This outcome validates the framework’s design objective of accessibility for IoD practitioners lacking specialized security training.

The development of a GUI for the framework tool will improve accessibility for non-technical stakeholders, enabling broader adoption across the IoD development community.

8.2. Decision Accuracy and Requirement Selection Validation

Although the Manna SafeIoD tool does not aim to emulate the full analytical reasoning of human security specialists, our evaluation shows that it consistently produces decisions that align well with expert expectations, both in terms of selecting security requirements and recommending suitable algorithms. This conclusion is supported by a systematic comparison between the contextual information provided by participants (Table 17 and Table 18) and the outputs generated by the framework—namely, the assigned security requirements, algorithm recommendations, and corresponding maturity assessments. Additional validation is also drawn from the detailed military certification case study, which further verifies the coherence of the tool’s decision-making process.

As an example of the accuracy decision, for hardware implementation requests, the framework’s algorithm selection demonstrates careful consideration of platform-specific optimization characteristics. Participant MSI321 specified an FPGA-based security co-processor design with requirements for data confidentiality, mutual authentication, and hardware roots of trust. The framework recommended PRESENT-128, a lightweight block cipher extensively evaluated for FPGA implementations with well-documented slice counts and maximum operating frequencies. For mutual authentication, it suggested challenge–response protocols suitable for hardware state machines. However, for hardware roots of trust implementation, the tool returned "*No matching algo found!" because this requirement maps to architectural patterns (TPM modules, secure enclaves) rather than cryptographic algorithms per se, falling outside the current algorithm database’s scope.

For participant MSI111 implementing an ASIC-based drone security module, the framework successfully recommended algorithms across all specified requirements (data confidentiality, message integrity, secure certificate management) because ASIC implementations have been the primary focus of lightweight cryptography standardization efforts, with comprehensive performance evaluations available in terms of gate alents (GEs), throughput, and energy consumption metrics.

8.3. Algorithm Database Limitations and Design Rationale

The “*No matching algo found!” notifications appearing in Table 18 reflect deliberate design decisions rather than framework deficiencies. The Manna SafeIoD algorithm database currently contains 127 lightweight cryptographic primitives that have undergone rigorous standardization processes (NIST Lightweight Cryptography Competition finalists, ISO/IEC standardized algorithms, CRYPTREC evaluated algorithms) and possess sufficient published performance evaluations [138] to enable confident recommendations across diverse IoD hardware platforms.

8.4. Secure-by-Design Process

A significant direction for enhancing the Manna SafeIoD framework for secure-by-design process involves the adoption of Model-Based Systems Engineering (MBSE) techniques, particularly through the Systems Modeling Language (SysML), to provide a standardized and visual approach to secure IoD design. This extension would directly support RQ1 (Security Requirements Elicitation) by enabling systematic, model-driven derivation of security requirements from architectural representations.

Currently, the Manna SafeIoD framework captures security context through structured questionnaires and textual specifications. While effective, this approach presents limitations in terms of visual comprehension, traceability, and integration with existing systems engineering workflows. SysML, as a general-purpose graphical modeling language for systems engineering [139], offers the potential to represent IoD architectures, threat models, and security requirements within a unified, standardized notation that facilitates communication across multidisciplinary teams.

Recent research has demonstrated the viability of SysML extensions for security analysis in cyber–physical systems. Carter et al. [140] proposed the CYBOK methodology, which leverages SysML to model CPS topologies and automatically construct attack surfaces by mapping system components to potential attack vectors. Their approach, validated on unmanned aerial systems, demonstrates how SysML block definition diagrams can be extended with security-relevant metadata to enable systematic vulnerability identification.

In the UAV domain specifically, Hossain et al. [141] demonstrated the application of MBSE with SysML for UAV system modeling using the Magic Grid methodology, integrating SysML models with external simulation tools such as MATLAB and OpenMDAO.

This SysML-based approach would transform the current textual secure design workflow into an interactive, visual modeling environment where security engineers and IoD developers collaborate using a shared architectural representation.

8.5. Privacy-by-Design Issues

The structure of Manna SafeIoD was developed with an emphasis on security rather than privacy analysis. However, due to the modular architecture of the framework, it can be expanded with privacy analysis components in future work. Privacy is often considered a security requirement during the development of IoD systems. However, research in the area of privacy requirements engineering has identified distinct types of privacy requirements that require further analysis. Recent regulations, such as the General Data Protection Regulation (GDPR), impose strict rules on how users’ personal information should be handled. In this context, privacy-oriented risk analysis can significantly contribute to the evolution of certification.

8.6. Monitoring System

A particularly promising extension involves developing continuous monitoring mechanisms for the IoD application layer that enable automated certificate validation and revocation. As outlined in Section 5.5, integrating runtime security monitoring with the certification framework would provide real-time traceability of certified devices, automatically detecting configuration drift, firmware tampering, or emergence of zero-day vulnerabilities that invalidate existing certifications. This capability would materialize the dynamic recertification model central to the framework’s lifecycle approach, ensuring that security assurances remain valid throughout operational deployment rather than representing static, point-in-time assessments.

The development of a monitoring framework addresses three critical requirements identified through our threat modeling analysis (Section 4) and certification methodology (Section 5.5): (1) Continuous Certification Validation: The framework must continuously verify that certified IoD entities maintain compliance with their assigned security levels throughout their operational lifecycle; (2) Adaptive Threat Response: Given the dynamic nature of IoD threats, the framework must adapt security policies and trust assessments based on observed behavioral patterns and emerging threat intelligence; and (3) Decentralized Trust Management: To avoid single points of failure inherent in centralized monitoring systems, the framework must distribute trust computation and enforcement across the IoD ecosystem while maintaining consistency.

A promising application is in a Multi-Chain Blockchain Technology for UAVs as introduced in [142] to ensure decentralized, tamper-proof, and auditable security enforcement, and smart contracts [143].

As a first model for this path, let $\mathcal{N}=\{n_1,n_2,\dots ,n_k\}$ represent the set of IoD nodes, $\mathcal{Z}=\{z_1,z_2,\dots ,z_m\}$ the set of Zone Service Providers, and $\mathcal{S}=\{s_1,s_2,\dots ,s_l\}$ the set of smart services operating within the application layer. The monitoring framework maintains a global state $\mathrm{\Gamma }\left(t\right)$ at time t, defined as:

$$\mathrm{\Gamma }\left(t\right)=\langle \mathcal{C}\left(t\right),\mathcal{T}\left(t\right),\mathcal{B}\left(t\right),\mathcal{P}\left(t\right)\rangle$$

where

• $\mathcal{C}\left(t\right)$ represents the certification state matrix;
• $\mathcal{T}\left(t\right)$ denotes the trust state matrix;
• $\mathcal{B}\left(t\right)$ captures the behavioral observation matrix;
• $\mathcal{P}\left(t\right)$ defines the active policy configuration.

9. Conclusions

The proliferation of the IoD paradigm promises substantial benefits across diverse application domains. However, these benefits remain constrained by significant security vulnerabilities inherent to resource-limited aerial devices operating in dynamic, contested environments. Regulatory and cybersecurity organizations increasingly recognize that robust certification frameworks constitute essential infrastructure for establishing trustworthy IoD ecosystems.

This study presented the Manna SafeIoD framework, a comprehensive security certification methodology specifically tailored for IoD environments. The framework addresses the three research questions: RQ1 (Security Requirements Elicitation), RQ2 (Risk Assessment Validity), and RQ3 (Cross-Context Applicability). The experimental evaluation, conducted with 15 participants across five distinct IoD deployment scenarios, yielded the following key findings:

Security Requirements Generation (RQ1): The framework successfully generated context-appropriate security requirements across all test scenarios, producing an average of 3.0 security requirements per device. The algorithm recommendation system, drawing from a curated database of 127 lightweight cryptographic primitives, achieved a 62.2% matching rate for implementation-specific recommendations. The unmatched cases (37.8%) corresponded primarily to architectural requirements (e.g., hardware roots of trust) that map to design patterns rather than specific algorithms.

Risk Assessment Validity (RQ2): The graph-based risk propagation model demonstrated predictive accuracy in the military tactical ISR case study (Test 5). COOJA network simulations validated that the framework’s risk mitigation recommendations reduced attack propagation from 60% network compromise to less than 5% under identical threat conditions, confirming the effectiveness of the proposed security controls.

Cross-Context Applicability (RQ3): The framework demonstrated adaptability across heterogeneous deployment contexts, spanning civilian applications to mission-critical military deployments. Usability assessment revealed that 73% of participants rated the tool as “easy to use,” with zero participants rating it as difficult, validating accessibility for practitioners with varying security expertise levels.

The Manna SafeIoD framework represents an initial contribution toward establishing standardized, scientifically grounded security certification practices for IoD systems. By operationalizing theoretical security requirements engineering through automated risk assessment and context-aware requirement selection, the framework bridges the gap between abstract security principles and concrete implementation guidance—serving both companies seeking to embed security-by-design principles and regulatory organizations requiring standardized assessment tools for certification processes.