La sicurezza della PEC si regge su quattro cose. Tutte le connessioni sono cifrate con TLS (IMAPS, POP3S, HTTPS, SMTP con STARTTLS) o con IPSec. Il gestore firma digitalmente ogni messaggio in uscita, e il gestore del destinatario verifica quella firma. L’accesso alla casella richiede sempre l’autenticazione. Le ricevute di accettazione e di consegna danno valore legale all’invio. A questi protocolli, fissati dalle regole tecniche nazionali, chi usa la PEC deve aggiungere le proprie misure: credenziali protette, autenticazione a più fattori, integrazioni API configurate in modo corretto e indirizzi dei destinatari verificati su fonti ufficiali.
In breve
- Le regole tecniche del DM 2 novembre 2005 impongono canali cifrati (TLS o IPSec), la firma del gestore sui messaggi e l’autenticazione obbligatoria dell’utente.
- La PEC certifica la trasmissione: data, ora, integrità e consegna. Non certifica chi ha scritto materialmente il messaggio né la verità di ciò che contiene.
- Per l’accesso alla casella sono previsti password, CIE, CNS, SPID e token dedicati. Con la REM l’autenticazione forte diventa obbligatoria.
- Le integrazioni via API vanno protette con OAuth 2.0 secondo le linee guida AgID, senza cedere a terzi le credenziali della casella.
- Inviare a indirizzi PEC presi da fonti ufficiali e aggiornate fa parte della sicurezza tanto quanto la cifratura.
Indice
- Il quadro normativo della sicurezza PEC
- I protocolli di trasporto: TLS, STARTTLS e IPSec
- Firma del gestore, ricevute e log: cosa certifica la PEC
- Cosa la PEC non certifica da sola
- Autenticazione alla casella PEC: password, SPID, CIE e token
- Dalla PEC alla REM: autenticazione forte e standard europei
- Sicurezza delle API PEC e delle integrazioni aziendali
- Indirizzi verificati: la sicurezza prima dell’invio
- Il punto di vista di TrovaPEC
- Indirizzi PEC ufficiali, senza ricerche manuali
- Domande frequenti
- Fonti
Il quadro normativo della sicurezza PEC
In Italia la PEC è uno dei pochi sistemi di posta con requisiti di sicurezza fissati per norma. Il riferimento principale sono le Regole Tecniche allegate al DM 2 novembre 2005, pubblicate da AgID. Descrivono come devono comunicare tra loro i gestori accreditati e come deve avvenire l’accesso degli utenti.
Le stesse regole sono state descritte a livello internazionale nella RFC 6109 dell’RFC Editor, che presenta la PEC italiana come standard aperto. Due principi tornano in entrambi i documenti:
- l’accesso al servizio è consentito solo dopo un’autenticazione riuscita dell’utente al punto di accesso;
- ogni comunicazione nella rete PEC passa su canali sicuri, con integrità e riservatezza garantite da protocolli basati su TLS o IPsec.
Negli ultimi anni a questo impianto si è aggiunta la cornice europea. Il documento REM-Policy-IT 2.0 di AgID, del 14 maggio 2024, definisce i requisiti del servizio elettronico di recapito certificato qualificato (REM) in base al Regolamento eIDAS n. 910/2014, modificato dal Regolamento (UE) 2024/1183. Lo stesso documento stabilisce che, dall’entrata in vigore del relativo DPCM, l’articolo 48 del Codice dell’amministrazione digitale è abrogato. Per i prestatori di servizi fiduciari, come ricorda Agenda Digitale, eIDAS 2.0 richiede anche una gestione dei rischi proporzionata e la segnalazione degli incidenti secondo la Direttiva NIS 2.
I protocolli di trasporto: TLS, STARTTLS e IPSec
Il primo livello di protezione riguarda il “tubo” in cui viaggiano i dati. Secondo la sezione 8.3 delle Regole Tecniche, le connessioni tra gestore e utente devono garantire integrità e confidenzialità con protocolli sicuri. Il colloquio tra gestori, invece, avviene con SMTP su trasporto TLS, come descritto nella RFC 3207.
| Tratta della comunicazione | Protocolli previsti | Cosa protegge |
|---|---|---|
| Client di posta e casella (lettura) | IMAPS, POP3S, POP3 con STLS | Riservatezza di messaggi e credenziali durante il download |
| Client di posta e casella (invio) | SMTP con STARTTLS | Cifratura del messaggio dal mittente al punto di accesso |
| Webmail e pannelli di gestione | HTTPS | Sessione del browser, password e contenuti consultati |
| Gestore e gestore | SMTP su TLS (RFC 3207) | Trasferimento tra i provider di mittente e destinatario |
| Collegamenti dedicati | IPSec | Canale di trasporto cifrato a livello di rete |
Gli enti pubblici descrivono il servizio negli stessi termini. Il Comune di Milano, per esempio, indica l’uso dei protocolli sicuri POP3s, IMAPs, SMTPs e HTTPs. Ricorda anche che il gestore conserva per 30 mesi le informazioni sulla trasmissione.
Per l’utente ne discende una regola pratica. Il client di posta va configurato soltanto con le porte e le modalità cifrate indicate dal proprio gestore, e non si accettano mai avvisi su certificati non validi durante la connessione.
Firma del gestore, ricevute e log: cosa certifica la PEC
Il secondo livello è la certificazione. Quando un messaggio entra nel circuito, il punto di accesso del gestore lo “imbusta” in una busta di trasporto e lo firma digitalmente. Il punto di ricezione del gestore destinatario verifica la firma prima di accettarlo. Le Regole Tecniche vietano inoltre il transito su sistemi esterni al circuito PEC e richiedono sistemi antivirus costantemente aggiornati.
Il valore legale nasce dalle ricevute. Come spiega la pagina ufficiale AgID sulla PEC, il gestore del mittente genera la ricevuta di avvenuto invio. Il gestore del destinatario genera la ricevuta di avvenuta o mancata consegna, che contiene il messaggio e gli allegati. È per questo che un invio PEC ha lo stesso valore di una raccomandata con avviso di ricevimento. Le condizioni che rendono opponibile una comunicazione sono descritte nella guida su quando una PEC ha valore legale.
La RFC 6109 spiega anche una scelta di progetto. Nella PEC sono le applicazioni sui server a firmare i messaggi, senza la complessità dei sistemi end-to-end. In questo modo il servizio resta semplice da usare e non chiede all’utente competenze crittografiche. La stessa RFC raccomanda un modulo hardware dedicato per custodire la chiave privata del gestore e le operazioni di firma.
Quando un’organizzazione deve attribuire un documento a una persona precisa, alla PEC si affianca la firma digitale del firmatario. Le due funzioni si completano: la PEC certifica il recapito, la firma digitale certifica l’autore e l’integrità del file. Chi vuole capire come introdurre questo strumento nei processi interni trova un approfondimento su firma digitale in azienda. Le differenze operative sono spiegate nella guida PEC e firma digitale.
Cosa la PEC non certifica da sola
Usare bene la PEC significa conoscere con precisione il perimetro della certificazione. Secondo AgID, la PEC:
- attesta la provenienza da una casella, ma non chi l’ha usata materialmente, perché la casella può essere condivisa tra più persone o compromessa;
- non certifica la lettura del messaggio, ma la consegna nella casella;
- non firma automaticamente il documento per conto del mittente;
- non certifica la verità del contenuto;
- non offre le stesse garanzie quando il destinatario è un indirizzo di posta ordinaria;
- non è di per sé un servizio di conservazione documentale: i log conservati per 30 mesi riguardano le tracce delle operazioni, non i messaggi.
Il rischio più concreto oggi riguarda le caselle compromesse. Il 27 ottobre 2026 il CERT-AGID ha segnalato campagne di phishing partite da PEC compromesse, con false multe a nome di PagoPA. In uno dei casi analizzati il messaggio era indirizzato a una casella ordinaria e aveva in copia circa 340 indirizzi PEC. Un link portava a un falso portale che chiedeva dati personali e di pagamento.
Le ricevute dimostrano che un messaggio è partito da una certa casella in un certo momento. Per questo AgID raccomanda di verificare chi scrive, valutare il contenuto, controllare le richieste di pagamento e fare attenzione a link e allegati, anche quando il messaggio arriva via PEC. Chi deve scegliere il canale giusto per una comunicazione formale può partire dal confronto PEC vs email.
Autenticazione alla casella PEC: password, SPID, CIE e token
L’autenticazione è il punto in cui la sicurezza dipende di più dall’utente. La sezione 8.2 delle Regole Tecniche rende obbligatoria l’autenticazione al punto di accesso. Lascia però al gestore la scelta tra user-id e password o, se disponibili, Carta d’identità elettronica e Carta nazionale dei servizi.
Oggi molti gestori offrono anche modalità più robuste. Il Manuale Operativo PEC di Register.it, versione 6.3 del 3 agosto 2026, ne descrive tre:
- accesso a un solo fattore, con le credenziali della casella;
- autenticazione forte a due fattori con SPID di livello 2;
- token di accesso sicuro, generati nell’area riservata, legati in modo univoco alla casella, revocabili in qualsiasi momento e memorizzati come hash crittografico.
Per capire cosa significa “SPID di livello 2” si può guardare il Manuale Operativo SPID di AgID (versione 5.2, 10 settembre 2024). Il livello 1 usa solo la password. Il livello 2 aggiunge un secondo fattore, cioè un codice OTP via app, email o SMS oppure un sistema biometrico. Il livello 3 si basa su certificati digitali con chiavi private custodite su dispositivi sicuri.
AgID raccomanda di custodire le credenziali e di attivare l’autenticazione a più fattori quando è disponibile. Chi entra in una casella può leggere le comunicazioni e inviare messaggi con il suo valore legale. In pratica:
- usare una password lunga e diversa da quella di qualsiasi altro servizio;
- attivare il secondo fattore o l’accesso con SPID se il gestore lo prevede;
- dare un token separato a ogni dispositivo o software e revocarlo quando non serve più;
- togliere subito gli accessi a chi lascia l’ufficio o cambia ruolo;
- se si sospetta una compromissione, cambiare le credenziali e contattare subito il proprio gestore.
Dalla PEC alla REM: autenticazione forte e standard europei
La REM porta la PEC dentro gli standard europei dei servizi di recapito qualificati. Secondo la REM-Policy-IT 2.0, l’autenticazione forte è obbligatoria. Il documento spiega anche perché: l’autenticazione forte prevista dallo standard EN 319 521 “rinnova” a ogni accesso l’identificazione iniziale del titolare, così ogni uso del servizio resta legato a una persona identificata.
Per i client di posta di mercato, come i programmi desktop, la policy prevede una soluzione precisa. L’utente si autentica in modo forte tramite un’applicazione del gestore e ottiene un token di sicurezza chiamato Application Password. Questo token si inserisce nel client al posto della password e scade secondo le regole del gestore, per esempio dopo 6 mesi. Questa modalità non vale per webmail, API e app mobili proprietarie: per queste la policy rimanda a un paragrafo dedicato basato su OAuth 2.0.
Per un’azienda il messaggio è chiaro. Conviene già oggi organizzare gli accessi alla PEC come se l’autenticazione forte fosse la regola, con identità nominative, token per i software e un registro di chi può inviare per conto dell’organizzazione.
Sicurezza delle API PEC e delle integrazioni aziendali
Sempre più aziende e PA collegano la PEC ai propri gestionali: CRM, protocollo informatico, software di fatturazione, piattaforme per gli invii massivi. Ogni integrazione è anche una porta d’accesso, e va protetta con lo stesso rigore della casella.
Il riferimento sono le Linee Guida AgID sulle tecnologie e gli standard per la sicurezza dell’interoperabilità tramite API. Indicano OAuth 2.0 come framework per proteggere risorse HTTP come un’API REST, con ruoli distinti per Resource Owner, Client, Authorization Server e Resource Server. Nel contesto machine-to-machine fissano un divieto esplicito: il Grant Type Resource Owner Password Credentials non deve essere usato, perché comporta la cessione a terzi delle credenziali. La strada indicata è il Client Credentials Grant Type.
Una checklist operativa per chi integra servizi PEC via API:
- Nessuna password della casella nel codice: usare client credentials o token dedicati, conservati in un archivio segreti e mai nei file di configurazione condivisi.
- Token con scadenza e revoca: durata limitata, rinnovo automatico, revoca immediata se un server viene dismesso o compromesso.
- Solo HTTPS: ogni chiamata viaggia su TLS, con verifica del certificato del server.
- Privilegi minimi: un’applicazione che deve solo cercare o verificare indirizzi non ha bisogno dei permessi di invio.
- Registro delle chiamate: chi ha chiamato l’API, quando e con quale esito, per ricostruire ogni operazione.
- Dati minimi: trasmettere solo i campi necessari, come Partita IVA o Codice Fiscale, nel rispetto delle regole descritte nella guida sulla privacy negli invii massivi di PEC.
Indirizzi verificati: la sicurezza prima dell’invio
Un messaggio può viaggiare cifrato, firmato e tracciato e arrivare comunque alla casella sbagliata. Un indirizzo digitato a mano, copiato da una vecchia anagrafica o ricevuto in una email non verificata è un rischio concreto. Può portare a una comunicazione mai ricevuta dal vero destinatario, a dati riservati consegnati a terzi o a una scadenza persa.
Per questo le organizzazioni che inviano PEC in volume seguono alcune pratiche:
- prendono gli indirizzi da fonti istituzionali come l’Indice Nazionale degli Indirizzi PEC, istituito dall’art. 6-bis del Codice dell’amministrazione digitale per imprese e professionisti;
- abbinano ogni indirizzo a un identificativo univoco, cioè Partita IVA o Codice Fiscale, e non alla sola ragione sociale;
- verificano lo stato della Partita IVA prima di inviare comunicazioni con effetti legali;
- conservano ricevute ed esiti in modo ordinato, come descritto nella guida alla rendicontazione degli invii PEC;
- non usano mai come fonte gli indirizzi indicati in un messaggio ricevuto, soprattutto se contiene richieste di pagamento o di modifica dell’IBAN.
Il punto di vista di TrovaPEC
Nel nostro lavoro quotidiano con aziende, studi professionali e pubbliche amministrazioni vediamo un punto ricorrente. I protocolli del circuito PEC sono solidi e definiti per norma, mentre i rischi si concentrano ai bordi: credenziali, integrazioni e qualità degli indirizzi.
Sul primo fronte la risposta è l’autenticazione forte, e la direzione indicata da AgID con la REM va proprio lì. Sul secondo serve un’architettura che non faccia mai circolare le password delle caselle tra i sistemi. Sul terzo, quello di cui ci occupiamo, la regola è semplice: ogni indirizzo deve arrivare da una fonte istituzionale ed essere legato a una Partita IVA o a un Codice Fiscale.
Per questo abbiamo costruito TrovaPEC sull’automazione. La ricerca parte da elenchi di identificativi e i dati sono aggiornati tramite l’Indice Nazionale degli Indirizzi PEC, così si eliminano i passaggi manuali in cui nascono errori e indirizzi non verificati. Per chi integra i propri processi mettiamo a disposizione web services e API, senza limiti di volume. In questo modo la verifica degli indirizzi entra nel flusso di lavoro e non resta un controllo saltuario.
Alessandro
Indirizzi PEC ufficiali, senza ricerche manuali
TrovaPEC aiuta aziende, studi e PA a lavorare solo con indirizzi certificati affidabili. Si carica un elenco di Partite IVA o Codici Fiscali e la piattaforma restituisce gli indirizzi PEC ufficiali, aggiornati tramite l’Indice Nazionale degli Indirizzi PEC. Per un singolo indirizzo è disponibile anche la ricerca gratuita. Il servizio comprende la verifica massiva delle Partite IVA, anche su VIES, e la normalizzazione e correzione delle anagrafiche.
Chi deve collegare la ricerca ai propri gestionali può usare i Web Services per la ricerca PEC. Per le campagne di comunicazione certificata è disponibile l’invio PEC massivo con rendicontazione dei ritorni. Per partire da un elenco si può usare la ricerca PEC massiva.
Domande frequenti
La PEC è cifrata end-to-end?
No. La PEC protegge i messaggi con canali cifrati TLS o IPSec in ogni tratta e con la firma digitale del gestore, come previsto dalle Regole Tecniche e dalla RFC 6109. Questa scelta mantiene il servizio semplice da usare. Quando serve attribuire un documento al suo autore, si allega un file firmato digitalmente dal mittente.
Come si attiva l’autenticazione a due fattori sulla PEC?
Dipende dal gestore. Molti offrono l’accesso alla webmail con SPID di livello 2 o con un codice OTP, e token dedicati per i programmi di posta. Le impostazioni si trovano di solito nell’area riservata della casella. AgID raccomanda di attivare l’autenticazione a più fattori quando è disponibile.
Un messaggio PEC è sempre affidabile?
Le ricevute certificano che il messaggio è partito da una certa casella ed è stato consegnato con data, ora e contenuto integri. Non certificano chi lo ha scritto né la verità del contenuto. Per questo, davanti a richieste di pagamento o link, conviene verificare il mittente con un canale indipendente, come raccomandano AgID e CERT-AGID.
Come si proteggono le API che inviano o cercano PEC?
Le Linee Guida AgID indicano OAuth 2.0 e, tra sistemi, il Client Credentials Grant Type. È invece vietato il flusso che richiede di cedere le credenziali dell’utente. Completano la protezione token con scadenza e revoca, HTTPS su ogni chiamata, permessi minimi e un registro delle operazioni.
Che differenza c’è tra PEC e REM sulla sicurezza?
La REM è il servizio di recapito certificato qualificato secondo eIDAS. Rende obbligatoria l’autenticazione forte e segue gli standard europei ETSI, come descritto nella REM-Policy-IT 2.0 di AgID. Mantiene la compatibilità con l’infrastruttura PEC esistente, quindi le organizzazioni possono arrivarci in modo graduale.
Fonti
- AgID, Regole tecniche del servizio PEC (DM 2 novembre 2005)
- AgID, Posta elettronica certificata
- RFC Editor, RFC 6109: La Posta Elettronica Certificata
- AgID, REM Services: Policy-IT 2.0
- Agenda Digitale, eIDAS 2.0: sicurezza, interoperabilità e compliance
- Comune di Milano, Posta Elettronica Certificata
- CERT-AGID, Phishing PagoPA tramite PEC compromesse
- Register.it, Manuale Operativo PEC
- AgID, Manuale Operativo SPID
- AgID, Linee Guida sulla sicurezza dell’interoperabilità tramite API
- Codice dell’amministrazione digitale, art. 6-bis