Conformita CRA: Lezioni dallo schema ENISA per l'EUDI Wallet [2026]

Il 3 aprile 2026 ENISA ha pubblicato la bozza v0.4.614 dello schema di certificazione per l'EU Digital Identity Wallet: 110 pagine, una consultazione pubblica aperta fino al 30 aprile e un webinar previsto per l'8 aprile. Si tratta del primo schema di certificazione della cybersecurity per servizi ICT mai redatto nell'ambito del Cybersecurity Act dell'UE. L'EUCC copre già i prodotti ICT; questo schema apre nuovi orizzonti applicando lo stesso framework ai servizi. Riguarda i wallet di identita digitale, non i prodotti in generale. Ma gli standard probatori, gli obblighi sulla catena di fornitura e l'infrastruttura di conformita che stabilisce definiranno il funzionamento di tutta la certificazione europea in materia di cybersecurity, compresi gli schemi che regolamenteranno in futuro i prodotti soggetti al CRA. Di seguito si descrive cosa richiede lo schema, dove il CRA viene esplicitamente citato e quali aspetti i produttori dovrebbero tenere sotto osservazione.

Perche uno schema per i wallet interessa i produttori

Lo schema EUDI Wallet e il CRA operano su oggetti giuridici diversi. Il CRA disciplina i prodotti con elementi digitali immessi sul mercato UE. Lo schema per il wallet riguarda un tipo specifico di servizio: la EUDI Wallet Solution. Non sono lo stesso regolamento.

Ma condividono la stessa impalcatura normativa.

L'articolo 24 e l'articolo 27 del CRA fanno entrambi riferimento agli schemi di certificazione della cybersecurity previsti dal Cybersecurity Act come percorso alternativo di conformita. Un prodotto coperto da uno schema CSA applicabile puo utilizzare la certificazione sotto quello schema per dimostrare la conformita ai corrispondenti requisiti essenziali del CRA. Ad oggi non esiste ancora nessuno schema che copra i prodotti CRA. Lo schema EUDI Wallet e il primo ad essere redatto, e le scelte che ENISA compie qui, sui formati delle prove, i requisiti della catena di fornitura e la metodologia di valutazione, si propagheranno in avanti.

Lo schema traccia una chiara linea di demarcazione giurisdizionale a pagina 9. Il testo è diretto: il CRA "non si applica direttamente ai wallet EUDI in quanto certificati nel contesto del presente schema, poiché vengono certificati come servizi ICT, non come prodotti ICT". Per la maggior parte dei partecipanti EUDIW, il CRA non costituisce un obbligo parallelo. Lo schema ha mutuato selettivamente la metodologia del CRA, ma tale mutuazione non estende l'ambito di applicazione del regolamento.

L'eccezione riguarda il mobile. Quando l'istanza del wallet è un'applicazione mobile immessa sul mercato da un'entita commerciale, il CRA si applica a quell'applicazione come prodotto con elementi digitali. Per le aziende che distribuiscono commercialmente un'app wallet mobile, due regimi si applicano simultaneamente. Il CRA copre gli obblighi di conformita pre-market e di gestione delle vulnerabilita post-market sul prodotto. Lo schema per il wallet copre la certificazione continua del servizio. Si sovrappongono, ma solo in questo scenario specifico. Un'organizzazione che fornisce una soluzione wallet esclusivamente come servizio ICT non ha alcun obbligo CRA derivante da questo schema.

L'infrastruttura comune comprende il CSA e il framework di valutazione basato su Common Criteria europeo (ECCF), il CEN TS 18072 per i requisiti del servizio wallet e l'EUCC (schema europeo di certificazione della cybersecurity basato su Common Criteria) come base compositiva per i componenti hardware e di piattaforma. Niente di questa infrastruttura e stato costruito solo per i wallet. E lo scheletro che useranno i futuri schemi collegati al CRA.

Un ulteriore limite: lo schema afferma che i certificati EUDIW "non saranno adatti alla presunzione di conformita" ai sensi del CRA (p.9). Anche per le app wallet mobile a cui il CRA si applica, il certificato EUDIW non soddisfa la conformita CRA. I due percorsi di compliance sono separati e devono essere completati ciascuno in modo indipendente.

