Gjelder Cyber Resilience Act for ditt produkt?

Hvis du lager maskinvare, skriver programvare eller importerer en av delene til Den europeiske union, har du sannsynligvis allerede hørt ordene «Cyber Resilience Act» kastet rundt i leverandør-e-poster, fagpresse og anskaffelses-spørreskjemaer. Det som er vanskeligere er å få et rent, forsvarlig svar på ett tilsynelatende enkelt spørsmål: gjelder CRA for mitt produkt, og hvis ja, hva må jeg faktisk gjøre? Dette gjennomgår produkt-siden av spørsmålet; enhets-siden er behandlet i Gjelder NIS2 for ditt EU-prosjekt? .

Grunnen til at det ikke er et énlinje-svar er at Forordning (EU) 2024/2847 — det formelle navnet på Cyber Resilience Act (CRA) — er bygget rundt fem logikklag som samhandler:

1. En produkttest, ikke en enhets-test. I motsetning til NIS2-direktivet spør ikke CRA om selskapet ditt er en bestemt type enhet. Den spør om hvert produkt med digitale elementer (PDE) du plasserer på unionsmarkedet er i omfang (Art. 2(1) ). Du kan være «produsent» av ett produkt, «importør» av et annet, og helt utenfor omfang for et tredje.
2. Rollebaserte forpliktelser. Om du er produsent, autorisert representant, importør eller distributør endrer hvilke plikter som gjelder, med produsenten som bærer hovedtyngden og importører/distributører som spiller en verifiseringsrolle (Art. 13, 18, 19, 20 ).
3. Et lagdelt klassifiseringssystem. Standardprodukter, Viktige produkter (delt i Klasse I og Klasse II) og Kritiske produkter følger hver en forskjellig samsvarsvurderingsrute (Vedlegg III og IV ; Art. 32 ).
4. Samspill med sektorlovverk. Medisinsk utstyr, motorvogner, sivil luftfart og marint utstyr er unntatt fordi deres egne sektorregimer allerede dekker cybersikkerhet (Art. 2(2)–(4) ; fortale 25, 27).
5. Spesiell behandling av fri og åpen kildekode-programvare (FOSS). Ikke-kommersiell FOSS er ute; «forvaltere av åpen kildekode-programvare» møter et lett regime; kommersielle FOSS-distributører er fullverdige produsenter (Art. 24 ; fortale 17–19).

Bommer du på ett av disse lagene, kan du enten overforbruke på etterlevelse for et produkt som er unntatt, eller — langt mer smertefullt — underforberede et produkt som trenger samsvarsvurdering hos teknisk kontrollorgan og oppdage at du ikke kan CE-merke det i tide til fristen 11. desember 2027 (Art. 71 ).

Beslutningstreet

flowchart TD
    A[Start: Plasseres produktet på EU-markedet som ledd i kommersiell aktivitet?] --> B{Er det et 'produkt med digitale elementer'?
dvs. PV/MV + direkte eller indirekte datatilkobling
Art. 3 1}
    B -- Nei --> X1[Utenfor omfang]
    B -- Ja --> C{Gjelder et artikkel 2-unntak?
MDR/IVDR, motorvogner, luftfart,
marint, forsvar/nasjonal sikkerhet,
klassifisert informasjon, kvalifiserende reservedeler}
    C -- Ja --> X2[Utenfor CRA-omfang
følg sektorregler]
    C -- Nei --> D{Er det FOSS levert utenfor
kommersiell aktivitet?
Fortale 15-18}
    D -- Ja, ikke-kommersiell FOSS --> X3[Utenfor omfang
Forvalterregime kan gjelde Art. 24]
    D -- Nei / Kommersiell --> E{Hva er din rolle?
Produsent / Autorisert rep /
Importør / Distributør
Art. 3 13-20}
    E --> F{Klassifiser produktet:
Standard, Viktig Klasse I,
Viktig Klasse II, eller Kritisk?
Vedlegg III & IV}
    F -- Standard ~90% av PDE-er --> G[Egenvurdering Modul A
mulig. Vedlegg VIII]
    F -- Viktig Klasse I --> H[Egenvurdering HVIS harmoniserte
standarder/felles spesifikasjoner/EU-sertifisering
anvendt; ellers tredjepart]
    F -- Viktig Klasse II --> I[Tredjeparts samsvarsvurdering
OBLIGATORISK
Modul B+C eller H]
    F -- Kritisk Vedlegg IV --> J[Europeisk cybersikkerhets-
sertifisering 'vesentlig'
når pålagt ved delegert rettsakt]
    G --> K[Anvend Vedlegg I essensielle
krav + sårbarhetshåndtering;
fastsett støtteperiode
≥ 5 år Art. 13 8]
    H --> K
    I --> K
    J --> K
    K --> L[Utarbeid EU-samsvarserklæring Vedlegg V
+ teknisk dokumentasjon Vedlegg VII
+ påfør CE-merking Art. 30]
    L --> M[Bygg opp artikkel 14-rapportering:
24t / 72t / 14d / 1 måned
via ENISA Single Reporting Platform]

    classDef entry fill:#1e88e5,stroke:#0d47a1,color:#fff;
    classDef out fill:#e53935,stroke:#b71c1c,color:#fff;
    classDef high fill:#fb8c00,stroke:#e65100,color:#fff;
    classDef med fill:#fdd835,stroke:#f9a825,color:#000;
    classDef ops fill:#43a047,stroke:#1b5e20,color:#fff;

    class A entry;
    class X1,X2,X3 out;
    class I,J high;
    class F,H med;
    class G,K,L,M ops;

Steg 1 — er produktet et «produkt med digitale elementer»?

