Cyber Resilience Act: 11. september 2026 er en reell frist

De fleste EU-forordninger gir deg en etterlevelsesdato og en overgangsperiode der alle stille organiserer seg. Cyber Resilience Act gjør noe annet. Dens første harde plikt er en 24-timers rapporteringsklokke, og den starter 11. september 2026.

En 24-timers klokke kan ikke fases inn. Enten finnes prosessen den dagen, eller så bommer du.

Hva CRA er

Forordning (EU) 2024/2847 setter cybersikkerhetskrav til produkter med digitale elementer som gjøres tilgjengelig på EU-markedet. Uttrykket dekker langt mer enn folk først antar: ethvert programvare- eller maskinvareprodukt, og dets løsninger for fjernbehandling av data, hvis tiltenkte eller rimelig forutsigbare bruk omfatter en direkte eller indirekte datatilkobling.

Tilkoblede enheter er omfattet. Det samme er det meste av kommersiell programvare, operativsystemer, nettlesere, mobilapper, fastvare og komponentene inne i andre produkter.

Forordningen ble publisert i november 2024 og gjelder trinnvis:

11. juni 2026: plikter for samsvarsvurderingsorganer.
11. september 2026: rapporteringsplikter for aktivt utnyttede sårbarheter og alvorlige hendelser.
11. desember 2027: full anvendelse, inkludert vesentlige cybersikkerhetskrav, CE-merking, teknisk dokumentasjon og programvarekomponentlisten.

Den midterste datoen er den å planlegge etter, fordi den kommer først og fordi den avhenger av kapasitet du kanskje ikke har.

Hva som skjer 11. september 2026

Fra den datoen må produsenter rapportere:

Aktivt utnyttede sårbarheter i produktene sine med digitale elementer, og

alvorlige hendelser som påvirker sikkerheten til disse produktene.

Rapporteringen går via CRAs enhetlige rapporteringsplattform, driftet av ENISA, til det CSIRT-et som er utpekt i medlemsstaten der produsenten har sitt hovedforetak, som deretter deler videre til andre berørte CSIRT-er og ENISA.

Tidslinjen:

Innen 24 timer etter kunnskap: et tidligvarsel.
Innen 72 timer: en full melding, inkludert korrigerende eller avbøtende tiltak som er iverksatt.
Innen 14 dager etter at et korrigerende tiltak er tilgjengelig: en sluttrapport for en aktivt utnyttet sårbarhet.
Innen én måned: en sluttrapport for en alvorlig hendelse.

Tjuefire timer fra kunnskap, ikke fra bekreftelse, ikke fra utbedring. Utnyttes en sårbarhet i en komponent i produktet ditt i naturen på en lørdag, går klokka på lørdag.

Hvorfor dette er vanskeligere enn det ser ut

Selve rapporteringsplikten er et skjema. Vanskeligheten ligger i alt du må ha på plass før du kan fylle det ut.

Du må vite hva som er i produktet ditt

For å rapportere at en sårbarhet i produktet ditt aktivt utnyttes, må du vite at den sårbare komponenten er i produktet ditt. For en moderne applikasjon med hundrevis av transitive avhengigheter er ikke det noe et menneske svarer på fra hukommelsen.

Derfor bygger team programvarekomponentlisteløyper nå, godt over et år før det formelle SBOM-kravet i desember 2027. SBOM er ikke målet. Målet er å kunne svare på «er vi berørt?» innen timer, og SBOM-en er det som gjør spørsmålet besvarbart.

Det ubehagelige er at dette også gjelder produkter du sendte for år siden. Har du støttede enheter i felt med fastvare bygget i 2022 fra et avhengighetstre ingen har registrert, er det reelt arbeid å rekonstruere.

Du må følge med

Kunnskap starter klokka, og kunnskapen forventes å være aktiv snarere enn tilfeldig. Det betyr å overvåke sårbarhetskilder, abonnere på varsler for komponentene dine, følge kataloger over kjente utnyttede sårbarheter, og ha en kanal der sikkerhetsforskere kan nå deg og få svar.

Du må ha en beslutningsvei

Noen må kunne avgjøre, når som helst på døgnet, om en hendelse når terskelen og om klokka har startet. Uten en navngitt rolle og en eskaleringsvei går de første timene med til å finne ut hvem som har lov til å ta avgjørelsen.

Avhengigheter uten støtte blir et ansvar

Får en komponent i produktet ditt ikke lenger sikkerhetsoppdateringer, bærer du fortsatt rapporteringsplikten når den utnyttes, og du har ingen oppstrøms rettelse å peke på. Å revidere avhengigheter uten støtte er noe av det nyttigste i opptakten, fordi svaret av og til tvinger fram en migrering med egen ledetid.

Hva full anvendelse i desember 2027 bringer

Pliktene fra desember 2027 er det større programmet, og de må startes lenge før.

Sikkerhet ved design og som standard. Produkter må utformes, utvikles og produseres for å sikre et passende cybersikkerhetsnivå basert på risiko. Ingen standardpassord. Sikker konfigurasjon rett ut av boksen. Minimering av angrepsflaten. Beskyttelse av data under overføring og i hvile.

