CRA-rapportering er i kraft og fristen er 24 timer

Nøkkelpunkter per 13. september 2026:

• Fristen løper allerede. Siden 11. september 2026 må produsenter varsle aktivt utnyttede sårbarheter og alvorlige hendelser innen 24 timer (EU-kommisjonen).
• Tre frister, ikke en. Tidlig varsel innen 24 timer, full varsling innen 72 timer, og sluttrapport innen 14 dager eller en måned (teldat.com, 2025).
• Klokken starter ved kunnskap. Fristen løper fra det øyeblikket produsenten blir klar over utnyttelsen, ikke fra når rettelsen er klar (teldat.com, 2025).
• Porteføljen bakover teller. Rapporteringskravene omfatter også produkter som allerede er på markedet hos eksisterende kunder (europesays.com, 2026).
• Bøtetaket er 15 millioner euro eller en andel av global årlig omsetning ved alvorlige brudd på regelverket (teldat.com, 2025).

---

Hva CRA-rapporteringsplikten faktisk pålegger produsenter

Cyber Resilience Act trådte i kraft 10. desember 2024, og de fleste norske programvareselskaper la den i mappen for ting som skjer i 2027 (EU-kommisjonen). Den mappen er feil sted nå. Fra 11. september 2026 må produsenter rapportere aktivt utnyttede sårbarheter og alvorlige hendelser som påvirker sikkerheten til produkter med digitale elementer (EU-kommisjonen). Plikten er ikke lenger under forberedelse. Den løper.

Det som gjør denne delen av regelverket krevende, er ikke innholdet i rapporten. Det er klokken. Tidlig varsel skal sendes innen 24 timer etter at produsenten blir klar over forholdet, og fristen bryr seg ikke om det er tirsdag formiddag eller lørdag kveld (EU-kommisjonen). For et selskap uten avklart eskaleringsvei hviler hele etterlevelsen på at riktig person tilfeldigvis leser riktig e-post i tide. Det er en tynn tråd å henge en forordning på.

Hvem forordningen regner som produsent

Plikten treffer produsenten, ikke sluttbrukeren og ikke nødvendigvis den som drifter løsningen. CRA innfører obligatoriske cybersikkerhetskrav for produsenter som dekker planlegging, design, utvikling og vedlikehold av produktene (EU-kommisjonen). Det er en livsløpsplikt, ikke en godkjenning dere passerer en gang. Utvikler dere programvare eller tilkoblede enheter som selges inn i EU-markedet, bør utgangspunktet være at dere er produsent inntil en jurist har konkludert med noe annet.

Rollefordelingen blir uklar i praksis når produktet består av deres kode, en tredjeparts komponent og en kundes egen konfigurasjon. Avklaringen bør skje nå, ikke mens en hendelse pågår. Den vanligste feilen er at to parter hver for seg antar at den andre rapporterer, og at ingen sender noe innen fristen.

Hva et produkt med digitale elementer er

Kategorien er bredere enn mange antar. CRA er EUs primære lovgivning for cybersikkerhet i digitale produkter og stiller bindende krav til produsenter av tilkoblede produkter som selges i EU (europesays.com, 2026). Det dekker langt mer enn maskinvare med nettkabel: applikasjoner, innebygd programvare, og produkter som henter oppdateringer eller data over nett.

For enkelte produkter kommer det et ekstra lag. Noen kan måtte gjennomgå en tredjepartsvurdering av et teknisk kontrollorgan før de selges på EU-markedet (EU-kommisjonen). Den delen hører til hovedforpliktelsene og ligger lenger frem, men klassifiseringen av porteføljen er den samme jobben. Gjør den en gang, og bruk den både til rapportering nå og til samsvar senere.

Hvorfor rapportering kom før resten av regelverket

Rapporteringsplikten i artikkel 14 er den første delen av CRA som trer i kraft (teldat.com, 2025). Logikken er praktisk: myndighetene vil ha øye på aktiv utnyttelse i markedet før de begynner å håndheve produktkravene. Resten av forordningen, inkludert CE-merking, gjelder fra 11. desember 2027 (teldat.com, 2025).

Alura mener rekkefølgen gir et smalt, men reelt fortrinn: rapporteringsplikten gjelder allerede, mens resten av CRA først treffer i desember 2027. Det gir tid til å bygge rutinene i rolige omgivelser i stedet for midt i en hendelse. Selskaper som bruker denne perioden til å øve, sitter med en fungerende varslingskjede når produktkravene kommer. De som venter, får to store leveranser samtidig.

