Il Cyber Resilience Act (Regolamento UE 2024/2847) introduce obblighi di cybersicurezza per prodotti hardware e software connessi venduti nel mercato europeo. Dal 2026 scatteranno i primi obblighi di notifica delle vulnerabilità, mentre dal dicembre 2027 saranno pienamente applicabili requisiti come secure by design, gestione delle vulnerabilità, SBOM e conformità CE cybersecurity. Il regolamento coinvolge produttori, importatori, distributori e anche molte PMI che lavorano con dispositivi digitali, firmware, IoT o software embedded.

Dal 10 dicembre 2024 è in vigore il Cyber Resilience Act (CRA), formalmente Regolamento (UE) 2024/2847 la prima normativa europea che introduce requisiti obbligatori di cybersicurezza per tutti i prodotti con elementi digitali destinati al mercato UE. La piena applicazione scatta l’11 dicembre 2027, ma il primo obbligo operativo è già fissato all’11 settembre 2026: da quella data chiunque produca, importi o distribuisca prodotti digitali in Europa deve essere in grado di notificare vulnerabilità attivamente sfruttate e incidenti gravi. Questa guida analizza in dettaglio scadenze, soggetti obbligati, categorie di prodotti, sanzioni, differenze con NIS2 e una roadmap operativa per prepararsi.

Cos’è il Cyber Resilience Act e perché nasce

Il Cyber Resilience Act è il primo regolamento europeo che impone requisiti orizzontali obbligatori di cybersicurezza per i prodotti con elementi digitali come hardware, software, firmware, componenti connessi commercializzati nel mercato UE. È stato adottato dal Parlamento Europeo il 12 marzo 2024, approvato dal Consiglio il 10 ottobre 2024 e pubblicato nella Gazzetta Ufficiale dell’UE il 20 novembre 2024, entrando in vigore il 10 dicembre 2024.

La motivazione è nei numeri: il costo globale del cybercrimine era stimato in 5,5 trilioni di euro nel 2021, con milioni di prodotti digitali che presentavano vulnerabilità diffuse e ricevevano aggiornamenti di sicurezza insufficienti o incoerenti. Prima del CRA non esisteva in Europa nessuna norma che imponesse direttamente ai fabbricanti di progettare prodotti sicuri. Esistevano certificazioni volontarie, la NIS2 per i settori critici, il GDPR per i dati personali, ma nessun obbligo di “cybersecurity by design” per tutti i dispositivi.

Con il CRA la sicurezza informatica diventa una caratteristica strutturale del prodotto, al pari della qualità e della conformità CE. Il principio guida è secure by design e secure by default: la protezione deve essere integrata nella progettazione, non aggiunta dopo.

A chi si applica: soggetti obbligati e perimetro

Il CRA si applica a chiunque metta a disposizione sul mercato UE prodotti con elementi digitali: hardware o software che prevedono una connessione dati logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Sono coinvolti fabbricanti, importatori e distributori, con responsabilità differenziate.

Chi sono i fabbricanti

I fabbricanti – cioè chi progetta e produce il prodotto, o lo fa produrre apponendo il proprio nome o marchio — portano la responsabilità principale. Devono garantire che il prodotto soddisfi i requisiti essenziali di cybersicurezza, redigere la documentazione tecnica, rilasciare la Dichiarazione di Conformità UE, apporre la marcatura CE e gestire le vulnerabilità per tutta la vita utile del prodotto (minimo 5 anni). Devono notificare vulnerabilità e incidenti gravi alle autorità competenti.

Chi sono gli importatori

Gli importatori – chi immette nel mercato UE prodotti fabbricati in Paesi terzi – devono verificare che il prodotto sia conforme al CRA prima di immetterlo. Se riscontrano non conformità, devono impedirne la distribuzione e informare il fabbricante e le autorità di vigilanza del mercato. Rispondono in solido in caso di prodotto non conforme.

Chi sono i distributori

I distributori che immettono un prodotto con elementi digitali nel mercato UE devono assicurarsi che il prodotto rechi la marcatura CE, che sia accompagnata dalla documentazione richiesta e che il fabbricante e l’importatore abbiano rispettato gli obblighi previsti. Non possono rendere disponibile un prodotto che sanno non conforme.

Chi è escluso

Attenzione alle esclusioni: il CRA non si applica a prodotti digitali già disciplinati da normative UE settoriali con requisiti di cybersicurezza equivalenti (dispositivi medici, prodotti aeronautici, automobili, attrezzature marittime). È escluso anche il software open source fornito senza intento commerciale; il CRA si applica invece all’open source destinato in ultima istanza ad attività commerciali (ad es. integrato in servizi o prodotti a pagamento). Sono escluse anche le applicazioni SaaS (Software as a Service) e i servizi cloud puri.

Tabella: Soggetti obbligati e responsabilità

Le categorie di prodotti: standard, importanti, critici

Il Regolamento di esecuzione (UE) 2025/2392, pubblicato il 1° dicembre 2025, ha definito tecnicamente le categorie di prodotti importanti (Allegato III) e critici (Allegato IV). La classificazione determina il percorso di valutazione della conformità richiesto: più è critico il prodotto, più è stringente la procedura.

Nota: la classificazione si basa sulla funzionalità principale del prodotto. Un dispositivo che svolge la funzione principale di una categoria Importanti o Critici non può ricorrere all’autovalutazione, indipendentemente da come viene commercializzato.

Le scadenze operative dettagliate

Il CRA introduce un sistema di scadenze graduate. Non si tratta di una singola data di adeguamento: il regolamento entra progressivamente in vigore con obblighi diversi a seconda del soggetto e del tipo di attività. Errore comune è aspettare il 2027: il 2026 porta già obblighi operativi con sanzioni attive.

Focus sulla scadenza del settembre 2026: microimprese e piccole imprese godono di una parziale esenzione: non potranno essere sanzionate per il mancato rispetto del solo termine delle 24 ore per l’allarme rapido. Per tutto il resto degli obblighi di notifica, anche le PMI sono pienamente soggette.

Gli obblighi principali per i fabbricanti

L’Allegato I del CRA definisce i requisiti essenziali di cybersicurezza che si articolano in due parti: requisiti relativi alle proprietà del prodotto (Parte I) e requisiti relativi alla gestione delle vulnerabilità (Parte II).

Requisiti di progettazione (secure by design)

• Superficie di attacco ridotta: il prodotto deve essere consegnato con una configurazione sicura di default, con funzionalità non necessarie disabilitate.
• Protezione da accessi non autorizzati: meccanismi di autenticazione, controllo degli accessi, protezione dei dati in transito e a riposo.
• Riservatezza e integrità dei dati: i dati personali, finanziari e di altro tipo memorizzati, trasmessi o elaborati devono essere protetti.
• Resilienza agli attacchi DoS: il prodotto deve resistere agli attacchi di tipo denial-of-service che lo rendano inaccessibile.
• Minimizzazione dei dati: il prodotto deve raccogliere ed elaborare solo i dati strettamente necessari alla sua funzionalità.

Gestione delle vulnerabilità (lifecycle security)

• SBOM (Software Bill of Materials): il fabbricante deve identificare e documentare tutti i componenti software del prodotto, incluse librerie e moduli di terze parti, in un elenco strutturato e aggiornato.
• Monitoraggio continuo: il fabbricante deve monitorare le vulnerabilità nei componenti del prodotto per tutto il ciclo di vita (minimo 5 anni dalla messa in commercio).
• Patch e aggiornamenti di sicurezza: devono essere forniti tempestivamente, separabili dagli aggiornamenti funzionali e distribuibili in modo sicuro.
• Divulgazione coordinata delle vulnerabilità (CVD): il fabbricante deve disporre di una policy pubblica per la gestione e la segnalazione responsabile delle vulnerabilità.

