Cyber Resilience Act (CRA) 2026–2027: hvad vi allerede ved, hvad der stadig mangler, og hvordan man reelt forbereder et produkt – før de harmoniserede standarder foreligger

Hvad vi med sikkerhed ved i dag (og hvorfor det ikke er et “2027-tema”)

Cyber Resilience Act kan godt ligne endnu et dokument “fra Bruxelles”, som man kan skubbe til senere. Det er en naturlig reaktion, især hvis virksomheden lever i projektcyklusser: prototype, implementering, serieproduktion, service. Reguleringer kommer ofte ind som et “slutkrav” — noget, man får lukket på målstregen. CRA ændrer den logik, fordi det ikke kun handler om det, der kan ses i produktet på salgsdagen. Det handler om, hvorvidt producenten kan opretholde produktets sikkerhed over tid og dokumentere, at det er gjort bevidst — ikke tilfældigt.

Den vigtigste kendsgerning er enkel, men har strategiske konsekvenser: CRA er en produktregulering, forankret i EU-markedets mekanik (herunder CE-mærkning). Europa-Kommissionen beskriver direkte, at produkter skal bære CE-mærket som signal om overensstemmelse med CRA, og at håndhævelsen ligger hos markedsovervågningsmyndighederne. Det er altså ikke en “IT-standard”, man kan behandle som et internt forbedringsprogram. Det er en ramme, der påvirker muligheden for at sælge.

Datoer, der skaber overblik

I selve teksten til forordning (EU) 2024/2847 fremgår en trinvis anvendelse. CRA finder anvendelse fra 11. december 2027, men med tydelige undtagelser. Artikel 14 (rapportering) gælder fra 11. september 2026, og kapitlet om notifikation af organer for overensstemmelsesvurdering (Chapter IV) fra 11. juni 2026. Det er tre datoer, der er værd at betragte som “milepæle”, fordi de svarer til tre forskellige typer parathed: operationel, institutionel og produktmæssig.

Kommissionen kommunikerer det endnu mere enkelt: CRA trådte i kraft 10. december 2024, de grundlæggende forpligtelser fra 11. december 2027, og rapportering fra 11. september 2026. Hvis nogen i virksomheden siger “vi har tid til 2027”, mener de oftest designkrav og overensstemmelsesvurdering. Men rapporteringen kommer tidligere og vedrører hændelser, der ikke venter på en tidsplan.

Rapportering: en forpligtelse, der tvinger en proces igennem (ikke et dokument)

Rapporteringskravet er en god lakmusprøve, fordi det viser, hvordan CRA forstår “produktsikkerhed i cybersammenhæng”. Det er ikke en hensigtserklæring eller en “politik”. Det er en proces, der skal fungere under pres: når der opstår en aktivt udnyttet sårbarhed eller en alvorlig hændelse.

Kommissionen beskriver det entydigt: producenten skal indberette aktivt udnyttede sårbarheder samt severe incidents, der påvirker produktets sikkerhed. Der kræves en “early warning” inden for 24 timer efter, at man er blevet bekendt med forholdet, en fuld indberetning inden for 72 timer, og en slutrapport: senest 14 dage efter at en afhjælpning er tilgængelig for aktivt udnyttede sårbarheder samt inden for en måned for severe incidents.

I praksis betyder det, at organisationen har brug for mere end en tjekliste. Den har brug for en mekanisme, der besvarer tre spørgsmål: hvordan får vi at vide, at problemet findes; hvem vurderer, om det allerede er “aktivt udnyttet” eller “severe”; og hvordan organiserer vi informationsdeling og rettelse inden for en tidsramme, der ikke giver plads til improvisation.

Hvis der opstår kaos på kurser, skyldes det ofte, at CRA rammer et hul mellem IT og produktet. For IT kan en “hændelse” være noget, der sker i infrastrukturen. For en producent er en “hændelse” noget, der rammer produktet hos kunden — en bestemt version, en konfiguration, en udrulningsmåde. CRA tvinger disse verdener sammen til ét samlet ansvar.

