I de flesta efterlevnadskalendrar anges att lagen om cyberresiliens träder i kraft i december 2027. Det är då förordningens centrala bestämmelser börjar gälla: inbyggd säkerhet, teknisk dokumentation, bedömning av överensstämmelse och CE-märkning.
Rapporteringsskyldigheterna träder dock i kraft betydligt tidigare. Från och med den 11 september 2026 måste tillverkare av produkter med digitala komponenter anmäla aktivt utnyttjade sårbarheter och allvarliga incidenter inom fastställda tidsramar, och dessa skyldigheter gäller även produkter som redan har släppts ut på EU-marknaden. En produkt som först levererades 2018 och fortfarande säljs idag omfattas av bestämmelserna från dag ett.
För tillverkarna innebär detta en 24-timmarsrapporteringsfrist. För den betydligt större gruppen organisationer som köper och använder teknik snarare än att släppa ut den på marknaden inför CRA något som är mindre synligt och som man är betydligt mindre förberedd på: en ny ström av säkerhetsmeddelanden från tredje part, som kommer enligt deras tidsplan snarare än enligt er egen.
Två veckor före datumet har ytterst få organisationer bestämt vem som ska ta emot dem.
Ingen inlämning ska ske på själva datumet. Det finns ingen deklaration att lämna in och inget formulär att fylla i. Den 11 september är den tidpunkt då händelsestyrda skyldigheter träder i kraft, vilket gör det svårare att planera för än en konventionell tidsfrist. Utlösaren är en incident, och incidenter följer inte kalendrar.
För tillverkare är ramverket tydligt. Så snart en organisation får kännedom om att en sårbarhet i en av dess produkter aktivt utnyttjas, har den 24 timmar på sig att utfärda en tidig varning, 72 timmar på sig att lämna en mer utförlig anmälan och därefter en fastställd tidsfrist för att lämna in en slutrapport. Påföljderna för bristande efterlevnad av förordningens centrala skyldigheter för tillverkare uppgår till 15 miljoner euro eller 2,5 % av den globala årsomsättningen, beroende på vilket belopp som är högst.
Huruvida en organisation faller inom den kategorin behandlas nedan. Den mer övergripande iakttagelsen, som hittills har fått liten uppmärksamhet, är att CRA:s mest omedelbara operativa effekter kommer att märkas av organisationer som inte direkt omfattas av förordningen.
Det är värt att stanna upp vid i vilken ordning åtgärderna träder i kraft i september.
Den rapporteringsplattform som drivs av ENISA är planerad att vara i drift vid det datumet, inte före. De harmoniserade standarderna som kommer att definiera vad efterlevnad innebär för tillverkare är fortfarande föremål för offentlig remiss. Och kravet på att upprätthålla en samordnad policy för offentliggörande av sårbarheter – den mekanism genom vilken tillverkare oftast får veta att deras produkter utnyttjas – träder inte i kraft förrän i december 2027.
Skyldigheten att rapportera föregår därför skyldigheten att inrätta den kanal genom vilken de flesta rapporterna kommer.
Detta är inte ett förbiseende. Det återspeglar en medveten förändring i hur EU:s digitala reglering sekvenseras: skyldigheterna införs stegvis och träder i kraft före den stödjande infrastrukturen, med motiveringen att en väntan på fullständiga verktyg skulle fördröja riskminskningen med flera år. NIS2 följde detta mönster. AI-lagen följde det. CRA följer det nu.
För GRC-funktioner är konsekvensen snarare strukturell än taktisk. Efterlevnadsprogram måste i allt högre grad fungera under den period som förflyter mellan att en skyldighet träder i kraft och att ekosystemet kring den mognar. Att planera utifrån antagandet att regleringen införs fullt utvecklad innebär att man planerar utifrån en modell som inte längre gäller.
Detta kräver en kort och noggrann bedömning, eftersom undantagen är kostsamma.
Få organisationer beskriver sig själva som tillverkare. Förordningen bygger inte på självbeskrivning. Den beaktar vad som släpps ut på EU-marknaden och under vems namn eller varumärke. Hårdvara under eget varumärke, medföljande firmware, uppkopplade enheter som säljs vidare under ett företags egen logotyp och programvara inbäddad i en fysisk produkt kan alla innebära att en organisation omfattas av förordningen. Importörer och distributörer som byter varumärke på en produkt eller väsentligt modifierar den övertar därmed tillverkarens skyldigheter.
Den relevanta frågan är därför inte om en organisation utvecklar programvara. Den är: vad släpper organisationen ut på EU-marknaden, under vems namn, och vad innehåller den produkten?
Vi rekommenderar att ni dokumenterar svaret redan denna vecka. För de flesta organisationer är det en enkel uppgift. För en minoritet är det skillnaden mellan ett välplanerat program och ett oplanerat sådant.
Utöver sina skyldigheter gentemot myndigheterna kräver CRA att en tillverkare som får kännedom om en aktivt utnyttjad sårbarhet eller en allvarlig incident informerar de drabbade användarna, och i förekommande fall alla användare, samt anger vilka åtgärder dessa användare kan vidta för att mildra effekterna. Om en tillverkare inte gör detta inom en rimlig tidsfrist kan det samordnande nationella CSIRT-teamet vidarebefordra informationen direkt.
Sett ur mottagarens perspektiv skapar detta ett helt nytt inkommande flöde. Från och med den 11 september kommer organisationer att börja ta emot säkerhetsmeddelanden om produkter i sin egen miljö, utfärdade av tillverkaren av dessa produkter, vilket ofta inte är den part som har den kommersiella relationen.
Detta medför tre konsekvenser.
Ansvaret är oklart. Dessa meddelanden hamnar vanligtvis hos en kundansvarig, inom inköpsavdelningen eller i en gemensam inkorg som kontrolleras under kontorstid. Enligt vår erfarenhet vidarebefordras sårbarhetsmeddelanden från leverantörer sällan till incidenthanteringen enligt standardrutiner. De eskaleras informellt av den som råkar inse deras betydelse.
Meddelandet inleder en bedömning, inte en rapportering. Denna distinktion förväxlas ofta och det är värt att vara tydlig med detta. En tillverkares säkerhetsmeddelande utgör i sig inte en incident som ska rapporteras. Huruvida den blir en sådan enligt NIS2 eller DORA beror på om organisationens egna tjänster påverkas väsentligt, vilket sällan framgår inom den första timmen. Det är just därför det är viktigt att strukturera den första timmen. Om tröskeln därefter uppfylls förväntas organisationen kunna styrka vid vilken tidpunkt den blev medveten om saken.
Avtalen behandlar för närvarande inte detta. Få leverantörsavtal specificerar anmälningskanalen, formatet, den namngivna mottagaren eller den förväntade tidsramen. Här erbjuder CRA upphandlingen något som tidigare saknats. Under ett decennium har leverantörernas säkerhetsgarantier till stor del byggt på frågeformulär med begränsad avtalsmässig verkan. Förordningen fastställer nu en grundnivå utifrån vilken specifika åtaganden kan förhandlas fram: tillgång till en programvaruförteckning (SBOM), en offentliggjord informationspolicy, en definierad supportperiod och överenskomna anmälningsrutiner. Det bör noteras att CRA ålägger tillverkarna att ta fram en SBOM; den ålägger dem inte att tillhandahålla den till sina kunder. Denna distinktion är syftet med avtalsförnyelser, och de flesta förnyelser sker långt före december 2027.
Varje tidsram i detta regelverk löper från den tidpunkt då kännedom uppnås.
Europeiska kommissionen har tagit itu med detta på tillverkarnivå och publicerade i juli 2026 riktlinjer som förklarar när en tillverkare anses ha blivit medveten. Vad inga externa riktlinjer kan avgöra är vem inom en given organisation som kan bli medveten på organisationens vägnar.
I praktiken kommer signalen via en supporttekniker klockan 19:00, en forskare som skriver till en allmän e-postadress eller en kunds säkerhetsavdelning som kontaktar en kundansvarig som är ledig.
Parallellen med GDPR är lärorik. Överträdelser har anmälts flera veckor för sent, inte på grund av mörkläggning, utan på grund av bristande klassificering. Supporten registrerade problemet som ett fel. IT-avdelningen behandlade det som en felkonfiguration. Ingen hade kommit överens om vad som utgjorde en händelse som skulle anmälas, bedömningen inleddes aldrig och den juridiska avdelningen fick kännedom först när en kund ställde en fråga.
Tre saker bör finnas dokumenterade före den 11 september: de kriterier som utlöser en omedelbar bedömning, de personer som har befogenhet att eskalera ärendet och fatta beslut utanför kontorstid samt det protokoll där händelsen dokumenteras.
Två veckor räcker inte för att inrätta ett fullständigt CRA-program. Det räcker dock för att inrätta de delar som ska tas i bruk först.
För organisationer som släpper ut produkter på EU-marknaden:
För alla andra organisationer:
Den sista punkten är den enda som visar om de övriga fungerar.
En organisation kan använda alla tillgängliga verktyg och ändå missa det avgörande ögonblicket.
En tidig varning kan inte lämnas in enbart på grundval av ett certifikat. En produkt kan inte klassificeras enligt en policy. Och en 24-timmarsbedömning kan inte genomföras enligt en process som endast existerar som ett dokument som ingen har övat på.
De organisationer som hanterar september väl är de där en namngiven person, som kontaktas klockan 19.00 en lördag, förstår att hen har befogenhet att agera.
Oavsett vilken teknik som används börjar det med rätt dos av styrning.
Två veckor räcker inte för att bygga upp ett CRA-program, men det räcker för att besvara de två frågor som denna artikel väcker: om förordningen gäller för din organisation och vem som tar emot anmälan när den kommer.
Våra CRA-tjänster omfattar avgränsning av tillämplighet, beredskap för rapportering enligt artikel 14, vidarebefordran av leverantörsmeddelanden samt integrering av CRA-skyldigheter i de redan pågående NIS2- och DORA-programmen.
Vi uppmanar organisationer att ta upp detta innan den 11 september. Efter det datumet blir situationen en annan.