CRA per le startup: conformità snella con un ingegnere

Sta per lanciare un prodotto connesso con un team piccolo, e il CRA lo riguarda. Gli obblighi principali si applicano dall’11 dicembre 2027, con la segnalazione delle vulnerabilità già dall’11 settembre 2026: è un problema da affrontare ora, non a tempo debito. Due aspetti colgono di sorpresa le startup: l’obbligo di supporto sulla sicurezza pluriennale, che scatta nel momento in cui il prodotto viene immesso sul mercato UE, e il fatto di doverlo gestire tutto senza un’assunzione dedicata alla sicurezza.

Questa guida è per founder e primi ingegneri che devono essere conformi al CRA senza spendere troppo né costruire più del necessario. Copre cosa si può saltare in sicurezza, cosa no, e come una sola persona può gestire l’intero processo.

Il CRA si applica alla sua startup?

Bastano quattro verifiche rapide. Il CRA copre i prodotti con elementi digitali che si connettono a una rete o a un altro dispositivo e sono resi disponibili sul mercato UE nell’ambito di un’attività commerciale.

Se il prodotto rientra nell’ambito, la domanda successiva è quale categoria gli spetta. È questo a decidere se può autovalutarsi o se serve un organismo notificato. Lo confermi con la guida alla classificazione dei prodotti prima di dedicare anche solo un giorno a qualsiasi altra cosa.

Il suo vantaggio strutturale: l’autovalutazione

Il risparmio più grande per una startup è che un prodotto fuori dalle categorie Importante e Critica è un prodotto Default. Per questi il CRA consente l’autovalutazione: il lavoro di conformità lo svolge lei stesso, firma la dichiarazione UE di conformità e appone la marcatura CE. Nessun organismo esterno, nessuna tariffa per prodotto. I meccanismi di ciascun percorso sono nella guida alla valutazione di conformità. Il punto, per una startup, è non pagare per una valutazione di terzi di cui non ha bisogno.

Le agevolazioni CRA pensate per le startup

Il CRA include misure di sostegno scritte specificamente per microimprese, piccole e medie imprese e startup. Se le agevolazioni si applicano dipende dalla dimensione dell’azienda, secondo la definizione UE standard: una microimpresa ha meno di 10 dipendenti e un fatturato o bilancio pari o inferiore a 2 milioni di euro, una piccola impresa ha meno di 50 dipendenti e un fatturato o bilancio pari o inferiore a 10 milioni di euro.

Quattro agevolazioni che una startup può davvero usare:

• Documentazione semplificata: le microimprese e le piccole imprese possono presentare la documentazione tecnica in un formato semplificato specificato dalla Commissione, e gli organismi notificati devono accettare quel formato.
• Tariffe di conformità ridotte: quando il prodotto richiede un organismo notificato, le esigenze specifiche delle PMI, comprese le startup, devono essere prese in considerazione e le tariffe ridotte in proporzione.
• Sandbox normative: gli Stati membri possono istituire ambienti controllati in cui sviluppare e testare un prodotto innovativo rispetto al CRA prima di immetterlo sul mercato, con accesso agevolato per le startup.
• Supporto diretto: dove opportuno, gli Stati membri gestiscono attività di sensibilizzazione e formazione e un canale di consulenza dedicato per le imprese più piccole, e la Commissione segnala il supporto finanziario disponibile.

Consiglio: chieda alla sua autorità nazionale di vigilanza del mercato o al suo digital innovation hub se il modulo di documentazione semplificata e una sandbox normativa sono già attivi nel suo paese. Entrambi dipendono dall’attuazione nazionale e della Commissione, quindi la disponibilità varia.

Conformità CRA con un solo ingegnere

Non serve un team di sicurezza. Serve un responsabile designato e un breve elenco di cose che girano in automatico. Questa persona mantiene il fascicolo tecnico, analizza le segnalazioni di vulnerabilità in arrivo e firma la dichiarazione di conformità. Il ruolo può stare su una sola persona, ma va detto con chiarezza che la gestione continua delle vulnerabilità, la consegna degli aggiornamenti e la documentazione sono lavoro ingegneristico vero e proprio. La guida ai costi di conformità CRA modella l’impegno e il budget per un piccolo team, così può pianificare l’organico in modo corretto.

Tre cose vale la pena automatizzare per prime. Ognuna è un problema già risolto da strumenti gratuiti, e insieme coprono gli obblighi iniziali più visibili. Sono un punto di partenza, non il quadro completo.

• Generi un SBOM in CI: il CRA richiede una distinta base del software che copra almeno le dipendenze di primo livello, e strumenti open source come Syft e Trivy ne producono una a ogni build. La catena di strumenti completa è nella guida alla generazione SBOM.
• Monitori le vulnerabilità: scansioni le dipendenze a ogni build e agisca sui risultati in base al rischio prima che raggiungano i clienti. Al CRA interessa che lei analizzi e corregga, non quale scanner usi.
• Pubblichi un contatto di sicurezza: un file security.txt e un indirizzo di sicurezza funzionante danno ai ricercatori un modo per segnalare. La guida alla configurazione di security.txt include un modello pronto.

