Jarenlang viel ingebouwde beveiliging in de categorie “nice to have” — iets wat je toevoegde als er tijd en budget over was, of zodra het product groot genoeg werd om op te vallen. Die tijd is voorbij. Tegenwoordig is beveiliging van embedded systemen essentieel, en ingenieurs die het als bijzaak behandelen, zullen systemen opnieuw moeten ontwerpen, fouten oplossen die voorkomen hadden kunnen worden of toekijken hoe hun producten op lijsten met kwetsbaarheden belanden.
 
Embedded World hamert hier al jaren op en het wordt steeds duidelijker. Wanneer bijna elke microcontroller, sensor node, huishoudelijk apparaat, industriële controller, wearable en voertuigsubsystem direct of indirect verbonden is met een netwerk, is het aanvalsoppervlak in feite het hele internet. Een MCU in het veld zetten zonder goede beveiliging in 2026 is hetzelfde als in 1999 een pc uitleveren met bestandsdeling aan voor de hele wereld en zonder firewall.

Dit is een praktische reactie op een industrie waar aanvallen op de software supply chain, firmware-sabotage en gehackte IoT-vloten inmiddels routine zijn. Van de embedded-sector wordt nu verwacht dat die dezelfde eigenschappen levert als “grote” IT-systemen: vertrouwelijkheid, integriteit, authenticiteit en veerkracht. Het verschil is dat embedded systemen dit moeten waarmaken met een zuinig stroomverbruik, weinig geheugen en een levensduur van tientallen jaren.

Als ingenieurs dit niet vroeg genoeg belangrijk maken, zullen ze later veel meer tijd kwijt zijn aan het herstellen ervan.
 

embedded security is no longer optional
Ingebouwde beveiliging is niet langer optioneel.

Het Groeiende Dreigingsmodel: Alles Praat Met Alles

Tien jaar geleden stond een 8-bit microcontroller die wat regellusjes draaide, bij niemand op de cyberbeveiligingsradar. Die communiceerde waarschijnlijk via een simpele seriële bus en zat achter een gateway. Nu kan hetzelfde apparaat contact maken met:
 
  • Een IP-geschikte draadloze module
  • Een cloudservice
  • Meerdere vendor SDK’s en externe libraries
  • Mobiele apps via Bluetooth LE
  • Een bootloader op het apparaat die updates accepteert in het veld

Met andere woorden: het apparaat is niet langer geïsoleerd. Zelfs goedkope, minimalistische ontwerpen hebben een route naar buiten, soms indirect via andere subsystemen.

Zodra connectiviteit in beeld komt, komen de klassieke IT-aanvalswegen mee:
  • Vervalste firmware-updates
  • Gestolen inloggegevens
  • Zijkanaal-lekken
  • Remote code execution via malafide pakketten
  • Supply chain manipulatie (gecompromitteerde ontwikkeltools, vergiftigde libraries, aangepaste binaries)

Dit zijn geen theoretische risico’s. Industriële IoT-toepassingen, consumentenelektronica en zelfs auto-ECU’s zijn gehackt via firmware-updates, debugpoorten en onveilige bijbehorende apps.

De grootste verandering: het maakt aanvallers niet meer uit of een apparaat op zichzelf waardevol is. Is er iemand die bang is dat een hacker hun vaatwasser op afstand aanzet? Nee, maar botnets, DDoS-infrastructuren en zijwaartse aanvallen zorgen dat zelfs een slimme lamp een doelwit kan zijn.

Als elk knooppunt een potentiële toegangspoort is, mogen ontwikkelaars er niet meer vanuit gaan dat iets te klein of te onbekend is om te worden aangevallen.

Hardware Loopt Eindelijk In (Meestal)

