CRA för startups: efterlevnad med en enda ingenjör

Du levererar en uppkopplad produkt med ett litet team, och cyberresiliensförordningen kommer att omfatta den. Huvudskyldigheterna gäller från 11 december 2027, med sårbarhetsrapportering redan från 11 september 2026, så det här är något du bygger in nu, inte något du skjuter upp till senare. Två saker fångar startups på sängen: den fleråriga supportplikten för säkerhet som du tar på dig i samma stund du släpper ut produkten på EU-marknaden, och att klara allt det utan en dedikerad säkerhetsanställd.

Den här guiden är för grundare och tidiga ingenjörer som behöver bli CRA-efterlevande utan att spendera för mycket eller bygga för mycket. Den går igenom vad du säkert kan hoppa över, vad du inte kan, och hur en enda person kan äga hela ansvaret.

Gäller CRA ens din startup?

Gör fyra snabba kontroller. CRA omfattar produkter med digitala element som ansluter till ett nätverk eller en annan enhet och som tillhandahålls på EU-marknaden som en del av en kommersiell verksamhet.

Om din produkt omfattas är nästa fråga vilken kategori den hamnar i. Det avgör om du självbedömer eller behöver ett anmält organ. Bekräfta det med guiden för produktklassificering innan du lägger en enda dag på något annat.

Din enda strukturella fördel: självbedömning

Den enskilt största besparingen för en startup är att en produkt utanför kategorierna Viktig och Kritisk räknas som en Standardprodukt. För dessa låter CRA dig självbedöma: du gör arbetet med överensstämmelse själv, undertecknar EU-försäkran om överensstämmelse och sätter på CE-märkningen. Inget externt organ, ingen avgift per produkt. Mekaniken bakom varje väg finns i guiden för bedömning av överensstämmelse. Poängen för en startup är att inte betala för tredjepartsbedömning du inte behöver.

Viktigt: Självbedömning är inte lättare efterlevnad. Du uppfyller samma väsentliga säkerhetskrav som alla andra. Du intygar dem bara själv i stället för att betala någon annan för att göra det.

Lättnaderna som CRA byggt in för startups

CRA innehåller stödåtgärder skrivna specifikt för mikroföretag, små och medelstora företag och startups. Om lättnaderna gäller dig beror på din storlek, enligt EU:s standarddefinition: ett mikroföretag har färre än 10 anställda och en omsättning eller balansomslutning på högst 2 miljoner euro, och ett litet företag har färre än 50 anställda och en omsättning eller balansomslutning på högst 10 miljoner euro.

Fyra lättnader en startup faktiskt kan använda:

• Förenklad dokumentation: mikroföretag och små företag får lämna in den tekniska dokumentationen i ett förenklat format som kommissionen anger, och anmälda organ måste acceptera det formatet.
• Reducerade avgifter för bedömning av överensstämmelse: där din produkt väl behöver ett anmält organ ska de särskilda behoven hos små och medelstora företag, inklusive startups, beaktas och avgifterna sänkas proportionerligt.
• Regulatoriska sandlådor: medlemsstaterna får inrätta kontrollerade miljöer där du utvecklar och testar en innovativ produkt mot CRA innan du släpper ut den på marknaden, med underlättad tillgång för startups.
• Direkt stöd: där det är lämpligt driver medlemsstaterna informations- och utbildningsinsatser och en dedikerad rådgivningskanal för mindre företag, och kommissionen hänvisar till tillgängligt finansiellt stöd.

Tips: Fråga din nationella marknadskontrollmyndighet eller digitala innovationshubb om det förenklade dokumentationsformatet och en regulatorisk sandlåda redan är på plats i ditt land. Båda beror på nationellt och kommissionens genomförande, så tillgången varierar.

Uppnå efterlevnad med en enda ingenjör

Du behöver inget säkerhetsteam. Du behöver en ansvarig ägare och en kort lista med saker som körs automatiskt. Den personen underhåller den tekniska filen, triagerar inkommande sårbarhetsrapporter och undertecknar försäkran om överensstämmelse. En person kan hålla i rollen, men var ärlig med att den löpande sårbarhetshanteringen, uppdateringsleveransen och dokumentationen är verkligt ingenjörsarbete. Guiden för CRA-efterlevnadskostnader modellerar insatsen och budgeten för ett litet team så att du kan planera bemanningen ordentligt.

Tre saker är värda att automatisera först. Vart och ett är ett löst problem med gratisverktyg, och tillsammans täcker de dina mest synliga tidiga skyldigheter. De är en utgångspunkt, inte hela bilden.

• Generera en SBOM i CI: CRA kräver en materialförteckning för programvara (SBOM) som täcker åtminstone dina toppnivåberoenden, och verktyg med öppen källkod som Syft och Trivy producerar en vid varje bygge. Fullständig verktygskedja i SBOM-genereringsguiden.
• Bevaka sårbarheter: skanna dina beroenden vid varje bygge och agera på fynd utifrån risk innan de når kunderna. CRA bryr sig om att du triagerar och åtgärdar, inte vilken skanner du kör.
• Publicera en säkerhetskontakt: en security.txt-fil och en fungerande säkerhetsadress ger forskare ett sätt att rapportera. Guiden för att sätta upp security.txt har en färdig mall.

