EUs Cyber Resilience Act treffer IoT i september. De fleste produktteam er ikke klare.

Den 11. september 2026 viser EUs Cyber Resilience Act tenner for første gang. Fra den datoen må alle som selger et produkt med digitale elementer i EU — en smart termostat, en flåtesporer, en tilkoblet kaffemaskin, fastvaren inni hvilken som helst av dem — rapportere aktivt utnyttede sårbarheter til EU-myndighetene innen 24 timer etter at de fikk kjennskap til dem. Ikke 24 arbeidstimer. Tjuefire timer.

Det er tre måneder fra nå. Og det gjelder produkter du allerede har levert, ikke bare de du lanserer etter fristen.

Det meste av CRA-dekningen handler om desember 2027, når de fulle secure by design-kravene og CE-merkingsforpliktelsene kommer. Den innrammingen er behagelig, og feil. Du kan ikke rapportere en sårbarhet innen 24 timer med mindre du allerede har maskineriet til å finne den, vurdere den og melde den inn. Det maskineriet tar lengre tid enn ett kvartal å bygge.

Hva CRA dekker (sannsynligvis produktet ditt)

Forordningens formulering er «produkter med digitale elementer», og den er så bred som den høres ut: maskinvare med programvare i, pluss frittstående programvare i seg selv. Forbruker-IoT, industrielle sensorer, rutere, mobilapper solgt i EU, den innebygde koden i en brusautomat. Hvis det kjører kode og finnes på EU-markedet, bør standardantakelsen være at det er omfattet.

Hvor selskapet ditt holder til spiller ingen rolle. Som GDPR følger CRA produktet inn i markedet. En amerikansk eller britisk startup som selger smarte enheter til tyske kunder, har de samme forpliktelsene som en produsent i München.

Noen få kategorier slipper unna, fordi de er regulert andre steder: medisinsk utstyr, biler, luftfartssystemer, noe maritimt utstyr. Åpen kildekode får sin egen behandling — mer om det nedenfor. Alle andre er på én tidslinje med to datoer som betyr noe: 11. september 2026 for rapportering, 11. desember 2027 for alt annet.

11. september er den egentlige fristen

Her er sekvensen forordningen forventer når noen aktivt utnytter et hull i produktet ditt. Et tidlig varsel til ditt nasjonale CSIRT innen 24 timer etter at du ble klar over det. En fyldigere melding innen 72 timer. En sluttrapport innen 14 dager etter at en utbedring er tilgjengelig. Alvorlige hendelser følger samme mønster, med en måned for sluttrapporten. Alt går gjennom en ny felles rapporteringsplattform, som ruter det til medlemsstatens CSIRT og til ENISA, EUs cybersikkerhetsbyrå, samtidig.

Les det en gang til med produktsjef-øyne, og problemet er åpenbart. «Innen 24 timer etter at du ble klar over det» forutsetter at du blir klar over det. De fleste små og mellomstore enhetsprodusenter har ingen strukturert måte å få vite at en CVE nettopp ble publisert for et bibliotek som er bakt inn i fastvaren deres, ingen innboks der en sikkerhetsforsker kan nå et menneske, og intet internt svar på spørsmålet «hvem avgjør at dette teller som aktivt utnyttet, og hvem melder inn?»

Det er derfor den praktiske SBOM-fristen er 2026, ikke 2027. Programvarestyklisten — en maskinlesbar oversikt over hver komponent i produktet ditt — er formelt et 2027-krav. Men du kan ikke overvåke avhengigheter du ikke har listet opp, og du kan ikke rekke en 24-timersfrist med en vurderingsprosess som starter med «vent, bruker vi i det hele tatt det biblioteket?» Rapporteringsplikten drar i stillhet SBOM-arbeidet ett år frem.

Én ubehagelig detalj til: rapporteringsplikten dekker produkter som allerede er på markedet. Enheten du leverte i 2022 med en vag plan om å «se på sikkerheten senere», er omfattet i det øyeblikket noen begynner å utnytte den.

Hva produktet ditt trenger innen utgangen av 2027

Desember 2027-bølgen er det største ingeniørløftet. For produkter som plasseres på markedet fra den datoen, omfatter de grunnleggende kravene:

• Levering uten kjente utnyttbare sårbarheter, med en sikker standardkonfigurasjon — som blant annet setter punktum for æraen med det universelle standardpassordet.
• En reell oppdateringsmekanisme: sikkerhetsoppdateringer levert OTA der det er aktuelt, kryptografisk signert, verifisert på enheten, beskyttet mot tilbakerulling til eldre sårbare versjoner, og robust nok til ikke å brikke flåten midt i en oppdatering.
• En maskinlesbar SBOM, i praksis SPDX eller CycloneDX, generert som del av bygget i stedet for satt sammen for hånd én gang i året.
• En policy for koordinert sårbarhetsavsløring med en offentlig kanal der forskere kan melde fra om problemer — og noen som faktisk leser det som kommer inn.
• Gratis sikkerhetsoppdateringer gjennom produktets støtteperiode — minst fem år, eller produktets forventede levetid hvis den er kortere.

Samsvar stemples med CE-merket, det samme merket du allerede kjenner fra elektronikk, nå utvidet til å dekke cybersikkerhet. De fleste produkter kan egenvurderes. De «viktige» klassene — rutere, brannmurer, passordbehandlere, smarthjem-huber med sikkerhetsfunksjoner og lignende — trenger et tredjeparts teknisk kontrollorgan til å sjekke leksene. Det er verdt å finne ut tidlig hvilken kategori produktet ditt havner i, for kapasiteten hos kontrollorganene i 2027 kommer til å bli en flaskehals.

Bøtene, og det med liten skrift

Brudd på de grunnleggende kravene gir bøter på inntil €15 millioner eller 2.5% av total global årsomsetning, det som er høyest. Mindre overtredelser ligger på €10 millioner eller 2%, og å villede myndighetene koster inntil €5 millioner eller 1%. Prosentene er selve poenget — dette er GDPR-aritmetikk, utformet slik at det aldri kan bli billigere å ignorere reglene enn å følge dem.

Det finnes to unntak folk har en tendens til å overtolke. Mikro- og småbedrifter kan ikke bøtelegges for å bomme på 24-timers- og 72-timersfristene for rapportering — men alle andre forpliktelser bærer fortsatt fulle sanksjoner, så dette er en høflighetsgest, ikke et fritak. Og open source-forvaltere (stiftelser og vedlikeholdere som utvikler programvare uten å tjene penger på den) er helt fritatt fra bøter. Men i det øyeblikket åpen kildekode skipes inni ditt kommersielle produkt, er du produsenten, og sårbarhetene er ditt rapporteringsproblem.

Hva du bør gjøre mellom nå og september

Hvis du selger, eller planlegger å selge, et tilkoblet produkt i EU, er sommersjekklisten kort og konkret. Kartlegg hva som faktisk finnes i produktene dine — generer en SBOM fra bygget, ikke rekonstruer en fra hukommelsen. Sett opp et mottak for sårbarheter: en security.txt, en overvåket postboks, en avsløringspolicy en forsker kan finne. Skriv hendelsesdreieboken og kjør en tørrtrening på 24-timersfristen én gang, på en falsk CVE, slik at den første ekte kjøringen ikke også er generalprøven. Og sjekk produktets klassifisering, for den avgjør om 2027 betyr egenvurdering eller revisjonskø.

Det vanskeligste punktet står ikke på den listen, for det er ikke et septemberproblem: fastvare som kan oppdateres i felt. Hvis enhetene dine ikke kan ta imot en signert oppdatering OTA i dag, er det måneder med arbeid å ettermontere det, på tvers av bootloader, leveringsinfrastruktur og flåtedrift. Team som starter i 2027, kommer til å gjøre det i håndhevingsperioden i stedet for før den.

Ingenting av dette er eksotisk ingeniørkunst. Signerte oppdateringer, sporing av avhengigheter, en måte for noen å fortelle deg at produktet ditt er ødelagt — et veldrevet produktteam vil ha dette uansett, på samme måte som det vil ha tester og sikkerhetskopier. CRA gjorde bare «vil ha» om til «må ha» og festet en dato på det. To datoer, faktisk. Den andre får all oppmerksomheten. Den første er fristen.