CRA-konformitet: Lärdomar från ENISA:s EUDI Wallet-schema [2026]

Den 3 april 2026 publicerade ENISA utkast v0.4.614 av EU Digital Identity Wallet-certifieringsschemat: 110 sidor, ett offentligt samråd öppet till den 30 april och ett webbinarium den 8 april. Det här är det första cybersäkerhetscertifieringsschemat för IKT-tjänster som någonsin utarbetats under EU:s cybersäkerhetsakt. EUCC täcker redan IKT-produkter; detta schema bryter ny mark genom att tillämpa samma ramverk på tjänster. Det riktar sig mot digitala identitetsplånböcker, inte mot produkter i allmänhet. Men de beviskrav, leveranskedjskyldigheter och konformitetsinfrastruktur som det upprättar kommer att forma hur all EU-cybersäkerhetscertifiering fungerar, inklusive de scheman som så småningom kommer att reglera CRA-produkter. Här är vad schemat kräver, var CRA uttryckligen hänvisas till och vad produkttillverkare bör följa.

Sammanfattning

• Utkast v0.4.614 publicerades den 3 april 2026; offentligt samråd öppet till den 30 april, webbinarium den 8 april
• Första CSA-certifieringsschemat för IKT-tjänster under EU:s cybersäkerhetsakt (EUCC täcker redan IKT-produkter; detta är det första schemat för tjänster)
• Enbart säkerhetsnivå "hög": självbedömning är uttryckligen förbjudet för alla plånboksansökande
• SBOM obligatorisk i maskinläsbart format som del av utvärderingsbevispaketet
• CRA:s bilaga I uttryckligen hänvisad till för krav på sårbarhethantering
• ISO 27001 förklaras otillräcklig som ensamt konformitetsbevis
• Årlig övervakning inklusive penetrationstestning; 5-årig fast certifikatgräns utan undantag
• Mobilplånboksappar är CRA-produkter när de placeras på marknaden av ett kommersiellt företag (s.9)

Varför ett plånboksschema är relevant för produkttillverkare

EUDI Wallet-schemat och CRA reglerar olika juridiska objekt. CRA styr produkter med digitala element som placeras på EU-marknaden. Plånboksschemat styr en specifik typ av tjänst: EUDI Wallet Solution. Det rör sig inte om samma förordning.

Men de delar juridisk infrastruktur.

Artikel 24 och artikel 27 i CRA hänvisar båda till EU:s cybersäkerhetscertifieringsscheman under cybersäkerhetsakten som en alternativ konformitetsväg. En produkt som omfattas av ett tillämpligt CSA-schema kan använda certifiering under det schemat för att visa konformitet med motsvarande CRA-väsentliga krav. Inget sådant schema som täcker CRA-produkter existerar ännu. EUDI Wallet-schemat är det första som utarbetats, och de val ENISA gör här, rörande evidensformat, leveranskedjskrav och utvärderingsmetodik, kommer att föras vidare.

Schemat drar en tydlig jurisdiktionsgräns på sidan 9. Texten är direkt: CRA "gäller inte direkt för EUDI-plånböcker när de certifieras inom ramen för detta schema, eftersom de certifieras som IKT-tjänster, inte IKT-produkter." För de flesta EUDIW-deltagare är CRA inte en parallell skyldighet. Schemat har selektivt lånat från CRA:s metodik, men det lånandet utvidgar inte förordningens tillämpningsområde.

Undantaget gäller mobila lösningar. När plånboksinstansen är en mobilapplikation som placeras på marknaden av ett kommersiellt företag gäller CRA för den applikationen som en produkt med digitala element. För företag som distribuerar en mobilplånboksapp kommersiellt gäller två regelverk samtidigt. CRA täcker skyldigheter avseende konformitet före marknadsintroduktionen och hantering av sårbarheter efter. Plånboksschemat täcker den kontinuerliga tjänstecertifieringen. De staplas på varandra, men enbart i detta specifika scenario. En organisation som tillhandahåller en plånbokslösning uteslutande som en IKT-tjänst har ingen CRA-skyldighet genom detta schema.

Det delade ramverket omfattar cybersäkerhetsakten och det europeiska Common Criteria-baserade utvärderingsramverket (ECCF), CEN TS 18072 för krav på plånbokstjänster och EUCC (EU Common Criteria-baserat cybersäkerhetscertifieringsschema) som kompositionsbas för hårdvaru- och plattformskomponenter. Ingen av den infrastrukturen byggdes enbart för plånböcker. Det är skelettet som framtida CRA-anknutna scheman kommer att använda.