De tre är tidiga automatiseringsvinster, inte hela jobbet. Säker design, riskbedömning, uppdateringsleverans och produktkontrollerna finns vid sidan av dem. Din tekniska dokumentation växer med produkten i stället för i en stressig period före lansering, så håll arkitektur- och säkerhetsanteckningar löpande. Det obligatoriska innehållet finns i guiden för teknisk dokumentation.

Din process för sårbarhetshantering måste vara på plats innan rapporteringsskyldigheterna börjar gälla den 11 september 2026. Från och med det datumet startar en aktivt utnyttjad sårbarhet eller en allvarlig incident en snäv klocka via ENISA:s gemensamma rapporteringsplattform: en tidig varning inom 24 timmar, följt av en fylligare anmälan inom 72 timmar. Slutrapporten skiljer sig åt beroende på spår. För en aktivt utnyttjad sårbarhet ska den lämnas inom 14 dagar efter att en korrigerande eller lindrande åtgärd blivit tillgänglig. För en allvarlig incident ska den lämnas inom en månad efter 72-timmarsanmälan. Du måste också informera berörda användare. Mekaniken finns i guiden för sårbarhetsrapportering.

Du kan leverera snabbt utan att omcertifiera varje release

Att iterera snabbt betyder inte att du kör om bedömningen av överensstämmelse varje sprint. Du behöver bara ta upp överensstämmelsen igen efter en väsentlig ändring, det vill säga en förändring efter lansering som påverkar produktens överensstämmelse med de väsentliga säkerhetskraven, eller som ändrar det avsedda ändamål produkten bedömdes mot. En säkerhetsuppdatering som enbart minskar cybersäkerhetsrisken utan att ändra det avsedda ändamålet är generellt inte en väsentlig ändring, och en mindre förändring som att lägga till ett nytt UI-språk är det i regel inte heller. En funktionsuppdatering som breddar attackytan eller ändrar vad produkten gör kan vara det. Så rutinmässiga patchar och små uppdateringar levereras utan ny bedömning, och du bedömer om igen när en förändring på riktigt ändrar vad produkten är eller dess riskprofil.

Om du bygger på eller förvaltar öppen källkod

Två fakta om öppen källkod spelar roll för en startup. För det första omfattas fri och öppen programvara bara när den tillhandahålls som en del av en kommersiell verksamhet. Programvara som dess underhållare inte tjänar pengar på räknas i regel inte som kommersiell verksamhet, men monetisering är bredare än att ta betalt för koden, så väg in betald support och liknande arrangemang. Att bidra med källkod till ett projekt som inte ligger under ditt ansvar gör inte att CRA blir tillämplig på dig. Att monetisera öppen källkod, eller leverera den inuti en produkt du säljer, för in den produkten i tillämpningsområdet som vanligt.

För det andra skapar CRA en lättare roll kallad förvaltare av öppen programvara (open-source software steward) för en organisation, annan än en tillverkare, som upprätthåller utvecklingen av öppen programvara avsedd för kommersiellt bruk. En förvaltares skyldigheter kretsar kring en dokumenterad cybersäkerhetspolicy och samarbete med myndigheter. Sårbarhetsrapportering gäller i den utsträckning förvaltaren är involverad i produktens utveckling, och rapportering av allvarliga incidenter samt användarnotifiering gäller där en incident påverkar de system förvaltaren tillhandahåller för den utvecklingen. Dessa skyldigheter är lättare än hela uppsättningen tillverkarskyldigheter. Om din startup både förvaltar ett projekt och säljer en produkt, var tydlig med vilken hatt du bär för vilken aktivitet, eftersom skyldigheterna skiljer sig åt.

Den femåriga supportplikten är ett affärsmodellsproblem

Det här är den delen av CRA som en startup inte kan lösa med enbart verktyg. Supportperioden måste vara minst fem år, och om produkten förväntas användas kortare tid än fem år matchar perioden i stället den kortare förväntade användningstiden. Under den perioden hanterar du sårbarheter utifrån risk, åtgärdar dem utan dröjsmål och levererar uppdateringarna till kunderna.

För ett tidigt bolag är det ett verkligt åtagande, inte en bock i rutan:

• Plikten följer produkten: den knyts till produkten när du först släpper ut den på EU-marknaden, och en senare pivotering avslutar den inte för enheter som redan är utsläppta.
• Den måste prissättas in: om din marginal inte bär supportperioden är priset fel. Modellera supportkostnaden in i din enhetsekonomi före lansering, och räkna med att den avtar allteftersom kodbasen stabiliseras.
• Planera för tio år, inte fem: varje säkerhetsuppdatering du ger ut måste förbli tillgänglig i minst 10 år efter lansering, eller under resten av supportperioden, beroende på vilket som är längst.
• Publicera slutdatumet: du måste visa supportperiodens slutdatum, åtminstone månad och år, vid köptillfället. Sätt det medvetet, för kunder och köpare kommer att läsa det.