Tretrinnsmodellen: tidlig varsel, full varsling og sluttrapport

Rapportering under CRA er ikke en innsending, men en sekvens. Prosessen har tre trinn: tidlig varsel innen 24 timer, full varsling innen 72 timer, og endelig rapport innen 14 dager for sårbarheter eller en måned for alvorlige hendelser (teldat.com, 2025). Hvert trinn har sitt eget informasjonsnivå, og de to første løper fra samme startpunkt.

Trinn	Frist	Regnes fra	Hva innsendingen dekker
Tidlig varsel	24 timer	Fra dere blir klar over forholdet	At forholdet finnes, hvilket produkt det gjelder, første vurdering av alvorlighet
Full varsling	72 timer	Fra dere blir klar over forholdet	Oppdatert bilde av omfang, berørte versjoner og status på tiltak
Sluttrapport, aktivt utnyttet sårbarhet	14 dager	Fra korrigerende tiltak er tilgjengelig	Endelig beskrivelse, årsak og hva som er rettet
Sluttrapport, alvorlig hendelse	En måned	Etter varslingen	Endelig beskrivelse, konsekvens og gjennomførte tiltak

Tidlig varsel innen 24 timer

Det første varselet er ikke en analyse. Det er en beskjed om at noe pågår. Produsenter må sende tidlig varsel innen 24 timer etter at de blir klar over forholdet (EU-kommisjonen). Innholdet skal reflektere det dere faktisk vet på det tidspunktet, ikke det dere håper å vite i morgen.

Den vanligste selvpåførte skaden er å utsette varselet for å få et penere bilde. Fristen er absolutt, mens kunnskapsnivået er forventet å være lavt. Et tynt varsel sendt i tide er etterlevelse. Et grundig varsel sendt for sent er brudd.

Full varsling innen 72 timer

Andre trinn kommer raskt etter det første. Full varsling skal sendes innen 72 timer (EU-kommisjonen). Her forventes et mer presist bilde: hvilke versjoner som er berørt, hva slags utnyttelse som er observert, og hva dere gjør med det. Det er dette trinnet som avslører om dere har oversikt over egen portefølje.

Selskaper som ikke vet hvilke kunder som kjører hvilken versjon, bruker hele vinduet på å finne det ut. Da blir varselet vagt der det trengs å være konkret. Et oppdatert produktregister er derfor et rapporteringsverktøy, ikke bare et driftsverktøy.

Sluttrapporten: 14 dager eller en måned

Sluttrapporten avslutter saken. For aktivt utnyttede sårbarheter skal den sendes senest 14 dager etter at et korrigerende tiltak er tilgjengelig, og for alvorlige hendelser innen en måned (EU-kommisjonen). Startpunktet er altså forskjellig fra de to første trinnene: for sårbarheter teller det fra rettelsen foreligger, ikke fra kunnskapstidspunktet.

For alvorlige hendelser beskriver kildene fristen som en måned regnet fra oppfølgingsvarselet (europesays.com, 2026). Praktisk konsekvens: en hendelse dere lukker raskt kan likevel ha en rapporteringshale som løper i ukene etter. Legg inn påminnelser i saksbehandlingen, ellers ryker sluttrapporten fordi alle har gått videre til neste oppgave.

---

Les også: DeepSeek: Hvorfor den kinesiske KI-satsingen er gode nyheter for Norge. DeepSeek har tatt verden med storm med åpne, kostnadseffektive KI-modeller.

---

Aktivt utnyttet sårbarhet eller alvorlig hendelse: hvor går grensen

To ulike forhold utløser plikten, og de har hver sin terskel. I henhold til artikkel 14 må produsenter varsle ENISA om aktivt utnyttede sårbarheter og alvorlige sikkerhetshendelser etter definerte tidsfrister (europesays.com, 2026). Forskjellen betyr noe i praksis, fordi den ene krever bevis for utnyttelse og den andre ikke gjør det.

Spørsmål	Aktivt utnyttet sårbarhet	Alvorlig hendelse
Kjernen i definisjonen	En svakhet eller feil som er blitt utnyttet av en ondsinnet aktør	En hendelse som påvirker eller kan påvirke produktets evne til å beskytte tilgjengelighet, autentisitet, integritet eller konfidensialitet
Krever bevist utnyttelse	Ja, utnyttelse må ha funnet sted	Nei, potensiell påvirkning er nok
Frist for tidlig varsel	24 timer	24 timer
Frist for full varsling	72 timer	72 timer
Frist for sluttrapport	14 dager etter at tiltaket er tilgjengelig	En måned