CRA gjelder kun hvis produktet ditt er et «produkt med digitale elementer» (PDE) — gateway-testen nedenfor avgjør om du er i omfanget i det hele tatt. Under artikkel 3(1) i CRA er en PDE «et programvare- eller maskinvareprodukt og dets fjern-databehandlingsløsninger, inkludert programvare- eller maskinvarekomponenter som plasseres på markedet separat». Artikkel 2(1) begrenser CRA til PDE-er «gjort tilgjengelig på markedet, hvis tiltenkte formål eller rimelig forutsigbare bruk inkluderer en direkte eller indirekte logisk eller fysisk datatilkobling til en enhet eller et nettverk» (Forordning (EU) 2024/2847, Art. 2(1) ).

Tre ting følger av den definisjonen:

• Både maskinvare og programvare teller. Innebygd firmware, mobilapper, skrivebordsprogramvare, IoT-enheter, industrielle kontrollere — alle er PDE-er (EK-sammendrag, Ordliste ).
• Komponenter plassert separat på markedet er også PDE-er. En mikroprosessor solgt til integratorer er en PDE i seg selv, ikke bare det ferdige produktet den havner i (Fortale 9).
• Fjern-databehandlingsløsninger designet og utviklet av, eller under ansvar av, produsenten trekkes inn i produktets omfang når fraværet av den behandlingen ville hindre produktet i å utføre en av sine funksjoner (Art. 3(2); Fortale 11–12). Sky-aktivert funksjonalitet av en smart-hjem-enhet er inne. Generisk SaaS/PaaS/IaaS solgt til tredjeparter er regulert av NIS2 i stedet — se Gjelder NIS2 for ditt EU-prosjekt? .

Bruk denne sjekken:

• Produktet mitt er maskinvare eller programvare (eller en komponent av en av delene).
• I normal bruk eller rimelig forutsigbar bruk gjør det en logisk eller fysisk datatilkobling — direkte eller indirekte — til en annen enhet eller et nettverk.
• Hvis det er avhengig av en backend-/sky-komponent jeg designet (eller har fått designet på mine vegne), har jeg inkludert den backend-en i omfangsanalysen min.

Hvis alle tre bokser krysser: fortsett til Steg 2. Et rent analogt produkt uten programmerbare digitale elementer og uten tilkobling er ikke en PDE.

Steg 2 — gjelder et unntak?

Selv om produktet teknisk sett er en PDE, unntar artikkel 2 flere kategorier. Gå gjennom denne listen nøye — hvis produktet ditt faller under et annet EU-regime som allerede dekker cybersikkerhet, kan CRA trekke seg unna.

Sektorunntak (Art. 2(2)–(4)):

• Medisinsk utstyr og IVD-er dekket av Forordning (EU) 2017/745 (MDR) eller Forordning (EU) 2017/746 (IVDR) — ute (Art. 2(2); Fortale 25).
• Motorvogner, deres systemer og komponenter som Forordning (EU) 2019/2144 om kjøretøy-typegodkjenning gjelder for — ute, fordi UN-forordning nr. 155 om cybersikkerhets-styringssystemer allerede gjør det tunge løftet (Art. 2(3); Fortale 27).
• Sivil luftfartsprodukter sertifisert under Forordning (EU) 2018/1139 — ute (Art. 2(3); Fortale 27).
• Marint utstyr innenfor omfanget av Direktiv 2014/90/EU — ute (Art. 2(4)).
• Reservedeler som er ment å erstatte identiske komponenter i et produkt som allerede er plassert på markedet, og som er produsert etter samme spesifikasjoner som delen de erstatter — ute (Art. 2(5); Fortale 29).

Sikkerhet- og forsvarsunntak (Art. 2(6)–(7)):

• Produkter utviklet eller modifisert utelukkende for nasjonal sikkerhet eller forsvarsformål.
• Produkter spesifikt designet for å behandle klassifisert informasjon (Fortale 26).
• Produkter utviklet eller modifisert av en offentlig forvaltningsenhet utelukkende for egen bruk (Fortale 16).

Fri og åpen kildekode-programvare (Art. 2(8) og fortale 17–19): FOSS levert utenfor løpet av en kommersiell aktivitet er utenfor omfang. Se Steg 9 for den detaljerte FOSS-analysen — det er en seksjon i seg selv.

En praktisk merknad om radioutstyr. Der produktet ditt er en radioenhet, gjelder de cybersikkerhetsrelaterte essensielle kravene i artikkel 3(3)(d), (e) og (f) i radioutstyrsdirektivet 2014/53/EU, slik de er aktivert ved Kommisjonens delegerte forordning (EU) 2022/30 , allerede. Fortale 30 i CRA bekrefter at CRAs essensielle cybersikkerhetskrav dekker samme grunn som RED 2022/30 og at Kommisjonen har til hensikt å endre eller oppheve RED 2022/30 slik at den slutter å gjelde produkter underlagt CRA i overgangsperioden. I mellomtiden, behandle dem som overlappende heller enn alternative.

Hvis ingen unntak gjelder: fortsett til Steg 3.

Steg 3 — hvem er du? Identifiser din rolle under CRA

Forpliktelsene dine avhenger av om du er produsent, autorisert representant, importør eller distributør. Definisjonene kommer fra artikkel 3:

Noen viktige konsekvenser:

• En distributør som ommerker eller vesentlig endrer et produkt blir produsent for CRA-formål (Fortale 38; Art. 22 anser visse aktører som produsenter).
• En nettbasert markedsplass som bare formidler, blir ikke selv en økonomisk aktør; men den samme juridiske enheten som selger produkter gjennom markedsplassen sin kan samtidig være produsent eller distributør for disse produktene (Fortale 78).
• Der produsenten er utenfor EU og det ikke finnes importør, er en skriftlig-mandat autorisert representant den rette strukturen for klarhet (Art. 18; se «Tips for ikke-EU-produsenter» nedenfor).

Kryss av rollen(e) dine:

• Produsent (inkl. den som markedsfører et produkt under egen merkevare, selv om en kontraktsprodusent laget det).
• Autorisert representant (med skriftlig mandat fra en ikke-EU-produsent).
• Importør (EU-etablert, plasserer et ikke-EU-merket produkt på markedet for første gang).
• Distributør (lenger ned i kjeden, påvirker ikke produktegenskaper).

Steg 4 — klassifiser produktet: Standard, Viktig (Klasse I/II) eller Kritisk

Produktklassifisering under CRA driver hvilken samsvarsvurderingsrute du må følge, så det er den enkeltbeslutningen som mest preger arbeidsmengden for å komme på markedet. CRA deler PDE-er i fire bøtter basert på cybersikkerhetsrisiko:

Standardprodukter (den residuelle kategorien)

Alt som ikke er listet i Vedlegg III eller IV er «standard». Europakommisjonen anslår at dette dekker rundt 90 % av alle PDE-er — husholdningsapparater, mobilapper, dataspill, smarte høyttalere, minnebrikker og lignende (EK-sammendrag ).

→ Egenvurdering er tillatt via intern kontrollprosedyre (Modul A) i Vedlegg VIII.

Viktige produkter — Klasse I (Vedlegg III, Del I)

Dette er PDE-er hvis kjernefunksjonalitet matcher en kategori i Vedlegg III, Del I i forordningen. Listen (parafrasert fra endelig tekst av Vedlegg III ) inkluderer:

• Identitetsstyringssystemer og privilegert tilgangsstyring (PAM) programvare og maskinvare, inkludert autentiserings- og tilgangskontroll-lesere, inkludert biometriske lesere
• Frittstående og innebygde nettlesere
• Passordbehandlere
• Programvare som leter etter, fjerner eller karantenerer ondsinnet programvare
• Produkter med funksjon som virtuelt privat nettverk (VPN)
• Nettverksadministrasjonssystemer
• Sikkerhetsinformasjon- og hendelsesstyring (SIEM)-systemer
• Boot-håndterere
• Offentlig nøkkelinfrastruktur og utstedere av digitale sertifikater
• Fysiske og virtuelle nettverksgrensesnitt
• Operativsystemer
• Rutere, modemer ment for tilkobling til internett, og svitsjer (ikke dekket av Klasse II)
• Mikroprosessorer, mikrokontrollere, ASIC-er og FPGA-er med sikkerhetsrelaterte funksjonaliteter
• Smart-hjem generelle virtuelle assistenter
• Smart-hjem-produkter med sikkerhetsfunksjonaliteter, inkludert smarte dørlåser, babymonitor-systemer og alarmsystemer
• Internett-tilkoblede leker (med sosialt interaktive funksjoner eller stedssporing)
• Personlige bærbare produkter ment å bæres på menneskekroppen som har et helse-overvåkingsformål (der MDR/IVDR ikke gjelder) og personlige bærbare produkter ment for bruk av barn

→ Egenvurdering (Modul A) er kun tillatt hvis produsenten anvender relevante harmoniserte standarder, felles spesifikasjoner, eller en utpekt europeisk cybersikkerhetssertifiseringsordning som dekker de essensielle kravene. Ellers kreves tredjeparts samsvarsvurdering (Art. 32(2); Fortale 91).

Viktige produkter — Klasse II (Vedlegg III, Del II)

En mindre liste med høyere risiko:

• Hypervisorer og container-runtime-systemer som støtter virtualisert kjøring av operativsystemer og lignende miljøer
• Brannmurer, inntrengningsdeteksjons- og inntrengningsforhindringssystemer
• Manipulasjonssikre mikroprosessorer og mikrokontrollere

→ Tredjeparts samsvarsvurdering er obligatorisk i alle tilfeller (Art. 32(3)). Produsenter kan velge mellom Modul B+C (EU-typeundersøkelse fulgt av samsvar med type) eller Modul H (full kvalitetssikring), begge detaljert i Vedlegg VIII (Fortale 91).

Kritiske produkter (Vedlegg IV)

Endelig Vedlegg IV lister:

• Maskinvareenheter med sikkerhetsbokser
• Smartmåler-gatewayer innenfor smart-målesystemer og andre enheter for avanserte sikkerhetsformål, inkludert sikker kryptoprosesserring
• Smartkort eller lignende enheter, inkludert sikre elementer

→ Kommisjonen kan, ved delegert rettsakt, kreve at produsenter av kategorier av kritiske PDE-er får et europeisk cybersikkerhetssertifikat på sikkerhetsnivå «vesentlig» eller høyere under en ordning vedtatt i henhold til Forordning (EU) 2019/881 (Cybersecurity Act). Inntil en slik delegert rettsakt er vedtatt, følger kritiske produkter samme samsvarsvurderingsprosedyrer som Klasse II viktige produkter (Art. 8; Fortale 46–48).

To praktiske poenger:

• Klassifisering følger kjernefunksjonalitet, ikke innebygde funksjoner. En smarttelefon blir ikke omklassifisert som «passordbehandler» bare fordi den leveres med en; en app som integrerer en nettleser-motor er ikke et «nettleser-produkt» (Kommisjonens gjennomføringsforordning (EU) 2025/2392, Fortale 3–5 ).
• De tekniske beskrivelsene av hver Vedlegg III- og IV-kategori ble fastsatt ved Kommisjonens gjennomføringsforordning (EU) 2025/2392 av 28. november 2025 — den autoritative referansen hvis du argumenterer om grensetilfeller med et teknisk kontrollorgan.

Kryss av klassifiseringen din:

• Standard (residuell)
• Viktig Klasse I (Vedlegg III, Del I)
• Viktig Klasse II (Vedlegg III, Del II)
• Kritisk (Vedlegg IV)

Steg 5 — bekreft de essensielle cybersikkerhetskravene (Vedlegg I)