Ytterligare en gräns: schemat anger att EUDIW-certifikat "inte kommer att vara lämpliga för presumtion om konformitet" under CRA (s.9). Även för mobilplånboksappar där CRA är tillämplig uppfyller EUDIW-certifikatet inte CRA-konformiteten. De två efterlevnadsspåren är separata och måste var för sig genomföras oberoende av varandra.

Mobilplånboksdistributörer: två oberoende efterlevnadsspår. Om du är ett kommersiellt företag som placerar en mobilplånboksapp på EU-marknaden gäller CRA för den appen som en produkt med digitala element. Du behöver CRA-konformitetsbedömning för produkten och EUDIW-certifiering för plånbokstjänsten. Inget av dem uppfyller det andra. Båda måste genomföras oberoende av varandra och underhållas under separata övervakningscykler. Om du tillhandahåller plånboken uteslutande som en IKT-tjänst utan en separat distribuerad mobilapp gäller CRA inte för dig genom detta schema.

Om dina produkter så småningom kommer att bli föremål för ett CSA-certifieringsschema under CRA:s artikel 27-väg, är plånboksschemat din tydligaste förhandsvisning av hur den utvärderingen kommer att se ut. De metoder som valideras här är de metoder du kommer att möta.

Se guiden för konformitetsbedömning för de aktuella CRA-modulalternativen medan CSA-scheman fortfarande är under utarbetande.

Certifieringsinfrastrukturen i dag

CRA:s konformitetslandskap har för närvarande fyra nivåer. Standardprodukter (majoriteten) kan använda Module A självbedömning. Viktiga klass I-produkter kan använda Module A om de tillämpar harmoniserade standarder, eller vända sig till ett anmält organ. Viktiga klass II- och kritiska produkter kräver tredjepartsutvärdering, och kritiska produkter behöver dessutom ett tillämpligt CSA-schema där ett sådant finns.

Luckan: inget CSA-schema täcker för närvarande CRA:s väsentliga krav. Det innebär att artikel 27-vägen, där CSA-certifiering utlöser presumtion om konformitet med CRA, ännu inte är möjlig att gå för någon produkt. Den finns i förordningen men inte i praktiken.

EUDI Wallet-schemat fyller inte den luckan. Men det fastställer modellen.

Schemat kräver uteslutande säkerhetsnivå "hög", utan lägre nivåer. Motiveringen i dokumentet är direkt: "alla funktioner som tillhandahålls av EUDI-plånböckerna är säkerhetsfunktioner, en del av dem med kritisk känslighet" (s.17). Schemat gör bedömningen att ingen plånboksfunktion är tillräckligt lågriskig för att tillåta självbedömning.

Självbedömning avvisas inte bara. Det blockeras: "En konformitetsbedömning genom självbedömning... ska inte vara tillåten" (s.18).

Logiken är parallell med CRA:s förhållningssätt till viktiga och kritiska produkter. Högre insatser motiverar strängare konformitetsvägar. Den specifika tröskeln skiljer sig mellan regelverken, men principen är identisk. När ENISA utarbetar framtida CSA-scheman för CRA-produktkategorier, förvänta dig samma resonemang tillämpat på bilaga III- och IV-produkter.

Viktigt: Mappningen av säkerhetsnivåer mellan CRA-produktnivåer och framtida CSA-scheman är vår analytiska slutledning, inte ett uttryckligt uttalande i EUDIW-schemat. Schemat täcker enbart plånböcker.

För aktuella produktklassificeringsregler under CRA, se guiden för produktklassificering.

Vad schemat kräver av privata företag

Schemat definierar en livscykel i fyra steg för ansökande.

Förberedelse omfattar sammanställning av dokumentation, riskbedömning och insamling av säkerhetsevidens för komponenter. Det är här din leveranskedjesevidens blir ett blockerande beroende, inte ett tillägg som man försöker uppnå i mån av tid.

Första utvärderingen innefattar designgranskning och beroendeanalys. En IT Security Evaluation Facility (ITSEF) granskar din arkitektur, din förtroendemodell och konformitetsstatusen för varje komponent din plånbok är beroende av.

Andra utvärderingen innefattar funktionell testning, penetrationstestning och sårbarhetsbedömning mot plånbokens deklarerade säkerhetsfunktioner. Det är inte en dokumentgenomgång. Testare undersöker aktivt systemet.

