In 2025, a stack-based buffer overflow vulnerability (CVE-2025-24132) was found in the Apple AirPlay SDK. For third-party smart speakers and receivers, this vulnerability allowed proof-of-concept zero-click remote code execution (RCE) that made it possible for attackers to overwrite memory and execute malicious code on many devices. An unpatched code injection vulnerability in AVTECH IP cameras (CVE‑2024‑7029) enabled a Mirai botnet variant in 2024.
In both cases, vulnerabilities gave attackers access to important security infrastructure. This illustrates the need for ongoing risk assessment throughout device lifecycles to ensure cybersecurity remains airtight. Such a strategy is proposed in this blog, which outlines checklists, toolkits and third-party expertise that embedded teams can use to build effective vulnerability management into their development workflow.
IoT & Embedded System Risk Assessment Checklist
The growing number of common vulnerabilities and exposures (CVEs) in complex embedded and IoT products is no surprise given the evolving complexity of these systems. Modern embedded devices are sophisticated integrations of interdependent components, often patchworked together with open-source libraries and custom firmware. This makes identifying, assessing, mitigating, and remediating vulnerabilities a multi-layered effort full of threat vectors that can be easily overlooked. By implementing a well-managed, continuous vulnerability assessment strategy, embedded teams can close security gaps as they arise to minimize the attack surface throughout a product’s lifecycle.
When starting a vulnerability management or security regimen for embedded and IoT systems, checklists are a great way to ensure all possible vectors are covered. Documents like the IoT Security Foundation’s IoT Security Assurance Framework, OWASP’s IoT Security Testing Guide, and the ETSI EN 303 645 and NISTIR 8529A standards can serve as checklists themselves or a solid foundation for creating your own.
For example, the following risk assessment checklist is based on industry best practices and can be used as a baseline when examining embedded systems for common architecture and requirements vulnerabilities:
- Criticality – How badly will exploitation impact device operation, safety and data?
- Likelihood – What is the probability the vulnerability will be exploited?
- Operating environment – Is the complete combination of operating system (OS), applications, hardware, connectivity, network configuration and other components secure during deployment?
- User access – Who can access, control or modify the device?
- Data protection – What data can be accessed, and which data contains sensitive information?
- Exposed components – What physical or logical parts can be reached by an attacker?
- Interfaces – How can hackers gain access to the system (network ports, APIs, USB, UART, JTAG, etc.)?
A checklist alone will not secure a system. What it does do, however, is help development teams isolate vulnerabilities and threats so they can be addressed methodically using common tools and methodologies.
The following table shows how the example checklist could be applied in the case of an Advantech RSB-3720-based industrial IoT gateway running Windows 10 IoT LTSC on an NXP i.MX 8M Plus processor and suffering from the recent CVE-2026-20876, a heap-based buffer-overflow flaw in Windows’ Virtualization-Based Security (VBS) Enclave that allows an authorized attacker to elevate privileges locally.
| Category | Observations | Mitigation strategies (short-term) | Remediation strategies (long-term) |
|---|---|---|---|
| Criticality | CVE-2026-20876 is a heap-based buffer-overflow flaw in Windows Virtualization-Based Security (VBS) Enclave that lets an authenticated attacker gain Virtual Trust Level 1 (VTL2) privileges. On a gateway with dual GbE, USB and optional wireless connectivity, compromise could lead to device takeover and lateral movement. | Disable VBS enclaves if not required, limit local privilege escalation paths and monitor for exploitation attempts. Physically secure units and isolate them from sensitive network segments. | Apply Microsoft’s security update when available and rebuild the Windows 10 IoT LTSC image with the patched BSP. Use secure boot and signed firmware (leveraging the onboard TPM 2.0 chip) to protect against persistent malware. |
| Likelihood | Exploitation requires local authenticated access (Common Vulnerability Scoring System (CVSS) vector AV:L/PR:H). However, the device exposes multiple physical interfaces (USB, serial, CAN and UIO expansion lines) and can be deployed in unsecured environments. | Remove or lock unused ports (cap USB connectors, disable debug UART, etc.) and enforce strict remote-access controls. Segment OT networks and restrict management services (RDP/SSH, etc.) behind VPNs. | Institute multi-factor authentication and role-based access control across all devices. Design network architecture with micro-segmentation and dedicated management networks to reduce attack opportunities. |
| Operating environment | Windows 10 IoT LTSC receives long-term security updates but requires manual integration into custom images. Additional drivers and applications (like AI modules) widen the attack surface. | Maintain a current SBOM for the OS, drivers and applications. Monitor vendor advisories and temporarily disable non-essential services/modules until patched. | Build a formal patch-management process: Integrate automated CI/CD pipelines from platforms like Dojo Five EmbedOps* to rebuild and test images with each vendor update. Adopt signed over-the-air (OTA) update mechanisms so devices can be reliably updated in the field. |
| User access | Local technicians, remote operators and administrators may interact with the device; the RS-232/422/485 header provides a console. Elevated privileges are required to exploit the VBS flaw. | Enforce least-privilege by disabling unused accounts and restricting interactive logons. Physically secure the console header and require authentication for any maintenance mode. | Deploy a central identity-management system supporting role-based access and multi-factor authentication. Incorporate hardware-rooted attestation so only authorized software can run. |
| Data protection | The gateway stores configuration, credentials (Wi-Fi or SIM), sensor data and potentially proprietary algorithms. Without encryption, an attacker with elevated privileges could exfiltrate or manipulate data. | Limit storage of sensitive data where possible and restrict file permissions. Use encrypted channels (TLS/IPSec) for all communications. | Encrypt data at rest using Windows 10 IoT features and store keys in the TPM. Implement secure backup and recovery procedures and regularly test integrity monitoring tools. |
| Exposed components | Physical interfaces include dual Ethernet, USB 3.2/USB 2.0, RS-232/422/485, CAN, Micro-SD, and nano-SIM slots; expansion slots (mini-PCIe, M.2) can add wireless radios. | Inventory all ports and disable those not required. Use port blockers or glue/covers on unused connectors and restrict wireless modules to trusted ones with signed firmware. | Redesign enclosures to shield internal headers and adopt hardware gating to completely remove or isolate unused connectors in production units. Keep firmware (for network and wireless modules) up-to-date and sign custom drivers. |
| Interfaces (attack vectors) | Attackers can target network services on LAN1/LAN2, cellular/Wi-Fi modules, USB mass storage, debug serial ports, CAN bus and JTAG/UART test pads. | Harden network services: disable unused protocols, enforce firewalls and monitor traffic. Disable USB boot, require whitelisting of USB devices and restrict debug interfaces to authorized maintenance only. | Implement a secure boot chain with cryptographically verified bootloaders and kernels. Transition OT protocols (CAN, UART) to authenticated versions and include intrusion-detection sensors. Replace insecure management protocols with modern, encrypted alternatives. |
* — EmbedOps is a DevOps orchestration platform that integrates with popular continuous integration/continuous deployment (CI/CD) platforms like GitHub and GitLab and uses containerized build environments for essential software tests that can enhance cybersecurity. It provides developers with the means to embed automated unit testing, HIL testing, CVE scanning and more directly into development pipelines for zero-day risk visibility. The intuitive EmbedOps dashboard simplifies report and documentation cataloging for easy traceability when new vulnerabilities are disclosed.
Embed Risk Assessment into Your Development Workflow
When applied correctly and combined with the right expertise, a risk assessment checklist like the one described can provide the foundation for a comprehensive vulnerability management practice. Engineering organizations can then take advantage of a modern security toolbox to harden vulnerability mitigation and remediation strategies into robust embedded products.
Core elements of such a toolbox are described below.
1. Secure boot and hardware security
A hardware root of trust sets the stage for mechanisms like secure boot and is essential for ensuring only authorized code runs on a device. Additional safeguards include trusted execution environments (TEEs) and cryptographic signatures that require verification before code can be changed.
2. Supply chain and SBOM best practices
Software bill-of-materials (SBOM) transparency is becoming a key part of emerging cybersecurity regulations like the EU Cyber Resilience Act (CRA) and Radio Equipment Directive (RED). Complete visibility of firmware, libraries, and dependencies in the software supply chain is key to understanding potential and known vulnerabilities.
3. Ongoing vulnerability scanning and CVE detection
Common Vulnerabilities and Exposures (CVE) scanning matches SBOM components against databases of known security gaps. This process helps identify potential attack points across OS kernels, drivers, and communication protocol stacks so they can be patched as soon as issues are disclosed.
4. Static and dynamic code analysis
Static analysis finds bugs like hardcoded passwords or insecure API calls without running code. Dynamic analysis tests code during runtime for resilience to malformed data that may cause crashes or memory buffer overflows that can be exploited.
5. HIL testing and runtime validation
Hardware-in-the-loop (HIL) testing bridges the gap between correctly functioning code and real-world performance. By testing code on target hardware, developers can find and fix issues that would be impossible to determine within purely virtual environments, such as a device becoming permanently bricked after a direct firmware update (DFU) is interrupted.
6. Risk scoring and prioritization
Frameworks like the Common Vulnerability Scoring System (CVSS) help developers prioritize patches based on security or safety risks, rather than minor problems with user interfaces, for example.
Device teams can also benefit from professional firmware reviews. For instance, the Dojo Five Firmware Audit is performed by seasoned engineers who examine embedded software for security and regulation readiness against leading industry standards. Dojo Five’s experts uncover hidden risks security scanners and black box testing tools cannot, while providing recommendations that improve business impact and reduce overall engineering costs.
Comprehensive Security is an Ongoing Process
Cybersecurity presents an ongoing challenge for developers, but adhering to common risk assessment best practices can minimize the attack surface for embedded and IoT products. Keeping comprehensive documentation like SBOMs, risk assessment reports and remediation history further supports long-term product maintenance and eases compliance efforts in the event of audits or investigations—for an extended look at embedded firmware risks, check out this blog post.
Ultimately, however, security risk assessment is a continuous process that every embedded team should adopt to avoid vulnerabilities that may cause safety hazards, enable data theft or damage customer faith in products. As regulatory bodies tighten cybersecurity requirements across the globe, development culture must fully embrace vulnerability management as a key part of product lifecycles.