Questi tre sono vittorie rapide di automazione, non l’intero lavoro. Accanto ci sono la progettazione sicura, la valutazione del rischio, la consegna degli aggiornamenti e i controlli di prodotto. La documentazione tecnica cresce insieme al prodotto invece che nella corsa dell’ultimo minuto prima del lancio, quindi tenga aggiornate le note di architettura e sicurezza man mano che procede. I contenuti richiesti sono nella guida alla documentazione tecnica.

Il processo di gestione delle vulnerabilità deve essere operativo prima che gli obblighi di segnalazione partano l’11 settembre 2026. Da quella data, una vulnerabilità attivamente sfruttata o un incidente grave fanno scattare un orologio stretto attraverso la piattaforma unica di segnalazione ENISA: un allarme preliminare entro 24 ore, poi una notifica più completa entro 72 ore. Il rapporto finale cambia a seconda del percorso. Per una vulnerabilità attivamente sfruttata è dovuto entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave è dovuto entro un mese dalla notifica delle 72 ore. Deve inoltre informare gli utenti interessati. I meccanismi sono nella guida alla segnalazione delle vulnerabilità.

Iterare rapidamente senza rivalutare ogni release

Iterare velocemente non significa rifare la valutazione di conformità a ogni sprint. La conformità va rivista solo dopo una modifica sostanziale, cioè un cambiamento successivo al lancio che incide sulla conformità del prodotto ai requisiti essenziali, oppure ne cambia la finalità prevista per cui è stato valutato. Un aggiornamento di sicurezza che riduce soltanto il rischio di cibersicurezza senza cambiare la finalità prevista non è una modifica sostanziale, e in genere non lo è nemmeno una modifica minore come l’aggiunta di una lingua all’interfaccia. Un aggiornamento funzionale che allarga la superficie di attacco o cambia cosa fa il prodotto può esserlo. Quindi le patch di routine e i piccoli aggiornamenti si rilasciano senza nuova valutazione, e si rivaluta quando un cambiamento altera davvero cosa è il prodotto o il suo profilo di rischio.

Startup e software open source

Per una startup contano due fatti sull’open source. Primo, il software libero e open source rientra nell’ambito solo quando è fornito nel corso di un’attività commerciale. Un software che i manutentori non monetizzano generalmente non è un’attività commerciale, ma la monetizzazione è più ampia del semplice far pagare il codice, quindi vanno considerati anche il supporto a pagamento e accordi simili. Contribuire con codice sorgente a un progetto che non è sotto la sua responsabilità non fa scattare il CRA per lei. Monetizzare l’open source, o distribuirlo dentro un prodotto che vende, fa rientrare quel prodotto nell’ambito come di consueto.

Secondo, il CRA crea un ruolo più leggero, quello di steward del software open source, per un’organizzazione, diversa da un fabbricante, che sostiene lo sviluppo di software open source destinato a uso commerciale. Gli obblighi di uno steward ruotano attorno a una politica di cibersicurezza documentata e alla cooperazione con le autorità. La segnalazione delle vulnerabilità si applica nella misura in cui lo steward è coinvolto nello sviluppo del prodotto, e la segnalazione degli incidenti gravi e la notifica agli utenti si applicano quando un incidente colpisce i sistemi che lo steward mette a disposizione per quello sviluppo. Questi obblighi sono più leggeri dell’intero insieme di obblighi del fabbricante. Se la sua startup fa sia da steward di un progetto sia da venditrice di un prodotto, sia chiaro su quale ruolo indossa per quale attività, perché gli obblighi differiscono.

L’obbligo di supporto quinquennale e il modello di business

Questa è la parte del CRA da cui nessuno strumento automatico salva una startup. Il periodo di supporto deve essere di almeno cinque anni, e se il prodotto è previsto in uso per meno di cinque anni, il periodo si allinea a quella durata più breve. Durante quel periodo si gestiscono le vulnerabilità in base al rischio, si correggono senza ritardo e si consegnano gli aggiornamenti ai clienti.

Per un’azienda in fase iniziale è un impegno reale, non una casella da spuntare:

• L’obbligo segue il prodotto: scatta alla prima immissione sul mercato UE, e un pivot successivo non lo estingue per le unità già immesse.
• Va messo a bilancio nel prezzo: se il margine non copre il periodo di supporto, il prezzo è sbagliato. Modelli il costo del supporto nell’unit economics prima del lancio, e si aspetti che si riduca man mano che il codebase si stabilizza.
• Pianifichi per dieci anni, non cinque: ogni aggiornamento di sicurezza rilasciato deve restare disponibile per almeno 10 anni dopo il rilascio, o per il resto del periodo di supporto, a seconda di quale sia più lungo.
• Pubblichi la data di fine: deve mostrare la data di fine del periodo di supporto, almeno mese e anno, al momento dell’acquisto. La fissi con attenzione, perché clienti e acquirenti la leggeranno.