Underhåll fortsätter efter certifikatutfärdande. Årlig övervakning krävs, inklusive penetrationstestning på varje årsdag. Det är inte en bocksida. Det är en återkommande utvärderingskostnad inbyggd i certifikatets livscykel.

Certifikatet är giltigt i 5 år. Gränsen är fast. Schemat anger att inget undantag är möjligt (s.26). När certifikatet löper ut måste plånboken avaktiveras. Det finns ingen tidsfrist att förhandla.

Skyldigheten avseende informationsintegritet är skarpare än de flesta efterlevnadsramverk. Att lämna felaktig eller ofullständig information till certifieringsorganet klassificeras som bristande efterlevnad, inte som nonkonformitet (s.23-24). Distinktionen är viktig: nonkonformitet utlöser en saneringsprocess. Bristande efterlevnad kan utlösa suspension eller återkallelse på andra grunder.

Efter underrättelse om nonkonformitet har du 30 dagar på dig att bedöma om fyndet är väsentligt (s.38). Det fönstret börjar inte när du upptäcker problemet. Det börjar när certifieringsorganet meddelar dig. Organisationer som inte har intagsprocesser för konformitetsunderrättelser kommer att ha förbrukat det fönstret innan någon har läst e-postmeddelandet.

Suspension är offentlig. Schemat kräver obligatorisk offentliggörande när ett certifikat suspenderas (s.40). Maximal suspensionsperiod är 42 dagar, förlängningsbar till 1 år av den nationella cybersäkerhetscertifieringsmyndigheten (NCCA). Det är inte en intern fråga. Dina kunder och förlitande parter kommer att se det.

Dokumentbevaring sträcker sig 5 år efter certifikatets utgång, inklusive fysiska produktexemplar där det är tillämpligt (s.49). För programvaruprodukter med ett 5-årigt certifikat innebär det minst 10 år av beviskedja.

CRA-modellen kräver konformitetsbedömning före marknadsintroduktionen och hantering av sårbarheter efter. Plånboksschemat kräver kontinuerlig konformitet med årlig penetrationstestning och övervakning under hela certifikatets livscykel. För företag som är föremål för båda är plånboksschemats skyldigheter efter certifiering mer krävande än CRA:s i scope och frekvens.

Din leveranskedja är nu en del av certifieringskedjan

Plånboksschemat använder en kompositionell utvärderingsmodell med tre distinkta lager.

Wallet Secure Cryptographic Application (WSCA) och dess underliggande hårdvaruplattform utvärderas under EUCC, EU:s Common Criteria-schema. Det täcker hårdvarusäkerhetsmodulerna, säkra element och betrodda exekveringsmiljöer som plånboken är beroende av.

Plånboksinstansen (programvaran som körs på användarens enhet) utvärderas under FiTCEM, Functional IT Common Evaluation Method, som hanterar utvärdering av programvara där hårdvaruseparation inte är möjlig.

Plånbokstjänster (serverkomponenter, identitetsutfärdande, gränssnitt för förlitande parter) bedöms mot CEN TS 18072-krav.

Varje lager har sin egen utvärderingsväg. Ditt certifikat är beroende av certifikaten under det.

Schemat är tydligt om den börda detta lägger på ansökande: du måste "samla in säkerhetsdokumentation för sina komponenter, vilket kan innebära att vissa av dem certifieras" (s.14). "Kan innebära" underskattar det. Om en komponent saknar den krävda säkerhetsdokumentationen kan din utvärdering inte avslutas.

Underleverantörers uppgifter ska lämnas uttömmande. Varje underleverantör måste listas, tillsammans med den konformitetsbedömning som tillämpats på deras bidrag (s.78). Det finns ingen generisk kategori "vi använder välrenommerade leverantörer". Varje tredje part antingen har dokumenterad konformitetsevidens eller inte, och den luckan är ditt problem i utvärderingen.

Skyldigheter att notifiera om uppströmssårbarheter är obligatoriska i båda riktningarna. När en sårbarhet påverkar en IKT-produkt som utgör underlag för en sammansatt IKT-tjänst måste EUCC-certifikatinnehavaren informera beroende EUDIW-certifikatinnehavare (s.43). Det är en specifik skyldighet kopplad till sårbarhetsinformation, inte en generell notifiering vid varje certifikatändring. Om din komponentleverantör identifierar en sårbarhet och inte berättar det för dig befinner de sig i avtalsbrott. Om de berättar det för dig har du ett 30-dagarsfönster för väsentlighetsbedömning att svara på.