Du kan göra åtagandet mer hanterbart, men var uppmärksam på vad som faktiskt fritar dig från det:

• Välj stabila beroenden: varje snabbrörligt bibliotek du drar in är år av underhåll du skrivit på för. Föredra tråkiga, väl underhållna komponenter.
• Versionera medvetet: definiera produktgenerationer och planera hur supporten går över mellan dem, så att du inte underhåller en obegränsad mängd aktiva versioner.
• Riskbegränsande åtgärder fritar dig inte från plikten: en skriftlig överföring av supportansvaret till en förvärvare, ett escrow-arrangemang eller att öppna upp de säkerhetskritiska komponenterna som öppen källkod kan hålla korrigeringar flödande, men ingen av dem tar i sig bort din skyldighet.

Om du lägger ner verksamheten och inte längre kan efterleva kraven måste du informera marknadskontrollmyndigheterna och, i den mån det är möjligt, dina användare innan nedläggningen träder i kraft. Vad som händer med den kvarvarande plikten när företaget inte längre existerar är inte klart avgjort och beror på jurisdiktion. Planera avvecklingsvägen nu, medan du fortfarande kan, och dokumentera den i den tekniska filen.

Gör efterlevnad till en försäljnings- och finansieringstillgång

För en startup kan CRA-arbetet göra dubbel nytta: det öppnar EU-marknaden, och det ger dig bevis att lämna över till en företagskund eller en investerare.

Bygg due diligence-paketet en gång. EU:s upphandlingsteam kan under leverantörsgranskningen be om en aktuell SBOM, en undertecknad försäkran om överensstämmelse och en dokumenterad process för sårbarhetsrapportering med en svarstid. Det här är starka bevis snarare än bevis på fullständig efterlevnad, eftersom beredskapen i slutändan vilar på att uppfylla varje väsentligt säkerhetskrav. Men att ha allt samlat på ett ställe sparar dig från att skrapa ihop bevisen senare, och det är samma paket en investerares tekniska granskning kan be om att få se.

Investerare bryr sig om att du kan leverera lagligt. Att bryta mot de väsentliga säkerhetskraven eller tillverkarens kärnskyldigheter medför administrativa böter på upp till 15 miljoner euro eller 2,5 procent av den totala globala årsomsättningen, beroende på vilket som är högst. Mer konkret måste en produkt som släpps ut på EU-marknaden från och med den 11 december 2027 uppfylla CRA för att få säljas där. Att rama in efterlevnad som marknadstillträde och en riskreducerad EU-etablering landar bättre hos en styrelse än att rama in det som en kostnad.

Offentliga program kan finansiera en del av arbetet. EU-instrument som Horizon Europe, Digital Europe Programme och EIC Accelerator stöder cybersäkerhet och utveckling av säkra produkter, och nationella program bidrar med mer. Belopp och behörighet varierar, så kontrollera din nationella digitala innovationshubb för vad som är öppet. Rama in ansökan kring att bygga pålitliga, säkra digitala produkter snarare än kring att bocka av ett regulatoriskt krav.

Om säkerhetscertifieringar kommer upp i säljprocessen, förstå var CRA står i förhållande till dem. Överlappet med ett ledningssystem för informationssäkerhet (ISMS) täcks i guiden CRA vs ISO 27001, och team som jobbar med konsument-IoT bör läsa guiden om EN 303 645.

Vanliga startupmisstag

• ”Vi tar tag i säkerheten efter finansieringsrundan”: med begränsad runway bränner efterhandsinstallerad säkerhet upp kapitalet du just tog in. Bygg in grunderna från första sprinten.
• ”Vi prissatte produkten utan supportplikten”: flerårigt säkerhetsunderhåll måste rymmas inom din enhetsekonomi. Gör det inte det, är priset fel.
• ”Vår efterlevnadsansvariga slutade och ingen tog över”: om en enda person håller i den tekniska filen och rapporteringsprocessen blir deras avgång ett hål i efterlevnaden. Skriv ner vem som äger ansvaret.
• ”Förvärvaren tar väl över plikten”: en affär kan tilldela supportarbetet, men det lyfter inte i sig den lagstadgade plikten från dig. Reglera det uttryckligen i villkoren, och anta ingenting.
• ”Vi löser CRA när vi expanderar till EU”: om EU-användare redan kan nå din produkt tillhandahåller du redan EU-marknaden, och att montera på efterlevnad i efterhand blir en ombyggnad. Designa för 2027-skyldigheterna från start.
• ”Vi är för tidiga i vår fas för att omfattas”: att vara en startup ger dig lättnader, inte ett undantag. Plikten knyts till produkten vid första utsläppandet på marknaden oavsett var du befinner dig i din resa.