Het goede nieuws: chipmakers zijn wakker geworden. De meeste nieuwe microcontrollers en SoC’s worden nu geleverd met functies die vroeger alleen bij high-end processoren hoorden:
 
  • Secure boot
  • Hardware root of trust
  • On-chip key storage (PUF’s, HSM-achtige blokken, eenmalig programmeerbare gebieden)
  • Geïsoleerde uitvoerzones (ARM TrustZone-M, RISC-V PMP)
  • Versnellers voor cryptografie
  • Manipulatie-detectie en actieve afscherming (bij sommige beveiligde MCU’s)

Het probleem is niet het gebrek aan mogelijkheden, maar dat veel teams deze functies niet inschakelen of gebruiken. De vier meest gehoorde redenen:
 
  • Beveiligingsfuncties maken ontwikkeling lastiger. Ze vragen om zorgvuldige provisioning en signing flows die niet in het standaard ontwikkelproces zitten.
  • Documentatie is vaak gefragmenteerd of vendor-specifiek. Secure boot op de ene Cortex-M33 is niet hetzelfde als op een andere.
  • Beveiliging voelt als ‘extra werk’ als de deadline drukt. Features schuiven door naar ‘fase twee’, die nooit komt.
  • Teams hebben geen gezamenlijke beveiligingsmindset. Firmware-ontwikkelaars, hardwareontwerpers, DevOps en cloudontwikkelaars zien beveiliging als een SEP (“someone else’s problem”).

De hardware is er klaar voor. De processen meestal niet.

Wat De Huidige Situatie Vraagt

Sterke embedded security draait niet meer om losse functies, maar om vertrouwen van begin tot eind:

Een betrouwbare hardwarebasis
  • Onveranderbare ROM bootloader
  • Getekende firmware
  • Gecontroleerde updatekanalen

Unieke beveiligde identiteiten per apparaat
  • Unieke cryptografische sleutels
  • Authenticatie op basis van certificaten
  • Sleutels die nooit het MCU verlaten

Weerstand tegen aanvallen
  • Memory protection units
  • Compiler-hardening
  • Firmware-aanvalsoppervlak verkleinen

Bescherming van data in opslag en tijdens transport
  • On-chip versleutelde flash
  • TLS of vergelijkbare beveiligde kanalen

Een veilige ontwikkelworkflow
Levenscyclusbeheer
Het belangrijkste punt: beveiliging is geen extraatje meer. Het is een doorlopend proces in ontwerp, productie, uitrol en onderhoud.

Waar Ontwikkelaars Het Meest Struggelen

In elke sector – van hobbyprojecten tot industrie – duiken steeds dezelfde valkuilen op:

Half afgemaakte secure boot-ketens

Ontwikkelaars tekenen de eerste bootloader, maar laten het applicatie-image ongetekend. Of ze laten debug-keys openstaan tijdens productie.

Zwakke of hergebruikte sleutels

Verrassend veel apparaten worden nog steeds geleverd met:
  • Gedeelde private keys voor complete productlijnen!
  • Hardgecodeerde inloggegevens
  • Symmetrische sleutels in de firmware

Zodra er één uitlekt, is de hele vloot kwetsbaar.

OTA-updates zonder integriteitscheck

Zelfs in 2026 halen sommige apparaten nog updates binnen via HTTP zonder handtekeningcontrole! Dat is nog altijd het makkelijkste aanvalspad voor IoT-aanvallen.

Blind vertrouwen in ‘security by obscurity’

Gesloten firmware, ongebruikelijke MCU’s, eigen protocollen en andere verbergtechnieken helpen niet meer. Aanvallers reverse engineeren obscure architecturen gewoon.

Geen plan voor onderhoud op de lange termijn

Producten gaan 10 tot 20 jaar mee. Leveranciers overleven drie tot vijf productcycli. Cloudbackends komen en gaan. Beveiligingsplannen houden daar zelden rekening mee.

Praktische Stappen Voor Ontwikkelaars

Beveiliging is alleen eng als je alles tegelijk wilt doen. De beste aanpak: vanaf het begin meenemen in het ontwerp, niet pas achteraf.