Når en sårbarhet regnes som aktivt utnyttet

Definisjonen er kort og bred: en aktivt utnyttet sårbarhet er enhver svakhet eller feil som er blitt utnyttet av en ondsinnet aktør (europesays.com, 2026). Det avgjørende er ikke hvor alvorlig svakheten er på papiret, men om noen har brukt den. En lavt scoret sårbarhet som faktisk utnyttes, utløser plikten. En kritisk sårbarhet uten observert utnyttelse gjør det ikke, i alle fall ikke på dette grunnlaget.

Det betyr at trusselbildet, ikke sårbarhetsdatabasen, er den utløsende faktoren. Selskaper som kun følger med på CVE-strømmen fanger opp halve bildet. Dere må også vite om deres egen installerte base blir angrepet, og det krever logging hos kunden eller telemetri fra produktet.

Terskelen for alvorlig hendelse

Her er terskelen lavere og skjønnsrommet større. En alvorlig hendelse er enhver hendelse som negativt påvirker eller kan påvirke produktets evne til å beskytte tilgjengelighet, autentisitet, integritet eller konfidensialitet til sensitive data eller funksjoner (europesays.com, 2026). Ordet «kan» gjør mye arbeid i den setningen. Potensiell påvirkning holder.

Det praktiske spørsmålet blir dermed: hvor lav legger dere terskelen internt? Sett den for høyt, og dere oppdager i etterkant at fristen løp mens dere diskuterte. Sett den for lavt, og dere bruker beredskapsressurser på støy. En brukbar tommelfingerregel er å eskalere alt som berører sikkerhetsfunksjoner i produktet, og la beslutningstakeren avgjøre om det skal rapporteres. Vurderingen skal dokumenteres uansett utfall, også når konklusjonen er at forholdet ikke er rapporteringspliktig.

Når klokken starter og hva som skjer de første 24 timene

Hele regimet henger på ett tidspunkt: da dere ble klar over forholdet. Rapporteringsklokken starter fra det øyeblikket produsenten blir klar over utnyttelsen eller den alvorlige hendelsen (teldat.com, 2025). Alt annet i beredskapen er en funksjon av hvor raskt det tidspunktet inntreffer og hvor godt det er dokumentert.

Alura mener 24-timersfristen er en driftsutfordring før den er en juridisk utfordring. Den avgjøres av om selskapet oppdager og eskalerer raskt nok, ikke av hvor godt policydokumentet er skrevet. Et selskap med en tynn policy og en fungerende vaktordning holder fristen. Et selskap med det motsatte gjør det ikke.

«Blir klar over» er et organisatorisk begrep

Kunnskap sitter sjelden ett sted. En supportkonsulent kan ha lest en kundemelding om merkelig oppførsel før sikkerhetsteamet vet noe. En utvikler kan ha sett en anomali i loggen uten å koble den til et angrep. Legg til grunn at kunnskap hos en ansatt i en relevant rolle kan telle som kunnskap hos selskapet, og bygg rutinen deretter.

Konsekvensen er konkret: eskaleringsplikten må gjelde folk som ikke jobber med sikkerhet til daglig. Support, salg og drift må vite hva de skal gjøre når en kunde nevner noe som lukter utnyttelse. Opplæringen trenger ikke være omfattende, men den må være reell og gjentatt.

Kildene som utløser klokken

Meldinger kommer fra flere kanaler samtidig, og hver av dem må ha en dokumentert vei inn. Kunder rapporterer avvik. Sikkerhetsforskere sender inn funn. Trusseletterretning peker på at en komponent dere bruker blir utnyttet i markedet. Egen overvåkning slår ut. Automatiserte skannere finner noe i et bibliotek.

Uten en felles inngang havner disse i fem forskjellige innbokser med fem forskjellige responstider. Ett mottakspunkt med tidsstempling gjør det mulig å svare på spørsmålet «når visste dere det?» med en logglinje i stedet for en gjetning. Det samme gjelder informasjonshygiene generelt: virksomheter som allerede har ryddet i hvordan data flyter internt, for eksempel gjennom arbeid med privacy-first AI, har mye av dette kartlagt fra før.

Fra melding til innsendt varsel