Hvad CRA omfatter: produktet som relation til netværket, ikke “en enhed på bordet”

I praksis har vi i risikovurderinger af maskiner lært, at risiko ikke er en egenskab ved selve maskinen — den opstår i relationen menneske–maskine. I CRA sker en tilsvarende forskydning i perspektiv: sikkerhed findes ikke “i enheden”, men i relationen mellem produktet og det digitale miljø, anvendelsesmåden og producentens evne til at reagere.

Kommissionen fremhæver i sin sammenfatning af CRA definitionen af “produkter med digitale elementer” og det forhold, at rapporteringsforpligtelserne gælder for alle sådanne produkter, der stilles til rådighed på EU-markedet — også dem, der er bragt i omsætning før 11. december 2027. Det er en afgørende præcisering, fordi den fjerner en udbredt myte: “for gamle produkter betyder det ikke noget”. Rapportering — det gør det.

Hvad der endnu ikke findes (harmoniserede standarder), og hvorfor det ikke bør lamme

W drøftelser om CRA dukker ofte sætningen op: “der findes endnu ingen harmoniserede standarder, så man kan ikke gøre noget”. Det lyder logisk, men der ligger en skjult faldgrube i det. Harmoniserede standarder er et værktøj, der gør det lettere at påvise overensstemmelse (formodning om overensstemmelse), men de er ikke den eneste vej til at opbygge reel produktsikkerhed. Og de er heller ikke en forudsætning for at begynde at designe rigtigt.

Kommissionen håndterer emnet standarder direkte via siden “CRA Standardisation” og oplyser, at den har vedtaget standardisation request M/606, som omfatter et sæt på 41 standarder, der understøtter CRA — både horisontale og vertikale (produktspecifikke). Det er vigtigt, fordi det viser, at EU forstår markedets udfordring: uden standarder vil virksomheder opbygge overensstemmelse hver på sin egen måde, og markedsovervågningen vil få sværere ved at føre tilsyn.

Horisontale og vertikale standarder: hvad betyder det for producenten

Forenklet:

• horisontale standarder skal beskrive “hvordan” man opbygger og vedligeholder produktsikkerhed uafhængigt af kategori (processer, metoder, risikobaseret tilgang),
• vertikale standarder skal præcisere kravene for konkrete produktklasser (der, hvor risici og arkitekturer er typiske).

Denne sondring har praktiske konsekvenser. Hvis du udvikler et industriprodukt, hvor en del af miljøet er “OT”, og livscyklussen er lang, har du brug for standarder, der ikke er skrevet til en SaaS-applikation. Og netop derfor er vertikale standarder vigtige: de hjælper med at gå fra generelle principper til, hvad der skal kontrolleres i reelle arkitekturer.

Tidsplanen: standarderne kommer i etaper, ikke “som en samlet pakke før 2027”

Kommissionen viser i materialer om implementeringen af CRA, at CRA indføres trinvist, og at standarderne skal understøtte processen over tid. Faktuelt, det vi med sikkerhed ved i dag: vi har en formelt vedtaget forordning, og vi har en igangsat standardiseringsmekanisme (M/606).

Det vigtigste i praksis er at forstå én sætning: selv når en standard er udarbejdet af standardiseringsorganisationer, opstår “formodning om overensstemmelse” i juridisk forstand først, når henvisningen til standarden offentliggøres som en harmoniseret standard i EU-Tidende. Det er den samme mekanik som i EU’s harmoniseringsmodel: standarder er broen mellem jura og ingeniørpraksis, men broen skal formelt “anerkendes” af EU.

Set fra producentens perspektiv betyder det, at årene 2026–2027 bliver en periode, hvor nogle virksomheder vil arbejde ud fra egne metoder til at påvise overensstemmelse (risk – based + evidens), mens andre allerede vil kortlægge deres arbejde op mod de standarder, der løbende kommer til. Og det er helt normalt.

