A client came to us four months into PCB layout with a problem.
They'd chosen STM32F4. Solid MCU, team knew it, reasonable price. Then compliance
review hit: no hardware Secure Boot. No TrustZone. No hardware key storage.
Wi-Fi connected industrial gateway. EU market. CRA scope. Wrong chip — not a bad
chip, wrong chip for this use case.
Board spin: €40,000. Timeline impact: five months.
I've been in embedded hardware for over 10 years. That conversation happens more
than it should. So we built something to catch it earlier.
The regulatory context (skip if you know CRA)
EU Cyber Resilience Act enforcement: September 2026.
RED Delegated Act (Wi-Fi, BT, cellular products): August 2025 — already in effect.
Both have hardware implications that can't be patched in firmware:
- Hardware Secure Boot (silicon-level, not software)
- Hardware key storage (Secure Element or TrustZone — flash keys aren't compliant)
- Per-device unique credentials (needs manufacturing provisioning infrastructure)
- Anti-rollback protection (hardware monotonic counters)
- Vulnerability disclosure policy before market entry
Most teams pick silicon based on cost and familiarity. Compliance gaps show up later,
when changing them is expensive.
What we built — and what we were honest about upfront
The MCU vs MPU Architecture Advisor
was built with a specific and limited scope: fast orientation, not a compliance report.
At the start of a project — before architecture locks, before BOM drafts — you
don't need 40 pages. You need a 30-second answer to: "Is this silicon direction
sane for EU market? What should I be worried about?"
That's what it does. Nothing more.
It won't replace a qualified embedded engineer or a formal CRA gap analysis.
But it asks the right questions at the moment it's cheapest to change the answer.
What it returns for a plain-English project description:
| Dimension | Output |
|---|---|
| Architecture verdict | MCU / MPU / Crossover / FPGA + confidence % |
| Suggested silicon | Specific chips with 🇪🇺 EU origin flag |
| Supply chain risk | Non-EU silicon exposure warning |
| CRA risk | HIGH / MEDIUM / LOW + specific gaps |
| BOM complexity | Upstream dependency estimate |
| Engineering rationale | Shareable with your team |
How CRA Article 13 maps to silicon
The hardest part of building this was translating regulatory language into
selection criteria:
| CRA Requirement | What it means for silicon |
|---|---|
| Secure by default | Unused interfaces disabled at production |
| Cryptographic integrity | Hardware Root of Trust, full Secure Boot chain |
| Unique device identity | eFuse or Secure Element provisioning |
| Data at rest confidentiality | Hardware key storage — not flash |
| Lifetime update support | OTA with anti-rollback |
Three projects — actual outputs
🌿 Laser weeding robot
Battery-powered, galvo control, 4G logging, IP65, EU Machinery Directive + GPSR
MCU — 91% confidence
Chip: STM32H7 (STMicroelectronics, 🇪🇺 Switzerland/Italy)
CRA: MEDIUM — Secure Boot capable, but provisioning infrastructure needed
Supply chain: 🟢 EU-origin
🎙 Edge AI mic array
7 mics, 360° beamforming, on-device wake word + speaker ID, BLE 5.3, EU RED + CRA
Crossover/MPU — 87% confidence
Chips: NXP i.MX RT1170 or i.MX 8M
CRA: HIGH — audio = personal data under EN 18031-2, full privacy architecture needed
Supply chain: ⚠ NXP Netherlands 🇪🇺, fab Taiwan
🚁 Drone AI compute
YOLOv8 on dual cameras at 30fps, no cloud, Wi-Fi 6, GPS log, CE + RED
FPGA — 78% confidence
Chips: AMD Xilinx Kria K26, Intel Agilex
CRA: HIGH — custom bitstream = non-standard update pathway, no EU-origin FPGA at this tier
Supply chain: 🔴 US-origin
What the results taught us
The FPGA recommendation surprises people most. Default assumption is MCU or MPU.
But 30fps inference on dual cameras with hard latency bounds — the parallelism
math wins.
EU silicon coverage is decent at MCU-class. STMicro (🇨🇭), Infineon (🇩🇪),
NXP (🇳🇱) cover most use cases. At FPGA performance tier, EU-origin doesn't
exist yet. That gap matters for programs with sovereignty requirements.
CRA risk is architecture-level, not just chip-level. A drone on custom FPGA
logic has fundamentally different vulnerability disclosure challenges than an MCU
on RTOS. The tool tries to flag that distinction.
Try it
Describe your project — the more specific the better. Power budget, interfaces,
OS requirements, EU regulatory scope. Vague input = generic output.
👉 inovasense.com/tools/mcu-vs-mpu
Free. No email. No sign-up.
One last thing: this is intentionally basic. The goal was never comprehensiveness —
it was speed. A 30-second check that catches the most common expensive mistakes
before they compound. If your project needs deeper analysis, that's what a
professional review is for. But most projects just need the right questions asked
early. That's what this does.
— Vladimir Vician, Founder @ Inovasense
10+ years in embedded hardware. We help EU manufacturers navigate CRA, RED, and CE marking.
Top comments (0)