Tre misforståelser er ved at sætte sig fast i CRA-forberedelserne på tværs af europæiske virksomheder. De er forståelige, men de er forkerte. Og hvis du bygger din produktstrategi på dem, risikerer du at stå over for en markedsovervågningsmyndighed med en supportdeklaration, der ikke holder.
I dette blogindlæg går vi de tre udbredte misforståelser igennem og fortæller præcis, hvad supportkravene i CRA faktisk betyder.
De tre misforståelser ser sådan ud:
Vi tager dem én ad gangen, så frem med notesblokken.
Det er den nok mest udbredte misforståelse. Virksomheder deklarerer fem år, planlægger sikkerhedsopdateringer i fem år, og betragter sig som compliant. Men Article 13(8) sætter fem år som en minimumsgrænse – en sikkerhedsventil for produkter med kortere forventet brugstid.
Den gælder altså ikke alle produkter, hvilket vejledningen også understreger:
"A support period of five years is therefore not to be considered as the default for all products with digital elements."
I virkeligheden bygger reglen på en enkel logik, nemlig at supportperioden skal afspejle produktets forventede brugstid – ikke en abstrakt eller tilfældig periode, men den forventede brugstid.
Producerer du eksempelvis industrielt udstyr, embedded-løsninger til infrastruktur eller medicinsk teknologi, er den realistiske brugstid nærmere 10-15 år. Og så er din supportperiode ifølge CRA også 10-15 år.
Det er en større forpligtelse end mange måske har indregnet – men ikke desto mindre er det, hvad CRA faktisk kræver.
Frygten for at skulle gentage hele overensstemmelsesvurderingen ved hver større softwareopdatering er reel. Men vejledningen er langt mere proportional end de fleste forestiller sig.
For softwareopdateringer gælder en risikobaseret vurdering: introducerer opdateringen nye trusselvektorer, muliggør den nye angrebsscenarier, eller ændrer den sandsynligheden eller konsekvensen af kendte trusler?
Er svaret nej – og holder de eksisterende risikovurderinger stadig – er der sandsynligvis slet ikke tale om en væsentlig ændring.
Er der tale om en væsentlig ændring, kan du genbruge al eksisterende dokumentation og alle testresultater for de uberørte dele af produktet. Vurderingen fokuserer på det, der faktisk er ændret. Du skal udstede en ny overensstemmelseserklæring – men det er ikke en fuldstændig omstart.
Det skel er afgørende i praksis: En fuldstændig ommer ville gøre hurtig respons på sårbarheder uholdbart dyr og langsom. Proportionalitetsprincippet er designet til at sikre, at producenter faktisk kan handle hurtigt, når det er nødvendigt.
Den er måske den mest kontraintuitive. Udgangspunktet er, at en væsentlig ændring behandles som et nyt produkt under CRA – og mange drager derfra den konklusion, at supporturet starter forfra.
Det gør det ikke automatisk. Ifølge vejledningen nulstilles supportperioden kun, hvis den væsentlige ændring rent faktisk gælder de faktorer, der i sin tid bestemte produktets forventede brugstid.
En ny softwarefunktion på en industriel controller lever så længe hardwaren holder – og den ændring rykker ikke ved brugernes forventninger til produktets brugstid. Supportperioden løber videre fra det punkt, den er nået til.
Helt konkret betyder det, at hvis der er to år tilbage af supportperioden, når du laver en væsentlig softwareændring, som ikke berører brugstidsfaktorerne, er der to år tilbage bagefter. Minimumsgrænsen på fem år gælder for den oprindelige fastsættelse, og det påvirker ikke restsupporten.
De tre misforståelser opstår, fordi CRAs supportkrav er formuleret med en proportionalitet og kontekstafhængighed, som ikke fremgår af en overfladisk læsning af loven.
Det korrekte svar på "hvor lang er vores supportperiode" kræver en analyse af produktets faktiske livscyklus.
Det korrekte svar på "kræver denne opdatering en ny vurdering" er løbende dokumentation for, hvad der er ændret, og hvad der ikke er.
Ingen af delene er uoverkommelige, men begge kræver, at arbejdet er gjort på forhånd. Når en myndighed beder om dokumentationen, eller I skal vurdere, om næste opdatering udløser nye compliancekrav, er det for sent.
Hos NorthGRC hjælper vi producenter med præcis det: både den rådgivning, der afklarer, hvad CRA faktisk kræver af jeres produkt, og den platform, der sikrer, at dokumentationen er i orden, når den skal bruges.
Continuous delivery-modellen er nævnt direkte i vejledningen. Du kan koncentrere din aktive sårbarhedsafhjælpning om den seneste version. Dog kun såfremt brugerne kan opgradere gratis, og uden at det kræver ny hardware eller fundamentale infrastrukturændringer.
Det giver mening for en SaaS-model, men det fjerner ikke alle forpligtelser: koordineret sårbarhedsafsløring og rapporteringsforpligtelserne gælder fortsat for alle versioner under supportperioden.