Kontinuerlig övervakning slutar inte vid din organisationsgräns. När ett bascertifikat för en komponent uppdateras eller ersätts måste CAB:en utföra en differentiell beroendeanalys av förändringarna (s.84). En väsentlig uppdatering av ett beroende utlöser en formell CAB-bedömning av om ditt certifieringsscope är påverkat.

Molnleverantörer är inte undantagna. Schemat klassificerar infrastruktur "tillhandahållen av leverantör" (s.61) som en komponent i scope för leveranskedjesbedömning. Om din plånbokstjänst körs på en molnplattform är plattformens konformitetsstatus en del av ditt evidenspaket.

Propagationsregeln är betydelsefull: om en korrigering av nonkonformitet är utestående i en baskomponents certifieringsrapport måste CAB:en bedöma dess påverkan på den sammansatta IKT-tjänsten (s.84). Om den påverkan är väsentlig kan kompositutvärderingen inte avslutas förrän nonkonformiteten är löst. Det sker inte automatiskt — det beror på om nonkonformiteten bedöms vara väsentlig för din tjänst. Men en allvarlig öppen nonkonformitet i din WSCA-leverantörs certifieringsrapport kan stoppa din utvärdering från att slutföras.

Det här är inte en hypotetisk framtida modell för CRA. CRA:s SBOM-skyldighet (bilaga I del II) och krav på sårbarhetövervakning (artiklarna 13 och 14) fungerar efter samma princip. Plånboksschemat visar hur dessa skyldigheter fungerar i praktiken inom ett formellt certifieringsramverk: dokumenterade, bilaterala och blockerande.

Viktigt: Reglerna om leveranskedjsnotifiering och propagation som beskrivs här gäller för EUDIW-certifieringsschemat. CRA:s parallella skyldigheter finns i artikel 13 och artikel 14. Hur de samverkar i praktiken för produkter som är föremål för båda regelverken är ännu inte fastslaget i vägledning.

För hur CRA:s leveranskedjeskyldigheter kommer att samverka med framtida CSA-certifieringsscheman, se Cybersecurity Act 2. För de praktiska aspekterna av SBOM-generering och underhåll, se SBOM-genereringsguiden.

Vad dina befintliga certifieringar faktiskt är värda

De flesta tillverkare antar att deras befintliga certifieringar väger tungt i nya scheman. För EUDIW beror svaret helt på vilken certifiering du innehar och hur noggrant din revisor mappade dess scope mot schemats kriterier.

Schemat tar upp detta direkt i avsnitt 5.3. Det tillåter CAB:er att förlita sig på tidigare arbete, men villkoren är strikta. Ett bryggebrev krävs när det finns ett gap mellan den tidigare revisionens rapporteringsperiod och den aktuella utvärderingen (s.85). Partiellt förtroende är vanligt; fullt förtroende är sällsynt.

ISO 27001-fyndet förtjänar direkt uppmärksamhet. Schemat konstaterar klart: "det ger inte, på egen hand, tillräcklig säkerhet för att de enskilda kontroller som valts i tillämpbarhetsdeklarationen är utformade och fungerar på den rigorösitetsnivå som krävs av detta schema" (s.88).

Logiken här gäller bortom EUDIW. ISMS-certifiering bekräftar processmognad och att ett ledningssystem finns. Det bekräftar inte att enskilda kontroller fungerar på den garantinivå ett specifikt schema kräver. Samma resonemang kommer att gälla under CRA när harmoniserade standarder är fastställda.

Om din SOC 2 Type II-revision gjordes utan EU:s cybersäkerhetskriterier i åtanke kommer den inte att kvalificera för villkorligt förtroende. Du skulle behöva verifierad mappning från din revisor. Planera för det samtalet nu, innan du är inne i en certifieringstidslinje.

För en djupare jämförelse av vad ISO 27001 faktiskt täcker kontra CRA-krav, se vår jämförelseguide för ISO 27001.

Viktigt: EUDIW-schemat är specifikt för plånboksinfrastrukturens kontext. CRA:s harmoniserade standarder kan sätta olika trösklar för vad tidigare certifieringar uppfyller. Behandla denna analys som vägledande, inte definitiv.

Sårbarhethantering går bortom CRA

