Security for the Rest of Us: What Matters and Where to Start

In this session, we take a practical look at embedded cybersecurity for developers and product teams building connected devices and trying to make sense of the security landscape. We walk through the major regulations and expectations that shape connected-device security today, such as the FDA’s guidance, the EU’s Cyber Resilience Act (CRA), and the U.S. Cyber Trust Mark, along with the product requirements they introduce.

We start with the first steps small teams can take to close the biggest gaps. This includes early wins like generating and using SBOMs, identifying the tasks that continue long after a device ships, and sorting out which requirements truly matter for your product. We also cover cloud-specific topics such as secure architecture, provisioning, and lifecycle planning.

We spend time looking at what real attacks actually look like, why attackers target even “unimportant” devices, and how we can evaluate and verify our own products. Along the way, we explore how to talk about risk in business terms, what “good enough” looks like for consumer hardware. By the end, you will have a clear and practical picture of the baseline safeguards every connected-device team should put in place and how to implement them.

What this presentation is about and why it matters

How do you decide what security work actually matters for an embedded device, and where do you start when the list feels endless? Mark Omo approaches that problem as a practical risk reduction exercise, using IoT examples, NIST guidance, and a real device case study to connect product context, software inventory, and device features. He walks through how to think about exposure, what to document, and which capabilities tend to carry the most security value in shipped products. This is especially useful for teams building connected embedded devices, or for anyone who needs a clearer way to prioritize security work without pretending every risk can be eliminated.

Who will benefit the most from this presentation

• Embedded engineers who need a concrete starting point for device security work
• Product or system engineers who have to explain what a device protects and why
• Technical leads working on connected products with third-party software in the stack
• Teams preparing for IoT compliance, certification, or post-shipment maintenance
• Managers who need to fund security work but want to understand the business case first

What you need to know

No deep security background is required. It helps to be familiar with how an embedded product is built and shipped, and to have seen terms like firmware update, cloud connection, or bill of materials before.

• Basic understanding of embedded devices and their interfaces
• Some familiarity with connected products, cloud links, or wireless comms
• Awareness of what a software bill of materials is, even if only at a high level

Glossary (terms used in this talk)

• Cyber Resilience Act (CRA): A European Union regulation focused on cybersecurity requirements for products with digital elements. It drives manufacturers to assess risks, implement security measures, and keep documentation aligned with product changes.
• MQTT (Message Queuing Telemetry Transport): A lightweight publish-subscribe messaging protocol commonly used to connect devices, automation systems, and scripts. It is often chosen for simple control and status flows across mixed hardware and software.
• IoT device security capability core baseline: A baseline set of security capabilities for connected devices, used to structure what a product should support across identity, configuration, updates, interfaces, data protection, and reporting. It provides a practical checklist for evaluating whether a device has the security features needed for its risk level.
• Coordinated vulnerability disclosure: A process for receiving vulnerability reports, validating them, and communicating fixes to customers on a planned timeline. It helps balance user protection, vendor response, and responsible public disclosure.
• Public key infrastructure (PKI): A system for issuing, managing, and trusting digital certificates and public keys. It supports device identity and authentication at scale, especially when many devices need to prove who they are to remote services.
• EU MDR: The European Union Medical Device Regulation, a regulatory framework for medical devices sold in the EU. It can impose cybersecurity and post-market expectations on device manufacturers.
• PSTI (Product Security and Telecommunications Infrastructure Act): A UK product security law for consumer connectable products. It establishes baseline security expectations and disclosure duties for affected devices.
• CISA (Cybersecurity and Infrastructure Security Agency): The U.S. Cybersecurity and Infrastructure Security Agency, which publishes security guidance and participates in vulnerability disclosure activities.

Toolbox (mentioned in this talk)

• FreeRTOS: A widely used real-time operating system for embedded systems. It is commonly integrated as a library that the application initializes and then starts scheduling tasks.
• Zephyr RTOS: A scalable real-time operating system for connected and resource-constrained devices. It often owns much of the system startup flow, including hardware initialization and thread setup.
• ESP32: A low-cost family of Wi-Fi and Bluetooth-enabled microcontrollers widely used for embedded networking and real-time control. It includes integrated wireless connectivity and is supported by a broad software ecosystem.
• ESP-IDF: Espressif's development framework for ESP32-family microcontrollers. It provides the build system, SDK components, and project structure used to create embedded firmware for Espressif targets.
• NVD (National Vulnerability Database): A public vulnerability database that aggregates security issues and related metadata for software and devices. It is commonly used when assessing exposure and tracking known weaknesses.
• Arduino ESP framework: An Arduino-based software framework for Espressif devices. It provides a higher-level development environment on top of the vendor platform and is often used alongside other embedded SDK components.

Final thoughts

Practical and grounded, this talk works like a field guide for teams that need to make security decisions without getting lost in abstractions. The value is a clearer way to reason about exposure, product context, software dependencies, and the security functions that shape shipped devices. It will help embedded engineers, product owners, and technical managers who need to turn vague concern into a plan. The overall feel is straightforward: security is presented as an engineering discipline, not a mystery.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.