De EU Cyber Resilience Act raakt IoT al in september. De meeste productteams zijn er niet klaar voor.

Op 11 september 2026 zet de EU Cyber Resilience Act voor het eerst de tanden erin. Vanaf die datum moet iedereen die een product met digitale elementen in de EU verkoopt — een slimme thermostaat, een fleettracker, een connected koffiemachine, de firmware in elk daarvan — actief misbruikte kwetsbaarheden bij de EU-autoriteiten melden binnen 24 uur nadat hij ervan weet. Niet 24 kantooruren. Vierentwintig uur.

Dat is over drie maanden. En het geldt voor producten die je al geleverd hebt, niet alleen voor wat je na de deadline lanceert.

De meeste berichtgeving over de CRA focust op december 2027, wanneer de volledige secure-by-design-eisen en de CE-markeringsplicht arriveren. Dat frame is comfortabel, en onjuist. Je kunt een kwetsbaarheid niet binnen 24 uur melden als je niet al de machinerie hebt om hem te vinden, te triëren en in te dienen. Die machinerie bouw je niet in een kwartaal.

Wat onder de CRA valt (waarschijnlijk jouw product)

De verordening spreekt van "producten met digitale elementen", en dat is zo breed als het klinkt: hardware met software erin, plus losse software zelf. Consumenten-IoT, industriële sensoren, routers, mobiele apps die in de EU worden verkocht, de embedded code in een verkoopautomaat. Draait er code op en staat het op de EU-markt, ga er dan standaard van uit dat het eronder valt.

Waar je bedrijf gevestigd is doet er niet toe. Net als de AVG volgt de CRA het product de markt op. Een Amerikaanse of Britse startup die slimme apparaten aan Duitse klanten verkoopt, draagt dezelfde verplichtingen als een fabrikant in München.

Een paar categorieën ontspringen de dans, omdat ze elders gereguleerd zijn: medische apparaten, auto's, luchtvaartsystemen, sommige maritieme apparatuur. Open source krijgt een eigen behandeling — daarover hieronder meer. Voor alle anderen geldt één tijdlijn met twee data die ertoe doen: 11 september 2026 voor de meldplicht, 11 december 2027 voor al het andere.

11 september is de echte deadline

Dit is de volgorde die de verordening verwacht wanneer iemand een gat in je product actief misbruikt. Een vroege waarschuwing aan je nationale CSIRT binnen 24 uur nadat je ervan weet. Een vollediger melding binnen 72 uur. Een eindrapport binnen 14 dagen nadat een corrigerende fix beschikbaar is. Ernstige incidenten volgen hetzelfde patroon, met een maand voor het eindrapport. Alles loopt via een nieuw Single Reporting Platform, dat het tegelijk doorstuurt naar de CSIRT van je lidstaat en naar ENISA, het cybersecurityagentschap van de EU.

Lees dat nog eens met de blik van een productmanager en het probleem is evident. "Binnen 24 uur nadat je ervan weet" veronderstelt dat je het te weten komt. De meeste kleine en middelgrote apparaatbouwers hebben geen gestructureerde manier om te horen dat er net een CVE is gepubliceerd voor een library die in hun firmware zit gebakken, geen inbox waar een securityonderzoeker een mens kan bereiken, en geen intern antwoord op de vraag "wie bepaalt dat dit telt als actief misbruikt, en wie dient de melding in?"

Daarom is de praktische SBOM-deadline 2026, niet 2027. De software bill of materials — een machineleesbare inventaris van elk component in je product — is formeel een eis voor 2027. Maar je kunt geen dependencies monitoren die je niet hebt opgesomd, en je haalt geen 24-uursklok met een triageproces dat begint bij "wacht, gebruiken we die library überhaupt?" De meldplicht trekt het SBOM-werk stilletjes een jaar naar voren.

Nog één ongemakkelijk detail: de meldplicht geldt voor producten die al op de markt zijn. Het apparaat dat je in 2022 leverde met het vage plan om "later nog eens naar security te kijken" valt binnen de scope zodra iemand het begint te misbruiken.

Wat je product eind 2027 nodig heeft

De golf van december 2027 is de grotere engineeringklus. Voor producten die vanaf die datum op de markt komen, omvatten de essentiële eisen onder meer:

