embedded world North America 2026 Recap

After walking the floor at embedded world North America 2026, I noticed many of the vendors there were focused on how to make connected devices do more on their own. Industrial controllers, cameras, vehicles, and robotics platforms are now capable of running AI inference locally, and each new generation ships more software than the last. RISC-V kept drawing crowds as teams bring new architectures into their products, and the EU Cyber Resilience Act came up whenever the talk turned to security. For manufacturers, all of it adds up to more firmware to answer for, to customers and increasingly to regulators, for years after a device leaves the factory.

Finite State came to Anaheim with a question that is simple to ask and hard to answer. How does a manufacturer prove what's actually inside a product it has already shipped? I took it on from the regulatory side in Show Your Work: The Engineering Behind Credible Regulatory Documentation. Sharon Hagi, our Chief Security Officer, came at it from a perspective of incident response in When a CVE Drops: Portfolio-Scale Impact Analysis for Embedded Device Manufacturers. Roland Lindsey, our Chief Product Security Engineer, took the attacker's view in When the Bug Hunter Is an Agent: AI-Assisted Pen Testing for Embedded Firmware.

We were excited to share where that work has landed, and the questions in the session rooms and at our booth showed how many teams are wrestling with the same problem. The compiled binary is the most reliable record of what a connected product contains, and the evidence built from it has to exist before a regulator, a customer, or an attacker comes looking.

We call that record binary-grounded evidence. It's the SBOM reconciled against the compiled image, the threat model tied to paths that actually execute, and the VEX statement backed by reachability in that specific build, instead of documentation pieced together from source manifests and design intent.

Regulators Now Want Proof of What Shipped

My session opened on four regulatory mechanisms that North American manufacturers rarely see side by side. The FCC's Covered List now names whole product categories. The BIS connected vehicle rule requires Declarations of Conformity certified under penalty and names SBOMs as supporting documentation. FDA Section 524B premarket expectations call for an SBOM, a threat model, and a postmarket monitoring plan. And the EU Cyber Resilience Act, whose Article 14 reporting obligations have applied since September 11, is the price of selling globally. The mechanisms differ, yet each one asks manufacturers to prove what's inside the product they shipped.

Getting the shape of that documentation right is easy. What’s harder is getting the documentation to match the actual product, instead of just the design intent. A source-derived SBOM that was never reconciled against the compiled binary looks complete until a reviewer asks whether it matches the shipped build. The problem is common. When ENISA surveyed 194 organizations across 31 countries early this year, two-thirds had heard of the CRA, but only 13% felt confident they could produce the technical documentation it requires.

In every regime, the remedy starts with an SBOM grounded in the binary, a threat model tied to execution-level evidence, and VEX statements backed by reachability rather than assertion. Those artifacts become the foundation for every regulatory response and customer questionnaire. I also made a case for timing. FDA pre-submission meetings, BIS advisory opinions, and FCC pre-approval guidance exist so manufacturers can calibrate "good enough" while design choices are still changeable, and more teams should take advantage of these tools.

If you missed my talk, then here’s the big reveal: transparency about your product security demonstrates responsible governance. The risks in a product are there whether anyone documents them or not. Engage early, and a regulator sees that risk picture with your context and rationale attached. An issue found in preparation isn't a failure; it's the process working.

"Which Products Are Affected?" Is an Architecture Question

When Log4Shell landed in December 2021, every PSIRT started with the same question: are we vulnerable? The per-product SBOMs of the time couldn't answer it. They were generated from source manifests, and none reliably reflected what had compiled into shipped firmware. Sharon opened his session there because the problem hasn't gone away, and the CRA's 24-hour early-warning clock is now live. What used to be an operational headache has become a governance conversation between boards and their product organizations.

Sharon's answer is that portfolio-scale impact analysis is an architecture problem. The foundation is a binary-grounded inventory across every product, variant, and firmware version, with declared and binary-extracted versions reconciled and the remaining gaps kept visible. On top of that inventory, "which products contain this component, in a reachable configuration?" becomes a query the team can run on demand.

Variants are where most programs quietly break. The same source built with different compiler flags produces a different call graph, and with it a different justification for whether a vulnerability applies. One VEX statement can't cover a product line, so reachability has to run on every variant. Priority then weighs reachability and exploitability against the regulatory obligation in each market where a product is sold, the same logic behind risk-based CRA triage applied across a whole portfolio.

The output is evidence-backed VEX that persists and re-evaluates as firmware ships and CVE data changes. It serves customers in machine-readable form and regulators as an audit trail that feeds the CRA's vulnerability-handling documentation. He calls the goal, “PSIRT as infrastructure.” Being PSIRT-ready means the answer is true before the incident, not assembled during it.

A Private Source Tree Is No Longer a Defense