Begin met een hardware root of trust

Als de MCU of SoC secure boot ondersteunt, zet dat meteen aan. Richt je firmware signing en provisioning workflow vroeg in, nog voor je een regel applicatiecode schrijft. Dan voorkom je het “we beveiligen het later”-syndroom.

Unieke sleutels per apparaat, geen gedeelde geheimen

Moderne MCU’s hebben hardware key storage precies hiervoor. Stel unieke credentials in tijdens productie of bij eerste gebruik, liefst direct in het apparaat gegenereerd.

Strip het aanvalsoppervlak van de firmware

Zet ongebruikte randapparatuur, communicatieprotocollen en debuginterfaces uit. Gebruik zo min mogelijk externe code. Elke ongebruikte driver is alsnog een potentiële kwetsbaarheid.

Eis geauthentiseerde updates

Updates moeten altijd zowel transportbeveiliging (TLS, DTLS etc.) als cryptografische handtekeningcontrole van het image afdwingen.

Modelleer bedreigingen vroeg

Geen consultancy-rapport van 50 pagina’s – gewoon een gestructureerd halfuurtje:
 
  • Wat kan een aanvaller zien?
  • Wat kan hij bedienen?
  • Waar kan hij fysiek bij?
  • Wat gebeurt er als hij dat krijgt?

Zo ontdek je ontwerpfouten voordat het architectuurproblemen worden.

Documenteer je beveiligingsplan

Als jouw team niet kan uitleggen waar de sleutels worden opgeslagen, hoe updates worden geauthenticeerd en hoe de boot chain werkt, heb je geen veilig apparaat – je hebt gewoon geluk, voorlopig.

Waarom Vroeg Met Beveiliging Beginnen Tijd En Geld Bespaart

Beveiliging wordt vaak gezien als een dure vertraging. In werkelijkheid zijn snelle, goedkope implementaties duurder – onveilige systemen kosten uiteindelijk meer:
 
  • Terugroepacties door gehackte firmware
  • Spoedpatches onder tijdsdruk
  • Klantverlies na incidenten
  • Regelgevingsproblemen (vooral bij medisch, industrie of consument-IoT)
  • Kortere levensduur omdat later fixen niet meer lukt

Een kleine investering in provisioning en architectuur aan het begin voorkomt jaren achteraf repareren en brandjes blussen.

Nog een voordeel: veilige apparaten blijven langer bruikbaar. Als je hardware zijn firmware en updateketen vertrouwt, kun je features, patches of helemaal nieuwe workflows nog jarenlang toevoegen na de lancering.

De Nieuwe Verantwoordelijkheid Van De Embedded-ontwikkelaar

De verschuiving is duidelijk: elk apparaat met firmware is nu een beveiligingsgevoelig systeem. Ingenieurs bouwen vertrouwen, niet alleen functionaliteit. Of je nu werkt met kleine Cortex-M0+-onderdelen, krachtige Linux-SoC’s of nieuwe RISC-V-platforms, de verwachtingen zijn hetzelfde.

De community, de markt en steeds vaker ook de wet verwachten standaard veilig gedrag.

Dit is het uitgangspunt voor onze Embedded World special in 2026. De beurs laat een grote omslag zien: van “security als extra” naar “security als infrastructuur”. De tijd dat MCU’s werden gezien als losse blokken is voorbij. Ze zijn knooppunten in een wereldwijd systeem en hun beveiliging is belangrijker dan ooit.

Beveilig Jouw Toekomst

Ingebouwde beveiliging is misschien niet zo spannend als nieuwe AI-accelerators of ultra-low-power radio’s, maar het bepaalt of je product het redt in de echte wereld, betrouwbaar blijft en niet in het volgende grote IoT-incident terechtkomt.

Wie nu embedded systemen bouwt, maakt beveiliging tot een vast onderdeel van het vak – niet langer optioneel.