Når du vet at du er i omfang, er Vedlegg I hjertet av forpliktelsene. Det er delt i to deler.

Vedlegg I, Del I — produktegenskaper

Produsenter må sikre at PDE-en er designet, utviklet og produsert slik at den:

• Leveres uten kjente utnyttbare sårbarheter
• Leveres med en sikker-som-standard-konfigurasjon, inkludert evnen til å tilbakestille til opprinnelig tilstand
• Sikrer at sårbarheter kan håndteres gjennom sikkerhetsoppdateringer, inkludert, der det er aktuelt, automatiske oppdateringer som er tydelig varslet til brukere
• Gir beskyttelse mot uautorisert tilgang ved passende kontrollmekanismer (autentisering, identitets- eller tilgangsstyring)
• Beskytter konfidensialiteten av lagrede, overførte eller på annen måte behandlede data (f.eks. via topp-moderne kryptering)
• Beskytter integriteten av lagrede, overførte eller behandlede data og av programmer og konfigurasjon
• Behandler kun de dataene som er tilstrekkelige, relevante og begrenset til det som er nødvendig (dataminimering)
• Beskytter tilgjengeligheten av essensielle og grunnleggende funksjoner, inkludert mot tjenestenektangrep
• Minimerer sin egen negative innvirkning på tilgjengeligheten av tjenester levert av andre enheter/nettverk
• Er designet for å begrense angrepsflater, inkludert eksterne grensesnitt
• Er designet for å redusere virkningen av en hendelse gjennom passende utnyttings-avbøtende mekanismer
• Gir sikkerhetsrelatert informasjon ved å registrere og overvåke relevant intern aktivitet (med logger tilgjengelige for brukeren der det er passende)
• Gir muligheten for brukere til å sikkert og enkelt fjerne alle data og innstillinger og, der det er aktuelt, overføre dem til andre produkter

Vedlegg I, Del II — sårbarhetshåndtering

For varigheten av støtteperioden må produsenter:

• Identifisere og dokumentere sårbarheter og komponenter i produktet, inkludert ved å utarbeide en programvare-stykkliste (SBOM) i et vanlig brukt, maskinlesbart format som dekker minst toppnivå-avhengighetene
• Adressere og utbedre sårbarheter uten forsinkelse, inkludert ved å tilby sikkerhetsoppdateringer
• Anvende effektive og regelmessige tester og gjennomganger av produktets sikkerhet
• Når en sikkerhetsoppdatering er tilgjengelig, offentlig avsløre informasjon om utbedrede sårbarheter (beskrivelse, virkning, alvorlighet, utbedringstrinn)
• Innføre og håndheve en politikk for koordinert sårbarhetsavsløring (CVD)
• Iverksette tiltak for å fasilitere deling av informasjon om potensielle sårbarheter, inkludert ved å oppgi en kontaktadresse for rapportering
• Sikre at sikkerhetsoppdateringer distribueres gratis, med rådgivinger ved siden av, til rett tid

For industrielle produkter med digitale elementer (PLSer, RTUer, HMIer, industrielle svitsjer, SCADA-komponenter) er IEC 62443-4-1 og 4-2 den mest forsvarlige praktiske bevisruten for Vedlegg I. Produktsidens standarder IEC 62443-4-1 (sikker utviklingslivssyklus) og 4-2 (tekniske komponentkrav) er designet for å demonstrere nøyaktig de sikker-ved-design-, sårbarhetshåndterings- og oppdateringsstyringsforpliktelsene som Vedlegg I pålegger. ISASecure SDLA- og CSA-tredjepartssertifikater mot disse delene av 62443 er den slags bevis som et teknisk kontrollorgan eller en markedsovervåkings­myndighet kan lese direkte inn i Vedlegg I-strukturen. Systemnivå-standardene IEC 62443-3-2 og 3-3 utvider den samme bevismodellen til integrerte kontrollsystemer, og forvaltningssystem-standardene dekket i IEC 62443-2-x runder av den operasjonelle disiplinen som kreves for støtteperiodens sårbarhetshåndtering ovenfor.

Sjekkliste for produsenter:

• Jeg har en dokumentert cybersikkerhets-risikovurdering som begrunner hvilke Vedlegg I, Del I-krav som gjelder og hvordan hvert oppfylles (Art. 13(2); Fortale 54). Der et krav ikke gjelder, ligger begrunnelsen i den tekniske dokumentasjonen (Fortale 55).
• Jeg produserer en SBOM for hvert produkt i et vanlig brukt maskinlesbart format som dekker minst toppnivå-avhengigheter (Vedlegg I, Del II; Fortale 77).
• Jeg publiserer en politikk for koordinert sårbarhetsavsløring og driver et enkelt kontaktpunkt (Art. 13(18); Fortale 63).
• Sikkerhetsoppdateringer skilles fra funksjonalitetsoppdateringer der det er teknisk mulig (Fortale 57) og leveres gratis (Vedlegg I, Del II).

Steg 6 — fastsett støtteperioden (artikkel 13(8))

Under artikkel 13(8) må produsenten fastsette en støtteperiode som «reflekterer tiden produktet med digitale elementer forventes å være i bruk». Den støtteperioden:

• Må være minst fem år, med mindre produktets forventede levetid er kortere — i hvilket tilfelle støtteperioden tilsvarer den levetiden (Art. 13(8); Fortale 60 )
• Må ta hensyn til rimelige brukerforventninger, produktets art, og annet relevant unionslovverk om produktlevetider (Fortale 59)
• Må være transparent kommunisert til brukere på kjøpstidspunktet, inkludert sluttdato (måned og år) for støtteperioden (Art. 13(19); EK-sammendrag )
• Bør være lenger for produkter med naturlig lengre levetider — operativsystemer, rutere, hovedkort, mikroprosessorer, industrielle kontrollsystemer — der fem år ville være utilstrekkelig (Fortale 60)