De første timene bør handle om verifisering og eskalering, ikke om utredning. Bekreft at meldingen er reell, identifiser hvilket produkt og hvilke versjoner som berøres, og kall inn beslutningstakeren. Målet i denne fasen er en avgjørelse om hvorvidt forholdet faller innenfor definisjonene, ikke en rotårsaksanalyse.

Deretter går arbeidet i to parallelle spor: håndtering av selve forholdet, og utfylling av varselet. Disse må ikke kjøre i serie. Hvis rapporteringen venter på at teknisk team blir ferdig, sender dere for sent. Sluttfasen bør være ren kontroll og innsending, med god margin til fristen, slik at en teknisk feil på plattformen ikke velter hele etterlevelsen.

Beredskap på mandag morgen: roller, logg og varslingskanal

Beredskap under CRA er påfallende lite juridisk i praksis. Den består av navngitte personer, en kanal som alltid er bemannet, og en logg som tåler å bli lest av andre i ettertid. Det følgende oppsettet er ikke et krav i forordningen, men et arbeidsverktøy for å møte fristene som er (EU-kommisjonen).

Rolle	Ansvar i de første timene	Krav til tilgjengelighet
Mottaker	Tar imot melding fra kunde, forsker eller overvåkning og tidsstempler den	Døgnkontinuerlig, via vakttelefon eller alarmert kanal
Vurderer	Avgjør om forholdet er en aktivt utnyttet sårbarhet eller en alvorlig hendelse	Kalles ut innen minutter, ikke timer
Beslutningstaker	Godkjenner at tidlig varsel sendes, også når bildet er ufullstendig	Navngitt person med navngitt stedfortreder
Innsender	Fyller ut og sender via Single Reporting Platform	Har tilgang og konto klar på forhånd
Loggfører	Dokumenterer tidspunkter, beslutninger og grunnlaget for dem	Løper parallelt gjennom hele hendelsen

Rollene må ha navn, ikke titler

«Sikkerhetsansvarlig varsler» er ikke en rutine. Det er en formulering. Rutinen begynner når det står et navn, et telefonnummer og en stedfortreder i dokumentet, og når begge vet at de står der. Beslutningstakeren er den kritiske rollen: noen må ha myndighet til å sende et varsel på ufullstendig grunnlag uten å innhente godkjenning fra ledergruppen.

Dette er også stedet å avklare hvem som ikke skal involveres tidlig. Kommunikasjonsavdelingen og juridisk kan bremse en innsending i timevis mens de vurderer formuleringer. Fristen tar ikke hensyn til intern konsensusbygging.

Loggen som dokumenterer at dere holdt fristen

Fristen måles fra kunnskapstidspunktet, og det tidspunktet må kunne dokumenteres. En hendelseslogg med tidsstempler på mottak, vurdering, beslutning og innsending er det eneste som gjør etterlevelsen etterprøvbar. Skriv ned også de forholdene dere vurderte og konkluderte med at ikke var rapporteringspliktige, sammen med begrunnelsen.

Loggen har en dobbeltfunksjon. Den beskytter dere hvis vurderingen senere blir bestridt, og den er råmaterialet for full varsling innen 72 timer og for sluttrapporten. Selskaper som fører logg i sanntid slipper å rekonstruere hendelsesforløpet fra Slack-tråder to uker senere.

Automatiser det som ikke tåler en helg

Alura mener overvåkning, logging og varslingsflyt bør automatiseres så langt det lar seg gjøre, fordi manuelle rutiner sjelden overlever en helg eller en ferie. En rutine som forutsetter at noen leser en delt innboks, fungerer i mars og feiler i juli. Alarmer som ringer, eskalering som eskalerer av seg selv, og tidsstempling som skjer uten menneskelig inngripen er det som skiller papirberedskap fra reell beredskap.

Terskelsetting og førstelinjes triage er også et område der maskinell støtte gir mest igjen, på samme måte som i andre automatiserte kontrollrutiner. Poenget er ikke at en modell skal avgjøre om noe er rapporteringspliktig. Poenget er at ingenting skal bli liggende ubehandlet fordi en person ikke var pålogget.

Single Reporting Platform og veien til riktig CSIRT

Rapporteringen går ett sted. Produsenter rapporterer kun en gang gjennom CRA Single Reporting Platform, forkortet SRP (EU-kommisjonen). ENISA har ansvar for å etablere plattformen i henhold til artikkel 16 i CRA, og den skal være operativ innen 11. september 2026, samme dato som rapporteringskravene trer i kraft (EU-kommisjonen).