Obblighi di notifica (Art. 14, operativi dall’11 set 2026)

Dal settembre 2026 ogni fabbricante deve notificare all’ENISA (tramite la piattaforma unica) e al CSIRT nazionale (in Italia: ACN – Agenzia per la Cybersicurezza Nazionale):

Nota per le microimprese e piccole imprese: non sono sanzionabili per il solo ritardo nelle 24 ore dell’allarme rapido. Tutti gli altri obblighi di notifica si applicano integralmente.

Il sistema delle sanzioni (Art. 64)

L’Articolo 64 del Regolamento (UE) 2024/2847 articola le sanzioni su tre livelli progressivi di gravità. Le sanzioni sono stabilite e applicate dagli Stati membri, che devono garantire che siano effettive, proporzionate e dissuasive.

Oltre alle sanzioni pecuniarie, le autorità di vigilanza del mercato possono ordinare il ritiro dal mercato o il richiamo del prodotto, limitarne o vietarne temporaneamente la distribuzione e disporre misure correttive urgenti. Per le organizzazioni più piccole (microimprese e PMI), le sanzioni tengono conto della capacità economica, ma non sono azzerate: la proporzionalità non equivale all’esenzione.

CRA vs NIS2: differenze e sovrapposizioni

CRA e NIS2 condividono l’obiettivo di elevare il livello di cybersicurezza europeo, ma operano su piani distinti e complementari. Molte aziende sono soggette a entrambi: è fondamentale capire dove si sovrappongono e dove divergono, per evitare duplicazioni e garantire la coerenza dei processi.

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Chi deve applicare entrambi: un’azienda manifatturiera italiana che produce macchinari con firmware connesso e supera le soglie dimensionali NIS2 (50 dipendenti o 10 M€ di fatturato, nel settore manifatturiero classificato come “importante”) sarà soggetta sia al CRA per il prodotto sia alla NIS2 per la propria organizzazione. I processi di notifica incidenti devono essere coordinati per garantire coerenza verso ENISA e ACN.

L’impatto sulla supply chain e sulle PMI italiane

Per il tessuto produttivo italiano fatto di PMI manifatturiere, industriali, tecnologiche e di distribuzione, il CRA è una norma con un impatto spesso sottovalutato. Il punto critico non è se un’azienda “fa cybersecurity”: è capire se progetta, vende, importa, integra o modifica qualcosa che contiene software, firmware, connettività o componenti digitali.

Molte PMI non si percepiscono come produttori digitali, ma ogni giorno lavorano con prodotti che incorporano tecnologia: un macchinario industriale con firmware, un dispositivo di automazione connesso, un sistema di controllo con interfaccia software. Tutti questi prodotti, se venduti o distribuiti nel mercato UE, rientrano nel perimetro del CRA.

La pressione che arriva dalla filiera

Uno degli effetti più concreti del CRA sarà la pressione a cascata lungo la supply chain. Chi immette un prodotto sul mercato UE dovrà dimostrare che quel prodotto è stato progettato e mantenuto secondo i requisiti di sicurezza. Questo significa che i grandi committenti chiederanno garanzie ai fornitori, agli integratori, ai sviluppatori software, ai manutentori. Chi non sarà in grado di rispondere rischia di perdere contratti, non di ricevere solo sanzioni.

Le informazioni che spesso mancano nelle PMI:

• L’elenco dei componenti software (SBOM) dei propri prodotti, incluse le librerie di terze parti e le loro versioni
• La responsabilità degli aggiornamenti del firmware o del software embedded: chi lo fa, con quale frequenza, con quale processo
• La procedura di gestione delle vulnerabilità: cosa succede se viene scoperta una falla nel prodotto dopo la vendita
• La durata del supporto: per quanto tempo verrà garantito il supporto di sicurezza (il CRA chiede minimo 5 anni)

Il rischio principale non è tecnico: è organizzativo. Il CRA obbliga le aziende a rendere visibile e gestibile ciò che spesso è implicito, frammentato tra ufficio tecnico, produzione, fornitori software, manutentori e rivenditori.

Roadmap operativa: come prepararsi al CRA

Il Cyber Resilience Act non chiede alle aziende di essere perfette il giorno dell’applicazione: chiede di essere pronte. La finestra di lavoro è adesso. Ecco una roadmap strutturata in 5 fasi.

Fase 1 — Mappatura del perimetro (entro Q3 2025, ma è già urgente)

1. Inventario prodotti: identificare tutti i prodotti dell’azienda che contengono elementi digitali (hardware, software, firmware, componenti connessi)
2. Classificazione CRA: per ciascun prodotto, stabilire se rientra nella categoria Standard, Importanti Classe I, Importanti Classe II o Critici sulla base degli Allegati III e IV del Regolamento di esecuzione (UE) 2025/2392
3. Mappatura dei ruoli: per ogni prodotto, definire se l’azienda è fabbricante, importatore o distributore ai sensi del CRA

Fase 2 — Gap analysis tecnica e organizzativa (Q4 2025 — Q1 2026)

4. Valutazione dei requisiti Allegato I: confrontare i propri prodotti con i requisiti essenziali di cybersicurezza (secure by design, gestione accessi, aggiornamenti, ecc.)
5. Analisi della documentazione tecnica esistente: la documentazione richiesta dal CRA (All. VII) include descrizione del prodotto, risultati dell’analisi del rischio, misure di sicurezza adottate, procedure di test e aggiornamento
6. Verifica supply chain: identificare fornitori di componenti software e firmware, verificare quali hanno obblighi CRA propri e quali richiedono contratti di sicurezza aggiornati

Fase 3 — Implementazione processi di vulnerability management (Q1-Q2 2026)

7. Creazione o aggiornamento della SBOM: documento strutturato (formati SPDX o CycloneDX) con tutti i componenti software del prodotto, incluse versioni e licenze
8. Processo interno di rilevazione e gestione vulnerabilità: chi monitora, chi classifica, chi decide, chi notifica e con quali strumenti
9. Policy di divulgazione coordinata (CVD): canale pubblico (es. pagina security.txt o security@dominio) per ricevere segnalazioni di ricercatori e terzi
10. Predisposizione del processo di notifica ENISA/ACN: prima della scadenza dell’11 settembre 2026, il processo deve essere testato e funzionante

Fase 4 — Conformità e certificazione (Q3 2026 — Q2 2027)

11. Percorso di valutazione della conformità: per i prodotti Standard: autovalutazione + Dichiarazione di Conformità UE; per Importanti Classe I: verifica standard armonizzati; per Importanti Classe II e Critici: selezione e coinvolgimento di un organismo notificato (disponibile dal 11 giugno 2026)
12. Aggiornamento marcatura CE: aggiornare la documentazione CE per includere la conformità al CRA
13. Revisione contrattualistica: aggiornare i contratti con fornitori e partner per includere obblighi CRA, SLA di patching, clausole di notifica incidenti

Fase 5 — Governance e mantenimento (continuo, da Q3 2027)

14. Monitoraggio continuo delle vulnerabilità: sistemi automatici (CVE database, NVD, vendor advisory) per identificare tempestivamente vulnerabilità nei componenti usati
15. Aggiornamenti di sicurezza regolari: processo definito e documentato per il rilascio di patch e la comunicazione agli utenti
16. Revisione periodica della SBOM: ad ogni aggiornamento significativo del prodotto, aggiornare l’elenco dei componenti
17. Formazione interna: sensibilizzazione continua di team tecnico, produzione, acquisti e management sui requisiti CRA e sulle procedure operative

FAQ e People Also Ask – Le domande più frequenti sul Cyber Resilience Act