ADCO (Administrative Cooperation Group av markedstilsynsmyndigheter) har myndighet til å publisere statistikk og veiledning om passende støtteperioder per kategori, og Kommisjonen kan vedta delegerte rettsakter som setter minimums-støtteperioder for spesifikke kategorier (Fortale 62).

Sjekkliste:

• Jeg har satt en støtteperiode på minst fem år, eller en kortere begrunnet levetid, og dokumentert begrunnelsen.
• Sluttdatoen vises til kjøperen på kjøpstidspunktet og i den medfølgende brukerinformasjonen (Vedlegg II).
• Sårbarhetshåndtering under Vedlegg I, Del II er ressurs-allokert for hele støtteperioden.

Steg 7 — rapporteringsforpliktelser under artikkel 14

Artikkel 14 er forpliktelsen som biter først — den gjelder fra 11. september 2026, mer enn et år før resten av forordningen, og den gjelder for alle PDE-er på markedet, inkludert de plassert før 11. desember 2027 (Art. 69(3); EK-sammendrag ).

Produsenter må varsle, samtidig, ENISA og CSIRT utpekt som koordinator om:

Aktivt utnyttede sårbarheter (Art. 14(2)–(3))

• Tidlig varsel — innen 24 timer etter at produsenten blir oppmerksom
• Sårbarhetsvarsling — innen 72 timer, med tilgjengelig informasjon inkludert, der det er aktuelt, korrigerende eller avbøtende tiltak
• Sluttrapport — ikke senere enn 14 dager etter at et korrigerende eller avbøtende tiltak er tilgjengelig

Alvorlige hendelser som påvirker produktsikkerhet (Art. 14(4)–(5))

• Tidlig varsel — innen 24 timer
• Hendelsesvarsling — innen 72 timer
• Sluttrapport — innen én måned etter 72-timers-innsendingen

Varslinger sendes inn via CRA Single Reporting Platform, etablert og drevet av ENISA (Art. 16; EK-sammendrag ).

Produsenter må også informere berørte brukere uten unødig forsinkelse om alvorlige hendelser, og der det er aktuelt om eventuelle korrigerende tiltak brukere kan bruke (Art. 14(8); Fortale 67).

Sjekkliste:

• Jeg vet hvilken medlemsstats-CSIRT som er min koordinator (typisk CSIRT-en til medlemsstaten for hovedetablering).
• Jeg har en hendelsesresponseprosess som kan oppdage, triage og rapportere innen 24 timer.
• SBOM-verktøyene mine kan raskt peke ut berørte produkter når en ny CVE dukker opp.
• Jeg har en kommunikasjonsmal klar for bruker-rettede varslinger.

Merknad om mikro- og småbedrifter. Produsenter som kvalifiserer som mikrobedrifter eller småbedrifter kan ikke bøtelegges for å bomme på 24-timers-fristen spesifikt (Art. 64(10)(a); EK-sammendrag ). Andre forpliktelser gjelder fortsatt.

Steg 8 — samsvarsvurdering, erklæring og CE-merking

Når de essensielle kravene er oppfylt, må produsenten kjøre riktig samsvarsvurderings-prosedyre (Art. 32 og Vedlegg VIII), utarbeide EU-samsvarserklæringen (Vedlegg V), oppbevare den tekniske dokumentasjonen (Vedlegg VII), og påføre CE-merkingen (Art. 30).

Prosedyrene fra Vedlegg VIII er basert på standardmodulene fra New Legislative Framework fra Beslutning nr. 768/2008/EF :

Dokumentasjons-sjekkliste:

• Teknisk dokumentasjon utarbeidet i tråd med Vedlegg VII: produktbeskrivelse, design og produksjon, anvendte krav, risikovurdering, liste over anvendte harmoniserte standarder/felles spesifikasjoner, testrapporter, samsvarsvurderings-rapporter, SBOM, sårbarhetshåndteringsprosedyrer. Oppbevart i minst 10 år etter at produktet er plassert på markedet eller for varigheten av støtteperioden hvis lengre (Art. 31).
• EU-samsvarserklæring utarbeidet per Vedlegg V (eller forenklet DoC per Vedlegg VI), som lister CRA og annen unions-harmoniseringslovgivning som gjelder.
• CE-merking påført synlig, leselig og uutslettelig på produktet, dets emballasje, eller den medfølgende dokumentasjonen i tilfelle programvare, per Art. 30.
• Informasjon og instruksjoner til brukeren per Vedlegg II følger med produktet, på et språk som lett forstås av brukere i den aktuelle medlemsstaten.

Fri og åpen kildekode-vri. Produsenter av viktige Klasse I- eller Klasse II-produkter som kvalifiserer som FOSS kan bruke den interne kontrollprosedyren (Modul A), forutsatt at de gjør den tekniske dokumentasjonen offentlig tilgjengelig (Art. 32(7); EK-sammendrag ).

Steg 9 — spesifikke forpliktelser for importør og distributør

Importør-forpliktelser (Artikkel 19)

Hvis du er en EU-etablert virksomhet som plasserer en ikke-EU-merket PDE på unionsmarkedet for første gang, lander Artikkel 19 rett på deg. Du må:

• Kun plassere samsvarende produkter på markedet — produkter som oppfyller Vedlegg I essensielle krav og der produsenten har oppfylt Art. 13-forpliktelsene (Art. 19(1)).
• Verifisere før produktet plasseres på markedet at:
  • Produsenten har gjennomført riktig samsvarsvurderings-prosedyre;
  • Produsenten har utarbeidet teknisk dokumentasjon;
  • Produktet bærer CE-merkingen;
  • Produktet følges av EU-samsvarserklæringen og informasjonen og instruksjonene krevd av Vedlegg II på et språk lett forstått av brukere i medlemsstaten der produktet plasseres.