Distributori di wallet mobile: due percorsi di compliance indipendenti. Se siete un'entita commerciale che immette sul mercato UE un'app wallet mobile, il CRA si applica a quell'app come prodotto con elementi digitali. Dovete completare la valutazione della conformita CRA per il prodotto e la certificazione EUDIW per il servizio wallet. Nessuna delle due soddisfa l'altra. Entrambe devono essere completate in modo indipendente e mantenute con cicli di sorveglianza separati. Se fornite il wallet esclusivamente come servizio ICT senza un'app mobile distribuita separatamente, il CRA non si applica a voi attraverso questo schema.

Se i vostri prodotti saranno eventualmente soggetti a uno schema CSA nell'ambito del percorso dell'articolo 27 del CRA, lo schema per il wallet e il vostro anticipo piu chiaro di come sara quella valutazione. Le metodologie che vengono validate qui sono le metodologie che dovrete affrontare.

Per le opzioni attuali dei moduli del CRA mentre gli schemi CSA sono ancora in attesa, consultare la guida alle decisioni sulla valutazione della conformita.

L'infrastruttura di certificazione oggi

Il panorama della conformita CRA ha attualmente quattro livelli. I prodotti predefiniti (la maggioranza) possono utilizzare l'autovalutazione con il Modulo A. I prodotti Importanti Classe I possono usare il Modulo A applicando standard armonizzati, oppure rivolgersi a un organismo notificato. I prodotti Importanti Classe II e Critici richiedono una valutazione di terza parte, con i prodotti Critici che necessitano anche di uno schema CSA applicabile dove ne esista uno.

Il problema: nessuno schema CSA copre attualmente i requisiti essenziali del CRA. Cio significa che il percorso dell'articolo 27, dove la certificazione CSA attiva la presunzione di conformita con il CRA, non e ancora percorribile per nessun prodotto. Esiste nel regolamento, ma non nella pratica.

Lo schema EUDI Wallet non colma questa lacuna. Ma stabilisce il modello.

Lo schema impone esclusivamente il livello di garanzia "alto", senza livelli inferiori consentiti. La motivazione nel documento e diretta: "tutte le funzioni fornite dai wallet EUDI sono funzioni di sicurezza, alcune di esse di sensibilita critica" (p.17). Lo schema giudica che nessuna funzione del wallet abbia un rischio sufficientemente basso da consentire l'autovalutazione.

L'autovalutazione non e solo scoraggiata. E bloccata: "L'autovalutazione di conformita... non deve essere consentita" (p.18).

La logica rispecchia l'approccio del CRA ai prodotti Importanti e Critici. Rischi piu elevati giustificano percorsi di conformita piu rigorosi. La soglia specifica differisce tra i due regimi, ma il principio e identico. Quando ENISA redigerà futuri schemi CSA per le categorie di prodotti CRA, aspettatevi la stessa logica applicata ai prodotti degli Allegati III e IV.

Nota importante: La mappatura tra i livelli di prodotto CRA e i futuri schemi CSA e una nostra inferenza analitica, non un'affermazione esplicita dello schema EUDIW. Lo schema riguarda solo i wallet.

Per le attuali regole di classificazione dei prodotti ai sensi del CRA, consultare la guida alla classificazione dei prodotti.

Cosa richiede lo schema alle aziende private

Lo schema definisce un ciclo di vita in quattro fasi per i richiedenti.

La preparazione comprende l'assemblaggio della documentazione, la valutazione del rischio e la raccolta delle prove di garanzia per i componenti. E qui che le prove sulla vostra catena di fornitura diventano una dipendenza bloccante, non un'aggiunta a buon fine.

La prima valutazione prevede la revisione del progetto e l'analisi delle dipendenze. Una struttura ITSEF (IT Security Evaluation Facility) esamina la vostra architettura, il vostro modello di fiducia e lo stato di conformita di ciascun componente da cui dipende il wallet.

La seconda valutazione prevede test funzionali, penetration testing e valutazione delle vulnerabilita rispetto alle funzioni di sicurezza dichiarate del wallet. Non si tratta di una revisione documentale. I tester esaminano attivamente il sistema.

La manutenzione prosegue dopo il rilascio del certificato. E richiesta una sorveglianza annuale, con penetration testing ad ogni anniversario. Non e una formalita. E un costo di valutazione ricorrente integrato nel ciclo di vita del certificato.

Il certificato e valido 5 anni. Il limite e inderogabile. Lo schema afferma che non e possibile alcuna deroga (p.26). Quando il certificato scade, il wallet deve essere disattivato. Non esiste un periodo di proroga da negoziare.