Sårbarhetshåndtering. En dokumentert prosess som dekker identifisering, utbedring, testing, distribusjon og offentliggjøring. Sikkerhetsoppdateringer må leveres uten opphold og gratis, i en støtteperiode som gjenspeiler produktets forventede levetid, med fem år som vanlig referanse.

Programvarekomponentliste. I maskinlesbart format, som minst dekker avhengighetene på øverste nivå, og holdes oppdatert.

Teknisk dokumentasjon og samsvarsvurdering. De fleste produkter egenvurderer. Viktige og kritiske kategorier, som blant annet omfatter passordbehandlere, VPN-er, operativsystemer og industrielle kontrollsystemer, krever medvirkning fra tredjepart.

CE-merking. Den digitale ekvivalenten til det fysiske merket, som erklærer samsvar.

Retningslinjer for koordinert sårbarhetsoffentliggjøring. Publisert, med et kontaktpunkt som fungerer.

Hvem som faktisk er omfattet

Noen få grensetilfeller går igjen.

Fri og åpen kildekode-programvare utviklet utenfor kommersiell virksomhet faller stort sett utenfor. Forordningen innfører begrepet forvalter av åpen kildekode-programvare med lettere plikter. Men kommersialiserer du åpen kildekode, eller leverer den inne i et produkt du selger, er produktpliktene dine.

Programvare som tjeneste faller generelt utenfor CRA og ligger heller under NIS2, selv om løsninger for fjernbehandling av data som er integrert i et produkt med digitale elementer trekkes inn. Avhenger enheten din av skybackenden din for å fungere, følger den backenden med produktet.

Importører og distributører bærer også plikter. Bringer du et tredjepartsprodukt på EU-markedet under eget navn eller varemerke, behandles du som produsent.

Produkter som allerede er regulert andre steder, som medisinsk utstyr, kjøretøy og luftfartsutstyr, håndteres i sine egne rammeverk.

Virkeområdespørsmålene er reelt ikke trivielle, og dette er et sted der en time med juristene deres sparer måneder med feilrettet utvikling.

Hva vi ville gjort i tiden som gjenstår

Er du omfattet og starter nå, er dette rekkefølgen som fungerer:

Først, etabler produktoversikten. Hva har du faktisk på EU-markedet? Inkludert gamle versjoner fortsatt i felt, white label-varianter og produkter du distribuerer for noen andre. Denne listen er som regel lengre enn noen forventer.

Deretter, bygg SBOM-generering inn i CI. Generer en SBOM ved hver bygging, i CycloneDX eller SPDX, lagre den sammen med utgivelsesartefaktet og hold den søkbar. Poenget er å kunne spørre «hvilke av våre leverte utgivelser inneholder dette biblioteket?» og få svar på minutter.

Deretter, koble på sårbarhetsovervåking. Mat SBOM-dataene inn i en skanner som følger varsler og kataloger over kjente utnyttede sårbarheter, og rut varsler til en kanal noen leser.

Deretter, skriv hendelseshåndboken. Hvem erklærer, hvem vurderer, hvem rapporterer, hvem kommuniserer. Navngitte personer, stedfortredere og kontakter utenom arbeidstid. Øv så én gang med et fiktivt varsel. Det er i øvelsen du oppdager at personen med tilgangen til rapporteringsplattformen er på ferie.

Deretter, publiser retningslinjer for sårbarhetsoffentliggjøring. En security.txt-fil, en overvåket adresse og en oppgitt responstid. Det er en ettermiddags arbeid og forskjellen mellom å høre om et problem fra en forsker eller fra en journalist.

Til slutt, start arbeidet mot desember 2027. Sikre standardinnstillinger, oppdateringsmekanismer, beslutninger om støtteperiode og dokumentasjon er arkitekturspørsmål, ikke papirarbeid. Produkter du designer i 2026 vil fortsatt være på markedet i 2028.

Overlappen ingen bruker

Det finnes betydelig dobbeltarbeid mellom CRA og andre regimer, og de fleste selskaper håndterer hvert for seg, noe som er sløsing.

En SBOM bygget for CRA besvarer de fleste leverandørkjedespørsmålene i NIS2. Hendelseshåndboken overlapper med NIS2s 24-timers tidligvarsel og med GDPRs 72-timers avviksmelding. Prosessene for sårbarhetshåndtering mater direkte inn i kunders sikkerhetsspørreskjemaer og innkjøp i store virksomheter.

Bygg dette én gang som plattformkapasitet. Alternativet er tre team som bygger tre versjoner av den samme ressursoversikten.

Hvor du får hjelp

Vi bygger og vedlikeholder programvare for selskaper som selger inn i EU, noe som i økende grad betyr å bygge den leverandørkjedeoversikten og oppdateringsinfrastrukturen CRA forutsetter. Prøver du å finne ut om du er omfattet, eller har du septemberdatoen i kalenderen uten overvåking på plass, ta kontakt på office@c9group.dev.

Vår tjeneste for vedlikehold av eldre systemer er ofte der dette starter, fordi produktene med dårligst avhengighetsoversikt gjerne er de eldste. Det bredere regulatoriske bildet finnes i vår guide til EU digital etterlevelse 2026.

Vi er ingeniører snarere enn jurister. Beslutninger om virkeområde og klassifisering hører til hos juristene deres, og vi bygger etter svaret de gir.