Questa sezione raccoglie le domande reali che utenti e professionisti pongono a Google e alle AI su CRA, NIS2 e conformità cybersecurity prodotti.

Conclusione: la cybersicurezza non è più un accessorio

Il Cyber Resilience Act non è l’ennesimo adempimento burocratico europeo. È un cambio strutturale nel modo in cui la sicurezza viene concepita, progettata e certificata nei prodotti digitali. Il messaggio è diretto: un prodotto digitale non può considerarsi davvero pronto se non è stato pensato anche per resistere. La domanda fondamentale che ogni azienda deve porsi cambia: non più solo “il prodotto funziona?”, ma anche “è documentato, aggiornabile, monitorabile e gestibile quando emerge una vulnerabilità?”

Chi si muove con anticipo trasforma l’obbligo in un vantaggio competitivo: processi più robusti, supply chain più affidabile, fiducia dei clienti, accesso a mercati che richiedono conformità. Chi aspetta rischia di trovarsi nel settembre 2026 con obblighi di notifica già attivi  e sanzioni  senza le basi operative per rispettarli. La finestra di lavoro è adesso.

Alchimie Digitali affianca le aziende nel valutare il proprio livello di esposizione normativa e tecnica rispetto al Cyber Resilience Act, progettando percorsi di adeguamento ordinati, comprensibili e sostenibili.

Fonti: Regolamento (UE) 2024/2847 (GU UE 20.11.2024) · Regolamento di esecuzione (UE) 2025/2392 (GU UE 1.12.2025) · Commissione Europea – digital-strategy.ec.europa.eu · ENISA · D.Lgs. 138/2024 (recepimento NIS2 in Italia) · Linee Guida ACN versione 2.0, dicembre 2025

Ultimo aggiornamento: maggio 2026

In sintesi – SPF, DKIM e DMARC proteggono il dominio aziendale solo se rispecchiano davvero tutte le sorgenti di invio: server interni, CRM, newsletter, gestionali e piattaforme esterne. Una configurazione realizzata anni fa può non includere più i servizi aggiunti nel tempo, lasciando il dominio esposto a spoofing e impersonificazione. DMARC produce report che segnalano fallimenti e tentativi di abuso ma solo se qualcuno li legge e li interpreta. La posta elettronica aziendale non va solo fatta funzionare: va governata.

La posta elettronica aziendale è uno di quei servizi che vengono dati per scontati fino al giorno in cui qualcosa smette di funzionare. Una newsletter finisce nello spam. Un gestionale non recapita più le notifiche. Un cliente riceve una falsa richiesta di pagamento. Un fornitore segnala un messaggio sospetto. Oppure il dominio aziendale viene usato — o tentato di essere usato — per inviare email che sembrano legittime ma non lo sono.

In molti casi, quando si comincia a indagare, la risposta è sempre la stessa: “Ma la posta ha sempre funzionato.”

Ed è proprio qui il problema.

Una configurazione che sembrava corretta dieci anni fa non è detto che sia corretta oggi. Nel frattempo sono cambiati i provider, sono aumentate le piattaforme esterne, sono entrati in azienda CRM, gestionali, sistemi di ticketing, newsletter, servizi cloud, firme automatiche, inoltri, vecchi server rimasti accesi e account configurati manualmente. La posta elettronica non passa più soltanto dal “server mail dell’azienda”. Spesso esce da molti punti diversi: non sempre censiti, non sempre autorizzati, non sempre firmati correttamente.

SPF, DKIM e DMARC servono proprio a mettere ordine in questo scenario. Ma pubblicare tre record DNS non basta. Il vero lavoro è capire se quei record descrivono davvero il modo in cui l’azienda invia email ogni giorno.

La posta elettronica nasce in un mondo che non esiste più

I primi esperimenti di posta elettronica di rete risalgono al 1971, in un contesto tecnico radicalmente diverso da quello attuale. Allora non esistevano phishing industrializzato, spoofing di dominio, piattaforme marketing cloud, CRM con invii automatici, portali SaaS o supply chain digitali complesse.

L’email si è evoluta nel tempo aggiungendo controlli, policy e strumenti di autenticazione sopra un modello nato quando il livello di fiducia della rete era incomparabilmente più alto. Questo spiega perché molte configurazioni “storiche” continuano a funzionare tecnicamente, ma non sono più adeguate dal punto di vista della sicurezza, della recapitabilità e della governance.

Un server può ancora inviare posta. Un account può ancora spedire messaggi. Un gestionale può ancora produrre notifiche. Una newsletter può ancora partire. Ma questo non significa che tutto sia coerente con SPF, DKIM e DMARC, né che il dominio aziendale sia protetto da abusi o errori silenziosi.

Nel 2026, il tema non è più solo “la posta funziona?”. La domanda corretta è: la posta esce davvero dai server che il dominio dichiara come autorizzati?

SPF, DKIM e DMARC non sono decorazioni DNS

SPF, DKIM e DMARC vengono spesso trattati come tre voci tecniche da sistemare una volta sola. In realtà sono tre strumenti distinti, che funzionano bene soltanto se rappresentano fedelmente l’infrastruttura reale di invio.

SPF indica quali server sono autorizzati a inviare posta per conto di un dominio. Il problema è che molte aziende, nel tempo, accumulano servizi su servizi: Microsoft 365, Google Workspace, CRM, piattaforme newsletter, gestionali, sistemi di fatturazione, ticketing, portali HR, software verticali. Ogni servizio deve essere incluso correttamente. Ma SPF ha anche un limite tecnico critico: la valutazione non deve superare i 10 meccanismi che causano query DNS aggiuntive (come definito dall’RFC 7208). Se il record diventa troppo esteso o disordinato, può fallire restituendo un PermError — proprio mentre cerca di autorizzare troppe sorgenti. E quando SPF fallisce in questo modo, DMARC perde uno dei suoi due pilastri di allineamento.

Il punto è questo: SPF, DKIM e DMARC non servono a “mettere il bollino” sulla posta. Servono a dichiarare, verificare e monitorare l’identità tecnica delle email aziendali.

Se ciò che è scritto nei DNS non corrisponde a ciò che accade davvero, DMARC comincia a mostrare il problema.

Quando DMARC segnala un fallimento, di solito ha ragione

DMARC non è capriccioso: confronta quello che il dominio dichiara con quello che i server riceventi osservano. Se una newsletter parte da una piattaforma non autorizzata, DMARC rileva un fallimento. Se un gestionale invia email senza DKIM configurato correttamente, DMARC rileva un fallimento. Se un account viene usato tramite il server SMTP sbagliato, DMARC rileva un fallimento. Se un vecchio server interno continua a spedire posta — anche se nessuno lo considera più parte dell’infrastruttura ufficiale — DMARC rileva un fallimento.

In altre parole, DMARC non scopre solo gli attacchi. Scopre anche il disordine.

E nelle aziende, il disordine della posta elettronica è molto più comune di quanto sembri.

Il problema dei vecchi server e delle configurazioni ereditate

Molte infrastrutture email aziendali non sono state progettate da zero in modo ordinato. Sono state costruite nel tempo: un provider cambiato, un server migrato, un gestionale aggiunto, una newsletter esternalizzata, un dominio secondario, un sistema di ticketing, un vecchio applicativo che manda notifiche automatiche, un server SMTP interno rimasto attivo “perché tanto serve ancora”.

Questa stratificazione genera debito tecnico. Non solo codice vecchio o software non aggiornato: anche una configurazione che nessuno ha più il coraggio, il tempo o la memoria storica per toccare. La posta continua a funzionare, quindi non viene analizzata. Ma nel frattempo i criteri antispam si sono irrigiditi, i grandi provider valutano con maggiore attenzione l’autenticazione, i clienti sono più esposti a tentativi di frode e i domini aziendali sono diventati asset reputazionali da proteggere.