L'obbligo di integrita delle informazioni e piu stringente rispetto alla maggior parte dei framework di compliance. Fornire informazioni errate o incomplete all'organismo di certificazione e classificato come non conformita (non-compliance), non come difformita (nonconformity) (pp.23-24). La distinzione e rilevante: una difformita attiva un processo di rimedio. Una non conformita puo comportare la sospensione o il ritiro su basi diverse.

Dopo la notifica di una difformita, si hanno 30 giorni per valutare se il rilievo sia materiale (p.38). Questa finestra non parte dal momento in cui si scopre il problema. Parte dal momento in cui l'organismo di certificazione notifica la difformita. Le organizzazioni che non dispongono di processi di ricezione per le notifiche di conformita bruceranno quella finestra prima che qualcuno legga l'email.

La sospensione e pubblica. Lo schema impone la divulgazione pubblica obbligatoria quando un certificato viene sospeso (p.40). Il periodo massimo di sospensione e di 42 giorni, estendibile a 1 anno dall'autorita nazionale di certificazione della cybersecurity (NCCA). Non si tratta di una questione interna. I vostri clienti e le parti facenti affidamento lo sapranno.

La conservazione dei documenti si estende a 5 anni oltre la scadenza del certificato, inclusi i campioni fisici del prodotto ove applicabile (p.49). Per i prodotti software con certificato quinquennale, la catena probatoria ha una durata minima di 10 anni.

Il modello CRA richiede una valutazione della conformita prima dell'immissione sul mercato e una gestione delle vulnerabilita post-market. Lo schema per il wallet richiede una conformita continua con penetration testing annuale e sorveglianza per l'intera durata del ciclo di vita del certificato. Per le aziende soggette a entrambi, gli obblighi post-certificazione dello schema per il wallet sono piu esigenti di quelli del CRA per ambito e frequenza.

La vostra catena di fornitura e ora nella catena di certificazione

Lo schema per il wallet utilizza un modello di valutazione compositiva con tre livelli distinti.

La Wallet Secure Cryptographic Application (WSCA) e la piattaforma hardware sottostante vengono valutate sotto l'EUCC, lo schema UE basato su Common Criteria. Questo copre i moduli di sicurezza hardware, gli elementi sicuri e gli ambienti di esecuzione affidabili da cui dipende il wallet.

L'istanza del wallet (il software in esecuzione sul dispositivo dell'utente) viene valutata sotto FiTCEM, il Functional IT Common Evaluation Method, che gestisce la valutazione software nei casi in cui la separazione hardware non sia praticabile.

I servizi wallet (componenti lato server, emissione di identita, interfacce per le parti facenti affidamento) vengono valutati rispetto ai requisiti del CEN TS 18072.

Ogni livello ha il proprio percorso di valutazione. Il vostro certificato dipende dai certificati sottostanti.

Lo schema e esplicito riguardo al peso che questo pone sui richiedenti: occorre "raccogliere la documentazione di garanzia per i propri componenti, il che puo implicare la certificazione di alcuni di essi" (p.14). "Puo implicare" sottostima la portata dell'obbligo. Se a un componente manca la documentazione di garanzia richiesta, la vostra valutazione non puo concludersi.

La divulgazione dei subappaltatori e esaustiva. Ogni subappaltatore deve essere elencato, insieme all'entita della valutazione di conformita applicata al loro contributo (p.78). Non esiste una categoria generica "utilizziamo fornitori affidabili". Ogni terza parte dispone o meno di prove di conformita documentate, e tale lacuna diventa vostro problema in fase di valutazione.

Le notifiche di vulnerabilita upstream sono obbligatorie in entrambe le direzioni. Quando una vulnerabilita riguarda un prodotto ICT che costituisce la base di un servizio ICT composito, il titolare del certificato EUCC deve informare i titolari di certificati EUDIW dipendenti (p.43). Si tratta di un obbligo specifico legato alle comunicazioni di vulnerabilita, non di una notifica generica per ogni modifica al certificato. Se il fornitore di un vostro componente identifica una vulnerabilita e non ve lo comunica, è inadempiente. Se ve lo comunica, avete una finestra di 30 giorni per la valutazione della materialita.

Il monitoraggio continuo non si ferma al confine della vostra organizzazione. Quando il certificato di un componente di base viene aggiornato o sostituito, il CAB deve eseguire un'analisi differenziale delle dipendenze sulle modifiche apportate (p.84). Un aggiornamento significativo a una dipendenza attiva una valutazione formale da parte del CAB per stabilire se il perimetro della vostra certificazione sia interessato.