“Ingen standarder” betyder ikke “ingen forpligtelse” — det betyder større vægt på dokumentation

Her kommer en væsentlig konsekvens: hvis der ikke findes standarder, der giver den enkleste vej til at påvise overensstemmelse, øges betydningen af det, som i auditpraksis altid er afgørende: et sammenhængende beslutningsspor.

Hvilke risici har vi vurderet? Hvilke scenarier har vi anset som realistiske? Hvordan har vi valgt beskyttelsesforanstaltninger? Hvordan håndterer vi sårbarheder? Hvor længe understøtter vi produktet? Hvordan informerer vi kunden? CRA kræver ikke, at producenten “gætter fremtidige EN-standarder”. Den kræver, at producenten kan vise, at beslutningerne ikke var tilfældige, men baseret på risiko og state of the art.

Hvordan man reelt forbereder et produkt til CRA (roadmap for producent og integrator)

Den største værdi ved CRA er, at den tvinger modenhed igennem: cybersikkerhed holder op med at være et ekstra lag oven på produktet og bliver en egenskab ved selve produktet. Men modenhed opstår ikke af erklæringer. Den opstår af en proces, der er præcis nok til at fungere i praksis og enkel nok til, at ingeniørarbejdet ikke begynder at gå udenom den.

I risikovurdering af maskiner opstår de bedste designbeslutninger, når vi holder op med at spørge “hvilke farer har maskinen”, og i stedet spørger “i hvilke opgaver og tilstande er mennesket udsat”. I CRA er det tilsvarende: vi holder op med at spørge “hvilke sårbarheder har produktet”, og begynder at spørge “under hvilke betingelser bliver produktet udsat, og hvad kan producenten så gøre”. Det skift skaber struktur i arbejdet.

Trin 1: Definér produktet som et system (ikke som en enhed)

Start med at definere, hvad der i dit tilfælde er et “produkt med digitale elementer”. Ikke kun hardware og firmware, men også det, der ofte overses, fordi det ikke ligger i kassen: komponenter, biblioteker, opdateringsmekanismer, tjenester, uden hvilke produktet ikke opfylder sin funktion. I CRA er det vigtigt, fordi producentens ansvar omfatter det, der bringes på markedet som et produkt — og ikke kun det, som mekanikafdelingen har fremstillet.

Det er også det første tidspunkt, hvor integratorer bør være ærlige over for sig selv: Hvis du integrerer komponenter og konfigurerer dem på en måde, der skaber et “slutprodukt” i kundens øjne, så er du ikke kun en “implementeringspartner”. Du er medskaber af risikoen og medskaber af ansvaret.

Trin 2: Lav CRA-risikovurderingen, så den bliver et beslutningsværktøj

Det handler ikke om en “matrix” på slides. Det handler om en risikovurdering, der munder ud i designbeslutninger og kan gentages på en ensartet måde.

I praksis starter en god tilgang til CRA med et enkelt spørgsmål: Hvilke realistiske misbrugsscenarier findes der i kundens miljø – og ikke kun i laboratoriet? Hvem har serviceadgang? Hvordan ser netværket ud? Hvor ofte opdaterer vi? Hvad er konsekvenserne af nedetid? I industrien er de spørgsmål mere ubekvemme end i IT, fordi svarene ofte lyder: “vi kan ikke opdatere hver uge” eller “vi har ikke telemetri”. Og netop derfor skal de stilles. CRA er lov, men konsekvenserne er designmæssige.

Krok 3: Opbyg “vulnerability handling” som en produktionsproces, ikke som en krisereaktion

Rapporteringskravene beskrevet af Kommissionen (24h/72h/14 dage/måned) er nådesløse for en organisation uden en proces. Hvis du vil være klar til 11. september 2026, skal du behandle “vulnerability handling” som en del af produktets livscyklus – ikke som “en opgave for security-teamet”.

Det betyder:

• én kanal til at modtage indberetninger (CVD policy + kontakt),
• triage med en tydelig ejer og klare kriterier,
• en mekanisme til at bygge og levere security updates,
• en kommunikationsmodel til kunder, der ikke er ren improvisation,
• beredskab til rapportering (hvem indberetter, med hvilke data, hvor hurtigt).

Det hele lyder som “organisatorisk” arbejde. I praksis er det produktarbejde, fordi det handler om versioner, kompatibilitet, opdateringsarkitektur og supportstrategi.

Krok 4: Vælg support period som en forretningsbeslutning, ikke som et minimumskrav

Hvis dine produkter lever i industrien i 10–15 år, er support period strategisk. CRA tvinger, at support ikke må være et løfte uden reelt indhold. Det betyder, at support period bør bygge på en analyse: hvor længe produktet vil være i brug, hvordan komponenternes forsyningskæde ser ud, og hvor længe du vil kunne levere rettelser. I praksis begynder support period at “trække” hele økosystemet med sig: aftaler med leverandører, tilgængelighed af build environment, vedligeholdelse af toolchains og endda beslutninger om, hvorvidt produktet har fjernfunktioner, eller om det er isoleret.

Hvis du behandler support period som en formalitet, vil du senest i 2027 havne i en konflikt: Kunden forventer support, men du har ikke længere ressourcerne eller afhængighederne til at levere den. CRA skaber ikke problemet — CRA synliggør det blot.

Krok 5: Få styr på forsyningskæden: dialogen med leverandører er en del af compliance

Der er ingen “magi” i CRA, der gør eksterne komponenter sikre. Hvis din enhed bygger på biblioteker, kommunikationsmoduler, operativsystem, SDK eller hardwarekomponenter, afhænger din risiko direkte af kvaliteten af leverandørens praksis.

Derfor giver det allerede nu mening at tage en dialog om ting, der ikke lyder som marketing, men som ingeniørarbejde:

• om leverandøren kan informere om sårbarheder på en forudsigelig måde,
• hvilken responstid de har,
• om de har en proces for udgivelse af rettelser,
• om de kan vedligeholde komponenten i en periode, der matcher din support period.

Her rammer CRA for alvor forretningen: En leverandør, der ikke kan håndtere sårbarheder, er ikke “billigere”. Det er en regulatorisk risiko.

Krok 6: Opbyg dokumentation som et sammenhængende spor: lov → risiko → beslutning → bevis

I compliance-audits vinder sammenhæng altid. Hvis risikovurderingen viser, at en given grænseflade er kritisk, men dokumentationen ikke beskriver, hvordan du sikrer den; hvis du erklærer, at opdateringer er sikre, men ikke kan vise, hvordan du sikrer pakkeintegritet; hvis du siger, at du har en proces for håndtering af sårbarheder, men ikke kan vise, hvordan du triagerer indberetninger — så er det ikke “manglende papir”. Det er mangel på bevis for, at processen fungerer.

I CRA, når der mangler harmoniserede standarder, er dette spor særligt vigtigt. For det bliver grundlaget for dialogen med markedsovervågningsmyndigheden, enterprise-kunden og i nogle produktkategorier også med en overensstemmelsesvurderings-enhed. Og lige så vigtigt: Det bliver grundlaget for intern stabilitet. Teamet ved, hvorfor vi gør noget — ikke kun “at vi skal”.

Afslutning: CRA som et nyt designkrav, ikke et “compliance-projekt”

Hvis jeg skulle efterlade én tanke, der binder de tre dele sammen: CRA er ikke et problem, der skal løses til sidst. Det er en ramme, der ændrer måden, man tænker om produktet på. Ligesom ISO 12100 lærer, at risiko opstår i relationen menneske–maskine, lærer CRA, at cybersikkerhed opstår i relationen produkt–miljø–producentens livscyklus.

Harmoniserede standarder kommer og vil forenkle visse forløb. Men deres fravær er ikke en grund til at stå stille. Det er en grund til at fokusere på det, CRA altid vurderer: beslutninger, beviser og evnen til at handle i virkeligheden — ikke i en præsentation.