Det praktiske rådet er kjedelig og viktig: skaff tilgang før dere trenger den. Kontooppsett, rolletildeling og en prøveinnsending tar minutter i rolige omgivelser og timer under press. Ingen bør møte påloggingsskjermen for første gang med klokken tikkende.

En innsending, flere mottakere

Varslingen rettes til CSIRT der produsenten har sin hovedvirksomhet, og informasjonen gjøres samtidig tilgjengelig for ENISA (EU-kommisjonen). Produsenter må altså varsle ENISA og relevant nasjonal CSIRT samtidig gjennom plattformen (teldat.com, 2025). Modellen er laget for å unngå at samme hendelse må meldes til et titalls mottakere hver for seg.

Det fritar ikke fra andre meldeplikter i andre regelverk. Har dere personopplysninger involvert eller er dere omfattet av sektorspesifikke krav, løper de parallelt med sine egne frister. Kartlegg overlappen på forhånd, slik at hendelsesteamet vet hvilke innsendinger som skal gjøres i hvilken rekkefølge.

Når videreformidling kan utsettes

Det finnes en sikkerhetsventil. I eksepsjonelle tilfeller, og basert på begrunnede cybersikkerhetsforhold, kan CSIRT beslutte å forsinke videreformidling til andre CSIRTer (EU-kommisjonen). Informasjonen gjøres normalt tilgjengelig for ENISA samtidig, med mindre særlige eksepsjonelle omstendigheter gjelder (EU-kommisjonen).

Merk hvem som treffer den beslutningen: det er myndigheten, ikke produsenten. Dere kan ikke holde tilbake et varsel med henvisning til at spredning ville være risikabelt. Dere sender innen fristen, og eventuell begrensning av videre deling håndteres på mottakersiden.

Hva dette betyr for norske programvareselskaper med EU-kunder

Spørsmålet norske ledere stiller først er som regel om dette gjelder oss, når vi sitter utenfor EU. Det praktiske svaret handler mindre om hvor selskapet er registrert og mer om hvor produktet selges. CRA stiller bindende krav til produsenter av tilkoblede produkter som selges i EU (europesays.com, 2026). Har dere kunder i EU-markedet, er utgangspunktet at kravene følger produktet dit.

Norske selskaper har sett dette mønsteret før: EU-regelverk som formelt gjelder et annet marked, men som i praksis setter standarden også her hjemme, slik EU-dommen mot Google illustrerte på et helt annet område. Å bygge to regimer, ett for EU-kunder og ett for norske, er nesten alltid dyrere enn å legge listen på EU-nivå for hele porteføljen.

Markedsadgang er den reelle drivkraften

Bøter er ikke den mest sannsynlige konsekvensen for et lite norsk selskap. Tapt salg er. EU-kunder vil begynne å spørre om CRA-status i anbud og due diligence lenge før noen tilsynsmyndighet banker på. Et selskap som ikke kan beskrive sin varslingsrutine på et halvt A4-ark, taper poeng i den samtalen.

Det gir en nyttig prioritering: bygg rutinen slik at den kan dokumenteres utad. Et kort notat med roller, kanaler, frister og et eksempel på en gjennomført øvelse dekker de fleste kundespørsmål og er samtidig den interne beredskapen.

Hvem i verdikjeden som bærer plikten

Rapporteringsplikten ligger hos produsenten av produktet med digitale elementer. Bruker dere en tredjepartskomponent som blir utnyttet, er spørsmålet om utnyttelsen rammer deres produkt. Gjør den det, må dere forholde dere til fristene uavhengig av hva komponentleverandøren gjør.

Dette bør reflekteres i avtalene. Krev varsling fra underleverandører innen en frist som gir dere reell tid til å rekke deres egen, og be om at de dokumenterer tidspunktet de selv ble kjent med forholdet. Uten slike klausuler arver dere en frist uten å arve informasjonen som skal til for å holde den. Juridiske avklaringer i grenselandet mellom teknologi og regelverk krever ofte samme grundighet som andre nye teknologirettslige spørsmål.

---

Les også: Privacy-first AI i Norge: Slik bruker du AI tryggere (uten å slutte å bruke det). Slik får du mer privat bruk av AI: skill identitet fra innhold, bruk stateless calls og BYOK.

---

Produkter som allerede står ute hos kundene er også omfattet