• Angi på produktet, dets emballasje eller i medfølgende dokumenter ditt navn, registrert handelsnavn eller registrert varemerke og en postadresse, pluss en e-post eller digital kontaktpunkt (Art. 19(3)).
• Ikke plassere produktet på markedet hvis du har grunn til å tro at det ikke er i samsvar med CRA — og informere produsenten og relevante markedstilsynsmyndigheter (Art. 19(4)).
• Sikre lagrings- og transportforhold mens produktet er under ditt ansvar ikke setter samsvar med Vedlegg I i fare (Art. 19(5)).
• Informere produsenten og markedstilsynsmyndigheter hvis du blir oppmerksom på en sårbarhet, og samarbeide for å utbedre den (Art. 19(6)).
• Oppbevare en kopi av EU-samsvarserklæringen tilgjengelig for markedstilsynsmyndigheter i 10 år etter at produktet er plassert på markedet, eller for støtteperioden hvis lengre (Art. 19(8)).
• Samarbeide med markedstilsynsmyndigheter på enhver begrunnet forespørsel, på et språk de lett kan forstå (Art. 19(9)).

Distributør-forpliktelser (Artikkel 20)

Distributører må «handle med tilbørlig aktsomhet» i relasjon til CRA. I praksis krever Artikkel 20 at du:

• Verifiserer at produktet bærer CE-merkingen før du gjør det tilgjengelig på markedet.
• Verifiserer at produsent og importør har overholdt sine identifikasjons-, kontaktinformasjons- og dokumentasjonsforpliktelser (navn på produkt, medfølgende instruksjoner, støtteperiode-informasjon).
• Sikrer lagrings- og transportforhold under ditt ansvar ikke setter samsvar i fare.
• Ikke gjøre tilgjengelig noen PDE du har grunn til å tro er i strid med samsvar — og informere produsent/importør og myndigheter.
• Når du blir oppmerksom på en sårbarhet, informer produsenten og samarbeide for å sikre at produsenten tar korrigerende tiltak.
• På begrunnet forespørsel, gi markedstilsynsmyndigheten all informasjon og dokumentasjon i din besittelse.

En distributør eller importør som modifiserer produktet eller plasserer det på markedet under sitt eget navn blir effektivt produsent for det produktet, med hele Artikkel 13-stakken av forpliktelser (Art. 22).

Steg 10 — markedstilsyn og sanksjoner

Hver medlemsstat utpeker en eller flere markedstilsynsmyndigheter (MSA-er) for å håndheve CRA — disse kan være de samme myndighetene som er kompetente under NIS2 eller under radioutstyrsdirektivet (Fortale 107). Prosedyrereglene i Forordning (EU) 2019/1020 gjelder, supplert av Kapittel V i CRA (EK-sammendrag, Kapittel V ).

MSA-er kan:

• Kreve at aktører bringer et produkt i samsvar, begrense tilgjengelighet, trekke tilbake eller tilbakekalle det (Art. 54–57).
• Gjennomføre felles aktiviteter og «sveip» på tvers av medlemsstater (Fortale 114).
• Eskalere via en union safeguard-prosedyre når mangel på samsvar har grensekryssende implikasjoner (Fortale 110).

De finansielle sanksjonene under Artikkel 64 er bevisst satt på GDPR-lignende nivåer:

Kilde: Forordning (EU) 2024/2847, Artikkel 64

To unntak å kjenne:

• Mikrobedrifter og småbedrifter kan ikke bøtelegges spesifikt for å bomme på 24-timers tidlig-varsel-fristene i Artikkel 14 (Art. 64(10)(a)).
• Forvaltere av åpen kildekode-programvare er unntatt fra administrative bøter for ethvert CRA-brudd (Art. 64(10)(b); EK-sammendrag ).

I tillegg til bøter kan MSA-er bestille tilbaketrekning, tilbakekalling, eller forbud mot å gjøre produktet tilgjengelig — som for mange produsenter er den mer smertefulle konsekvensen.

Steg 11 — sentrale datoer og overgangsbestemmelser

CRAs tidslinje er trinnvis i Artikkel 71 og overgangsbestemmelsene i Artikkel 69:

Eldre produkter (Artikkel 69(2)–(3)):

• Produkter plassert på markedet før 11. desember 2027 er ikke retroaktivt underlagt hoveddelen av CRA-forpliktelser — med mindre de gjennomgår en vesentlig endring etter den datoen, i hvilket tilfelle de må vurderes på nytt (Art. 69(2); Fortale 38–39).
• Rapporteringsforpliktelser under Artikkel 14 gjelder for alle produkter i omfang på EU-markedet, inkludert eldre produkter, fra 11. september 2026 (Art. 69(3); EK-sammendrag ).

Vesentlig endring er definert funksjonelt: en programvare- eller maskinvareendring som modifiserer det tiltenkte formålet, endrer naturen av faren eller øker cybersikkerhetsrisikoen, og som ikke var forutsett i den opprinnelige risikovurderingen (Fortale 39). En sikkerhetsoppdatering som bare reduserer risiko uten å endre tiltenkt formål er ikke en vesentlig endring.

Fri og åpen kildekode-programvare: det spesielle regimet

CRAs behandling av FOSS er området der jurister og ingeniører oftest snubler. Tre regimer eksisterer side om side:

1. Utenfor omfang: ikke-kommersiell FOSS

FOSS som ikke er «gjort tilgjengelig på markedet» — dvs. ikke levert for distribusjon eller bruk i løpet av en kommersiell aktivitet — er utenfor omfang (Art. 2(1) lest med fortale 15–18).

Kommisjonens fortaler er eksplisitte på at:

• Bare finansiell støtte fra produsenter, eller bidrag til et FOSS-prosjekts utvikling, gjør ikke i seg selv prosjektet til en kommersiell aktivitet (Fortale 18).
• Tilstedeværelsen av regelmessige utgivelser gjør ikke i seg selv aktiviteten kommersiell (Fortale 18).
• FOSS av ideelle organisasjoner hvis inntekter (etter kostnader) brukes til ideelle mål er ikke en kommersiell aktivitet (Fortale 18).
• Enkeltpersoner som bidrar med kode til FOSS-prosjekter som ikke er under deres ansvar er ikke innenfor omfanget (Fortale 18).
• Selve handlingen å hoste kode på et repository, pakkebehandler eller samarbeidsplattform er ikke å «gjøre tilgjengelig på markedet» (Fortale 20).

2. «Forvalter av åpen kildekode-programvare»-regimet (Artikkel 24)

Et nytt konsept introdusert av CRA. En forvalter av åpen kildekode-programvare er en juridisk person, annet enn en produsent, som systematisk gir vedvarende støtte til utviklingen av spesifikke FOSS-produkter ment for kommersielle aktiviteter og sikrer levedyktigheten av disse produktene. Stiftelser og visse ideelle organer som styrer sentrale FOSS-prosjekter passer typisk her (EK-sammendrag ; Fortale 19).

Forvaltere møter et lett, skreddersydd regime under Artikkel 24:

• Ha en dokumentert cybersikkerhetspolitikk som fremmer sikker utvikling og effektiv sårbarhetshåndtering
• Samarbeide med markedstilsynsmyndigheter og iverksette korrigerende tiltak etter behov
• Varsle aktivt utnyttede sårbarheter (i den grad de er involvert i utviklingen) og alvorlige hendelser (i den grad de påvirker systemene brukt for utvikling)

Forvaltere CE-merker ikke produkter og er unntatt fra administrative bøter under Artikkel 64(10)(b).

3. Kommersiell aktivitet rundt FOSS utløser fulle produsent-forpliktelser

Hvis du monetiserer et FOSS-produkt — ved å ta betalt en pris (annet enn for å dekke faktiske kostnader), ved bevisst å trekke ut verdi gjennom buntede betalte tjenester, ved å kreve persondata-behandling for andre formål enn sikkerhet eller kompatibilitet, eller ved å integrere det i din egen monetiserte PDE — så er du en produsent for det produktet og hele Artikkel 13-stakken gjelder (Fortale 15–19).

Kommisjonen har forpliktet seg i Fortale 6 til å utstede veiledning spesifikt om hvordan CRA gjelder for FOSS, og Open Regulatory Compliance Working Group som er vert hos Eclipse Foundation produserer fellesskaps-utviklet materiale parallelt.

Praktiske tips for ikke-EU-produsenter

Hvis du har hovedkvarter utenfor EU og produktet ditt når unionsmarkedet — enten du sender det direkte, gjennom et datterselskap eller via en distributør — er dette punktene som feller den uvarsomme.

Utpek en autorisert representant (Artikkel 18)

Der det ikke er en EU-etablert importør for produktet ditt, eller der du rett og slett ønsker et klart juridisk kontaktpunkt i Unionen, kan du utpeke en autorisert representant ved skriftlig mandat (Art. 18). Mandatet må tillate representanten å:

• Oppbevare EU-samsvarserklæringen og teknisk dokumentasjon tilgjengelig for MSA-er i 10 år (eller støtteperioden hvis lengre)
• Samarbeide med MSA-er på enhver handling for å eliminere cybersikkerhetsrisikoer
• Si opp mandatet hvis produsenten handler i strid med sine CRA-forpliktelser, og informere MSA-ene

CRA tar uttrykkelig høyde for at den autoriserte representanten ikke er produsentens stedfortreder for produktdesign — Vedlegg I-forpliktelser forblir hos produsenten — men de er det formelle unions-grensesnittet.

Dokumentasjon på EU-språk

Informasjon og instruksjoner til brukeren (Vedlegg II) må gis på et språk som lett forstås av brukere i medlemsstaten der produktet plasseres på markedet. Importører og distributører er uttrykkelig pålagt å verifisere at dette er tilfellet før de plasserer eller gjør tilgjengelig produktet (Art. 19(2), 20). Planlegg oversettelser tidlig — de er en betydelig kostnadsdriver, spesielt for SMB-er (Fortale 94).

Enkelt kontaktpunkt for sårbarhetsrapportering

Artikkel 13 krever at produsenter utpeker et enkelt kontaktpunkt for brukere å rapportere sårbarheter, og gjøre det lett tilgjengelig (Fortale 63; Vedlegg I, Del II). For ikke-EU-produsenter er dette ofte der den autoriserte representanten kommer inn. Automatiserte verktøy alene er ikke tilstrekkelig — oppgi et telefonnummer, e-post eller kontaktskjema også.

Snakk med importørene og distributørene dine nå

Importører vil, fra 11. desember 2027, be om å se bevis på samsvarsvurderingen din, EU-DoC-en din og Vedlegg VII teknisk filen din før de lovlig kan plassere produktet ditt på markedet (Art. 19). Bygg den bevis-pakken inn i standard produktlanseringsprosessen din.

Samspill med annet EU-produktlovverk

CRA lever ikke i isolasjon. Kartlegg forpliktelsene dine på tvers av disse nabolands-regimene:

• Radioutstyrsdirektivet 2014/53/EU og Delegert forordning (EU) 2022/30 — Cybersikkerhets-essensielle krav for visse radioutstyr. Kommisjonen har signalisert at CRA dekker samme grunn; forvent at Delegert forordning 2022/30 endres eller oppheves i tråd med CRA-overgangen (Fortale 30).
• NIS2-direktivet (EU) 2022/2555 — Operatør-siden cybersikkerhet for essensielle og viktige enheter. Hvis kundene dine er NIS2-regulerte, vil deres leverandørkjede-sikkerhets-forpliktelser (Art. 21(2)(d) NIS2) føre kontraktsmessige cybersikkerhetskrav tilbake til deg. IKT-produktsikkerhet på operatør-siden kan kreve strengere krav enn CRAs grunnlinje (Fortale 13). Enhets-siden-gjennomgangen er i Gjelder NIS2 for ditt EU-prosjekt? .
• AI Act — Forordning (EU) 2024/1689 — For PDE-er som også er høyrisiko-AI-systemer, anses Artikkel 15 i AI Acts cybersikkerhetskrav for oppfylt der CRAs essensielle krav er oppfylt, med samsvarsvurderingen under AI Act Artikkel 43 som hovedregel (Fortale 51).
• GDPR — Forordning (EU) 2016/679 — Der produkter behandler persondata, gjelder GDPR parallelt. Vedlegg I, Del I inkluderer dataminimeringskrav som overlapper med GDPRs databeskyttelse ved design og som standard (Fortale 32).
• Maskindirektivet (EU) 2023/1230 — Tilkoblet maskineri må oppfylle begge regimer. Kommisjonen og europeiske standardiseringsorganisasjoner jobber for å samkjøre harmoniserte standarder på tvers av begge (Fortale 53).
• MDR/IVDR (Forordning 2017/745 og 2017/746 ) — Medisinsk utstyr og IVD-er er utenfor omfanget av CRA, men MDR/IVDR-essensielle krav dekker allerede cybersikkerhet (Fortale 25).
• Typegodkjenningsregimer (motorvogner, luftfart, marint) — Som dekket i Steg 2.
• Produktansvars-direktivet (EU) 2024/2853 — Objektivt ansvar for skader forårsaket av mangel på sikkerhet, inkludert sikkerhetsoppdateringer. CRA-forpliktelser definerer effektivt gulvet for hva «trygt» betyr for digitale produkter (Fortale 31).

Nylige utviklinger å følge med på i 2026

• Kommisjonens gjennomføringsforordning (EU) 2025/2392 av 28. november 2025 fastsatte de tekniske beskrivelsene av Vedlegg III- og Vedlegg IV-produktkategoriene, og fjernet mye av den tidlige tvetydigheten om hva som teller som en «nettleser» eller et «smart-hjem-produkt med sikkerhetsfunksjonalitet» (EUR-Lex ; EK-sammendrag ).
• Kommisjonens delegerte forordning (EU) 2025/1535 av 29. juli 2025 unntok visse L-kategori-kjøretøy (under Forordning (EU) 168/2013) fra CRA-omfang (EUR-Lex ).
• Kommisjonen publiserte en arbeids CRA implementerings-FAQ i desember 2025 (lenket fra EK CRA-sammendragssiden ).
• Harmoniserte standarder produseres under en standardiseringsforespørsel til CEN-CENELEC JTC 13 og ETSI, med de første leveransene forventet i Q3 2026 i forkant av anvendelsesdatoen i desember 2027. Følg med på Den europeiske unions tidende for henvisninger — inntil disse referansene er publisert, vil produsenter av Klasse I viktige produkter ikke kunne stole på en presumsjon om samsvar via standarder alene (Fortale 80).
• ENISA bygger CRA Single Reporting Platform som vil være det enkle varslings-endepunktet for Artikkel 14-fristene fra 11. september 2026 (EK-sammendrag, Kapittel II ).
• Produsenter bør også følge NANDO-databasen for progressiv varsling av CRA-tekniske kontrollorganer, som medlemsstater er pålagt å utpeke fra 11. juni 2026 og fremover.

En konsolidert sjekkliste

Skriv ut. Heng på veggen.

• Steg 1: Bekreftet at produktet er en PDE (Art. 3(1)) — programvare/maskinvare med tiltenkt eller rimelig forutsigbar direkte eller indirekte datatilkobling.
• Steg 2: Sjekket alle Art. 2-unntak (MDR/IVDR, motorvogner, luftfart, marint, forsvar, klassifisert, kvalifiserende reservedeler).
• Steg 3: Identifisert rollen(e) mine: produsent / autorisert representant / importør / distributør (Art. 3(13)–(16)).
• Steg 4: Klassifisert produktet mot Vedlegg III/IV ved bruk av kjernefunksjonalitet og Gjennomføringsforordning (EU) 2025/2392.
• Steg 5: Kartlagt Vedlegg I, Del I & II til produktet, med en dokumentert risikovurdering.
• Steg 6: Satt en støtteperiode på minst 5 år (eller begrunnet kortere levetid) per Art. 13(8); sluttdato synlig for kjøpere.
• Steg 7: Bygget Artikkel 14-rapporteringsarbeidsflyt (24t / 72t / 14d / 1 måned) — klar innen 11. september 2026.
• Steg 8: Kjørt riktig Vedlegg VIII-modul; utarbeidet Vedlegg V DoC og Vedlegg VII teknisk dokumentasjon; påført CE-merking per Art. 30.
• Steg 9 (importører): Alle Art. 19 verifiserings-, identifikasjons- og samarbeidsplikter oppfylt. (Distributører: Art. 20 aktsomhetsplikter oppfylt.)
• Steg 10: Risiko-vurdert bot-eksponering under Art. 64 og modellert det mot verdensomspennende omsetning.
• Steg 11: Plottet Art. 71-datoer inn i produktveikartet (11. juni 2026, 11. september 2026, 11. desember 2027); identifisert eldre SKU-er og utløsere for vesentlig endring.

Hvis hver boks er krysset av med støttende bevis på fil, er du CRA-klar — og du kan bevise det. Og hvis organisasjonen din (heller enn bare produktlinjen) driver tjenester som kan falle under NIS2, jobb gjennom enhets-siden-sjekklisten neste: Gjelder NIS2 for ditt EU-prosjekt? .