Può rendere l’impegno più sostenibile, ma faccia attenzione a cosa lo estingue davvero:

• Scelga dipendenze stabili: ogni libreria che cambia in fretta e che integra nel prodotto è manutenzione pluriennale a cui si è iscritto. Preferisca componenti noiosi e ben supportati.
• Versioni in modo deliberato: definisca generazioni di prodotto e pianifichi come il supporto passa dall’una all’altra, così da non dover mantenere un insieme illimitato di versioni attive.
• Le mitigazioni non estinguono l’obbligo: un trasferimento scritto del supporto a un acquirente, un accordo di escrow, o l’apertura in open source dei componenti critici per la sicurezza possono mantenere il flusso di correzioni, ma nessuno di essi da solo rimuove il suo obbligo.

Se cessa l’attività e non può più rispettare l’obbligo, deve informare le autorità di vigilanza del mercato e, per quanto possibile, i suoi utenti prima che la cessazione diventi effettiva. Cosa succeda all’obbligo residuo una volta che l’azienda non esiste più non è definito in modo netto e dipende dalla giurisdizione. Pianifichi ora il percorso di chiusura, finché può ancora farlo, e lo documenti nel fascicolo tecnico.

Trasformare la conformità in vendite e finanziamenti

Per una startup, il lavoro sul CRA può servire a due scopi: apre l’accesso al mercato UE e fornisce le prove da consegnare a un acquirente enterprise o a un investitore.

Costruisca il pacchetto di due diligence una sola volta. I team di procurement UE possono chiedere, durante l’onboarding dei fornitori, un SBOM aggiornato, una dichiarazione di conformità firmata e un processo documentato di divulgazione delle vulnerabilità con una tempistica di risposta. Sono prove solide, non una dimostrazione di piena conformità, perché, in fondo, la preparazione dipende dal rispetto di ogni requisito essenziale. Ma averli già raccolti in un unico posto evita di doverli mettere insieme di corsa più avanti, ed è lo stesso pacchetto che la due diligence tecnica di un investitore può chiedere di vedere.

Agli investitori interessa che possa vendere legalmente. Violare i requisiti essenziali o gli obblighi principali del fabbricante comporta sanzioni amministrative fino a 15 milioni di euro o al 2,5% del fatturato mondiale totale annuo, a seconda di quale sia il valore più alto. Più concretamente, un prodotto immesso sul mercato UE dall’11 dicembre 2027 deve rispettare il CRA per poter essere venduto lì. Presentare la conformità come accesso al mercato e ingresso in UE a rischio ridotto convince un board più che presentarla come un costo.

I programmi pubblici possono finanziare parte del lavoro. Strumenti UE come Horizon Europe, il Digital Europe Programme e l’EIC Accelerator sostengono la cibersicurezza e lo sviluppo di prodotti sicuri, e i programmi nazionali aggiungono altro. Importi e requisiti di ammissibilità variano, quindi verifichi presso il suo digital innovation hub nazionale cosa è aperto. Imposti la candidatura sulla costruzione di prodotti digitali affidabili e sicuri, non sulla semplice spunta di un obbligo normativo.

Se le certificazioni di sicurezza emergono nelle trattative di vendita, sappia dove si colloca il CRA rispetto a loro. La sovrapposizione con un ISMS è trattata nella guida CRA vs ISO 27001, e i team che lavorano su IoT consumer dovrebbero leggere la guida EN 303 645.

Errori comuni delle startup

• «Ci occuperemo della sicurezza dopo il round di raccolta fondi»: con la runway che si consuma, rincorrere la sicurezza dopo brucia la liquidità appena raccolta. Costruisca le basi fin dal primo sprint.
• «Abbiamo prezzato il prodotto senza considerare l’obbligo di supporto»: la manutenzione di sicurezza pluriennale deve stare dentro l’unit economics. Se non ci sta, il prezzo è sbagliato.
• «Chi si occupava della conformità se n’è andato e nessuno ha preso il suo posto»: se una sola persona detiene il fascicolo tecnico e il processo di segnalazione, la sua uscita è una lacuna di conformità. Scriva nero su bianco chi è responsabile.
• «L’acquirente si accollerà semplicemente l’obbligo»: un accordo può assegnare il lavoro di supporto, ma da solo non solleva lei dall’obbligo di legge. Lo gestisca esplicitamente nei termini contrattuali, e non dia nulla per scontato.
• «Aggiungeremo il CRA quando ci espanderemo nell’UE»: se gli utenti UE possono già raggiungere il prodotto, sta già fornendo il mercato UE, e aggiungere la conformità dopo significa ricostruire. Progetti fin da subito per gli obblighi del 2027.
• «Siamo troppo in fase iniziale per rientrare nell’ambito»: essere una startup dà diritto ad agevolazioni, non a un’esenzione. L’obbligo scatta alla prima immissione sul mercato, indipendentemente dalla fase.