Threat Modelling Workshop – Let’s Inspect 2.0
23 July 2026
Whether it’s Amazon Alexa, Google Assistant, or Apple Siri, smart speakers have long been part of everyday life for many people. They respond to voice commands, control the home, and answer almost any question. But what actually happens to the data generated in the process? Where are the vulnerabilities—and how trustworthy are these systems really? The interactive workshop “Threat Modeling – Let’s Inspect 2.0” addressed precisely these questions.
In her introduction, Prof. Dr. Corinna Schmitt made it clear why a systematic approach to securing connected devices is essential: Connected devices are increasingly controlling physical processes, meaning that a security breach can result not only in data loss but, in the worst-case scenario, also in real-world damage. Furthermore, many IoT devices are produced cheaply, have limited computing power, and often remain in use for years without security vulnerabilities being promptly addressed. Since attackers need only a single overlooked point of access, developers need a method that systematically identifies all potential vulnerabilities.
This is exactly where “threat modeling” comes in: a structured, paper-based process that allows potential attacks on a system to be identified and classified according to their severity— even before a product is released to the market. The workshop followed a three-step approach: first, understanding the architecture of a system; second, breaking the system down into clearly defined components; and finally, systematically examining each of these components for threats.
The participants used the STRIDE framework as a tool — a well-established method in the field of IT security that distinguishes six recurring threat categories: spoofing (impersonation), tampering (unauthorized alteration of data), repudiation (denial of actions taken), information disclosure (unintended disclosure of information), denial of service (denying access to authorized users), and elevation of privilege (unauthorized expansion of privileges). These six questions served as the guiding thread that was applied to each individual system component.
In Let’s Inspect 2.0, a classic smart speaker with a microphone, a cloud-based voice assistant, a companion app, and a growing number of third-party skills served as a consistent example. The assets to be protected ranged from firmware, access credentials, event logs, and certificates to voice recordings and the physical device resources themselves.
The overall system was divided into four components with clearly defined trust boundaries: the voice interface with a microphone and wake word, the local storage including hardware and debug interfaces, the cloud connection to the voice service, and the accompanying smartphone app for setup and remote control. Potential attack vectors included communication between the components, as well as software, physical hardware, and the entire product lifecycle from manufacturing to disposal — potential attackers ranged from remote software attackers to attackers on the local network.
To begin, Prof. Dr. Schmitt used STRIDE to walk the participants through one of the identified components — the Cloud Connection — in its entirety as an example: from the lack of mutual authentication to insufficiently protected data integrity and inadequate logging, all the way to unencrypted data traffic, potential Denial-of-Service attacks, and unauthorized expansion of privileges. Each threat was linked to an appropriate countermeasure, such as mutual authentication, signed firmware updates, tamper-proof logging, encrypted transmission, redundant system design, and strict adherence to the principle of least privilege.

During the hands-on portion of the workshop, the participants split into groups and independently examined the remaining three components (voice interface, companion app, and local storage) following the same pattern. This resulted in a range of remarkably concrete and, in some cases, surprising threat scenarios: from manipulated voice commands to laser attacks on microphones, which can trigger audio signals without any audible sound or even eavesdrop on vibrations in rooms, to compromised car systems that could be used to spy on smartphones during a vacation road trip. Everyday scenarios, such as an unlocked smartphone in a café or a child accidentally gaining access to an adult’s account, were also included in the analyses.
The group that focused on the voice interface, in particular, clearly demonstrated just how treacherous a purely acoustic interface can be: Without voice authentication, virtually any command can be spoken by anyone, while even with voice recognition, impersonation, background noise, or targeted laser attacks on the microphone can bypass security measures. As a realistic countermeasure, the participants suggested that critical actions be additionally confirmed via a second, non-acoustic channel — such as a button on a display.
To conclude, the groups presented their findings: the component they had examined, the most surprising threat, and a realistic countermeasure. Schmitt explicitly emphasized that no group was required to fully cover all six STRIDE categories — depth was more important than completeness on this day.
The following key takeaways emerged from the workshop: Threat modeling transforms the vague hope of having thought of everything into a repeatable process. To this end, STRIDE provides the same six-question checklist for every system component, and those who delve deeply into a single component learn the method more quickly than by skimming through many components superficially. STRIDE alone is not sufficient; it merely provides an initial impression of lurking dangers and should therefore be combined with other methods for assessing the severity of identified threats, such as DREAD or CVSS, which can then be used to prioritize which vulnerabilities should be addressed first.
The workshop is part of a series of events through which SeCoSys and the CODE Research Institute at the University of the German Armed Forces in Munich are making topics related to secure communication and trustworthy digital infrastructure accessible to a broader audience — deliberately designed to be accessible and requiring no in-depth prior technical knowledge.
Photos: © SeCoSys/Schmitt