I provider cloud non sono esentati. Lo schema classifica l'infrastruttura "fornita dal provider" (p.61) come componente in perimetro per la valutazione della catena di fornitura. Se il vostro servizio wallet opera su una piattaforma cloud, lo stato di conformita di quella piattaforma fa parte del vostro pacchetto probatorio.

La regola di propagazione è significativa: se la correzione di una non conformita è in sospeso nel rapporto di certificazione di un componente di base, il CAB deve valutarne l'impatto sul servizio ICT composito (p.84). Se tale impatto è materiale, la valutazione composita non può concludersi finché la non conformita non è risolta. Questo non è automatico: dipende dal fatto che la non conformita sia considerata materiale per il vostro servizio. Tuttavia, una non conformita grave e aperta nel rapporto di certificazione del vostro fornitore WSCA può bloccare il completamento della vostra valutazione.

Questo non è un modello futuro ipotetico per il CRA. L'obbligo SBOM del CRA (Allegato I Parte II) e i requisiti di monitoraggio delle vulnerabilita (articoli 13 e 14) operano sullo stesso principio. Lo schema per il wallet mostra come tali obblighi funzionino in pratica all'interno di un framework di certificazione formale: documentati, bilaterali e bloccanti.

Nota importante: Le regole di notifica e propagazione nella catena di fornitura descritte qui si applicano allo schema di certificazione EUDIW. Gli obblighi paralleli del CRA sono contenuti negli articoli 13 e 14. Come interagiscano nella pratica per i prodotti soggetti a entrambi i regimi non e ancora definito nelle linee guida.

Per come gli obblighi del CRA sulla catena di fornitura interagiranno con i futuri schemi CSA, vedere Cybersecurity Act 2. Per la meccanica pratica della generazione e manutenzione degli SBOM, vedere la guida alla generazione degli SBOM.

Il reale valore delle vostre certificazioni esistenti

La maggior parte dei produttori presuppone che le certificazioni gia ottenute abbiano peso nei nuovi schemi. Per EUDIW, la risposta dipende interamente da quale certificazione detenete e da quanto rigorosamente il vostro auditor ha mappato il relativo perimetro ai criteri dello schema.

Lo schema affronta questo aspetto direttamente nella sezione 5.3. Consente agli organismi di valutazione della conformita (CAB) di fare affidamento su lavori precedenti, ma le condizioni sono stringenti. E richiesta una lettera di raccordo (bridge letter) quando vi e un divario tra il periodo di riferimento dell'audit precedente e la valutazione corrente (p.85). Il riutilizzo parziale e comune; il riutilizzo totale e raro.

Il rilievo su ISO 27001 merita attenzione diretta. Lo schema afferma chiaramente: "non fornisce, da solo, garanzie sufficienti che i singoli controlli selezionati nella dichiarazione di applicabilita siano progettati e operino al livello di rigore richiesto dallo schema" (p.88).

La logica qui si applica anche oltre EUDIW. La certificazione ISMS conferma la maturita dei processi e l'esistenza di un sistema di gestione. Non conferma che i singoli controlli funzionino al livello di garanzia richiesto da uno schema specifico. Lo stesso ragionamento si applichera sotto il CRA quando gli standard armonizzati saranno finalizzati.

Se il vostro audit SOC 2 Type II e stato impostato senza i criteri europei di cybersecurity in mente, non sara idoneo al riutilizzo condizionale. Dovrete ottenere una mappatura verificata dal vostro auditor. Pianificate quella conversazione adesso, prima di trovarvi in una tempistica di certificazione.

Per un confronto piu approfondito tra cio che ISO 27001 copre effettivamente e i requisiti CRA, vedere la nostra guida comparativa con ISO 27001.

Nota importante: Lo schema EUDIW e specifico al contesto dell'infrastruttura wallet. Gli standard armonizzati del CRA potrebbero fissare soglie diverse per cio che le certificazioni precedenti soddisfano. Considerate questa analisi come indicativa, non definitiva.

La gestione delle vulnerabilita va oltre il CRA

I requisiti di gestione delle vulnerabilita dello schema EUDIW attingono esplicitamente dal CRA. Lo schema afferma: "Questa sezione... trae in gran parte da altri regolamenti, come l'articolo 55 del CSA... e anche dal CRA" (p.43). Questa genealogia e importante perche i requisiti condividono la struttura ma divergono nella meccanica.

