Conformità CRA: lezioni dallo schema EUDI Wallet di ENISA

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 fabbricanti dovrebbero tenere sotto osservazione.

Aggiornamento del 17 ottobre 2026: La revisione pubblica della bozza v0.4.614 si è chiusa il 30 aprile 2026, dopo il webinar dell'8 aprile. La pagina ENISA sulla certificazione del Wallet EUDI non indica alcun passaggio successivo, quindi vi si verifichino il parere dell'ECCG e il testo finale dello schema. Questo articolo descrive la bozza così com'era durante la revisione.

Perche uno schema per i wallet interessa i fabbricanti

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 27 del CRA fa 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 è un'entità commerciale che immette sul mercato UE un'app wallet mobile, il CRA si applica a quell'app come prodotto con elementi digitali. Deve completare la valutazione della conformità 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 fornisce il wallet esclusivamente come servizio ICT senza un'app mobile distribuita separatamente, il CRA non si applica a lei attraverso questo schema.

Se i suoi prodotti saranno eventualmente soggetti a uno schema CSA nell'ambito del percorso dell'articolo 27 del CRA, lo schema per il wallet è l'anticipazione più chiara di come sarà quella valutazione. Le metodologie che vengono validate qui sono le metodologie che dovrà 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, specifiche comuni o uno schema di certificazione a livello di garanzia «sostanziale», oppure rivolgersi a un organismo notificato. I prodotti Importanti Classe II richiedono il Modulo B+C, il Modulo H oppure, dove disponibile, uno schema di certificazione a livello di garanzia «sostanziale». I prodotti Critici richiedono uno schema europeo di certificazione obbligatorio dove la Commissione abbia attivato l'Articolo 8, paragrafo 1. Un atto del genere non esiste ancora, quindi si applicano i percorsi della Classe II.

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. È qui che le prove sulla sua 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 sua architettura, il suo modello di fiducia e lo stato di conformità 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 suoi 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 sua catena di fornitura è 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 suo 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 sua valutazione non può 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 un suo 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 suo componente identifica una vulnerabilità e non glielo comunica, è inadempiente. Se glielo comunica, ha una finestra di 30 giorni per la valutazione della materialità.

Il monitoraggio continuo non si ferma al confine della sua 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 sua 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 suo servizio wallet opera su una piattaforma cloud, lo stato di conformità di quella piattaforma fa parte del suo 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 conformità sia considerata materiale per il suo servizio. Tuttavia, una non conformità grave e aperta nel rapporto di certificazione del suo fornitore WSCA può bloccare il completamento della sua 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 sue certificazioni esistenti

La maggior parte dei fabbricanti presuppone che le certificazioni gia ottenute abbiano peso nei nuovi schemi. Per EUDIW, la risposta dipende interamente da quale certificazione detiene e da quanto rigorosamente il suo 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 suo audit SOC 2 Type II è stato impostato senza i criteri europei di cybersecurity in mente, non sarà idoneo al riutilizzo condizionale. Dovrà ottenere una mappatura verificata dal suo auditor. Pianifichi quella conversazione adesso, prima di trovarsi 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 è un concetto nuovo se sta già 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 sua 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 può essere un CVSS 4.0 nel suo caso, ma deve 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 sua cadenza di patching e il suo stato di certificazione. L'orologio non si ferma alla valutazione.

Il confronto con il CRA e rilevante. Il CRA richiede la notifica entro 24 ore dalla presa di conoscenza di una vulnerabilita attivamente sfruttata, simultaneamente al CSIRT designato come coordinatore e a ENISA tramite la Piattaforma di segnalazione unica. EUDIW utilizza "senza indebito ritardo" attraverso la catena CAB. Orologi diversi, routing diverso, intento simile. Se sta costruendo processi per uno, li progetti 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 sua politica CVD, si veda il template di politica CVD.

Cosa e confermato e cosa e nostra analisi

Cinque aspetti da monitorare

Lo schema non era definitivo alla chiusura della revisione pubblica il 30 aprile, quindi sono possibili modifiche alla bozza. Queste sono le aree in cui l'esito incide materialmente sulla sua 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, punti al formato più strutturato che può 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 sia preparato. Questo non è sotto il suo controllo, ma incide sulle sue 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 pianifichi che le sue 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 sua certificazione attuale è rilasciata sotto uno schema nazionale, verifichi 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 si delimitano e si preventivano 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 fabbricanti a valle inizieranno a richiedere ai fornitori upstream certificazioni indipendenti, non semplici autodichiarazioni.
• La mappatura SOC 2 e una reale opportunita. Se coinvolge il suo auditor adesso per strutturare la mappatura dei criteri rispetto ai requisiti europei di cybersecurity, potrebbe posizionare il suo 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 fabbricanti adesso

La revisione pubblica si è chiusa e la pagina ENISA sul Wallet EUDI non indica ancora uno schema definitivo, il che lascia una finestra per prepararsi. Queste sono azioni concrete, non consigli generici.

• Capisca il suo percorso di valutazione della conformità. I livelli di garanzia dello schema si mappano a diverse categorie di prodotto. Ciò che si applica a lei non è sempre ovvio. Utilizzi un processo decisionale strutturato prima di dare per scontato di conoscere il suo percorso. Parta dalla nostra guida alle decisioni sulla valutazione della conformita.

• Costruisca le prove adesso. SBOM, valutazioni del rischio, politiche di divulgazione delle vulnerabilita e fascicoli tecnici richiedono tempo per essere prodotti correttamente. Iniziare prima che lo schema sia definitivo significa poter iterare prima che un CAB li richieda.

• Non dia per scontato che ISO 27001 la copra. Lo schema è esplicito. Se la sua postura di compliance è costruita su ISO 27001 come proxy per la garanzia di cybersecurity, ha una lacuna. Identifichi quali controlli necessitano di verifica indipendente.

• Strutturi il prossimo SOC 2 tenendo a mente la mappatura dei criteri UE. Se è in scadenza per un rinnovo SOC 2, ne parli con il suo 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.

• Segua il parere dell'ECCG e il testo finale dello schema. La revisione pubblica si è chiusa (webinar dell'8 aprile, scadenza scritta del 30 aprile). Se lo schema riguarda i suoi prodotti, monitori le modifiche rispetto alla bozza v0.4.614.

• Mappi la sua catena di fornitura. Identifichi quali componenti upstream rientrano nel perimetro dello schema. Se un fornitore non riesce a dimostrare la certificazione per un componente che integra, quella lacuna diventa un suo 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 propria politica di divulgazione delle vulnerabilità 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 propria 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.