Bilaga I Del II i förordning (EU) 2024/2847 fastställer åtta numrerade skyldigheter som varje tillverkare av en produkt med digitala element måste tillämpa under hela supportperioden: SBOM-förankrad identifiering, åtgärd utan dröjsmål, regelbunden testning, offentligt offentliggörande av korrigeringar, en policy för samordnad sårbarhetsredovisning, en extern rapporteringskanal, säker distribution av uppdateringar och kostnadsfria säkerhetsuppdateringar. Den här sidan går igenom varje skyldighet och visar var Bilaga I-hanteringen slutar och Artikel 14-rapporteringen börjar.
Sammanfattning
- Bilaga I Del II är den tekniska specifikationen för sårbarhetshantering enligt CRA, tillämplig på varje tillverkare för varje produkt med digitala element.
- Åtta numrerade skyldigheter: identifiera (med SBOM), åtgärda utan dröjsmål, testa regelbundet, offentliggöra åtgärdade sårbarheter, tillämpa en CVD-policy, underlätta sårbarhetsrapportering, distribuera uppdateringar säkert, leverera säkerhetsuppdateringar kostnadsfritt.
- Kostnadsfritt är icke förhandlingsbart: säkerhetsuppdateringar måste tillhandahållas kostnadsfritt enligt Bilaga I Del II led 8, med det enda undantaget för skräddarsydda produkter till företagsanvändare.
- CVD-policyn är obligatorisk, inte valfri: Bilaga I Del II led 5 gör samordnad sårbarhetsredovisning till en CE-märkningsskyldighet, inte en best practice.
- Sårbarhetshantering löper under hela supportperioden som definieras i Artikel 3(20) och Artikel 13(8); minimum är fem år från det att produkten släpps på marknaden.
- Sårbarhetshantering är inte Artikel 14-rapportering: hantering är den dagliga tekniska processen; rapportering är 24h/72h/14d-kadensen som utlöses endast av aktivt utnyttjade sårbarheter eller allvarliga incidenter (se CRA Artikel 14-rapportering).
De fyra ankarpunkterna som ramar in CRA-sårbarhetshantering: omfattning, varaktighet, kostnadsregel och bötestak.
De åtta skyldigheterna i Bilaga I Del II
Bilaga I Del II i förordning (EU) 2024/2847 listar åtta numrerade skyldigheter. De är inte en checklista: de beskriver en kontinuerlig livscykel som löper under hela supportperioden. Grupperingen nedan organiserar dem efter den operativa fas där var och en löper.
Led 1, 6. SBOM-baserad identifiering av komponenter och kända sårbarheter, plus en offentlig kontaktkanal som låter externa parter rapportera det dina skannrar missade.
Led 2, 3. Åtgärd utan dröjsmål (anpassad efter allvarlighetsgrad, inte en fast SLA) och effektiv regelbunden testning av kodbasen och dess beroenden.
Led 7, 8. Säker uppdateringskanal (signerad, autentiserad, automatisk där så är tillämpligt), med säkerhetsuppdateringar som kan separeras från funktioner och som är kostnadsfria utom för skräddarsydda B2B-produkter.
Led 4, 5. En policy för samordnad sårbarhetsredovisning som är införd och tillämpad, plus offentliga rådgivningar när en korrigering finns tillgänglig, med ett snävt undantag för "vederbörligen motiverad" fördröjning.
Vad varje skyldighet innebär i praktiken
| # | Skyldighet | Vad den faktiskt kräver |
|---|---|---|
| 1 | Identifiera och dokumentera sårbarheter och komponenter | En SBOM i CycloneDX eller SPDX, som täcker minst beroenden på toppnivå. SBOM:en är det index som gör CVE-matchning möjlig: du kan inte åtgärda det du inte har katalogiserat. |
| 2 | Åtgärda utan dröjsmål, separat från funktioner | Ingen fast SLA; den förväntade hastigheten anpassas efter allvarlighetsgrad. Säkerhetsgrenar måste kunna separeras från funktionsgrenar så att användarna inte kan skjuta upp en patch genom att skjuta upp en release. |
| 3 | Effektiv och regelbunden testning | Statisk analys, dynamisk testning, beroendeskanning mot sårbarhetsflöden och penetrationstestning. "Regelbundet" måste matcha risken och kodbasens förändringstakt. |
| 4 | Offentligt offentliggörande av åtgärdade sårbarheter | När en korrigering levereras, publicera beskrivning, berörd produkt, påverkan, allvarlighetsgrad och åtgärd. Fördröj endast "i vederbörligen motiverade fall" tills användarna kan patcha. CVE plus CSAF är de facto-bäraren. |
| 5 | Policy för samordnad sårbarhetsredovisning | En skriftlig, tillämpad CVD-policy med mottagningskanal, svars-SLA och redovisningsvillkor. ISO/IEC 29147 och 30111 ger en formell ram. |
| 6 | Underlätta extern sårbarhetsrapportering | En kontaktadress för rapportering av problem i produkten och dess tredjepartskomponenter. security.txt enligt RFC 9116 uppfyller kanalkravet. |
| 7 | Säker distribution av uppdateringar | Signerade, autentiserade uppdateringar, automatiska där så är tillämpligt. Produkter utan en uppdateringskanal måste bygga en eller dokumentera varför automatisering inte är tillämplig. Se säkerhetsuppdateringar. |
| 8 | Kostnadsfritt, med advisorymeddelanden | Säkerhetsuppdateringar måste spridas utan dröjsmål och kostnadsfritt (enda undantag: skräddarsydda produkter till företagsanvändare där parterna kommit överens om annat). Varje uppdatering måste innehålla ett advisorymeddelande som beskriver problemet och den åtgärd användaren behöver vidta. En grind med betald support, eller en tyst patch utan advisory, bryter mot led 8. |
Sårbarhetshantering och supportperioden
Kraven i Bilaga I Del II gäller under hela supportperioden som definieras i Artikel 3(20) och krävs av Artikel 13(8). Supportperioden är minst fem år från det datum då produkten släpps på EU-marknaden, eller den förväntade användningstiden om kortare och redovisad. Supportperiodens slutdatum måste anges i produktinformationen enligt Bilaga II. När supportperioden löper ut upphör skyldigheterna i Bilaga I Del II för den produktversionen, men dokumentationsskyldigheten enligt Artikel 31 (tio år från att produkten släpps på marknaden) fortsätter. Se CRA supportperiod.
Sårbarhetshantering är inte Artikel 14-rapportering
CRA skiljer mellan två skyldigheter som verkar på olika ytor och med olika mottagare:
- Bilaga I Del II sårbarhetshantering är den tekniska processen: SBOM, åtgärd, CVD-policy, offentligt offentliggörande, säkra uppdateringar. Den gäller alla sårbarheter, hela tiden, under hela supportperioden. Den levereras genom tillverkarens produktsäkerhetsorganisation.
- Artikel 14-rapportering är den regulatoriska anmälan som utlöses av en aktivt utnyttjad sårbarhet (Artikel 3(42)) eller en allvarlig incident som påverkar produktens säkerhet. Den levereras genom ENISA Single Reporting Platform i en kadens om 24h / 72h / 14d till ENISA och den CSIRT som utsetts som koordinator. För SRP-onboardingmekanik, se ENISA SRP-onboarding.
Ett produktteam kan vara fullt regelefterlevande mot Bilaga I Del II utan att någonsin lämna in en Artikel 14-rapport, eftersom de flesta sårbarheter åtgärdas innan de aktivt utnyttjas. Artikel 14 utlöses endast när åtgärden ännu inte hunnit ikapp aktiv exploatering. Se CRA Artikel 14-rapportering.
Påföljder vid överträdelse
Bristande efterlevnad av de väsentliga kraven i Bilaga I, inklusive sårbarhetshanteringen i Del II, faller under den högsta nivån av administrativa böter i Artikel 64(2): upp till 15 000 000 euro eller 2,5 % av total global årsomsättning, beroende på vilket belopp som är högre. Skyldigheten gäller från och med den 11 december 2027 för produkter som släpps på marknaden från det datumet.
Vanliga frågor
Måste SBOM:en enligt Bilaga I Del II led 1 täcka transitiva beroenden?
Den ordagranna texten kräver "åtminstone beroenden på toppnivå", vilket är det regulatoriska golvet. Transitiva komponenter omfattas inte av led 1, men de omfattas i praktiken av led 2: du kan inte "hantera och åtgärda sårbarheter utan dröjsmål" för en CVE i en transitiv komponent du aldrig har katalogiserat. De flesta tillsynsmyndigheter och kunder förväntar sig en djup SBOM som följer BSI TR-03183 eller motsvarande vägledning. CycloneDX och SPDX kvalificerar båda som "allmänt använda och maskinläsbara" format. Se CRA SBOM-krav.
Vad innebär "utan dröjsmål" i praktiken för åtgärd enligt led 2?
CRA anger ingen fast åtgärds-SLA. "Utan dröjsmål" anpassas efter cybersäkerhetsrisken: en kritisk sårbarhet med aktiv exploatering i det vilda kräver en korrigering på dagar, medan ett problem med låg allvarlighetsgrad kan vänta till nästa ordinarie cykel. Allvarlighetsgrad fastställs med CVSS, skärps med EPSS exploateringssannolikhetsdata och bekräftas med bevis från CISA KEV-katalogen där sårbarheten finns på CISA:s lista över aktivt utnyttjade. Se allvarlighetsgradering för den operativa stegen marknadsmyndigheterna tillämpar när de bedömer om en tillverkare åtgärdat "utan dröjsmål".
Kan säkerhetsuppdateringar avgiftsbeläggas under några omständigheter?
Endast ett undantag finns: Bilaga I Del II led 8 tillåter ett betalt arrangemang för skräddarsydda produkter som levereras till en företagsanvändare där tillverkaren och företagsanvändaren har kommit överens om annat. För alla andra produkter, inklusive alla konsumentprodukter och standard-B2B SaaS eller hårdvara, måste säkerhetsuppdateringar vara kostnadsfria under hela supportperioden. Att grinda en säkerhetspatch bakom en betald supportnivå är ett direkt brott mot led 8 och utsätter tillverkaren för den högsta bötenivån enligt Artikel 64(2).
Fortsätter skyldigheterna i Bilaga I Del II efter att supportperioden löpt ut?
Nej. De åtta skyldigheterna i Bilaga I Del II gäller under hela supportperioden enligt Artikel 13(8) och upphör för den produktversionen när supportperioden löper ut. Två skyldigheter överlever supportperioden: dokumentationsskyldigheten avseende teknisk dokumentation enligt Artikel 31 (tio år från att produkten släpps på marknaden), och eventuell Artikel 14-rapportering som redan pågick i det ögonblick perioden löpte ut. Nya sårbarheter som upptäcks efter end-of-support behöver inte åtgärdas för den versionen, men tillverkaren måste ha publicerat ett tydligt end-of-support-datum i produktinformationen så att användarna kan migrera. Se supportperiod och end-of-support-redovisning.
När blir en CVD-mottagning en Artikel 14-utlösare?
Utlösaren är "aktivt utnyttjad" enligt Artikel 3(42), inte "rapporterad" eller "utnyttjbar". En fungerande proof-of-concept bifogad till en CVD-rapport är inte i sig en Artikel 14-utlösare; den blir det när det finns rimlig övertygelse om att en angripare har använt bristen mot ett verkligt mål. När den tröskeln passeras startar 24-timmars tidiga varningen till ENISA och koordinator-CSIRT, följd av 72-timmarsanmälan och en slutrapport inom 14 dagar från att en korrigerande åtgärd blivit tillgänglig. Se CRA Artikel 14-rapportering.