Sikkerhet var noe en kjøper spurte om. I Europa er det i ferd med å bli noe produktet selv må bære. Cyber Resilience Act er forordning (EU) 2024/2847, vedtatt 23. oktober 2024, og den setter krav til cybersikkerhet for produkter med digitale elementer som selges i EU. Er produktet ditt ett av dem, er teksten verdt å lese før noen oppsummerer den for deg.
Dette er ikke juridisk rådgivning, og ingenting her sier om produktet ditt oppfyller loven. Den vurderingen hører til deg og rådgiverne dine. Det som følger, er hva teksten sier, forklart enkelt, med kilden lenket så du kan lese den selv.
Det er en forordning, og deler av den gjelder allerede
Ulikt et direktiv gjelder en forordning direkte i hver medlemsstat. Etter artikkel 71 trådte den i kraft 10. desember 2024, og den gjelder i tre trinn:
- fra 11. juni 2026, reglene om melding av organene som vurderer samsvar (kapittel IV);
- fra 11. september 2026, rapporteringspliktene i artikkel 14;
- fra 11. desember 2027, alt annet.
Så den dagen dette essayet publiseres, gjelder de to første trinnene allerede. Rapporteringspliktene gjelder; produktkravene gjør det ennå ikke.
Artikkel 69 legger til en overgangsregel som betyr noe for alt som allerede er i salg. Et produkt som er brakt i omsetning før 11. desember 2027, faller inn under kravene bare hvis det endres vesentlig fra den datoen. Rapporteringspliktene i artikkel 14 er annerledes: de gjelder også for produkter innenfor virkeområdet som ble brakt i omsetning før den datoen.
Hva som regnes som et produkt med digitale elementer
Ikke all programvare er omfattet, og grensen er verdt å få helt riktig.
Artikkel 3 definerer et produkt med digitale elementer som et programvare- eller maskinvareprodukt og løsningene for fjernbehandling av data som hører til det, inkludert komponenter som bringes i omsetning hver for seg. Artikkel 2 snevrer det inn til produkter der tiltenkt formål eller rimelig forutsigbar bruk omfatter en datatilkobling til en enhet eller et nettverk.
Skydelen er smalere enn den høres ut. Artikkel 3 regner fjernbehandling av data med bare der produsenten utformer den, eller får den utformet, og der produktet ikke kunne utført en av funksjonene sine uten den. Fortalepunkt 12 sier rett ut hva det betyr: nettsteder som ikke støtter funksjonaliteten til et produkt med digitale elementer, og skytjenester som er utformet utenfor en produsents ansvar, faller utenfor forordningen. Der en tjeneste er fjernbehandlingen av data bak en app eller en enhet du lager, kan svaret bli et annet, så sjekk hver del for seg.
Artikkel 2 holder også utenfor produkter som allerede er omfattet av egne sektorregler, som medisinsk utstyr, motorvogner og visse produkter for sivil luftfart. Om produktet ditt ligger innenfor grensen, er det første spørsmålet til rådgiverne dine.
Hva den krever av et produkt
Den krever to ting: at produktet er sikkert fra utformingen av, og at produsenten holder det slik.
Det første er vedlegg I, del I, som artikkel 6 gjør til vilkåret for i det hele tatt å være på markedet. Et produkt må gjøres tilgjengelig uten kjente sårbarheter som kan utnyttes, og med en sikker standardkonfigurasjon. Det må beskytte mot uautorisert tilgang, beskytte konfidensialiteten og integriteten til dataene det håndterer, behandle bare de dataene det trenger, og gjøre det mulig å håndtere sårbarheter gjennom sikkerhetsoppdateringer.
Det andre er vedlegg I, del II, om håndtering av sårbarheter. Det krever at produsenten identifiserer og dokumenterer produktets komponenter, inkludert en programvarestykkliste (software bill of materials) som minst dekker avhengighetene på øverste nivå. Det krever at sårbarheter håndteres og utbedres uten opphold, at sikkerhetsoppdateringer distribueres på en sikker måte, og at det finnes en policy for koordinert offentliggjøring av sårbarheter, med en adresse der sårbarheter kan meldes.
Artikkel 13 gjør dette om til produsentens plikter. Den krever en vurdering av cybersikkerhetsrisiko, oppbevart sammen med den tekniske dokumentasjonen. Den setter også en støtteperiode der sårbarheter håndteres: minst fem år, med mindre produktet ventes å være i bruk kortere, og med sluttdatoen gjort tydelig for brukeren ved kjøpet.
Det som gjelder allerede: rapportering
Artikkel 14 krever at en produsent rapporterer enhver aktivt utnyttet sårbarhet i produktet sitt, og enhver alvorlig hendelse som påvirker produktets sikkerhet, gjennom én felles rapporteringsplattform. Artikkelen beskriver trinnene: et tidlig varsel innen 24 timer etter at produsenten ble kjent med det, en fyldigere melding innen 72 timer, og en endelig rapport senere. Den krever også at produsenten informerer brukerne som er berørt.
Disse fristene måles i timer, og det gjør rapportering mer til et spørsmål om hvem som vet hva, og hvor raskt, enn et spørsmål om papirarbeid.
Hvordan et produkt viser at det oppfyller kravene
Veien avhenger av produktets klasse. Etter artikkel 32 kan en produsent av et produkt som verken er viktig eller kritisk, vurdere samsvar selv gjennom intern kontroll. Produkter som er oppført som viktige i vedlegg III, etter artikkel 7, eller som kritiske i vedlegg IV, etter artikkel 8, møter strengere veier, noen av dem gjennom en tredjepart.
Uansett blir resultatet teknisk dokumentasjon (artikkel 31), en EU-samsvarserklæring (artikkel 28) og CE-merkingen (artikkel 30). Etter artikkel 64 kan brudd på de grunnleggende kravene eller pliktene i artikkel 13 og 14 gi bøter på opptil 15 millioner euro eller 2,5 % av samlet årlig omsetning på verdensbasis, avhengig av hva som er høyest.
Hva dette betyr for veikartet
Teksten leses som et etterlevelsesprosjekt. For et produkt oppfører den seg mer som en vane du enten holder eller mister med hver lansering.
Vit hva som er inni produktet ditt. En liste over komponenter og avhengigheter er starten på alt det andre. Det er også det første du trenger når en ny sårbarhet blir kjent og noen spør om dere er berørt.
Gjør den sikre innstillingen til standard. Standardvalg avgjør hva de fleste brukere lever med. Et produkt som leveres låst og lar folk åpne det, er et annet produkt enn ett som leveres åpent og håper de lukker det.
Bestem hvor lenge du skal støtte hver versjon. En støtteperiode er en produktbeslutning med en kostnad. Ta den med vilje, skriv den ned, og fortell brukerne dine.
Avklar hvem som rapporterer, og til hvem. Rapportering gjelder allerede for produkter innenfor virkeområdet. Bli enige internt om hvem som avgjør at noe må rapporteres, og hvem som sender det.
Still rådgiverne dine de juridiske spørsmålene tidlig. Virkeområde, produktklasser og veien til samsvar er deres å svare på. Du tar bedre veikartvalg når du kjenner svaret deres, enn mens du gjetter det.
Ikke noe av dette trenger å fylle hvert møte. Avgjør det, hold kursen, og du kan løfte blikket fra artikkelnumrene til produktet kundene dine stoler på.
Der vi kommer inn
Vi gir ikke juridisk rådgivning, vi lover aldri etterlevelse, og vi sier ikke når du vil være klar. Den vurderingen blir hos deg og rådgiverne dine.
Det vi kan gjøre, er sikkerhetsarbeidet på produktet ditt som du velger, beskrevet i Harden security before the questionnaire arrives (på engelsk). Vi arbeider innenfor tilgangen du gir, og ikke noe mer. Arbeidet havner i ditt eget kodelager. Koden vi bygger for deg, er din. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning.
Det starter med en samtale, helt uforpliktende.