Sugli SBOM: lo schema richiede il formato leggibile da macchina (p.43), allineato all'Allegato I Parte II del CRA. Non e un concetto nuovo se state gia seguendo gli obblighi CRA, ma conferma che l'SBOM come artefatto tecnico sta diventando un'aspettativa di base in tutti gli schemi UE, non solo nel CRA.

Gli aggiornamenti di sicurezza devono essere distribuiti separatamente dagli aggiornamenti funzionali (p.43). Questo ha implicazioni operative rilevanti. Una release combinata che corregge vulnerabilita e aggiunge funzionalita crea ambiguita su cio che gli utenti stanno accettando. Lo schema tratta i due elementi come obblighi distinti.

La vostra politica CVD deve essere pubblica e allineata alla EN ISO/IEC 29147 (p.47). Non si tratta di un documento di policy sepolto in una cartella di compliance. Deve essere accessibile, aggiornata e strutturata secondo lo standard.

Sull'analisi di impatto: i punteggi CVSS da soli sono insufficienti. Lo schema richiede un'analisi specifica al contesto (p.44). Un CVSS 9.8 in un contesto di deployment puo essere un CVSS 4.0 nel vostro caso, ma dovete documentare quel ragionamento, non semplicemente affermarlo.

Il requisito operativamente piu significativo: una vulnerabilita materiale senza percorso di rimedio comporta il ritiro del certificato (p.45). Questo crea un legame diretto tra la vostra cadenza di patching e il vostro stato di certificazione. L'orologio non si ferma alla valutazione.

Il confronto con il CRA e rilevante. Il CRA richiede la notifica all'ENISA entro 24 ore dalla scoperta di una vulnerabilita attivamente sfruttata. EUDIW utilizza "senza indebito ritardo" attraverso la catena CAB. Orologi diversi, routing diverso, intento simile. Se state costruendo processi per uno, progettateli per soddisfare entrambi.

Per un'analisi dettagliata dell'obbligo di notifica entro 24 ore, vedere il nostro articolo sulla notifica delle vulnerabilita all'ENISA. Per un punto di partenza sulla vostra politica CVD, vedere il template di politica CVD.

Cosa e confermato e cosa e nostra analisi

Cinque aspetti da monitorare

Lo schema non e definitivo. La scadenza della consultazione il 30 aprile significa che sono ancora possibili modifiche. Queste sono le aree in cui l'esito incide materialmente sulla vostra pianificazione.

1. Requisiti sul formato delle prove: Lo schema fa riferimento a SBOM leggibili da macchina e alla struttura del fascicolo tecnico, ma non standardizza completamente come appaia nella pratica un livello "sufficiente". I CAB lo interpreteranno. Fino a quando non lo faranno, puntate al formato piu strutturato che potete difendere.

2. Capacita dei CAB: L'autorizzazione richiede sia l'accreditamento che l'approvazione dell'NCCA, piu il completamento di una valutazione pilota (p.30). Il problema del bootstrap e reale. Se i CAB qualificati sono scarsi quando lo schema entra in vigore, le tempistiche slittano indipendentemente da quanto siate preparati. Questo non e nel vostro controllo, ma incide sulle vostre ipotesi di pianificazione.

3. Riconoscimento reciproco: Lo schema non adotta le disposizioni sul riconoscimento reciproco dell'EUCC per gli schemi di paesi terzi (p.52). Il riconoscimento reciproco con paesi terzi è esplicitamente rimandato a una fase successiva: "queste condizioni potranno essere aggiunte in una fase successiva". La questione è irrisolta, non definita. Non pianificate che le vostre certificazioni statunitensi siano trasferibili, ma si tratta di una questione aperta e attiva, non di un rifiuto permanente.

4. Scadenza degli schemi nazionali: Gli schemi nazionali esistenti hanno una finestra di 12 mesi dopo l'entrata in vigore per restare validi (p.56). Se la vostra certificazione attuale e rilasciata sotto uno schema nazionale, capite quando quella finestra si chiude.

5. Questioni aperte: La titolarita del penetration testing, le soglie del livello di potenziale di attacco e i qualificatori di profondita per l'analisi delle vulnerabilita restano irrisolti nel testo attuale (pp.97-98). Non sono lacune redazionali. Incidono su come delimitate e preventivate le valutazioni.

Cosa sappiamo con certezza

• Il CRA e esplicitamente citato come fonte per i requisiti dello schema.
• L'SBOM in formato leggibile da macchina e obbligatorio.
• ISO 27001 da solo non soddisfa i requisiti di controllo organizzativo.
• L'autovalutazione non e disponibile a nessun livello di garanzia per i componenti EUDIW.
• La validita del certificato e limitata a 5 anni.

