Last week, headed to London for the TechWorks Semiconductor to Systems Summit 2026 – a one-day event that brought together the UK's chip-to-systems ecosystem for the first time. Over 600 leaders in the NMI, DESN, AESIN and IoTSF communities all united under one roof for the first time. We had a seat at a table with materials scientists, silicon vendors, and systems integrators all talking about the looming deadlines of the EU Cyber Resilience Act (CRA).

We didn't go to London to sell hardware. We went because the conversation in our industry has shifted from "should we care about CRA?" to "how do we actually implement this without blowing up our roadmap?" That's exactly the problem our CRA Package, built around TROPIC01 as a hardware root of trust, is designed to solve: reducing time-to-market for CRA-compliant IoT and embedded devices.

Technical Deep Dive: What We Presented

The core of our conversations was straightforward: most embedded teams don't lack the will to build secure products - they lack a clear, hardware-anchored starting point that maps cleanly onto CRA's essential requirements.

Lessons Learned & a Gotcha

1. CRA is no longer a "future problem" for business owners.

‍The regulatory timeline is real and it's close. Conformity assessment bodies already began notifying under CRA rules on June 11, 2026, mandatory vulnerability reporting and serious incident notifications begin September 11, 2026, and by December 11, 2027, all CRA requirements will be enforceable across the EU. It struck us in London how many decision-makers, not just engineers, were asking compliance questions. CRA has clearly moved from an engineering backlog item to a board-level risk conversation.

2. "Security-by-design" is a hard requirement, and checkbox security is a trap.

‍This was the single biggest theme of our talk. CRA's security-by-design principle means a late-stage patch or a bolted-on software fix isn't enough. It's tempting to reach for the nearest "checkbox" solution, but it doesn't make the product actually secure. Multiple conversations at our booth confirmed a pattern we keep seeing: teams treating CRA as a checklist pay for it later, either through a re-architecture under deadline pressure or, worse, through an actual incident. Investing in security-by-design from the beginning is cheaper than paying more unexpectedly.

3. CRA is deliberately non-prescriptive — which is both the challenge and the opportunity.

‍The regulation doesn't hand engineers a spec sheet. It leaves the how up to engineering judgment. For teams used to prescriptive standards, this ambiguity is uncomfortable. This is where a hardware root of trust earns its keep: TROPIC01 plus our reference architecture gives you a concrete, auditable answer to an otherwise open-ended requirement, instead of forcing every team to invent their own interpretation from scratch.

4. A CRA Gotcha worth flagging — hardware is covered too ‍

Several attendees assumed CRA compliance was purely a software/firmware exercise. It isn't. The requirements for integrity and authenticity verification, rollback protection, and secure key management push the conversation down to hardware decisions that are much harder (and more expensive) to change once a board is finalized. If your root of trust is an afterthought, your CRA compliance timeline just got longer.

What's Next / Closing

It’s clear from TechWorks that now is the moment where the UK and EU embedded ecosystem collectively figures out what "good" CRA compliance looks like in practice. There's real appetite for concrete, hardware-anchored answers rather than more checklists.

For us, the next steps are practical. We're taking the questions and gaps we heard in London, and feeding them directly into the next iteration of our CRA Package documentation. If you're wrestling with the same "where do I even start" problem, our TROPIC01-based CRA Package is built to be that starting point — not a compliance rubber stamp, but an actual root of trust you can build a secure architecture on top of.

‍