Una configurazione email vecchia non è per forza sbagliata. Va verificata. Il rischio reale è che l’azienda continui a ragionare come se esistesse un solo server di posta, mentre nella realtà le email escono da molti sistemi diversi.

Open relay, server mal configurati e relay permissivi

Un tema spesso sottovalutato riguarda i relay. Un open relay è un server che consente a soggetti non autorizzati di inviare posta verso terzi: una configurazione che da decenni dovrebbe essere evitata, perché può essere sfruttata per spam e invii non controllati. Oggi un mailserver ben gestito non dovrebbe accettare traffico da open relay e dovrebbe affidarsi anche a controlli reputazionali, blacklist e meccanismi di blocco.

Ma non esistono solo gli open relay evidenti. Ci sono anche configurazioni meno appariscenti ma comunque problematiche: server con comportamenti troppo permissivi, MTA installati frettolosamente, vecchie macchine lasciate attive, applicativi che usano credenziali generiche, account configurati in modo da usare sempre lo stesso server SMTP anche quando il mittente appartiene a un dominio diverso.

In questi casi il problema può non sembrare grave: l’invio parte, il messaggio arriva, l’utente non vede errori. Ma dal punto di vista dell’autenticazione, quella posta può non essere coerente. Ed è qui che nascono molti fallimenti difficili da diagnosticare.

Il caso degli account multipli e del server di uscita sbagliato

Un esempio molto comune riguarda i client di posta configurati con più account. Un utente gestisce cinque, dieci, a volte decine di caselle condivise o alias. Se il client usa sempre lo stesso server SMTP di uscita — oppure se l’account principale spedisce messaggi per identità diverse senza controlli adeguati — il risultato può essere tecnicamente incoerente.

Dal punto di vista dell’utente è tutto normale: seleziona il mittente, scrive e invia. Dal punto di vista del server ricevente, però, il messaggio racconta un’altra storia: un dominio nel campo mittente, un server di invio non previsto, una firma DKIM assente o non allineata, una policy DMARC che non trova corrispondenza tra ciò che viene dichiarato e ciò che sta accadendo.

Un mailserver ben configurato dovrebbe governare queste situazioni. Ma molte infrastrutture non lo fanno, soprattutto quando sono nate per accumulo o per urgenza.

Le newsletter sono spesso il punto in cui il problema emerge

Le piattaforme newsletter rappresentano uno dei casi più frequenti. Un’azienda decide di inviare comunicazioni commerciali o informative usando una piattaforma esterna. Il reparto marketing carica i contatti, crea il template, imposta il mittente con il dominio aziendale e inizia a spedire. Tutto sembra funzionare.

Ma se la piattaforma non è stata autorizzata correttamente in SPF, se DKIM non è configurato sul dominio, se il dominio di ritorno non è allineato, o se DMARC è già impostato in modo restrittivo, la newsletter può generare fallimenti, finire nello spam o danneggiare la reputazione del dominio.

Il punto non è “la newsletter è fatta male”. Il punto è che ogni piattaforma che invia email per conto dell’azienda deve essere trattata come parte dell’infrastruttura email aziendale. CRM, ERP, gestionali, sistemi di marketing automation, portali per preventivi, software di assistenza, piattaforme di fatturazione e strumenti di ticketing devono essere mappati, verificati e configurati in modo coerente.

DMARC senza monitoraggio è un’occasione sprecata

Uno degli errori più frequenti è pubblicare DMARC e poi non leggere i report. Questo approccio trasforma DMARC in una semplice riga nel DNS, non in uno strumento di sicurezza operativo.

I report DMARC servono a ricostruire cosa accade al dominio: quali server stanno inviando email, quali passano SPF o DKIM, quali falliscono, quali sorgenti sono legittime ma non ancora configurate, quali invii sembrano sospetti. I report aggregati offrono il quadro complessivo; quelli di fallimento — quando disponibili e supportati dal sistema ricevente — forniscono informazioni più granulari sui singoli messaggi.

Questo significa che non basta “mettere l’indirizzo dei report”. Serve qualcuno, o qualcosa, che li riceva, li analizzi e li trasformi in decisioni operative.

Un dominio può avere DMARC attivo e continuare a essere configurato male. Un dominio può ricevere report pieni di segnali utili senza che nessuno li guardi. Un dominio può mostrare tentativi di abuso, sorgenti dimenticate o invii non conformi — e l’azienda se ne accorge solo quando il problema diventa visibile a un cliente, a un fornitore o a un sistema antispam.

I segnali tecnici: SpamAssassin, DMARC e l’intelligence operativa

In molte infrastrutture, i sistemi antispam non si limitano a decidere se una mail è buona o cattiva. Raccolgono segnali, applicano regole, verificano reputazione, autenticazione, contenuto e comportamento. SpamAssassin, per esempio, include un plugin DMARC che verifica se i messaggi rispettano la policy dichiarata e richiede che siano abilitati anche i controlli SPF e DKIM. In base alla configurazione, questi sistemi possono contribuire a rendere disponibili dati utili sui fallimenti.

Il principio è importante: l’autenticazione email produce segnali tecnici che possono essere raccolti, analizzati e usati per capire cosa accade davvero. Senza monitoraggio, quei segnali restano rumore. Con il monitoraggio, diventano intelligence operativa.

Il rischio più serio non è lo spam: è l’impersonificazione

Quando si parla di SPF, DKIM e DMARC, molte aziende pensano prima di tutto alla recapitabilità. “Mi serve per non finire nello spam.” È vero, ma è solo una parte del problema.

Il tema più serio è l’impersonificazione. Se un attaccante riesce a inviare email che sembrano provenire dal dominio aziendale, può tentare frodi verso clienti, fornitori, amministrazione, direzione o reparti sensibili: una falsa richiesta di pagamento, una modifica IBAN, una comunicazione tecnica contraffatta, una richiesta urgente del management.

Quando l’attacco è rivolto a figure apicali o soggetti ad alto valore, si parla spesso di whaling — una forma mirata di phishing. In questo contesto, DMARC non elimina il rischio, ma può ridurre la possibilità che email non allineate al dominio vengano considerate legittime dai server riceventi, e può aiutare a ricostruire tentativi di abuso attraverso i report.

Il punto non è poter dire “avevamo DMARC”. Il punto è poter dimostrare che il dominio è stato configurato, monitorato e governato in modo coerente nel tempo.

Il falso senso di sicurezza: “abbiamo Microsoft 365” o “abbiamo Google Workspace”

Microsoft 365 e Google Workspace offrono strumenti solidi per la gestione della posta, ma non risolvono automaticamente tutto ciò che ruota intorno al dominio aziendale. Se tutte le email partissero solo da Microsoft o solo da Google, la situazione sarebbe più semplice. Ma raramente è così.

Molte aziende usano piattaforme esterne per newsletter, CRM, fatturazione, ticketing, preventivi, gestionali, e-commerce, portali clienti, sistemi di notifica, software verticali. Alcune usano più domini. Altre hanno sottodomini. Altre ancora hanno vecchi server interni che continuano a inviare email per applicativi legacy.

La domanda giusta non è: “Uso Microsoft 365 o Google Workspace, sono a posto?”

La domanda giusta è: tutte le email che sembrano uscire dal mio dominio passano davvero da sorgenti autorizzate, firmate e monitorate?

Cosa dovrebbe controllare un’azienda

