Introducing the Cyber-Physical Data Flow Diagram to Improve Threat Modelling of Internet of Things Devices Simon Liebl 1,2 , Ian Ferguson 2 , Andreas Aßmuth 3 , Natalie Coull 2 , George R. S. Weir 4 1
arXiv:2604.22307v1 [cs.CR] 24 Apr 2026
emgarde, Ebermannsdorf, Germany e-mail: [email protected] 2 Abertay University, Dundee, UK e-mail: ti.ferguson | [email protected] 3 Kiel University of Applied Sciences, Kiel, Germany e-mail: [email protected] 4 University of Strathclyde, Glasgow, UK e-mail: [email protected]
Abstract—A growing number of Internet of Things (IoT) devices are used across consumer, medical, and industrial domains. They interact with their environment through sensors and actuators and connect to networks such as the Internet. Because sensors may collect sensitive data and actuators can trigger physical actions, security, privacy, and safety are major challenges. Threat modelling can help identify risks, but established IT-focused methods transfer to the IoT only to a limited extent. In this paper, a new modelling technique specifically for IoT devices called CyberPhysical Data Flow Diagram (CPDFD) is proposed that also allows modelling of hardware with the aim to support manufacturers in identifying threats and developing countermeasures. The technique was examined through an experimental study and a survey with interviews. The results suggest that numerous other attack scenarios can be found through the modelling technique, improving the identification of threats to IoT devices. Keywords-Security; Internet of Things; Embedded Systems; Threat Modelling; Cyber-Physical Data Flow Diagram.
I. I NTRODUCTION The Internet of Things (IoT) is the interconnection of billions of devices via the Internet or another network. These devices are used in a wide variety of areas, such as the smart home, medical, and industrial applications. Their key characteristics include interacting with the environment via sensors and actuators and communicating with other devices and systems. Networking them aims to extend functionality, integrate services, improve usability, increase efficiency, and reduce costs. However, adding multiple network interfaces also expands the attack surface and increases the risk of cyber attacks. It seems that the number of published incidents is steadily increasing [1], indicating that IoT security is a serious problem. In recent years, incidents have been reported in various IoT application fields, such as industrial (e.g., attacks on Ukraine’s power grid [2]), medical (e.g., insulin pumps and ventilators [3]), automotive (e.g., hack of Tesla and its Wall Connector [4][5]), infrastructure (e.g., traffic lights [6]), and smart home (e.g., vacuum robot [7]). The described small sample of security incidents related to IoT devices and systems shows that there is a systematic problem threatening security, privacy, and safety. Therefore, new approaches are required to better protect IoT devices from such threats. A promising approach that is already
established in the IT domain is the risk assessment using threat modelling. Threat modelling is the systematic approach to identifying threats and vulnerabilities to a particular system. Appropriate countermeasures can then be defined. The process can also be carried out early in the product lifecycle, which supports the goal security by design. However, common threat modelling approaches from the IT domain cannot necessarily be adopted to IoT devices. Reasons for this are that IoT devices consist of resource-constrained embedded systems and that their interaction with the real world poses an increased risk to the privacy and safety of users. As part of this work, the modelling technique Data Flow Diagram (DFD), which is often used in threat modelling, was specifically examined. Several adaptations are proposed to increase the applicability of DFDs to IoT devices, including two new elements and the possibility to create a Hardware Diagram (HWD). This extension, called Cyber-Physical Data Flow Diagram (CPDFD), has the aim to enable more detailed modelling of the components of IoT devices and thus allow better threat identification compared to regular DFDs. This technique is intended to support device manufacturers in identifying threats and developing appropriate countermeasures. The remainder of this paper is structured as follows: in Section II, the fundamentals of IoT devices and threat modelling are provided. Section III presents related work regarding IoT security, threat modelling, and DFDs. In Section IV, the proposed extension CPDFD is introduced. The methodology for evaluating CPDFDs consisting of two studies is described in Section V, followed by the presentation of the results. These results are then discussed in Section VII. The paper ends with conclusions in Section VIII. II. BACKGROUND A. Internet of Things Devices The IoT is a “group of infrastructures interconnecting connecting objects and allowing their management, data mining and the access to the data they generate” [8]. These objects are devices extended with network connectivity and computing capabilities and require usually minimal human intervention [9]. The architecture of the IoT is often structured into different
Please cite as: Simon Liebl, Ian Ferguson, Andreas Aßmuth, Natalie Coull, and George R. S. Weir, “Introducing the Cyber-Physical Data Flow Diagram to Improve Threat Modelling of Internet of Things Devices,” in Proc of the First International Conference on Cross-Domain Security in Distributed, Intelligent and Critical Systems (CROSS-SEC 2026), Lisbon, Portugal, pp. 30–39, April 2026.
layers [10]. The perception layer, the lowest layer, consists of these physical objects, such as sensors, actuators, or RadioFrequency Identification (RFID) tags. These device are also used in a Cyber-Physical System (CPS), for example, to control physical processes in the real world [11]. For such systems, real-time requirements are essential, which differentiates them clearly from IT systems. The impact of IoT devices can thus affect security, privacy, and safety and have consequences such as the disclosure of sensitive data in medical applications or human injury in industrial applications. IoT devices are embedded systems, which are specific computer systems built for a custom purpose. Their basic components consist of hardware, software, and data [12]. Examples for hardware components are microcontroller, memory chip, Printed Circuit Board (PCB), security chip, power supply, and various sensors and actuators. Software components include firmware, basic libraries for cryptography and logging, and protocol stacks for numerous IoT protocols, such as Bluetooth, ZigBee, and MQTT. Besides firmware, devices store access data, keys, and configuration and log files, among others. B. Threat Modelling In this section, the DFD and two published threat modelling techniques are introduced. The small excerpt of techniques is necessary to understand the remainder of this paper. 1) Data Flow Diagram: The DFD is a graphical modelling technique used historically in the field of software engineering and system analysis [13]. It quickly gained popularity due to its intuitive nature and ability to capture both high-level and detailed views of system processes and data. A DFD consists only of four elements: Process, Data Store, External Entity, and Data Flow. This enables a simple visual representation of complex systems and illustrates how data is input, processed, stored, and output. Processes represent the transformation of data and can be thought of any running code. Data stores depict any type of data storage, such as files or databases. External entities are used to describe external data sources or destinations, e.g., people or any code outside your control. Data flows are used to connect the other three elements. Besides their use in software engineering, security experts found their application also valuable in the field of cyber security. The analysis of the system is an important part of a security assessment conducted to find threats and vulnerabilities. In order to limit the assessment for complex systems, another element called Trust Boundary or Trust Area was added to visualise different trust levels, initiating the second version of DFDs [14]. Since DFDs are typically created during early design, they naturally support the analysis of architectural security issues rather than implementation-level defects. 2) STRIDE and LINDDUN: The CIA triad – Confidentiality, Integrity, and Availability – forms the basis of information security, often complemented by goals such as authenticity, non-repudiation, and authorisation. STRIDE covers the threats spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege [14], and was developed
at Microsoft to identify such threats during design [15]. It maps directly to these six security goals. STRIDE can be applied to DFDs, but checking all six threats for every element is time-consuming. Since some elements are more susceptible to specific threats, STRIDE-per-Element and STRIDE-per-Interaction were introduced to streamline the analysis [14]. LINDDUN is a framework for privacy threat modelling. Similar to STRIDE, LINDDUN is an acronym that stands for linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance and can be combined with DFDs as well [16]. The threats are therefore not focused on security goals, but are instead aimed at privacy goals. III. R ELATED W ORK IoT security and privacy is still a huge problem, which is why a lot of research is being conducted in a variety of directions. Due to the many articles around IoT security, there are several reviews with the aim to summarise, among others, threats, attacks, challenges, and solutions [17]–[21]. Some researchers focused specifically on IoT devices, often using hands-on approaches to show how embedded systems can be attacked, which threats arise, and how they can be mitigated [22]–[26]. Regarding threat modelling and risk assessment, there are a couple of articles with the aim of adapting these methods for the IoT. In [27], they aim to automate this process for IoT systems by providing their own methodology. The authors of [28] present a STRIDE and DFD-based threat modelling approach specifically for CPSs with special focus on human injury, equipment damage as well as black-out. Many articles address specific fields of application such as automotive [29], building and home automation [30], agriculture [31], and healthcare devices [32]. DFDs are also relevant to this work. In this regard, [33] and [34] are particularly worth mentioning, as they propose adjustments to DFDs with the aim of improving threat identification and generation. In summary, there is a lot of research in the area of IoT security and privacy, also with special emphasis on threat modelling. In the case of IoT devices in particular, the differences between embedded systems and IT systems were recognised and threats analysed that emerge through sensors, actuators, and interaction with the environment and other systems. However, the hands-on approaches and the various methods for the different IoT applications emphasise that a common technique for modelling IoT devices has not yet been established. IV. C YBER -P HYSICAL DATA F LOW D IAGRAM This section introduces the proposed modelling technique CPDFD by describing its aims and adaptations. A. Aim As mentioned before, there are several issues with modelling IoT devices. One big difference between IT and IoT applications is the interaction with the physical world. While this is an
integral part of the latter, it is hardly present in IT applications. In IoT systems, a sensor, the data source, usually measures an environmental value, such as temperature, photographic picture, or heart activity. The processing of the data can in turn lead to physical operations by the actuator, the data sink, and thus result in changes in the environment. For example, a valve is opened, a car battery is charged, or a door is unlocked. From a security point of view, these sensor values and actuator actions are particularly interesting, as they can threaten the privacy and safety of users. It is therefore necessary to address this difference, the interaction with the physical environment, also in the modelling. Another difference between IT and IoT applications is the location and purpose. IoT devices are used in critical applications, such as healthcare, automotive, and automation. Many of them are placed outdoors, e.g., security cameras, charging stations, or pipeline valves. The criticality as well as the accessibility of the devices make hardware attacks interesting for attackers and are frequently reported [35]. Successful attacks give deep insight into the device and often lead to access to Intellectual Property (IP), sensitive data, credentials, and cryptographic secrets. Therefore, hardware attacks, which are often out of scope in IT applications, need to be considered due to the accessibility and the frequent critical application. One core element of IoT devices is the communication with other devices and systems. Besides dozens of wireless communication protocols, such as Z-Wave, Wi-Fi, and NFC, wired protocols including Modbus, Ethernet, and USB are commonly used. Additionally, several common protocols used in embedded systems are used, for instance, UART, RS-232, and JTAG. With the multitude of protocols and interfaces in use, it is therefore easy to lose track which of them are actually utilised in an IoT device. However, these various protocols and interfaces increase the attack surface and can become a gateway for attackers. The goal is therefore to be able to represent these interfaces in a model in order to get a quick overview of the connectivity of a device. There is another difference between the development of IoT devices and IT applications. Modelling the latter is mainly done by software and network engineers that commonly have a computer science background. However, modelling an IoT device may also require the help of hardware and embedded engineers with a background frequently in mechanical or electrical engineering. Therefore, a modelling technique for IoT devices needs to be simple and at the same time comprehensive in order to be applicable by people with different backgrounds. B. The Technique As mentioned before, the CPDFD is proposed to support modelling of IoT devices. The technique extends the DFD, which is commonly used for security assessments and is known by many security experts and engineers. The following paragraphs describe adjustments to the DFD in order to achieve the previously described aims.
It is difficult to represent the interaction with the physical environment through sensors and actuators using the five elements of a DFD. Depending on the sensor characteristics (e.g., simple electrical resistors or modules with a serial interface), it can make sense to represent them as Process, Data Store, or External Entity or even as a combination with Data Flows. However, this question of detail would take a lot of time and contradict the principle of simplicity of DFDs. If one does not know how to represent a specific component right away, it could be omitted. This in turn would lead to a situation where measured values which might threaten the privacy, for example, would not be recorded. This applies analogously to actuators and safety as a protection goal. It is therefore proposed to add a new element called Physical Link to the DFD notation in order to be able to model these interactions with the physical environment. The goal of this element is to give sensors and actuators a first-class representation in the diagrams, highlighting issues with the goals of privacy and safety. Another aim of the CPDFD technique is to enable the creation of hardware models in order to support the identification of hardware attacks, among others. In theory, there are dozens of modelling techniques (see [36]). However, the authors are not aware of any hardware modelling technique that is commonly used for the threat analysis. Hardware components were integrated into DFDs in a few cases (e.g., [37][38]). It is proposed to use the DFD notation to create a separate HWD. This is achieved by splitting the elements into logical and physical ones. Regular DFDs are mainly used for modelling software-related components, which are now referred to as logical elements. The additional physical elements are used for the creation of the HWD. The physical data store can be used to model a flash or One Time Programmable (OTP) memory, for instance. Likewise, the physical processor and the physical trust area can be used to model microprocessors and PCBs, for example. Modelling of data flows is not necessary in the HWD. The CPDFD technique should also allow users to get a quick overview of the device’s communication interfaces. Similar to the Physical Link before, modelling the interfaces through one of the standard elements could have the effect that these are not modelled. It is therefore proposed to model them as a separate element named Interface as part of the HWD. All elements of a CPDFD and their use in a DFD and HWD are shown in Table I. The proposed extension has further advantages. A DFD can be augmented with links to the hardware model. For example, for data stores, such as a file, it can be specified in which memory it is stored and for data flows, the utilised communication interface can be provided. This additional context can lead to a more precise description of an attack scenarios and thus support the threat identification. The new elements Physical Link and Interface have another benefit when it comes to software-aided modelling. Threat rules for automatic threat generation can be specified more precisely or can be created specifically for the two elements. This can reduce false positives, i.e., wrongly identified threats,
TABLE I. T HE ELEMENTS OF A CPDFD. T HE LAST TWO COLUMNS INDICATE THEIR USE IN DFD S AND HWD S . Element
Symbol
Process
Name
Data Store
Name
External Entity Interactor
Name Name
Data Flow
Trust Area
Name Name
Meaning & Examples
DFD
HWD
b l
l b
b l
l b
b b
l l
Communication between elements (Log.) Data Flow: Data flow with protocol (stack)
b
l
Delimited area of trust Log. Trust Area: Net segment, container Phy. Trust Area: PCB, casing
b b
l b
Executed code Log. Process: Code in C, web server Phy. Processor: Microprocessor, TPM Things that store data Log. Data Store: File, database Phy. Data Store: FLASH, OTP memory People or code outside your control Log. External Entity: Browser, cloud service Phy. External Entity: User, machine
Physical Link
Name
Link between physical and logical world Physical Link: Microphone, battery, motor
b
b
Interface
Name
Communication interface Interface: Wi-Fi, USB, JTAG
l
b
and false negatives, i.e., undetected threats. The commonly used techniques STRIDE-per-Element and LINDDUN can still be used for CPDFDs and also provide more accurate results. Last but not least, the CPDFD technique establishes a unifying notation for HWDs and DFDs. The resulting diagrams remain simple and clear, despite the addition of two elements and the distinction between physical and logical elements. They can be created and understood by hardware, embedded, and software engineers and other people as well.
body temperature. In this study, participants were supported by a custom software tool called TTModeler [40][41], but the supported modelling technique, specifically the two new elements, differed for both groups. The modelling technique thus serves as an independent variable. The produced project file and a concluding questionnaire served as the data source for further analysis. For the sake of completeness, it should be noted that there was a third group with a different software tool, but this is not of interest for this paper. The aim of this study is to gather evidence on the usability V. M ETHODOLOGY of each tool, which is the “degree to which a product or system The methodology for evaluating the improvements of the CP- can be used by specified users to achieve specified goals with DFD is introduced in this section. It consists of an experimental effectiveness, efficiency, and satisfaction in a specified context of use” [42]. For this purpose, effectiveness is defined as study and a survey with interviews. “accuracy and completeness with which users achieve specified A. Experimental Study goals” and efficiency as the resources expended in relation to This section introduces an experimental study with the the effectiveness [42]. More precisely, it was measured how objective to compare CPDFDs with DFDs by quantitatively much time is spent on the creation of a specific model and how comparing the number of attack scenarios identified by two many attack scenarios were found in this context, enabling the groups, each using one modelling technique. Participants of quantification in identified attack scenarios per minute for the the study, who were students of computer science-related study hardware model, among others. This can be used to determine programmes, were put in the following situation: As innovative the efficiency. The impact of the additional elements Physical students, they have applied their previously acquired knowledge Link and Interface was specifically examined. in practice and developed a smart IoT device alongside their It was decided to conduct the study with students because studies. They now want to bring the device to market, but they they are available at short notice and in larger numbers still have concerns about security and privacy. Therefore, each than, for example, developers from industry. Students from participant had the task of examining the device for threats study programmes related to computer science were invited and vulnerabilities. The analysed device was the open source to participate in the study. All participating students were in device Jaimico [39], which is a combination of voice assistant the fourth year of their studies. They represent the actual users and health monitor. The companion robot can be worn on the well, as they have, for example, only rudimentary experience shoulders in daily life and can be used as a voice assistant or in the field of security, as it is the case with many firmware health monitor to measure body temperature and heart activity and software developers. A total of 46 students volunteered to by connecting to a wearable. In addition to analysing health participate in the study. Five of them took part in a preliminary data in the cloud, the device offers the special feature of study, which was conducted to find issues in the procedure detecting Covid19 through analysing recorded coughing and and task description, and their results are not considered.
This results in a sample size of 41. Due to the omitted third group and unexpected cancellations, 12 participants used the modelling technique CPDFD, denoted as GCPDFD , and 14 participants used the DFD technique (GDFD ). Participants first read an information document covering the CIA, STRIDE, and LINDDUN threat models, as well as IoT privacy threats defined by [43]. They then received a second document introducing DFDs, including STRIDE-per-Element, LINDDUN-per-Element, and example diagrams. Group GCPDFD received a modified version explaining CPDFD elements instead of standard DFDs. Next, participants read the description of the example device Jaimico and watched a video demonstrating the main features of the assigned tool, including how to model the “Register device” use case and add threats. They then worked on the task, with the option to stop at any time within a three-hour limit. Finally, they completed the questionnaire and submitted their project file. The submitted project files and questionnaires served as the data sources. Project files were analysed for diagrams, elements, and attack scenarios. Duplicates and out-of-scope scenarios were marked and excluded. Remaining scenarios were filtered and labelled as considered attack scenarios. Because the device description was partly fictitious, scenarios were classified as having either low or high probability of correctness. Most were rated high, with exceptions such as “Malicious file on USB flash drive”, since the USB port was specified as charging-only. Each scenario was assigned a type: generic, outlined, or custom, indicating the level of detail and difficulty of identification. Generic scenarios were directly derived from STRIDE or LINDDUN, outlined scenarios added some detail (e.g., “Clear text data storage of the database”), and custom scenarios were highly specific or not obviously derived from a threat model (e.g., “Unsecure Bluetooth version”). Only high-probability scenarios of type outlined or custom were considered relevant. The tool was modified to track modelling time. After completing the task, participants answered a 21-item questionnaire, including eight items on threat identification and 13 on usability. The further analysis of the collected data was carried out with the help of descriptive and inferential statistical methods [44] and may be visualised using a box plot [45]. The significance level for rejecting a null hypothesis is set at α “ 5%. Depending on whether the results are normally distributed, either the t-test or the Mann-Whitney U test is used to test for a difference between two groups. Subsequently, Cohen’s d is calculated to quantify the effect size [46][47]. It can be assumed that there is a small effect for 0.2 ă d ă 0.5, a medium effect for 0.5 ď d ă 0.8, and a large effect for d ě 0.8.
TABLE II. OVERVIEW OF PARTICIPANT AND COMPANY CHARACTERISTICS . Category
Distribution
8 device manufacturers; 7 service providers 9 security experts; 6 engineers 7 large; 3 medium-sized; 4 small; 1 micro 8 industrial; 3 consumer; 2 automotive; Field of application 1 medical; 1 infrastructure 46.7% embedded security; 80.0% DFD; Experience 60.0% threat modelling Company type Participant role Company size
own devices and provide afterwards feedback through a questionnaire and an interview. The aim is to specifically ask for opinions on the HWD and the new elements. All persons with a connection to cyber security, IoT, or embedded systems were invited for the study. In total, 15 participants could be recruited for the study. Table II categorizes participants according to the type of company, the size of the company (according to [48]), and the experience. Noteworthy is that two participants had no cyber security experience (13.3%). At the start of the study, participants received an introduction to threat modelling, the adaptations used in this work, and their task. After completing and evaluating the contributions, they filled out a questionnaire and answered a few interview questions. The questionnaire, consisting mainly of five-point Likert items [49] and free-text fields, together with the interview, served as the data sources. Questionnaire responses were analysed descriptively, while the free-text fields and interview data were examined qualitatively. VI. R ESULTS The following section summarises the results of both studies. A. Experimental Study
This section presents the results of the experimental study, summarised in Table III. The first tests on the results using the Shapiro-Wilk test showed that the sample is not normally distributed. This could be caused by the rather small sample size, for example. It was therefore decided to consistently use non-parametric methods. Table III shows the duration needed to conduct the study for both groups. Note that this duration represents the pure interaction time with the tool and does not include the learning time required for the threat models, CPDFD/DFD, and the introduction to Jaimico. Group GCPDFD has a wide range of 80 to 142 minutes (M “ 111 min, SD “ 20 min). In contrast, GDFD has a higher mean value of 120 minutes (SD “ 10 min) and a narrower range of 98 to 132 minutes. Despite these differences, there is a large overlap of the ranges and it indicates that the technique used does not have a significant influence on the execution duration (Mann-Whitney U test, B. Survey and Interviews U “ 62.5, p “ .280, p ą α). The last study aims to get feedback from people who might The number of considered attack scenarios, i.e., without actually utilise CPDFDs. These include device manufacturers as duplicates, high probability of correctness and out of scope well as consultancies. Manufacturers often do not have security (see subsection V-A), have a large range. Participants of GCPDFD experts themselves and therefore hire external companies. found in total between 2 and 182 attack scenarios (M “ 69.21, Participants apply the methodology (Thing Threat Modelling SD “ 40.44) and GDFD found between 2 and 74 scenarios (TTM)), technique (CPDFD), and tool (TTModeler) on their (M “ 45.17, SD “ 19.85). The scenarios start at 2, as some
TABLE III. OVERVIEW OF THE PROJECT FILE ANALYSIS . GCPDFD Duration 111 min ˘ 20 min Considered attack scenarios 69.21 ˘ 40.44 19.29 ˘ 22.08 Type: Generic 27.86% ˘ 31.90% 10.86 ˘ 5.84 Type: Outlined 15.69% ˘ 8.44% 39.07 ˘ 17.17 Type: Custom 56.45% ˘ 24.80% 49.93 ˘ 21.00 Relevant attack scenarios 72.14% ˘ 30.34% 44.93 ˘ 19.48 Goal: Security 89.99% ˘ 39.01% 5.00 ˘ 2.11 Goal: Privacy 10.01% ˘ 4.23% 10.86 ˘ 5.17 Physical Link-related 21.75% ˘ 10.36% 11.21 ˘ 5.10 Interface-related 22.46% ˘ 10.22% 29.07 ˘ 11.28 Model: Hardware 58.23% ˘ 22.58% 4.29 ˘ 8.09 Model: Software 8.58% ˘ 16.20% 16.57 ˘ 8.71 Model: Data flow 33.19% ˘ 17.44% Time for hardware model 26 min ˘ 14 min Time for software model 9 min ˘ 7 min Time for data flow model 64 min ˘ 21 min Time per attack scenario 2 min ˘ 0 min - for hardware model 1 min ˘ 0 min - for software model 2 min ˘ 2 min - for data flow model 4 min ˘ 1 min
GDFD 120 min ˘ 10 min 45.17 ˘ 19.85 17.92 ˘ 14.64 39.67% ˘ 32.41% 9.58 ˘ 7.95 21.22% ˘ 17.60% 17.67 ˘ 10.00 39.11% ˘ 22.15% 27.25 ˘ 11.32 60.33% ˘ 25.07% 27.00 ˘ 11.14 99.08% ˘ 40.89% 0.25 ˘ 0.45 0.92% ˘ 1.66% Figure 1. Relevant attack scenarios for groups GCPDFD and GDFD as box plot. 9.50 ˘ 6.67 34.86% ˘ 24.47% 4.67 ˘ 5.77 17.13% ˘ 21.19% 13.08 ˘ 9.40 48.01% ˘ 34.51% 12 min ˘ 12 min 8 min ˘ 7 min 96 min ˘ 17 min 4 min ˘ 0 min 1 min ˘ 1 min 2 min ˘ 2 min 7 min ˘ 1 min
and Interface available, identified substantially more attack scenarios. Attack scenarios were categorised whether these threaten the security or privacy of the device under consideration. Group GCPDFD identified 5.00 scenarios on average (SD “ 2.11), while GDFD identified less than 1 scenario on average (M “ 0.25, SD “ 0.45). Therefore, they identified significantly more privacy attack scenarios than GDFD (Mann-Whitney U test, U “ 160.5, p “ .000, p ď α, dCohen “ 3.01, large Note: The values of the last two columns show the mean value and effect). A more detailed analysis shows that out of these 5 the standard deviation. Furthermore, the table is split in three sections. scenarios of GCPDFD , 3.64 scenarios were identified through The percentages in the second section refer to the considered attack the element Physical Link (SD “ 1.69), 1.21 through the scenarios, those in the third section to the relevant attack scenarios. Interface (SD “ 0.58), and only 0.14 scenarios through other elements (SD “ 0.36). Consequently, this suggests that the participants had mainly modelled the example use case showed used technique, CPDFD or DFD, has an influence on the in the introductory video. Their type, generic, outlined, and identified attack scenarios against privacy. Figure 2 shows the average number of identified attack custom, can be further analysed. The results for the types generic and outlined are similar and with overlapping error bars scenarios per group. Furthermore, it highlights how many (see Table III). A difference can be seen for the type custom. scenarios of GCPDFD relate to the additional elements of a The groups GCPDFD and GDFD found on average 39.07 (SD “ CPDFD – Physical Link and Interface. The comparison of 17.17) and 17.67 (SD “ 10.00) scenarios respectively. The GCPDFD and GDFD shows that both groups found on average Mann-Whitney U test shows that both groups are significantly almost the same number of scenarios for category Others. The different from each other. Therefore, GCPDFD found significantly extra scenarios of GCPDFD relate to the new elements. Therefore, more attack scenarios of the high ranked type custom than this suggests that further attack scenarios can be found through GDFD (U “ 155.0, p “ .000, p ď α, dCohen “ 1.50, large the two elements. effect). This means that GCPDFD found more scenarios with Table III includes in which model, hardware, software, high information value that are more difficult to find. or data flow, the attack scenarios were identified. The main The attack scenarios were filtered again to include only those difference can be seen for the hardware model. Group GCPDFD of the type outlined and custom as explained in subsection V-A. has a range of 14 to 45 identified scenarios, without a single This reduced list of relevant attack scenarios is visualised outlier at 2, and a median of 29.5. GDFD has a range of 0 to 19 in Figure 1. The main range of GCPDFD is between 33 and and a median of 11.5. The Mann-Whitney U test shows that 74 scenarios with two outliers at 2 and 94, while GDFD the groups are significantly different (U “ 156.0, p “ .000, ranges between 2 and 39. The ranges overlap, but the boxes p ď α, dCohen “ 2.08, large effect). Again, the difference highlighting the lower and upper quartiles do not. The median between GCPDFD and GDFD arises from the two new elements. of GCPDFD (49) differs from GDFD (30) by 19 scenarios. The median Physical Link and Interface-related scenarios for The result of the Mann-Whitney U test shows that group the former are 6 and 10.5 scenarios, respectively. The median GCPDFD identified significantly more attack scenarios than GDFD scenarios for the standard elements are 13 and similar to GDFD . (U “ 147.0, p “ .001, p ď α, dCohen “ 1.32, large effect). This The results indicate that it is worth creating a hardware model clearly shows that group GCPDFD , which had the Physical Link and that there is an improvement due to the new elements.
Whitney U test, U “ 13.5, p “ .911, p ą α). Therefore, the difficulty of creating a CPDFD and DFD can be considered as equal. B. Survey and Interviews This section presents the results of the survey and interviews with device manufacturers and consulting companies. The precise duration for conducting the study was not measured. Participants indicated that they invested from two hours up to two days. Most of them applied the TTM methodology on their own devices. A few also carried out the analysis for other devices, e.g., power inverter or smart home. Some people used the results from previous assessments for a side-by-side comparison. Figure 2. Average attack scenarios per group. In group GCPDFD , scenarios a) Questionnaire: All participants agreed that it is worth relating to the elements Physical Link and Interface are highlighted. to create and analyse a hardware model (13 strongly agreed, 2 agreed) and no one disagreed that reusing the elements of a DFD is the right technique for this (4 strongly agreed, 5 agreed, Furthermore, the tool TTModeler tracked how much time 3 indecisive). It was also asked about the added value of the participants spent on creating and analysing the different two new elements, resulting in exactly the same outcome. The models, enabling the calculation of the duration per attack majority of 58.3% strongly agreed that both elements Physical scenario (see Table III). Group GCPDFD needed on average 2 Link and Interface provided added value (17% agreed, 8% minutes per scenario (SD “ 0 min), while GDFD needed 4 each indecisive, disagreed, and strongly disagreed). They also minutes (SD “ 0 min). The average time per attack scenario agreed (72.7%) that the elements contribute to a more accurate in the hardware model was even less for both groups, because modelling of IoT devices. Additional feedback was provided both needed 1 minute per scenario on average. These scores noting that the two elements facilitate modelling, but that the indicate the improved efficiency of CPDFDs and also of a interface needs to be more integrated. It was also remarked that hardware model in general. the meaning of both elements is similar. The results suggest It was recorded how participants modelled certain com- that the hardware model, the Physical Link, and the Interface ponents. The technique CPDFD would classify microphone, improve the threat identification. loudspeaker, touch screen, and temperature sensor as element b) Interviews: This section summarises the findings of Physical Link, for example. While almost all participants in the interview analysis. Statements by individual persons are group GCPDFD modelled the microphone as Physical Link anonymised. If necessary, the person is described by categories (93%), the other group was divided. One quarter modelled introduced in subsection V-B. In these cases, the role of the the microphone as Process, 17% as External Entity, and the persons and their company type are indicated in parentheses, majority of 58% did not model it at all. For the loudspeaker, the together with their participant number, e.g., (P1 , security expert, picture is almost the same: only one participant had modelled manufacturer). it as Data Store instead of Process. While the majority of When participants were asked about the relevance of a GCPDFD also modelled the touch screen, the temperature sensor, hardware model, all agreed that this is an important part. Several and the PCB, the share for GDFD was one third or less. The participants stated that the hardware model was the best part battery was not modelled by anyone of GDFD , but by 86% of of the TTM methodology. Hardware attacks are not considered GCPDFD . Likewise, the same was analysed for the interfaces sufficiently and “without them one cannot find the crux of the JTAG, Bluetooth, Wi-Fi, and USB. Almost all participants of matter” (P8 , security expert, manufacturer). One participant GCPDFD modelled these components as element Interface (86%, had tried to represent hardware security in a model in the past 93%, 86%, and 79%, respectively). In contrast, only 8% of using the system modelling language. However, he said that GDFD modelled JTAG, Bluetooth, and Wi-Fi and 25% modelled a structured threat analysis was not possible. In general, it the USB interface. Since the majority of GCPDFD modelled all was seen as positive that one can quickly see how the device these components, while GDFD did not, this suggests an added is constructed and which interfaces and components, such as value of the two elements Physical Link and Interface. Trusted Platform Modules (TPMs), it uses. Last, a brief review of the questionnaire. The only item The extension of the DFD notation with the two elements of interest in this study was about the simplicity of creating Physical Link and Interface was seen positive, but some a CPDFD/DFD. A total of 61.54% of GCPDFD agreed that participants were not fully convinced. One participant found the creating a DFD is easy, while 41.67% agreed of GDFD . This extension very good, as she “struggled in the past to map certain seems to indicate that the two new elements of a CPDFD hardware components in a well-distinguishable yet abstract have not increased the difficulty of a DFD, but actually made way” (P13 , security expert, service provider). The Physical it easier. However, this difference is not significant (Mann- Link was found to be good, as data is generated there and
actuators can influence the environment. “Even if a sensor is analogue, that does not mean you don‘t have to think about it” (P10 , security expert, service provider). More feedback was given for the Interface. It is useful and important, as “debug interfaces are often overlooked” (P9 , security expert, service provider). In a certain way, one is also forced to think about interfaces. However, a few participants noted that they did not fully understand the difference between both elements. The elements could also make the models more abstract and thus more vague in certain cases. One participant noted that the new elements are useful; their use is left to the user. The feedback from the participants clearly shows that the hardware model brings improvements and is important for the threat analysis. Overall, the two new elements were also seen positively and their enrichment appreciated.
modelled specific components. For example, almost all of group GCPDFD modelled the microphone as Physical Link. In contrast, only 42% of GDFD modelled it. They were indecisive which element to use, as 3 participants modelled it as Process and 2 as External Entity. The interfaces such as JTAG and Bluetooth were modelled by about 90% of GCPDFD while these were modelled by only one third or less of GDFD . This means that the existence of the two new elements leads to such components being modelled at all. The two elements do not make the technique more difficult, as the questionnaire showed. In the survey, the majority of 75% agreed that each Physical Link and Interface provide added value and 73% agreed that they contribute to more accurate modelling of IoT devices (see subsection VI-B). In the interviews, the elements were generally seen positive. One security expert confirmed the problems with modelling certain hardware components without VII. D ISCUSSION the new elements. The Physical Link was said to be good as data A. Hardware Model is generated there and actuators can influence the environment In the experimental study, the median of group GCPDFD and the Interface was conceived to be important as debug identified 29.5 attack scenarios in the hardware model (59.1% interfaces are often overlooked, among others. However, it of all), GDFD found at least 11.5 scenarios (42.2%). The was noted a few times that the differentiation between both efficiency was also higher for the hardware model (1 minute per elements is not clear and that they could be summarised in one scenario) than for the average (2 and 4 minutes per scenario for element. In summary, there are many arguments in favour of GCPDFD and GDFD respectively). In the survey, all participants, introducing the two new elements. The Physical Link leads to security experts and engineers, agreed that it is worth to several additional scenarios, as seen in the experimental study, create and analyse a hardware model (see subsection VI-B). although not as many as for the Interface. The element can be Furthermore, they reaffirmed the importance of the hardware used to represent sensors, which in turn have mainly contributed model in the interviews. One of the advantages they mentioned to the identification of threats against privacy. This added value was the quick overview of all components and interfaces. In was also endorsed by the survey participants. The results thus conclusion, the quantitative and qualitative results speak in suggest that the Physical Link improves the threat identification. favour of a hardware model. This suggests that using a hardware The situation is similar for the Interface. Quantitatively, even more scenarios could be identified with this element. The model may improve threat identification. importance of interfaces was highlighted by students as well as B. Physical Link and Interface security experts and engineers. Therefore, the results suggest The two new elements Physical Link and Interface were the Interface improves the threat identification as well. evaluated separately, but the jointly collected results differ only slightly. Their results are therefore summarised together first C. Limitations Some limitations must be taken into account in the reported and then briefly discussed individually. In the experimental study, the two groups GCPDFD and GDFD results. The HWD produced dozens of attack scenarios, but had the single difference that the former had the two new several of them may also be found in DFDs, creating overlaps. elements available in the diagram editor. However, GCPDFD Consequently, the number of additional scenarios contributed by found significantly more scenarios than GDFD (49.9 and 27.3 on the HWD is lower than the raw count suggests. The quantitative average respectively) (see subsection VI-A). The assignment of effects of the two new elements must also be considered with the scenarios to elements showed that GCPDFD also discovered caution. In the experimental study, participants of GCPDFD had 27.9 scenarios for the standard elements. The additional predefined stencils for the Physical Link, e.g., microphone and scenarios were initiated by the Physical Link (10.9) and the loudspeaker, and for the Interface, e.g., JTAG and Bluetooth. Interface (11.2). There was also a difference regarding privacy- The list of dozens of stencils had to be searched through first, related threats. Group GCPDFD found on average 5.0 scenarios but these increase the likelihood that such components will while the GDFD found less than 1 scenario. The difference is be modelled. The modelling then automatically led to further not statistically significant, but can be explained by the fact scenarios. For a more detailed examination of the effects of that GCPDFD found 3.6 scenarios with the Physical Link and the two elements, further groups would have been necessary, 1.2 scenarios with the Interface. This effect could also be which would not have had predefined stencils available. seen in the hardware model. The median found 29.5 and 11.5 VIII. C ONCLUSIONS AND F UTURE W ORK scenarios for GCPDFD and GDFD , respectively. More than half of the scenarios of the former were based on the Physical Link The many security incidents in the IoT highlight the ongoing (6) and Interface (10.5). It was also analysed how participants need for improved security. Although numerous researchers
address IoT security, systematic approaches are often lacking. This work introduces a modelling technique tailored to IoT devices to simplify modelling and enhance threat identification, helping manufacturers address weaknesses early in the product development cycle and support security by design. The proposed CPDFD technique considers the special circumstances of IoT devices. Due to their use in critical applications as well as the high accessibility, the creation of a hardware model was proposed. In addition, due to the interaction with the environment and the high connectivity of IoT devices, the two new elements Physical Link and Interface were introduced. Across two studies, an experimental quantitative comparison was conducted and the perspectives of security experts and engineers were collected. In summary, all three changes of the CPDFD technique indicate improvements compared to the standard DFD. The technique enables more detailed modelling of IoT devices, which in turn leads to more identified attack scenarios, as the results demonstrated. This suggests that CPDFDs improve the identification of threats. In the future, the better integration of HWDs and DFDs will be addressed to exploit synergy effects and improve the identification of attack scenarios and countermeasures. R EFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
SonicWall, Annual number of Internet of Things (IoT) malware attacks worldwide from 2018 to 2022, Statista, 2023. Accessed: 2026-03-14. [Online]. Available: https://www.statista.com/ statistics / 1377569 / worldwide - annual - internet - of - things attacks/ D. E. Whitehead, K. Owens, D. Gammel, and J. Smith, ‘Ukraine cyber-induced power outage: Analysis and practical mitigation strategies’, in 2017 70th Annual Conference for Protective Relay Engineers (CPRE), 2017, pp. 1–8. DOI: 10. 1109/CPRE.2017.8090056 D. Truxius et al., ‘Cyber Security Review of NetworkConnected Medical Devices’, German Federal Office for Information Security (BSI), Tech. Rep., Dec. 2020. Accessed: 2026-03-14. [Online]. Available: https : / / www . bsi . bund . de / SharedDocs / Downloads / DE / BSI / DigitaleGesellschaft / ManiMed _ Abschlussbericht _ EN . pdf ? __blob=publicationFile&v=1 D. Comobo, How I got access to 25+ Tesla’s around the world. By accident. And curiosity. Jan. 2022. Accessed: 2026-03-14. [Online]. Available: https://medium.com/@david_colombo/ how-i-got-access-to-25-teslas-around-the-world-by-accidentand-curiosity-8b9ef040a028 C. R. Lab, 2025: Unpacking the Tesla Wall Connector exploit chain and its broader cybersecurity implication, Aug. 2025. Accessed: 2026-03-14. [Online]. Available: https://vicone.com/ blog/from-pwn2own-automotive-2025-unpacking-the-teslawall-connector-exploit-chain-and-its-broader-cybersecurityimplication B. Ghena, W. Beyer, A. Hillaker, J. Pevarnek, and J. A. Halderman, ‘Green Lights Forever: Analyzing the Security of Traffic Infrastructure’, in 8th USENIX Workshop on Offensive Technologies (WOOT 14), San Diego, CA: USENIX Association, Aug. 2014. Accessed: 2026-03-14. [Online]. Available: https : / / www . usenix . org / conference / woot14 / workshop program/presentation/ghena D. Giese, ‘Reverse engineering and hacking Ecovacs robots’, DEFCON 32, 11th Aug. 2024. Accessed: 2026-03-14. [Online]. Available: https : / / dontvacuum . me / talks / DEFCON32 / DEFCON32_reveng_hacking_ecovacs_robots.pdf
[8]
[9] [10]
[11]
[12]
[13]
[14] [15] [16]
[17]
[18]
[19]
B. Dorsemaine, J.-P. Gaulier, J.-P. Wary, N. Kheir, and P. Urien, ‘Internet of Things: A Definition & Taxonomy’, in 2015 9th International Conference on Next Generation Mobile Applications, Services and Technologies, Cambridge, United Kingdom: IEEE, Sep. 2015, pp. 72–77, ISBN: 978-1-4799-86606. DOI: 10.1109/NGMAST.2015.71 Accessed: 2026-03-14. [Online]. Available: http : / / ieeexplore . ieee . org / document / 7373221/ K. Rose, S. Eldridge, and L. Chapin, ‘The internet of things: An overview’, The internet society (ISOC), vol. 80, pp. 1–50, 2015, Publisher: Reston, VA. M. A. Iqbal, S. Hussain, X. Huanlai, and M. A. Imran, Enabling the internet of things: fundamentals, design, and applications (Wiley - IEE), First edition. Hoboken, NJ: Wiley, 2020, ISBN: 978-1-119-70125-5. H. Boyes, B. Hallaq, J. Cunningham, and T. Watson, ‘The industrial internet of things (IIoT): An analysis framework’, Computers in Industry, vol. 101, pp. 1–12, Oct. 2018, ISSN: 01663615. DOI: 10.1016/j.compind.2018.04.015 Accessed: 2026-03-14. [Online]. Available: https://linkinghub.elsevier. com/retrieve/pii/S0166361517307285 S. Liebl et al., ‘Analyzing the Attack Surface and Threats of Industrial Internet of Things Devices’, International Journal on Advances in Security, 1 & 2, vol. 14, pp. 59–70, Dec. 2021, ISSN : 1942-2636. Accessed: 2026-03-14. [Online]. Available: https://www.thinkmind.org/index.php?view=article&articleid= sec_v14_n12_2021_6 T. DeMarco, ‘Structure Analysis and System Specification’, in Pioneers and Their Contributions to Software Engineering: sd&m Conference on Software Pioneers, Bonn, June 28/29, 2001, Original Historic Contributions, M. Broy and E. Denert, Eds., Berlin, Heidelberg: Springer Berlin Heidelberg, 2001, pp. 255–288, ISBN: 978-3-642-48354-7. DOI: 10.1007/978-3642- 48354- 7_9 Accessed: 2026-03-14. [Online]. Available: https://doi.org/10.1007/978-3-642-48354-7_9 A. Shostack, Threat modeling: designing for security. Indianapolis, IN: Wiley, 2014, ISBN: 978-1-118-80999-0. L. Kohnfelder and P. Garg, ‘The threats to our products’, Microsoft, Tech. Rep., Apr. 1999. M. Deng, K. Wuyts, R. Scandariato, B. Preneel, and W. Joosen, ‘A privacy threat analysis framework: Supporting the elicitation and fulfillment of privacy requirements’, Requirements Engineering, vol. 16, no. 1, pp. 3–32, Mar. 2011, ISSN: 0947-3602, 1432-010X. DOI: 10.1007/s00766-010-0115-7 Accessed: 202603-14. [Online]. Available: http://link.springer.com/10.1007/ s00766-010-0115-7 Y. Harbi, Z. Aliouat, S. Harous, A. Bentaleb, and A. Refoufi, ‘A Review of Security in Internet of Things’, Wireless Personal Communications, vol. 108, no. 1, pp. 325–344, Sep. 2019, ISSN: 0929-6212, 1572-834X. DOI: 10.1007/s11277-019-06405-y Accessed: 2026-03-14. [Online]. Available: http://link.springer. com/10.1007/s11277-019-06405-y F. A. Alaba, M. Othman, I. A. T. Hashem, and F. Alotaibi, ‘Internet of Things security: A survey’, Journal of Network and Computer Applications, vol. 88, pp. 10–28, Jun. 2017, ISSN : 10848045. DOI : 10.1016/j.jnca.2017.04.002 Accessed: 2026-03-14. [Online]. Available: https://linkinghub.elsevier. com/retrieve/pii/S1084804517301455 E. Leloglu, ‘A Review of Security Concerns in Internet of Things’, Journal of Computer and Communications, vol. 05, no. 01, pp. 121–136, 2017, ISSN: 2327-5219, 2327-5227. DOI: 10 . 4236 / jcc . 2017 . 51010 Accessed: 2026-03-14. [Online]. Available: http://www.scirp.org/journal/doi.aspx?DOI=10.4236/ jcc.2017.51010
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
O. I. Abiodun, E. O. Abiodun, M. Alawida, R. S. Alkhawaldeh, and H. Arshad, ‘A Review on the Security of the Internet of Things: Challenges and Solutions’, Wireless Personal Communications, vol. 119, no. 3, pp. 2603–2637, Aug. 2021, ISSN : 0929-6212, 1572-834X. DOI : 10 . 1007 / s11277 - 021 08348 - 9 Accessed: 2026-03-14. [Online]. Available: https : //link.springer.com/10.1007/s11277-021-08348-9 M. Scott, ‘A Survey Study of Common Security Failures and Mitigations for the Internet of Things (IoT)’, Journal of Telecommunication, Electronic and Computer Engineering (JTEC), vol. 15, no. 2, pp. 9–15, Jun. 2023. Accessed: 202603-14. [Online]. Available: https://jtec.utem.edu.my/jtec/article/ view/6259 O. Arias, J. Wurm, K. Hoang, and Y. Jin, ‘Privacy and Security in Internet of Things and Wearable Devices’, IEEE Transactions on Multi-Scale Computing Systems, vol. 1, no. 2, pp. 99–109, 2015. DOI: 10.1109/TMSCS.2015.2498605 C. Kolias, A. Stavrou, J. Voas, I. Bojanova, and R. Kuhn, ‘Learning Internet-of-Things Security "Hands-On"’, IEEE Security & Privacy, vol. 14, no. 1, pp. 37–46, 2016. DOI: 10. 1109/MSP.2016.4 J. Wurm, K. Hoang, O. Arias, A.-R. Sadeghi, and Y. Jin, ‘Security analysis on consumer and industrial IoT devices’, in 2016 21st Asia and South Pacific Design Automation Conference (ASP-DAC), 2016, pp. 519–524. DOI: 10.1109/ ASPDAC.2016.7428064 A. W. Atamli and A. Martin, ‘Threat-Based Security Analysis for the Internet of Things’, in 2014 International Workshop on Secure Internet of Things, 2014, pp. 35–43. DOI: 10.1109/ SIoT.2014.10 S. Iskhakov, A. Shelupanov, and A. Mitsel, ‘Internet of Things: Security of Embedded Devices’, in 2018 3rd Russian-Pacific Conference on Computer Technology and Applications (RPC), 2018, pp. 1–4. DOI: 10.1109/RPC.2018.8482148 V. Casola, A. De Benedictis, M. Rak, and U. Villano, ‘Toward the automation of threat modeling and risk assessment in IoT systems’, Internet of Things, vol. 7, p. 100 056, Sep. 2019. DOI: 10.1016/j.iot.2019.100056 Accessed: 2026-03-14. R. Khan, K. McLaughlin, D. Laverty, and S. Sezer, ‘STRIDEbased threat modeling for cyber-physical systems’, in 2017 IEEE PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), 2017, pp. 1–6. DOI: 10 . 1109 / ISGTEurope.2017.8260283 M. Hamad, M. Nolte, and V. Prevelakis, ‘Towards Comprehensive Threat Modeling for Vehicles’, Publications Institute of Computer and Network Engineering, 2016. DOI: 10.24355/ dbbs.084-201806251532-0 D. Meyer, J. Haase, M. Eckert, and B. Klauer, ‘A threatmodel for building and home automation’, in 2016 IEEE 14th International Conference on Industrial Informatics (INDIN), 2016, pp. 860–866. DOI: 10.1109/INDIN.2016.7819280 M. R. A. Asif, K. F. Hasan, M. Z. Islam, and R. Khondoker, ‘STRIDE-based Cyber Security Threat Modeling for IoTenabled Precision Agriculture Systems’, in 2021 3rd International Conference on Sustainable Technologies for Industry 4.0 (STI), 2021, pp. 1–6. DOI: 10.1109/STI53101.2021.9732597 A. Omotosho, B. A. Haruna, and O. M. Olaniyi, ‘Threat Modeling of Internet of Things Health Devices’, Journal of Applied Security Research, vol. 14, no. 1, pp. 106–121, Jan. 2019. DOI: 10.1080/19361610.2019.1545278 Accessed: 202603-14. [Online]. Available: https://www.tandfonline.com/doi/ full/10.1080/19361610.2019.1545278 B. J. Berger, K. Sohr, and R. Koschke, ‘Automatically Extracting Threats from Extended Data Flow Diagrams’, in Engineering Secure Software and Systems, J. Caballero, E. Bodden, and E. Athanasopoulos, Eds., vol. 9639, Cham: Springer International Publishing, 2016, pp. 56–71, ISBN: 978-
[34]
[35]
[36]
[37] [38]
[39]
[40] [41] [42]
[43]
[44] [45] [46] [47]
[48]
[49]
3-319-30805-0. DOI: 10.1007/978-3-319-30806-7_4 Accessed: 2026-03-14. [Online]. Available: http://link.springer.com/10. 1007/978-3-319-30806-7_4 L. Sion, K. Yskout, D. Van Landuyt, and W. Joosen, ‘Solutionaware data flow diagrams for security threat modeling’, in Proceedings of the 33rd Annual ACM Symposium on Applied Computing, Pau France: ACM, Apr. 2018, pp. 1425–1432, ISBN : 978-1-4503-5191-1. DOI : 10.1145/3167132.3167285 Accessed: 2026-03-14. [Online]. Available: https://dl.acm.org/ doi/10.1145/3167132.3167285 Fraunhofer Institute for Applied and Integrated Security (AISEC), ‘A Study on Hardware Attacks against Microcontrollers’, German Federal Office for Information Security (BSI), Tech. Rep., Mar. 2023. D. D. Gajski, S. Abdi, A. Gerstlauer, and G. Schirner, Embedded System Design: Modeling, Synthesis and Verification. Boston, MA: Springer US, 2009. DOI: 10.1007/978-1-44190504-8 Accessed: 2026-03-14. [Online]. Available: https://link. springer.com/10.1007/978-1-4419-0504-8 E. Bochniewicz et al., Playbook for Threat Modeling Medical Devices. MITRE Corporation and Medical Device Innovation Consortium (MDIC). M. Wolf, ‘Combining safety and security threat modeling to improve automotive penetration testing’, 2019, Publisher: Universität Ulm. DOI: 10 . 18725 / OPARU - 13062 Accessed: 2026-03-14. [Online]. Available: https://oparu.uni- ulm.de/ xmlui/handle/123456789/13119 electrouser865, Jaimico: The New I-health Care Companion Robot. Accessed: 2026-03-14. [Online]. Available: https://www. electromaker.io/project/view/jaimico-the-new-i-health-carecompanion-robot emgarde, ‘emgarde | TTModeler Pro’, Accessed: 2026-03-14. [Online]. Available: https://emgarde.de S. Liebl, TTModeler. Accessed: 2026-03-14. [Online]. Available: https://github.com/SecSimon/TTM International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 25022:2016: Systems and Software Engineering - Systems and Software Quality Requirements and Evaluation (SQuaRE) - Measure of Quality in Use (International standard). ISO, 2016. Accessed: 202603-14. [Online]. Available: https://books.google.de/books?id= Wzc1ygEACAAJ J. Ziegeldorf, O. Morchon, and K. Wehrle, ‘Privacy in the internet of things: Threats and challenges’, Security and Communication Networks, vol. 7, Dec. 2014. DOI: 10.1002/ sec.795 S. H. Simpson, ‘Creating a Data Analysis Plan: What to Consider When Choosing Statistics for a Study.’, The Canadian journal of hospital pharmacy, vol. 68 4, pp. 311–7, 2015. R. McGill, J. W. Tukey, and W. A. Larsen, ‘Variations of box plots’, The American Statistician, vol. 32, no. 1, pp. 12–16, 1978, Publisher: Taylor & Francis Group. J. Cohen, Statistical power analysis for the behavioral sciences, 2nd ed. Hillsdale, N.J: L. Erlbaum Associates, 1988, ISBN: 978-0-8058-0283-2. J. Hartung, G. Knapp, and B. K. Sinha, Statistical MetaAnalysis with Applications (Wiley Series in Probability and Statistics). Hoboken, NJ, USA: John Wiley & Sons, Inc., Jul. 2008, ISBN: 978-0-470-29089-7. DOI: 10.1002/9780470386347 Foreign, Commonwealth & Development Office, Small to medium sized enterprise (SME) action plan, May 2023. Accessed: 2026-03-14. [Online]. Available: https : / / www. gov. uk/government/publications/fcdo- small- to- medium- sizedenterprise-sme-action-plan/small-to-medium-sized-enterprisesme-action-plan R. Likert, ‘A technique for the measurement of attitudes.’, Archives of Psychology, vol. 22 140, pp. 55–55, 1932.