Roland's session put AI agents to work against an attack surface that many security teams assume is secure, on firmware that has already shipped. The team built agents that investigate a device's binary for exploitable bugs, try to disprove each suspect, and then attempt to demonstrate the failures that survive, all without access to the original source code.

The method rests on the open-source reverse-engineering framework Ghidra, which decompiles machine code into C-like pseudocode. The variable names are generated, and some types come out wrong, but it still retains a recognizable structure: a branch, a buffer, a copy, and a length that came from the input. What made the approach practical at scale is the persistent binary context Finite State has built over nearly a decade of firmware analysis. The agents can return to stored evidence and check their own assumptions before moving on.

Every investigation moves through the same stages:

1. Decompile the shipped binary to recover enough code context to investigate.
2. Hunt for suspected bugs by tracing what an attacker can control.
3. Verify each suspect in an independent step whose only job is to find the reason it's wrong.
4. Prove the survivors by executing the failure and keeping the evidence.

The verification step is what makes the results credible. On one device, it rejected 11 of 13 suspected bugs. Across roughly 16 shipping devices, the team demonstrated about 70 exploits through execution, with static-only findings excluded from the count. When the first results looked too good to trust, Roland compared them to the output from a manual pen-test run by our Director of Offensive Operations. Eight of nine critical issues matched the manual findings, and the ninth was blocked by a hardware guard.

The economics matter as much as the method. Checking a suspected bug costs more than finding it, and as Roland put it, "We started with one engineer and a token budget. An attacker can start there too." Many product security programs treat source secrecy as a control, but this talk proved it isn’t one. That’s why source-based SCA falls short on firmware. The risk lives in the compiled image you actually ship.

Where Product Security Programs Go From Here

The show floor and the sessions point the same way. When a device carrying local AI inference needs patches, updates, and monitoring for years after it ships, the evidence behind it has to keep pace with every release, not just the first one. That changes how a program runs well before the CRA's main obligations apply in December 2027.

Documentation and security engineering become one discipline. The engineering that makes documentation credible is the same engineering that makes a security program better. Teams that staff the two separately will keep producing evidence that describes a product nobody shipped.

Impact analysis becomes a standing query. A 24-hour early-warning clock leaves no room for a manual search across a portfolio. The answer to "are we affected?" has to come from a record that already exists, grounded in every variant on the market.

Offensive testing becomes continuous. If an agent can investigate a binary on a token budget, an annual pen test describes a product that has already changed. The better model investigates every build, retains the evidence, finds where related code ships across the portfolio, and feeds what it finds into the same evidence-backed record.

Accountability matters more as these capabilities spread, not less. An AI-generated analysis carries no legal standing on its own. What gives it effect is the signature of a named person, whether on an ISO/SAE 21434 cybersecurity case, a UN R155 submission, or a CRA Declaration of Conformity. The faster the models get, the more a traceable sign-off chain is worth.

A few questions worth putting to your team this month:

• For your most recent releases, does the SBOM match the compiled binary or the build manifest?
• When an actively exploited CVE lands, how long does it take to name every affected product and variant, and where does the answer come from?
• Can each "not affected" statement in your VEX point to evidence for that specific build?
• If someone outside your company pointed an agent at your firmware tomorrow, what would they find that you haven't?

Beyond the Session Rooms

The conversation carried well past our sessions. Finite State's program started two weeks before the show, when Sharon joined the IoT M2M Council's pre-event webinar on multi-mode connectivity. In Anaheim, Doc sat down with Embedded Computing Design in its Embedded Executive podcast studio to talk about why security-by-design decisions are so hard to fix once a product is on the market, and what regulators are watching as AI-assisted coding pulls more third-party code into devices. The full conversation is worth a listen for any team working out what regulators will expect from its next release. Doc also recorded a booth interview with Keith Kreisher of the IoT M2M Council, focused on the CRA and what device makers owe now that the reporting clock is live. That video is coming soon.

The week also brought recognition for the team. Embedded Computing Design named Finite State's Product Security OS an embedded world North America 2026 Best in Show winner in the Security category, for helping manufacturers separate theoretical exposure from real product risk in the software they actually ship.

Build the Record Before Anyone Asks

The Finite State Platform is built for the record these sessions described. It analyzes the firmware and binaries you actually ship to build a ground truth inventory. It uses reachability analysis to confirm which vulnerabilities apply to each build and variant, and it maintains the SBOM and VEX record release over release, so your team reviews decisions instead of raw findings. Security discovery and compliance proof run as one system grounded in shipped software, and the evidence is there when a customer, an assessor, or a CRA reporting deadline calls for it.

If we met in Anaheim (or if you wish we had!), we'd welcome the conversation. Book a demo and bring a firmware image you've already shipped. We'll unpack it, run a live CVE against it, and show you the evidence behind every "not affected."