La nostra analisi (non confermata)

• Gli schemi di valutazione della conformita CRA seguiranno probabilmente modelli simili sui requisiti SBOM, sulla politica CVD e sull'insufficienza di ISO 27001 da solo. Lo schema EUDIW offre un'anticipazione di come ENISA ragiona su questi obblighi.
• La pressione sulla certificazione della catena di fornitura aumentera. I requisiti a livello di componente di EUDIW suggeriscono che i produttori a valle inizieranno a richiedere ai fornitori upstream certificazioni indipendenti, non semplici autodichiarazioni.
• La mappatura SOC 2 e una reale opportunita. Se coinvolgete il vostro auditor adesso per strutturare la mappatura dei criteri rispetto ai requisiti europei di cybersecurity, potreste posizionare il vostro prossimo SOC 2 Type II per il riutilizzo condizionale invece di ripartire da zero.

Cosa nessuno sa ancora

• Quando verra pubblicato uno schema di certificazione specifico per il CRA e quale sara la sua tempistica di consultazione.
• Quali standard armonizzati saranno designati sotto il CRA e quali soglie di garanzia fisseranno.
• Come si sviluppera la capacita dei CAB nazionali rispetto alla domanda quando piu schemi saranno attivi contemporaneamente.

Cosa dovrebbero fare i produttori adesso

La finestra di consultazione e la pubblicazione finale dello schema vi danno un periodo definito per prepararvi. Queste sono azioni concrete, non consigli generici.

• Capite il vostro percorso di valutazione della conformita. I livelli di garanzia dello schema si mappano a diverse categorie di prodotto. Cio che si applica a voi non e sempre ovvio. Utilizzate un processo decisionale strutturato prima di assumere di conoscere il vostro percorso. Partite dalla nostra guida alle decisioni sulla valutazione della conformita.

• Costruite le prove adesso. SBOM, valutazioni del rischio, politiche di divulgazione delle vulnerabilita e fascicoli tecnici richiedono tempo per essere prodotti correttamente. Iniziare durante il periodo di consultazione significa poter iterare prima che un CAB li richieda.

• Non date per scontato che ISO 27001 vi copra. Lo schema e esplicito. Se la vostra postura di compliance e costruita su ISO 27001 come proxy per la garanzia di cybersecurity, avete una lacuna. Identificate quali controlli necessitano di verifica indipendente.

• Strutturate il prossimo SOC 2 tenendo a mente la mappatura dei criteri UE. Se siete in scadenza per un rinnovo SOC 2, parlate con il vostro auditor prima che inizi il dimensionamento. La mappatura documentata dei criteri rispetto ai requisiti EUDIW (e in futuro CRA) e cio che converte un Type II da riutilizzo parziale a condizionale.

• Seguite il processo di consultazione. Il webinar dell'8 aprile e la scadenza scritta del 30 aprile sono gli ultimi punti formali di contributo prima che lo schema si avvii verso la finalizzazione. Se lo schema riguarda i vostri prodotti, inviate commenti o almeno monitorate le modifiche.

• Mappate la vostra catena di fornitura. Identificate quali componenti upstream rientrano nel perimetro dello schema. Se un fornitore non riesce a dimostrare la certificazione per un componente che integrate, quella lacuna diventa vostro problema al momento della valutazione.

Come CRA Evidence puo aiutare

CRA Evidence supporta l'infrastruttura di documentazione e processi richiesta dalle valutazioni EUDIW e CRA:

• Gestione degli SBOM: Generare, archiviare ed esportare SBOM in formati leggibili da macchina allineati ai requisiti dell'Allegato I Parte II del CRA.
• VDP con workflow CVD: Pubblicare e gestire la vostra politica di divulgazione delle vulnerabilita con un workflow strutturato di ricezione e risposta allineato alla EN ISO/IEC 29147.
• Tracciamento delle notifiche ENISA: Monitorare le finestre di notifica a 24 ore, 72 ore e 14 giorni con registri pronti per l'audit per ciascuna notifica.
• Portale fornitori: Gestire le notifiche upstream e downstream nella vostra catena di fornitura, con prove documentate delle comunicazioni per i fascicoli tecnici.

Scoprite cosa copre CRA Evidence su craevidence.com.

Questo articolo ha uno scopo puramente informativo e non costituisce consulenza legale. Per una guida specifica sulla compliance, consultare un consulente legale qualificato.