EUDIW-schemats krav på sårbarhethantering hänvisar uttryckligen till CRA. Schemat anger: "Detta avsnitt... hämtar till stor del från andra förordningar, såsom CSA:s artikel 55... och även från CRA" (s.43). Den härstamningen är viktig eftersom kraven delar struktur men skiljer sig i mekanik.

Gällande SBOM: schemat kräver maskinläsbart format (s.43), i linje med CRA:s bilaga I del II. Det är inget nytt koncept om du redan följer CRA-skyldigheter, men det bekräftar att SBOM som teknisk artefakt håller på att bli en baslinjsförväntning inom EU-scheman, inte bara CRA-specifikt.

Säkerhetsuppdateringar måste levereras separat från funktionsuppdateringar (s.43). Det är operativt viktigt. En kombinerad release som både patchar sårbarheter och lägger till funktioner skapar tvetydighet kring vad användarna accepterar. Schemat behandlar dem som separata skyldigheter.

Din CVD-policy måste vara offentlig och anpassad till EN ISO/IEC 29147 (s.47). Det är inte ett policydokument begravt i en efterlevnadsmapp. Det måste vara sökbart, aktuellt och strukturerat enligt standarden.

Gällande konsekvensanalys: CVSS-poäng ensamma är otillräckliga. Schemat kräver kontextspecifik analys (s.44). En CVSS 9.8 i ett driftsättningskontext kan vara en CVSS 4.0 i ditt, men du måste dokumentera det resonemanget, inte bara hävda det.

Det mest operativt viktiga kravet: en väsentlig sårbarhet utan lösningsväg utlöser återkallelse av certifikat (s.45). Det skapar en direkt länk mellan din patchfrekvens och din certifieringsstatus. Klockan stannar inte vid bedömningen.

Jämförelsen med CRA är relevant. CRA kräver ENISA-notifiering inom 24 timmar efter att man upptäckt en aktivt exploaterad sårbarhet. EUDIW använder "utan onödigt dröjsmål" genom CAB-kedjan. Olika klocka, olika routing, liknande avsikt. Om du bygger processer för ett, utforma dem för att uppfylla båda.

För en genomgång av den specifika 24-timmarsskyldigheten, se vår post om ENISA-sårbarhetrapportering. För en startpunkt för din CVD-policy, se CVD-policymallen.

Vad som är bekräftat kontra vår analys

Fem saker att bevaka

Schemat är inte slutligt. Samrådstidsgränsen den 30 april innebär att förändringar fortfarande är möjliga. Det här är de områden där utfallet väsentligt påverkar din planering.

1. Krav på evidensformat: Schemat hänvisar till maskinläsbara SBOM och teknisk filstruktur men standardiserar inte fullt ut hur "tillräckligt" ser ut i praktiken. CAB:er kommer att tolka detta. Tills de gör det, bygg mot det mest strukturerade format du kan försvara.

2. CAB-kapacitet: Auktorisering kräver både ackreditering och NCCA-godkännande, plus genomförande av en pilottvärdering (s.30). Uppstartsproblematiken är verklig. Om kvalificerade CAB:er är knappa när schemat träder i kraft, förskjuts tidslinjer oavsett hur väl förberedda du är. Det är utanför din kontroll, men det påverkar dina schemaläggningsantaganden.

3. Ömsesidigt erkännande: Schemat antar inte EUCC:s bestämmelser om ömsesidigt erkännande för tredjelandsscheman (s.52). Ömsesidigt erkännande för tredjeländer lämnas uttryckligen öppet för ett senare skede: "dessa villkor kan läggas till i ett senare skede." Det är en olöst fråga, inte ett avgjort beslut. Räkna inte med att dina amerikanska certifieringar gäller, men detta är en aktiv öppen fråga snarare än ett permanent avvisande.

4. Nationellt schemas solnedgång: Befintliga nationella scheman har ett 12-månadersfönster efter ikraftträdandet för att förbli giltiga (s.56). Om din nuvarande certifiering är utfärdad under ett nationellt schema, förstå när det fönstret stängs.

5. Öppna frågor: Ägandeskap av penetrationstestning, trösklar för attackpotentialnivå och djupkvalificerare för sårbarhetanalys förblir olösta i den nuvarande texten (s.97-98). Det är inte redaktionella luckor. De påverkar hur du scope och budgeterar bedömningar.

Vad vi vet med säkerhet