Dette er punktet flest bommer på. Rapporteringspliktene gjelder også produkter som allerede er på markedet (teldat.com, 2025). Rapportering av aktivt utnyttede sårbarheter og alvorlige hendelser er obligatorisk fra 11. september 2026, også for det som allerede er levert (europesays.com, 2026).

Alura mener konsekvensen er klar: kartleggingen må dekke hele porteføljen, ikke bare nye releaser. Et selskap som bare har oversikt over det som er sluppet det siste året, har oversikt over en brøkdel av risikoen sin. Det er sjelden den nyeste versjonen som blir utnyttet.

Kartlegging av hele porteføljen

Oppgaven er å kunne svare på tre spørsmål raskt: hvilke produkter og versjoner er i bruk, hos hvem, og hvilke komponenter inneholder de. Uten dette kan dere ikke fylle ut full varsling innen 72 timer med noe annet enn omtrentligheter. Kartleggingen er kjedelig, men den er engangsarbeid som deretter vedlikeholdes.

Start med det som har flest brukere og mest sensitiv funksjonalitet, ikke med det som er lettest å dokumentere. Prioriteringen skal følge risiko, ikke tilgjengelighet av dokumentasjon.

Gamle versjoner og glemte integrasjoner

De vanskelige tilfellene er versjoner dere formelt har sluttet å støtte, men som fortsatt kjører hos en kunde, og integrasjoner bygget for lenge siden av noen som har sluttet. Avklar statusen deres eksplisitt: er produktet fortsatt levert av dere, eller er det avviklet på en måte som er dokumentert overfor kunden?

Dette er også en anledning til å rydde. Hver versjon som fortsatt lever ute er en potensiell rapporteringshendelse dere må kunne håndtere innen 24 timer. Å avvikle formelt og migrere kunder er ofte billigere enn å holde beredskap for en hale av gamle installasjoner.

Kostnad og risiko: bøter opptil 15 millioner euro

Sanksjonsnivået er satt for å bli lagt merke til. Maksimal bot for alvorlige brudd på CRA er 15 millioner euro, eller en andel av global årlig omsetning (teldat.com, 2025). For de fleste norske SMB-er er det ikke selve bøtenivået som blir avgjørende, men at et brudd er dyrt nok til å endre et regnskapsår.

Tiltak	Hva det krever	Hva det koster å hoppe over
Vaktordning og eskaleringsvei	Bemanning utenom kontortid og en avklart varslingskjede	Fristen brytes i den første helgehendelsen
Overvåkning og logging	Verktøy, integrasjoner og fornuftige alarmterskler	Dere oppdager forholdet fra kunden eller fra pressen
Produktregister	Oversikt over versjoner, kunder og komponenter	Omfanget kan ikke avgrenses innen 72 timer
Tilgang til rapporteringsplattformen	Konto, roller og en prøveinnsending	Timer går tapt på pålogging midt i hendelsen
Øvelse	En simulert hendelse med reell klokke	Rutinen prøves første gang under press

Hva beredskapen faktisk koster

Den dominerende kostnaden er ikke verktøy. Det er tilgjengelighet utenom kontortid. Et lite selskap kan dekke dette med en enkel vaktrotasjon og en alarmkanal som faktisk vekker folk. Verktøysiden kan ofte bygges på det dere allerede har i drift, forutsatt at loggene finnes og er søkbare.

Den andre kostnaden er oppmerksomhet. Noen må eie rutinen, holde den oppdatert og kalle inn til øvelse. Dette faller lett mellom to stoler i selskaper der sikkerhet er en deltidsoppgave for en utvikler. Sett navn på eierskapet, ellers forvitrer rutinen stille i løpet av et halvår.

Kostnaden ved å tie mot kostnaden ved å overrapportere

Regnestykket er skjevt, og det bør styre terskelsettingen. Et varsel som viser seg å være unødvendig koster arbeidstimer og litt forlegenhet. Et manglende varsel er et regelbrudd med et bøtetak i millionklassen (teldat.com, 2025), pluss den omdømmekostnaden som følger av å ha holdt tilbake informasjon om aktiv utnyttelse.

Det betyr ikke at dere skal rapportere alt. Det betyr at tvilen bør falle i favør av å varsle, og at beslutningstakeren bør vite dette på forhånd. En rutine som premierer forsiktighet i den ene retningen og straffer den i den andre, gir feil beslutninger klokken tre om natten.

Fra rapporteringskrav nå til fulle CRA-krav i desember 2027

