edge lab LIVE! at electronica 2026

Generating an SBOM for one firmware build is increasingly straightforward. Maintaining a defensible chain between the shipped firmware, its components, vulnerability findings, engineering decisions, and later security updates is much harder.

Using a small connected Zephyr application, this session demonstrates a vendor-neutral workflow from build to reviewable CRA evidence. The build produces an SPDX inventory and build provenance. Open tooling validates and normalizes the component data, maps public vulnerability records, and creates a review queue. A VEX-based decision then records whether a finding is affected, not affected, fixed, or still under investigation, together with the rationale, supporting evidence, reviewer, and product versions concerned. A simple policy gate determines whether the release can proceed without treating scanner output as an automatically approved engineering decision.

The demonstration also covers failure modes common in embedded products: ambiguous component identifiers, supplier patches not reflected in public databases, a CVE that matches a library but not the compiled configuration, changed components between firmware versions, and a new advisory published after release.

Attendees will leave with a reproducible reference architecture, sample SPDX and VEX artifacts, a minimum data model for traceable vulnerability decisions, and a practical checklist for adding the workflow to an embedded CI/CD pipeline. The session focuses on engineering implementation and human-governed evidence, not legal theory or a commercial platform.

Cloud-enabled industrial gateways bridging Modbus field equipment to HTTPS/MQTT backends over VPN are directly in scope of the most demanding requirements made by the EU Cyber Resilience Act (CRA): deployed unattended in accessible locations, holding the VPN and cloud credentials that make them a pivot into both OT and cloud networks, and re-imaged over the network. Yet the network-boot tooling this lifecycle relies on executes unauthenticated images by design, in direct conflict with the CRA's software-integrity and secure-update requirements. Even signed images cannot answer the question an unattended fleet poses: how does an operator know, remotely and continuously, that a deployed gateway runs the software that was shipped?

This session demonstrates an end-to-end, fully open-source answer on RISC-V. Building on an already-released bare-metal programming framework and network-boot framework, we construct a complete trust chain: a minimal, PMP-protected firmware layer as the trusted base; authenticated network boot with signature verification and anti-rollback, doubling as the CRA-mandated secure update path; DICE-style measured boot providing device identity without requiring a TPM; and RATS-based remote attestation that gates release of VPN and MQTT credentials on proven platform state. A tampered device cannot even join the network. Attestation reference values are derived from reproducible builds of the boot chain, tying platform verification to the SBOM and supply-chain transparency the CRA expects of manufacturers and integrators. This technical session distills lessons learned building and releasing these frameworks, from the pitfalls of key derivation without a hardware root of trust to what breaks when netboot signing is integrated in real-world provisioning workflows.

The session concludes with a scripted QEMU demonstration that shows (i) a tampered image rejected at boot-time, and (ii) a verified gateway completing attestation, receiving its credentials, and publishing Modbus telemetry to an MQTT broker. This demonstration provides a practical mapping from each mechanism in an open-source stack to the CRA obligations it addresses.

Talk contributors:
Nick Kossifidis (mick@ics.forth.gr | Research Engineer at FORTH - Greece)
Manolis Marazakis (maraz@ics.forth.gr | Staff Research Scientist at FORTH - Greece)

Industrial AI projects often fail after the prototype, when an AI workflow must be connected to shop-floor equipment, operated over years, and maintained securely. This talk presents a field-oriented deployment pattern developed by SECO for production-line monitoring and control.

The demonstrator combines a SECO Modular Vision HMI, based on a SMARC computer-on-module, with Clea, SECO's edge-to-cloud software stack. Engineers build the acquisition, validation, vision/inference and control workflow in Clea Studio AI; the workflow is containerized and deployed to the Modular Vision device through Clea Edgehog. At runtime, the edge node interfaces with line data, executes local processing, manages offline operation, and exposes telemetry and operational status to the platform. The session will focus on concrete engineering choices: interface mapping between equipment and workflow nodes, deployment packaging, observability, update rollback, and separation between time-critical control functions and non-deterministic AI processing.

The hardware use case is based on SMARC, which is a SGET rather than a PICMG specification. However, it illustrates the same standardized module/carrier separation central to PICMG COM Express and COM-HPC: the application, BSP and lifecycle tooling must remain portable across compute modules, while carrier and HMI integration retain product-specific I/O.

The final section discusses CRA readiness in practice. We will show how a controlled Clea OS production image, full SBOM traceability, vulnerability management, and secure over-the-air updates create an auditable route from prototype to a maintainable embedded product.

Edge and Physical AI systems must guarantee the secure and safe execution of compute tasks. To solve this, NVIDIA builds Trusted Platform Modules (TPM 2.0) directly into its enterprise-ready platform for physical AI, the IGX Thor. The commercial ecosystem has fully adopted this hardware-backed approach. Lenovo and Wincomm released new ruggedized, industrial edge AI computers featuring discrete TPM 2.0 solutions to ensure regulatory compliance and data security. This talk provides concrete details how TPM 2.0 protects Physical AI while remaining accessible. We detail advanced security guarantees beyond basic key storage, covering authenticated bus communications and hardware tamper defenses. Finally, we map these hardware capabilities directly to EU Cyber Resilience Act (CRA) compliance.

Key Takeaways:

• Mapping Edge AI security needs to TPM 2.0 capabilities.
• Advanced TPM 2.0 security capabilities matching Physical AI needs.
• Mitigating physical tampering and bus-level attacks on Edge hardware.
• Meeting EU CRA requirements using TPM 2.0.

20-minute talk with demo "Secure GPIO for Physical AI using TPM 2.0".

Copyright 2026 Dimi Tomov (CEO of EnactTrust & Founder of TPM.dev)

Under the Cyber Resilience Act, discovering a vulnerability is not enough. OEMs need a secure and repeatable way to remediate vulnerabilities across products already operating in the field. For embedded and IoT teams, that becomes especially challenging across heterogeneous hardware, software versions, unreliable networks, and large device fleets.

This session examines the engineering practices behind secure vulnerability remediation at scale, including identifying affected devices, signed software artifacts, phased deployments, automated rollback, update verification, and maintaining an auditable.

(This proposal is for a 25-minute technical session; however, we are also open to participating in a panel or other opportunities.)