• CRA citeras uttryckligen som källa för schemats krav.
• SBOM i maskinläsbart format krävs.
• ISO 27001 ensamt uppfyller inte krav på organisatoriska kontroller.
• Självbedömning är inte tillgängligt på någon säkerhetsnivå för EUDIW-komponenter.
• Certifikatets giltighet är begränsad till 5 år.

Vår analys (ej bekräftad)

• CRA-konformitetsbedömningsscheman kommer sannolikt att följa liknande mönster för SBOM-krav, CVD-policy och otillräckligheten av ISO 27001 isolerat. EUDIW-schemat ger en förhandsvisning av hur ENISA tänker kring dessa skyldigheter.
• Trycket på leveranskedjscertifiering kommer att öka. EUDIW:s komponentnivåkrav antyder att nedströmstillverkare börjar kräva att uppströmsleverantörer innehar oberoende certifieringar, inte bara egna deklarationer.
• SOC 2-mappning är en verklig möjlighet. Om du engagerar din revisor nu för att strukturera kriteriemappning mot EU:s cybersäkerhetskrav kan du positionera din nästa SOC 2 Type II för villkorligt förtroende snarare än att börja från noll.

Vad ingen vet ännu

• När ett CRA-specifikt certifieringsschema kommer att publiceras och hur dess samrådstidslinje ser ut.
• Vilka harmoniserade standarder som kommer att utses under CRA och vilka garantitrösklar de kommer att sätta.
• Hur nationell CAB-kapacitet kommer att utvecklas i förhållande till efterfrågan när flera scheman är aktiva samtidigt.

Vad tillverkare bör göra nu

Samrådsfönstret och den slutliga schemapublikationen ger dig ett definierat fönster att förbereda dig. Det här är konkreta steg, inte allmänna råd.

• Förstå din väg för konformitetsbedömning. Schemats säkerhetsnivåer mappar mot olika produktkategorier. Vad som gäller för dig är inte alltid uppenbart. Använd en strukturerad beslutsprocess innan du antar att du vet din väg. Börja med vår guide för konformitetsbedömning.

• Bygg evidens nu. SBOM, riskbedömningar, policies för sårbarhetutlämnande och tekniska filer tar tid att producera korrekt. Att börja under samrådsperioden innebär att du kan iterera innan en CAB begär dem.

• Anta inte att ISO 27001 täcker dig. Schemat är tydligt. Om din efterlevnadsposition bygger på ISO 27001 som proxy för cybersäkerhetsgaranti har du en lucka. Identifiera vilka kontroller som behöver oberoende verifiering.

• Strukturera din nästa SOC 2 med EU-kriteriemappning i åtanke. Om du ska förnya din SOC 2, prata med din revisor innan scoping börjar. Dokumenterad kriteriemappning till EUDIW (och så småningom CRA) krav är det som omvandlar en Type II från partiellt till villkorligt förtroende.

• Följ samrådsprocessen. Webbinariet den 8 april och den skriftliga tidsgränsen den 30 april är de sista formella tidpunkterna för inlämning innan schemat rör sig mot finalisering. Om schemat påverkar dina produkter, lämna in kommentarer eller bevaka åtminstone vilka förändringar som görs.

• Kartlägg din leveranskedja. Identifiera vilka uppströmskomponenter som täcks av schemats scope. Om en leverantör inte kan visa certifiering för en komponent du integrerar, blir den luckan ditt problem vid bedömningstillfället.

Hur CRA Evidence hjälper

CRA Evidence stödjer den dokumentations- och processinfrastruktur som EUDIW- och CRA-bedömningar kräver:

• SBOM-hantering: Generera, lagra och exportera SBOM:er i maskinläsbara format anpassade till CRA:s bilaga I del II-krav.
• VDP med CVD-arbetsflöde: Publicera och hantera din policy för sårbarhetutlämnande med ett strukturerat intagnings- och svarsarbetsflöde anpassat till EN ISO/IEC 29147.
• ENISA-notifieringsspårning: Spåra 24-timmars-, 72-timmars- och 14-dagarsfönstren för rapportering med revisionsfärdiga poster för varje notifiering.
• Leverantörsportal: Hantera uppströms- och nedströmsnotifieringar inom din leveranskedja, med dokumenterade bevis på kommunikation för tekniska filer.

Se vad CRA Evidence täcker på craevidence.com.

Den här artikeln är enbart i informationssyfte och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, konsultera kvalificerad juridisk rådgivare.