Un controllo serio della posta elettronica aziendale non si limita a verificare se SPF, DKIM e DMARC esistono. Deve ricostruire il perimetro reale. In concreto, bisogna verificare quali domini e sottodomini inviano email, quali server sono autorizzati da SPF, se il record SPF supera o rischia di superare il limite dei 10 lookup DNS, quali piattaforme esterne inviano email per conto dell’azienda e se tutte firmano correttamente con DKIM. Vanno verificati l’allineamento DKIM al dominio mittente, la policy DMARC attiva (osservazione, quarantena o rifiuto), dove arrivano i report e chi li interpreta con quale frequenza. Non vanno trascurati i vecchi server SMTP, MTA, relay, inoltri o applicativi legacy, né i client di posta con account multipli che potrebbero usare server di uscita incoerenti. Vanno mappati newsletter, CRM, ERP e gestionali, e vanno analizzati i segnali di spoofing, abuso o configurazioni non autorizzate.

Questa analisi non serve solo a “mettere a posto la posta”. Serve a ridurre una superficie di rischio che spesso resta invisibile finché non produce un danno reale.

Cosa succede quando si passa troppo presto a DMARC reject

Impostare DMARC con policy p=reject può essere la scelta giusta, ma solo quando l’infrastruttura è stata mappata e verificata. Passare troppo presto a una policy restrittiva può bloccare email legittime: newsletter, notifiche di gestionali, messaggi automatici, comunicazioni da CRM, sistemi di ticketing o applicativi verticali.

Per questo l’approccio corretto è progressivo: prima si osserva, poi si mappano le sorgenti, poi si correggono SPF e DKIM, poi si analizzano i report, poi — con ragionevole certezza che gli invii legittimi siano allineati — si passa a una policy più restrittiva.

DMARC non deve essere usato come interruttore. Deve essere usato come processo.

Una configurazione email va mantenuta, non solo realizzata

La posta elettronica aziendale non è un impianto che si configura una volta e poi si dimentica. Ogni nuovo servizio può cambiare lo scenario. Ogni nuovo CRM può aggiungere una sorgente di invio. Ogni nuova piattaforma newsletter può richiedere una firma DKIM. Ogni cambio provider può modificare SPF. Ogni vecchio server lasciato acceso può continuare a produrre traffico non documentato. Ogni report DMARC ignorato può nascondere un segnale importante.

La sicurezza della posta elettronica deve entrare nella manutenzione ordinaria dell’infrastruttura IT — non come attività estetica, ma come presidio di sicurezza, continuità operativa e reputazione digitale.

In sintesi

SPF, DKIM e DMARC sono strumenti fondamentali, ma non bastano se vengono trattati come semplici record DNS da pubblicare una volta e dimenticare. Il tema centrale è la coerenza tra ciò che il dominio dichiara e ciò che l’azienda fa davvero quando invia email. Se la posta esce da server vecchi, piattaforme non censite, CRM non configurati, newsletter senza firma DKIM, account multipli con SMTP incoerenti o relay gestiti male, DMARC fa emergere il problema. E se nessuno legge i report, il problema resta lì.

Una configurazione email che funzionava dieci anni fa non è automaticamente adeguata oggi. Nel frattempo sono cambiati i rischi, i controlli, le aspettative dei provider, la complessità delle infrastrutture e il valore del dominio come identità digitale.

La posta elettronica non va solo fatta funzionare. Va governata.

Parla con Alchimie Digitali per una verifica della configurazione email aziendale. Se vuoi capire se la tua posta aziendale è davvero configurata in modo coerente, non limitarti a controllare che “funzioni”. Verifica da dove escono le email, chi le firma, quali server sono autorizzati e chi sta leggendo i segnali che DMARC produce.

FAQ

In sintesi – L’Agenzia per la Cybersicurezza Nazionale (ACN) ha pubblicato le nuove linee guida ufficiali per la configurazione della posta elettronica. Il documento indica come implementare correttamente SPF, DKIM e DMARC – i tre protocolli che autenticano il mittente e proteggono il dominio da phishing e spoofing. Se la tua posta non è configurata secondo questi standard, rischi che le email vengano filtrate come spam o rifiutate dai server destinatari, spesso senza che tu lo sappia. Se hai affidato la gestione della posta a un tecnico o a un’agenzia, è il momento di chiedere una verifica.

L’ACN ha pubblicato le nuove linee guida per l’autenticazione email

L’Agenzia per la cybersicurezza nazionale ha pubblicato le Linee guida per la configurazione del servizio di posta elettronica per l’autenticazione del mittente, con l’obiettivo di rafforzare l’affidabilità del servizio di posta elettronica di tutte le organizzazioni interessate.

Non si tratta di raccomandazioni generiche: è un framework tecnico operativo, rivolto a tutte le organizzazioni pubbliche e private, che stabilisce come configurare correttamente tre protocolli ormai fondamentali per qualsiasi infrastruttura email.

Il documento ufficiale è disponibile sul sito ACN: Framework di Autenticazione per la Posta Elettronica

Perché la posta elettronica è un punto critico

Il funzionamento della posta elettronica si basa sul protocollo SMTP, che non incorpora nativamente meccanismi di autenticazione del mittente né di protezione dell’integrità dei messaggi. Queste vulnerabilità espongono le organizzazioni al rischio di spoofing, phishing e manomissione del contenuto durante il transito.

In termini pratici questo significa che, senza protezioni adeguate, chiunque potrebbe inviare email fingendo di provenire dal tuo dominio — spacciandosi per te con i tuoi clienti, fornitori o colleghi — senza che tu lo sappia e senza che sia necessario accedere al tuo account.

Il problema non è teorico: quasi una organizzazione italiana su quattro non è in grado di impedire a soggetti terzi di inviare email fraudolente a suo nome.

I tre protocolli al centro delle linee guida

Le linee guida dell’ACN forniscono indicazioni operative per la corretta implementazione di SPF, DKIM e DMARC: tre standard ampiamente adottati a livello internazionale che, se configurati in modo coerente, permettono di aumentare il livello di fiducia nei messaggi ricevuti e di limitare l’uso fraudolento dei domini.

DMARC introduce anche il concetto di allineamento: verifica che il dominio visibile nel campo “Da:” corrisponda a quello autenticato via SPF o DKIM, intercettando le impersonificazioni anche nei casi tecnici più sofisticati.

Non è solo sicurezza: è anche recapitabilità

Questo è l’aspetto che le aziende sottovalutano più spesso. I principali provider di posta — Gmail, Microsoft 365, Yahoo — hanno progressivamente irrigidito i loro filtri antispam. Oggi valutano attivamente la presenza e la correttezza di SPF, DKIM e DMARC. Un dominio privo di questi record, o con una configurazione errata, viene automaticamente trattato con più sospetto.

Il risultato è che puoi inviare un preventivo, una conferma d’ordine, una risposta urgente — e il destinatario non la riceve, o la trova nello spam giorni dopo. Il tuo server non ti segnala nessun errore: l’email parte regolarmente. Il problema avviene in silenzio, sul lato del destinatario.

Il collegamento con NIS 2 e il quadro normativo italiano

Le linee guida ACN non sono un documento isolato. Le misure descritte si inseriscono nel contesto della Direttiva NIS 2, del Perimetro di Sicurezza Nazionale Cibernetica e del Regolamento Cloud ACN. In questo scenario, la sicurezza della posta elettronica non è più solo una best practice: per molte organizzazioni diventa un requisito di conformità.

Oggi in Italia sono già stati identificati oltre 21.000 soggetti obbligati dalla NIS 2, di cui almeno 5.000 classificati come essenziali. Per queste realtà, verificare la configurazione della posta non è più rimandabile.

Configurare SPF, DKIM e DMARC: più complesso di quanto sembri

Questi protocolli agiscono sui record DNS del dominio. In teoria bastano poche modifiche. In pratica ci sono insidie frequenti che portano a configurazioni errate, spesso senza che nessuno se ne accorga:

• SPF ha un limite di 10 lookup DNS. Superarlo causa errori su tutte le email in uscita. È un problema comune nelle aziende che usano più servizi in parallelo (CRM, newsletter, gestionale, PEC).
• DKIM richiede la gestione di chiavi crittografiche che vanno protette, ruotate periodicamente e configurate per ogni sorgente di invio.
• Passare subito a p=reject senza una fase di monitoraggio preliminare può bloccare email legittime, creando disservizi immediati.
• L’inoltro automatico delle email (forwarding) può invalidare le verifiche SPF e DKIM se non gestito correttamente.
• I servizi di terze parti — piattaforme di email marketing, CRM, ERP — devono essere esplicitamente inclusi e configurati per firmare con DKIM.

• Vecchi server di posta o MTA installati in modo frettoloso possono comportarsi come relay configurati male, permettendo invii non coerenti con l’identità dichiarata dal dominio.

• Account multipli configurati nello stesso client, se usano sempre il medesimo server di uscita senza controlli adeguati, possono generare invii formalmente funzionanti ma non allineati con SPF, DKIM e DMARC.

L’approccio corretto è graduale: partire con DMARC in monitoraggio per mappare i flussi reali, poi passare a quarantine e reject quando la configurazione è stabile e verificata. 

Avere un record DMARC pubblicato e non monitorarne i report, però, significa perdere gran parte del valore dello strumento. I report servono a capire se qualcuno sta tentando di usare il dominio in modo fraudolento, se una piattaforma legittima è stata dimenticata nella configurazione o se una vecchia impostazione continua a produrre errori silenziosi. In assenza di monitoraggio, DMARC rischia di diventare solo una riga nel DNS, non un presidio reale di sicurezza.

Il punto più delicato è che la posta elettronica aziendale raramente passa da un solo canale. Nel tempo si accumulano piattaforme, vecchi server, gestionali, newsletter, account configurati manualmente, inoltri automatici e servizi terzi. Una configurazione che anni fa sembrava corretta può non esserlo più oggi, soprattutto se nessuno ha mai ricostruito davvero tutte le sorgenti che inviano email per conto del dominio.

Cosa fare adesso

Hai un tecnico o un’agenzia che gestisce la tua posta?

Contattali e chiedi una verifica esplicita su questi quattro punti:

1. 1. Il record SPF è presente, corretto e ottimizzato, entro il limite dei 10 lookup?
   2. Tutte le sorgenti che inviano email per conto del dominio sono state mappate?
   3. DKIM è configurato per tutte le sorgenti di invio, non solo per il client principale?
   4. Le piattaforme esterne, come CRM, newsletter, gestionali e ticketing, firmano correttamente con DKIM?
   5. È presente un record DMARC con una policy coerente con lo stato reale della configurazione?
   6. I report DMARC vengono monitorati regolarmente e interpretati da qualcuno?
   7. Esistono vecchi server, relay, inoltri automatici o account configurati manualmente che possono generare invii non allineati?

Non dare per scontato che sia già tutto a posto. La posta “che funziona” non è la stessa cosa della posta “correttamente autenticata”.

Gestisci direttamente la tua infrastruttura IT?

Segui il percorso raccomandato dall’ACN:

1. 1. Avvia DMARC in modalità `p=none` con indirizzi di report configurati.
   2. Analizza i report per 2–4 settimane e mappa tutte le sorgenti reali di invio.
   3. Verifica che SPF includa solo le sorgenti necessarie e che resti entro il limite dei 10 lookup.
   4. Configura DKIM in modo completo su tutte le sorgenti, comprese piattaforme newsletter, CRM, ERP, gestionali e sistemi automatici.
   5. Controlla che non esistano vecchi server, relay, MTA dimenticati, forwarding o account configurati in modo incoerente.
   6. Passa progressivamente a `p=quarantine` e poi a `p=reject` solo quando la configurazione è stabile e verificata.

In sintesi

Le linee guida pubblicate dall’ACN chiariscono un punto che per anni è stato sottovalutato: la posta elettronica non è un servizio “che funziona o non funziona”, ma un’infrastruttura che deve essere configurata, monitorata e governata.

SPF, DKIM e DMARC non sono più elementi opzionali o tecnici “da specialisti”: sono il livello minimo per garantire affidabilità, protezione del dominio e continuità operativa nelle comunicazioni.

Il punto, però, non è soltanto pubblicare tre record DNS. Il vero lavoro consiste nel verificare se la posta aziendale rispecchia ancora il modo in cui l’organizzazione comunica oggi: server autorizzati, piattaforme esterne correttamente firmate, relay chiusi, account configurati in modo coerente e report DMARC realmente monitorati.

In questo scenario, il vero rischio non è solo subire un attacco, ma non accorgersi che qualcosa non sta funzionando correttamente: email che non arrivano, dominio utilizzato da terzi, reputazione compromessa senza segnali evidenti.

Le indicazioni dell’ACN offrono oggi un riferimento chiaro. Il punto non è tanto “implementarle”, ma essere consapevoli dello stato reale della propria infrastruttura email e delle sue implicazioni in termini di sicurezza e conformità.

Se vuoi capire perché una configurazione email apparentemente corretta può comunque generare errori, blocchi o segnali compatibili con spoofing e phishing, leggi anche il nostro approfondimento su vecchi server, relay configurati male, newsletter non allineate e report DMARC ignorati.

Fonte ufficiale: ACN — Framework di Autenticazione per la Posta Elettronica Articolo redatto da Alchimie Digitali

FAQ

NIS2 2026: nuovi adempimenti ACN, scadenze e cosa devono fare davvero i soggetti interessati

L’ACN ha pubblicato nuove determinazioni sugli adempimenti NIS2 per i soggetti inseriti nel 2026 e ha aggiornato le modalità di accesso e utilizzo della piattaforma digitale ACN. Il punto chiave è questo: la fase “dichiarativa” sta lasciando spazio a una fase più operativa, strutturata e verificabile.

Come indicato nella comunicazione ufficiale ACN sulle nuove determinazioni NIS2, e nella determina completa ACN sulla piattaforma NIS, il quadro normativo entra ora in una fase pienamente operativa.

Non basta più sapere di essere soggetti NIS. Ora bisogna organizzare ruoli, aggiornare correttamente i dati, censire i fornitori rilevanti, classificare attività e servizi e rispettare una roadmap precisa.

Cosa cambia davvero nel 2026

Il 13 aprile 2026 segna il passaggio dalla teoria all’operatività. L’ACN non si limita più a identificare i soggetti, ma impone un modello strutturato di gestione.

Non si tratta di un aggiornamento burocratico. È un cambio di paradigma: la cybersicurezza diventa governance, responsabilità e capacità dimostrabile.

Le scadenze per i soggetti NIS inseriti nel 2026

Per i soggetti che entrano nel perimetro NIS nel 2026, la roadmap è chiara:

• 31 maggio 2026 → Designazione sostituto punto di contatto

• 1 maggio – 30 giugno 2026 → Categorizzazione attività e servizi

• 31 dicembre 2026 → Designazione referente CSIRT

• 1 gennaio 2027 → Obbligo notifica incidenti

• 31 luglio 2027 → Adozione misure di sicurezza di base

Attenzione: queste scadenze non sono universali ma dipendono dalla data di inclusione nel perimetro NIS.

La piattaforma ACN: il vero centro della compliance

La piattaforma digitale ACN non è un semplice portale. È il punto centrale di:

• registrazione

• aggiornamento annuale

• aggiornamento continuo

• categorizzazione servizi

Tutte le comunicazioni ufficiali passano da qui. La qualità dei dati inseriti diventa parte integrante della compliance.

Aggiornamento annuale: cosa va davvero gestito

Dal 15 aprile al 31 maggio, ogni soggetto NIS deve aggiornare:

• dati anagrafici e legali

• organi di amministrazione

• IP e domini

• servizi erogati

• referente CSIRT

• fornitori rilevanti

Non è una formalità. È un processo di allineamento tra organizzazione reale e rappresentazione verso ACN.

Fornitori rilevanti: la sicurezza esce dall’azienda

La determina introduce un punto chiave: la sicurezza della supply chain.

I soggetti NIS devono censire i fornitori che:

• forniscono servizi ICT

• oppure sono critici per la continuità operativa

Per ciascun fornitore vanno indicati dati, paese, CPV e criterio di rilevanza.

Questo significa una cosa: la sicurezza non è più perimetro, ma ecosistema.

Categorizzazione attività e servizi: il vero nodo strategico

Dal 1 maggio al 30 giugno, ogni soggetto deve classificare le proprie attività e servizi.

Questa attività non è solo descrittiva. È la base per:

• analisi di impatto (BIA)

• definizione delle priorità

• costruzione della sicurezza

ACN può verificare a campione e richiedere modifiche.

Ruoli NIS2: non sono nomine simboliche

I ruoli chiave sono:

• Punto di contatto

• Sostituto punto di contatto

• Referente CSIRT

Devono essere persone reali, operative e competenti. In particolare, il referente CSIRT deve essere in grado di gestire incidenti e interfacciarsi con CSIRT Italia.

Il punto critico: la responsabilità è del management

La NIS2 non è un tema IT.

È responsabilità degli organi di amministrazione e direttivi.

Questo comporta:

• responsabilità diretta

• necessità di governance

• obbligo di controllo e supervisione

Chi delega senza controllo è esposto.

Verifiche ACN: non è più un’autodichiarazione

L’ACN può:

• verificare le informazioni

• chiedere integrazioni

• contestare incongruenze

La compliance deve essere coerente, difendibile e documentata.

Cosa devono fare ora le aziende

Le aziende devono partire da qui:

• chiarire il perimetro NIS

• definire i ruoli

• mettere ordine su asset e servizi

• censire i fornitori

• prepararsi alla categorizzazione

• strutturare governance e processi

Chi parte dalla piattaforma senza struttura rischia di costruire una compliance fragile.

Vuoi capire davvero se sei conforme NIS2?

La differenza non è tra chi ha compilato la piattaforma e chi no, ma tra chi ha costruito una struttura solida e chi ha solo dichiarato di averlo fatto.

Se vuoi fare chiarezza sul tuo perimetro NIS, sui fornitori rilevanti e su cosa devi davvero mettere in piedi nei prossimi mesi, puoi confrontarti con noi. Analizziamo la tua situazione attuale e ti diamo una lettura concreta, senza teoria inutile.

Richiedi un confronto diretto qui:

Nota importante: questo strumento non è sostitutivo di una gap analysis ma fornisce una valutazione orientativa. Non sostituisce una consulenza legale né un audit tecnico certificato. Le risposte restano solo nel browser e vengono perse alla chiusura della pagina.

FAQ

Cyber law per privati: a chi rivolgerti quando il digitale rischia di finire in tribunale

Un telefono che si comporta in modo strano. Un accesso che non riconosci. Dati che spariscono, file modificati, contenuti online che ti riguardano e che non dovrebbero esserci.

Il primo errore, in questi casi, è quasi sempre lo stesso: pensare che sia solo un problema tecnico.

In realtà è spesso il momento esatto in cui il digitale smette di essere un disagio operativo e comincia a diventare una questione più delicata — fatta di prove, responsabilità, verifiche, tempi e possibili conseguenze legali.

Il vero problema non è solo capire cosa è successo. È capire a chi rivolgersi prima di compromettere tutto.

Quando un problema digitale diventa una questione legale

Molte situazioni vengono ancora trattate come semplici anomalie informatiche, quando richiedono invece un approccio molto più attento. Non basta “sistemare” un dispositivo, recuperare un accesso o fare qualche controllo superficiale.

Serve capire cosa è accaduto, cosa può essere dimostrato e come muoversi senza peggiorare il quadro complessivo.

Alcune circostanze in cui il digitale incontra il diritto sono più comuni di quanto si pensi: il sospetto che un telefono sia stato controllato o compromesso, accessi non autorizzati a un account email o social, cancellazione o modifica di dati rilevanti, contenuti online diffamatori o lesivi della reputazione, contenziosi tra soci o collaboratori in cui i fatti transitano da dispositivi, file, cronologie e sistemi digitali.

In questi casi, intervenire senza metodo non aiuta. Spesso danneggia.

Il digitale lascia tracce ma ogni intervento eseguito nel modo sbagliato può alterarle, sovrascriverle o renderle inutilizzabili in una fase successiva.

Cos’è davvero il supporto tecnico-forense in ambito digitale

Il supporto tecnico-forense non sostituisce uno studio legale e non è una normale assistenza informatica. È qualcosa di preciso: un intervento specialistico che entra in gioco quando un problema digitale ha riflessi legali, probatori o contenziosi.

In pratica, significa avere accanto qualcuno in grado di analizzare dati e dispositivi con metodo, preservare le informazioni rilevanti, leggere correttamente ciò che è accaduto sul piano tecnico e tradurre quegli elementi in un quadro comprensibile anche per chi deve valutare il caso sotto un profilo giuridico.

Non è solo una questione tecnica. È una questione di metodo, rigore e tempestività.

Tra il tecnico che interviene ma non sempre lavora in ottica probatoria e il legale, che ha bisogno di elementi chiari, verificabili e tecnicamente fondati, si apre spesso un vuoto. Ed è lì che nascono gli errori più gravi: verifiche improvvisate, tracce perse, dati alterati, elementi che diventano difficili da ricostruire o da utilizzare correttamente.

Dove si colloca Alchimie Digitali in questo scenario

È esattamente in questo spazio che opera Alchimie Digitali, con un approccio che unisce competenze tecniche, capacità di analisi e supporto strutturato nei contesti più delicati.

Quando il digitale incontra il diritto, il rischio maggiore è muoversi tardi o muoversi male. Per questo è fondamentale avere accanto un interlocutore che sappia leggere il problema per quello che è davvero, senza ridurlo a una semplice anomalia tecnica.

Il servizio di assistenza forense e al contenzioso è pensato per affiancare privati, aziende, professionisti e legali nei casi in cui serva una lettura tecnica strutturata — utile a comprendere i fatti e a gestirli correttamente.

A supporto di quest’area opera Periti Digitali, la business unit specializzata nelle attività forensi e nelle analisi tecniche avanzate. Una struttura dedicata che permette di affrontare casi sensibili con maggiore profondità, metodo e coerenza operativa, soprattutto quando la componente digitale non può essere trattata con leggerezza.

Quando è il momento giusto per chiedere supporto

La risposta breve: prima di quanto si pensi.

Molte persone si attivano troppo tardi. Prima provano a risolvere da sole, poi chiedono a un conoscente, poi cambiano password, eliminano contenuti, aggiornano dispositivi — convinte di migliorare la situazione. Nel frattempo, alcune tracce cambiano, spariscono o diventano molto più difficili da interpretare.

Nel digitale, il tempo non sempre chiarisce. A volte compromette.

Vale la pena valutare un supporto tecnico-forense quando:

Le prove possono essere sovrascritte. I dati possono essere alterati. E anche un intervento fatto in buona fede può rendere più complessa la ricostruzione dei fatti. Non sempre un caso finisce in tribunale — ma quando accade, ciò che è stato fatto prima pesa moltissimo.

Cyber law per privati: perché questa espressione ha senso oggi

L’espressione cyber law può sembrare tecnica o distante, ma descrive qualcosa di molto concreto: l’area in cui tecnica, analisi e contesto legale devono dialogare bene, senza improvvisazioni.