• Leveren zonder bekende misbruikbare kwetsbaarheden, met een veilige standaardconfiguratie — wat onder andere het einde betekent van het tijdperk van het universele standaardwachtwoord.
• Een echt updatemechanisme: beveiligingsupdates waar van toepassing over the air geleverd, cryptografisch ondertekend, geverifieerd op het apparaat, beschermd tegen rollback naar oudere kwetsbare versies, en robuust genoeg om de vloot niet halverwege een update te bricken.
• Een machineleesbare SBOM, in de praktijk SPDX of CycloneDX, gegenereerd als onderdeel van de build in plaats van één keer per jaar handmatig in elkaar gezet.
• Een beleid voor coordinated vulnerability disclosure met een publieke route waarlangs onderzoekers problemen kunnen melden — en iemand die daadwerkelijk leest wat er binnenkomt.
• Gratis beveiligingsupdates gedurende de supportperiode van het product — minimaal vijf jaar, of de verwachte levensduur van het product als die korter is.

Compliance wordt bezegeld met de CE-markering, hetzelfde merkteken dat je al kent van elektronica, nu uitgebreid naar cybersecurity. De meeste producten mogen zichzelf beoordelen. De "belangrijke" klassen — routers, firewalls, wachtwoordmanagers, smarthomehubs met beveiligingsfuncties en dergelijke — hebben een externe notified body nodig die het huiswerk nakijkt. De moeite waard om vroeg uit te zoeken in welke categorie je product valt, want de capaciteit van notified bodies wordt in 2027 een bottleneck.

De boetes, en de kleine lettertjes

Schending van de essentiële eisen levert boetes op tot €15 miljoen of 2,5% van de totale wereldwijde jaaromzet, afhankelijk van welke hoger is. Lichtere overtredingen kosten €10 miljoen of 2%, en de autoriteiten misleiden tot €5 miljoen of 1%. Die percentages zijn de essentie — dit is rekenwerk in AVG-stijl, zo ontworpen dat de regels negeren nooit goedkoper kan zijn dan ze volgen.

Er zijn twee uitzonderingen die mensen graag te ruim lezen. Micro- en kleinbedrijven kunnen niet worden beboet voor het missen van de 24-uurs- en 72-uurstermijnen — maar elke andere verplichting blijft volledig beboetbaar, dus dit is een verzachting, geen vrijstelling. En open-sourcestewards (stichtingen en maintainers die software ontwikkelen zonder eraan te verdienen) zijn volledig vrijgesteld van boetes. Maar zodra die open-sourcecode in jouw commerciële product zit, ben jij de fabrikant, en zijn de kwetsbaarheden ervan jouw meldprobleem.

Wat te doen tussen nu en september

Verkoop je een connected product in de EU, of ben je dat van plan, dan is de zomerchecklist kort en concreet. Inventariseer wat er werkelijk in je producten zit — genereer een SBOM uit de build, reconstrueer er geen uit het geheugen. Zet een meldpunt voor kwetsbaarheden op: een security.txt, een mailbox die wordt gelezen, een disclosurebeleid dat een onderzoeker kan vinden. Schrijf het incidentdraaiboek en oefen de 24-uursklok één keer droog, op een neppe CVE, zodat de eerste echte keer niet meteen ook de generale repetitie is. En check de classificatie van je product, want die bepaalt of 2027 zelfbeoordeling betekent of een auditwachtrij.

Het zwaarste punt staat niet op die lijst, want het is geen septemberprobleem: firmware die in het veld bij te werken is. Kunnen je apparaten vandaag geen ondertekende update over the air ontvangen, dan kost dat achteraf inbouwen maanden werk aan bootloader, leveringsinfrastructuur en vlootbeheer. Teams die in 2027 beginnen, doen het tijdens de handhavingsperiode in plaats van ervoor.

Niets hiervan is exotische engineering. Ondertekende updates, dependency-tracking, een manier waarop iemand je kan vertellen dat je product kapot is — een goed geleid productteam wil dit toch al, net zoals het tests en back-ups wil. De CRA heeft "willen" alleen omgezet in "moeten" en er een datum aan gehangen. Twee data, eigenlijk. De tweede krijgt alle aandacht. De eerste is de deadline.