CRA rulles ut i etapper, og de to viktigste datoene ligger drøyt et år fra hverandre. Hovedforpliktelsene gjelder fra 11. desember 2027, mens rapporteringsforpliktelsene har gjeldt fra 11. september 2026 (EU-kommisjonen). Perioden imellom er ikke pause. Den er forberedelse med skarp rapporteringsplikt løpende i bakgrunnen.

Dato	Hva som skjer	Hva det betyr for dere
10. desember 2024	CRA trer i kraft	Rammeverket er vedtatt og overgangsperioden begynner
11. september 2026	Rapporteringsforpliktelsene gjelder, og Single Reporting Platform er operativ	24-timersfristen løper fra denne datoen
11. desember 2027	Hovedforpliktelsene gjelder, inkludert CE-merking	Teknisk dokumentasjon, samsvarsvurdering og grunnleggende sikkerhetskrav må være på plass

Hva som gjelder i dag

I dag er kravet avgrenset og skarpt: rapporter aktivt utnyttede sårbarheter og alvorlige hendelser etter tretrinnsmodellen, gjennom Single Reporting Platform, til CSIRT der dere har hovedvirksomheten (EU-kommisjonen). Det er ingen CE-merking å forholde seg til ennå, og ingen teknisk dokumentasjon som skal legges frem.

Nettopp avgrensningen gjør dette til en overkommelig førsteleveranse. Dere trenger ikke løse hele CRA for å etterleve det som gjelder nå. Dere trenger en deteksjons- og varslingskjede som virker.

Hva som treffer i desember 2027

Full CRA-samsvar, inkludert CE-merking, teknisk dokumentasjon og grunnleggende cybersikkerhetskrav, er planlagt å tre i kraft 11. desember 2027 (europesays.com, 2026). Da flyttes tyngdepunktet fra hendelseshåndtering til produktutvikling: kravene dekker planlegging, design, utvikling og vedlikehold (EU-kommisjonen). For enkelte produkter kommer tredjepartsvurdering i tillegg.

Det er en betydelig større leveranse enn rapporteringsrutinen, og den berører hvordan dere bygger, ikke bare hvordan dere reagerer. Selskaper som starter klassifiseringen av porteføljen nå, har allerede gjort en av de tyngste delene av det arbeidet.

Slik bruker dere vinduet

Rekkefølgen som fungerer: få varslingskjeden til å virke først, kartlegg porteføljen som neste steg, og bruk kartleggingen som inngang til samsvarsarbeidet. Hvert steg gir verdi alene, og hvert steg er en forutsetning for det neste. Det motsatte, å starte med et stort samsvarsprosjekt, gir lite beskyttelse mot fristen som løper i dag.

Legg inn en øvelse i kvartalsrytmen. En simulert melding, reell klokke, og en gjennomgang av hva som gikk tregt. Det avdekker mer enn en revisjon av dokumentasjonen, og det koster en formiddag.

Vanlige feil i CRA-beredskapen

Feilene går igjen på tvers av selskaper, og de fleste handler om avstanden mellom det som står skrevet og det som skjer i praksis. Ingen av dem krever store investeringer å rette. De krever at noen tar en beslutning og setter et navn på den.

Å forveksle policyen med beredskapen

Et velskrevet dokument som ingen har lest i drift, er ikke etterlevelse. Testen er enkel: ring en tilfeldig ansatt i support og spør hva de gjør hvis en kunde melder at noen ser ut til å utnytte en feil i produktet. Får dere et konkret svar med et navn eller et nummer, virker rutinen. Får dere «da tar jeg det videre», gjør den ikke det.

Å la klokken stå stille i helgen

Fristen er angitt i timer, ikke i arbeidsdager, og den løper fra kunnskapstidspunktet (teldat.com, 2025). En melding som kommer inn fredag ettermiddag skal håndteres innen lørdag ettermiddag. Selskaper som ikke har tenkt gjennom dette, oppdager svakheten første gang det faktisk skjer, og da er den allerede materialisert som et fristbrudd.

Å vente på et komplett bilde

Det tidlige varselet er designet for å være ufullstendig. Full varsling innen 72 timer er stedet for detaljene (EU-kommisjonen). Å holde tilbake det første varselet i påvente av teknisk avklaring er den mest utbredte og mest unødvendige måten å bryte fristen på.

Å planlegge bare for nye produkter