È un’area reale, in crescita costante, che riguarda sempre più persone comuni — non solo aziende strutturate o soggetti esposti. Chiunque utilizzi dispositivi digitali nella propria vita professionale o personale può trovarsi, prima o poi, in una situazione in cui ciò che ha fatto o non ha fatto sul piano tecnico diventa rilevante.

Capire presto, con il metodo giusto, è spesso il primo passo per proteggersi davvero.

Hai un dubbio su un accesso anomalo, un dispositivo compromesso o una situazione digitale potenzialmente delicata? Valutare subito il contesto con il giusto supporto può fare la differenza tra un problema gestito e un problema aggravato.

Domande frequenti dei clienti

Nota: le informazioni contenute in questa pagina hanno finalità divulgativa e non sostituiscono il parere di un avvocato o di un consulente legale. Ogni situazione va valutata caso per caso.

NIS2: perché molte aziende si fermano all’analisi (e cosa succede dopo)

Basta una gap analysis per essere conformi alla NIS2? No, non basta. Eppure questa è la trappola in cui stanno cadendo molte organizzazioni italiane: commissionano un’analisi iniziale, ricevono una fotografia della loro situazione e si fermano lì.

Non per disinteresse. Non per mancanza di comprensione. Ma perché adeguarsi alla NIS2 è un percorso strutturato, non un documento da archiviare e molte aziende non sono ancora pronte ad affrontarlo nella sua interezza.

Il rischio sottovalutato di fermarsi alla sola analisi

La gap analysis è necessaria: serve a capire dove si è, quali sono le criticità reali e quali i rischi prioritari. Ma sapere dove sono i problemi non li risolve. Avere un documento, una checklist o un report non equivale a essere conformi.

La NIS2 non richiede consapevolezza. Richiede azione.

Fermarsi all’analisi genera un problema specifico e spesso sottovalutato: la falsa sicurezza. L’azienda crede di aver “fatto qualcosa”, mentre di fatto non ha ancora intrapreso nulla di strutturalmente rilevante ai fini della normativa.

Cosa significa davvero adeguarsi alla NIS2

In Italia la NIS2 è stata recepita con il D.Lgs. 138/2024, in vigore dal 18 ottobre 2024. L’autorità competente è l’ACN (Agenzia per la Cybersicurezza Nazionale) che gestisce il portale NIS, definisce le specifiche tecniche e supervisiona la conformità.

La normativa introduce un meccanismo di adeguamento progressivo, che parte dalla comunicazione ufficiale di ACN con cui l’azienda viene inserita nell’elenco dei soggetti essenziali o importanti. Da quel momento scattano due scadenze precise e non negoziabili:

• Entro 9 mesi dalla comunicazione ACN: devono essere attivi i processi di gestione e notifica degli incidenti significativi al CSIRT Italia.
• Entro 18 mesi dalla comunicazione ACN: devono essere implementate tutte le misure tecniche e organizzative di sicurezza previste dal decreto.

Poiché le prime comunicazioni ACN sono partite ad aprile 2025, per la maggior parte dei soggetti questi termini scadono rispettivamente a gennaio 2026 e ottobre 2026.

L’adeguamento richiede interventi concreti su più livelli: misure tecniche reali, processi aziendali strutturati, formazione del personale, sistemi di monitoraggio attivi, procedure di gestione degli incidenti definite e testate. Non è un documento. È un sistema che deve funzionare.

Ed è, soprattutto, una responsabilità diretta del management: il D.Lgs. 138/2024 prevede per i soggetti essenziali sanzioni fino a 10 milioni di euro o il 2% del fatturato mondiale annuo, con responsabilità personali anche per le figure di direzione e controllo.

Il punto di contatto CSIRT: cosa è davvero (e cosa non è)

Uno degli elementi più citati — e più fraintesi — della NIS2 è il punto di contatto CSIRT. Chiarire cosa sia realmente è fondamentale per non costruire su basi errate.

Il punto di contatto CSIRT è il riferimento ufficiale dell’organizzazione verso il Computer Security Incident Response Team nazionale per la notifica degli incidenti, la gestione delle comunicazioni ufficiali e il coordinamento in caso di eventi critici.

Avere il punto di contatto non significa però essere conformi. È solo uno degli elementi richiesti.

Ciò che fa davvero la differenza non è il titolo della persona che ricopre il ruolo, ma il contesto organizzativo in cui opera. Può essere anche una figura interna non strettamente tecnica, a condizione che sia inserita in una struttura che le consenta di agire correttamente: con processi chiari di gestione degli incidenti, supporto tecnico adeguato, strumenti di monitoraggio e procedure interne definite.

Le competenze necessarie sono distribuite, non individuali: capacità di coordinamento, comprensione dei processi aziendali, accesso a competenze tecniche, capacità di attivare le procedure corrette nei tempi richiesti dalla normativa, pre-notifica entro 24 ore, notifica formale entro 72 ore, relazione finale entro 30 giorni.

La domanda giusta non è “chi è il punto di contatto?” ma “quanto l’azienda è pronta a supportarlo?”

Un approccio sostenibile: il percorso a fasi

Proprio per questa complessità, il modo corretto di affrontare la NIS2 non è un pacchetto unico e rigido. È un percorso progressivo, costruito per accompagnare l’organizzazione nel tempo senza bloccarla.

Il percorso si articola in fasi con obiettivi e output precisi: analisi reale dello stato attuale, definizione delle priorità e della roadmap, formazione del board e del management, implementazione tecnica delle misure, formazione operativa e adeguamento dei processi, monitoraggio e continuità operativa.

La formazione del board è un passaggio chiave, spesso sottovalutato. La NIS2 responsabilizza esplicitamente i vertici aziendali: i dirigenti devono seguire percorsi formativi sulla sicurezza informatica, approvare le politiche di sicurezza e monitorarne l’implementazione. Prima di intervenire sull’azienda, chi prende le decisioni deve avere piena consapevolezza dei rischi e delle proprie responsabilità personali.

Strutturare il percorso a fasi consente all’azienda di iniziare, valutare, comprendere il valore del lavoro svolto e decidere come proseguire, senza vincoli insostenibili e senza rischiare di paralizzarsi di fronte alla complessità complessiva.

Adeguamento NIS2: dalla strategia all’operatività, con un unico partner

Adeguarsi alla NIS2 è obbligatorio. Il modo in cui ci si arriva deve essere sostenibile.

Il valore di avere un unico partner lungo tutto il percorso, dalla prima analisi fino alla piena operatività, sta proprio in questo: non si limita a indicare i problemi, ma li affronta e li risolve insieme all’azienda. Nella definizione della strategia, nella formazione del management, nell’implementazione tecnica, nella riorganizzazione dei processi, nella continuità operativa.

Il primo passo: consapevolezza reale della propria situazione

Il momento più delicato è spesso proprio l’inizio. Prendere consapevolezza delle proprie vulnerabilità non è comodo. Ma è inevitabile.

Se la tua azienda rientra tra i soggetti NIS2, perché opera in uno dei 18 settori previsti, perché supera determinate soglie dimensionali, o perché è parte di una filiera rilevante, non si tratta più di valutare se adeguarsi. Si tratta di capire come farlo, con quali priorità e con quale sostenibilità.

Il primo passo è sempre un’analisi reale dello stato attuale. Solo così è possibile costruire una roadmap efficace e iniziare nel modo giusto.

La NIS2 non si acquista. Si costruisce. È un percorso, non un documento. L’importante non è iniziare tutto subito: è iniziare nel modo giusto.

FAQ

Workshop NIS2 a Modena: cosa abbiamo costruito insieme (e da dove si riparte)