Rapporteringsplikten omfatter også det som allerede står ute hos kundene (europesays.com, 2026). Beredskap som bare dekker aktivt vedlikeholdte produkter etterlater et hull nøyaktig der historikken, og dermed sårbarhetene, er størst. Kartleggingen må gå bakover i tid, ikke bare fremover i roadmapen.

Ofte stilte spørsmål om CRA-rapportering

Spørsmålene under er de som går igjen når norske ledergrupper går gjennom rapporteringsplikten for første gang. Svarene er praktiske, og de peker tilbake til kildene der regelverket er tydelig.

Gjelder 24-timersfristen kalendertid eller arbeidstid?

Fristen er uttrykt i timer fra det tidspunktet produsenten blir klar over forholdet (EU-kommisjonen). Det er ingenting i Kommisjonens beskrivelse som antyder at klokken stopper utenfor arbeidstid. Planlegg som om den løper kontinuerlig, inkludert i høytider og ferieperioder.

Hva om vi ikke vet nok til å fylle ut varselet?

Send det uansett. Tidlig varsel er første trinn i en tretrinnsprosess der full varsling følger innen 72 timer og sluttrapporten senere (teldat.com, 2025). Strukturen forutsetter at kunnskapen bygges opp underveis, og det er derfor de tre trinnene finnes.

Må vi rapportere sårbarheter som ikke er utnyttet?

Rapporteringsplikten gjelder aktivt utnyttede sårbarheter og alvorlige hendelser (EU-kommisjonen). En sårbarhet uten observert utnyttelse utløser ikke plikten på det grunnlaget. Men vurder alltid om forholdet likevel kan være en alvorlig hendelse, siden den definisjonen også omfatter potensiell påvirkning på produktets sikkerhetsegenskaper (europesays.com, 2026).

Må vi sende samme rapport til flere myndigheter?

Nei, ikke under CRA. Produsenter rapporterer kun en gang gjennom Single Reporting Platform, og varselet går til CSIRT der produsenten har hovedvirksomheten samtidig som det gjøres tilgjengelig for ENISA (EU-kommisjonen). Meldeplikter etter andre regelverk gjelder fortsatt uavhengig av dette.

Gjelder plikten produkter vi solgte for flere år siden?

Ja, hvis produktet fortsatt er på markedet. Rapporteringskravene omfatter uttrykkelig produkter som allerede er i markedet (teldat.com, 2025). Hvor grensen går for produkter dere formelt har avviklet, bør avklares konkret per produkt og dokumenteres.

Oppsummering og neste steg

CRA-rapporteringsplikten er den minste og mest håndterbare delen av forordningen, og den er den eneste delen som gjelder i dag. Kravet er å oppdage, vurdere og varsle raskt: tidlig varsel innen 24 timer, full varsling innen 72 timer, og sluttrapport innen 14 dager eller en måned avhengig av forholdets art (EU-kommisjonen). Alt annet i CRA kommer 11. desember 2027 (EU-kommisjonen).

Den avgjørende innsikten er hvor fristen faktisk vinnes eller tapes. Den vinnes i deteksjonen og eskaleringen, ikke i formuleringene. Et selskap som oppdager et forhold sent, har allerede tapt, uansett hvor presist varselet blir når det først sendes.

Det som bør være på plass denne uken

Navngi beslutningstaker og stedfortreder. Opprett en mottakskanal som er bemannet døgnkontinuerlig og som tidsstempler alt som kommer inn. Skaff tilgang til Single Reporting Platform og gjennomfør en prøveinnsending (EU-kommisjonen). Skriv ned hva som skal eskaleres, i et språk support og drift forstår. Dette er en formiddags arbeid, ikke et prosjekt.

Det som kan planlegges mot 2027

Kartleggingen av hele porteføljen, klassifisering av hvilke produkter som kan kreve tredjepartsvurdering, og oppbygging av teknisk dokumentasjon hører til løpet frem mot 11. desember 2027 (europesays.com, 2026). Start kartleggingen tidlig, siden den også er det som gjør varslingen innen 72 timer mulig å fylle med noe konkret. De to løpene deler grunnlagsarbeid, og det er den billigste måten å ta begge på.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

• EU-kommisjonen. Cyber Resilience Act - Reporting obligations
• teldat.com (2025). CRA reporting obligations from 11 September 2026
• europesays.com (2026). The EU Cyber Resilience Act: mandatory reporting requirements - Europe
• EU-kommisjonen. Cyber Resilience Act | Shaping Europe's digital future