Cambiamenti nell'ecosistema PKI nel 2026: cosa deve sapere il tuo team

• Apple applica certificati con durata di 200 giorni dalla fine di marzo 2026, mentre Amazon emette già certificati da 198 giorni. Entro il 2029 la durata scenderà a 47 giorni.
• L'81% delle interruzioni legate ai certificati è ancora causato da certificati scaduti o configurati male. Durate più brevi moltiplicano questo rischio.
• Il 60% delle aziende gestisce autorità di certificazione (CA) interne proprie, e una grande azienda media ha in uso oltre 140.000 certificati interni. La maggior parte ha una supervisione centrale minima.
• La minaccia «Harvest Now, Decrypt Later» legata al quantum computing significa che le organizzazioni dovrebbero adottare subito il TLS ibrido (che combina ECDHE classico e ML-KEM).
• Le organizzazioni hanno bisogno di un inventario dei certificati in tempo reale e multi-sorgente, che copra l'infrastruttura pubblica e privata, per stare al passo con questi cambiamenti.

I cambiamenti sono già qui. Apple applica una durata massima dei certificati di 200 giorni dalla fine di marzo 2026. Anche Amazon ha iniziato a emettere certificati da 198 giorni. Se nel tuo parco ci sono certificati di questi provider, il numero di certificati nel tuo ambiente almeno raddoppierà quest'anno.

E questo è solo l'inizio. Nel 2027 la durata scende a 100 giorni. Nel 2029 arriva a 47.

Ecco il calcolo che conta: una durata di 47 giorni significa circa otto volte più rinnovi di certificati all'anno rispetto a oggi. Se oggi la tua organizzazione ha 1.000 certificati pubblici, nel 2029 gestirai 8.000 rinnovi all'anno.

Con questi volumi il rinnovo manuale diventa impossibile. Ma, come ha sottolineato Billy McDiarmid durante il webinar, nemmeno l'automazione basta da sola.

«Ne parliamo con i clienti ogni singolo giorno», ha detto McDiarmid. «Vengono da noi e ci dicono che pensavano di aver automatizzato tutto. Poi l'automazione è fallita in una parte del loro parco, oppure è scaduto un certificato di terze parti da cui dipendeva uno dei loro servizi.»

Si accorcia anche la finestra di sostituzione. La buona pratica era iniziare la rotazione dei certificati 30 giorni prima della scadenza. Con durate più brevi, la finestra potrebbe ridursi a sette giorni. Questo riduce drasticamente il tempo a disposizione per accorgersi di un'automazione fallita e rimediare.

E la posta in gioco è reale: l'81% delle interruzioni legate ai certificati è ancora causato da certificati scaduti o configurati male. È già una delle principali cause di downtime. Durate più brevi, senza gli strumenti giusti, peggioreranno la situazione.

La PKI pubblica (i certificati che proteggono il tuo sito web, le API pubbliche e i domini esterni) riceve la maggior parte dell'attenzione. Esiste un ecosistema consolidato di CA, applicazione delle regole da parte dei browser, log di Certificate Transparency (CT) e requisiti di conformità che mantengono la PKI pubblica relativamente ben gestita.

La PKI privata è un'altra storia.

I certificati interni che proteggono server, VPN, pipeline DevOps, dispositivi IoT e API interne sono spesso emessi da CA private interne come Microsoft Active Directory Certificate Services (ADCS), con una supervisione centrale minima. Le durate sono spesso impostate su anni, a volte persino su decenni. In genere non c'è alcun monitoraggio esterno. E quando qualcosa va storto (una scadenza inattesa, una root compromessa, un intermedio configurato male), l'impatto può essere grave e difficile da diagnosticare.

I numeri parlano chiaro. Il 60% delle aziende gestisce CA interne proprie. Una grande azienda ha in media oltre 140.000 certificati interni in uso. E il 57% delle organizzazioni sta ora integrando lo zero trust nella propria strategia di crittografia, il che rende la PKI privata ancora più centrale nel loro modo di operare.

Lo zero trust segue un principio semplice: non fidarsi mai, verificare sempre. Ogni servizio riceve un certificato univoco. Ogni connessione usa il TLS reciproco (mTLS), cioè entrambe le parti devono presentare un certificato valido firmato da una CA attendibile. L'accesso è guidato da policy, non dalla posizione.

La PKI privata è ciò che rende tutto questo possibile su larga scala. Dà a ogni servizio, dispositivo e utente una solida identità crittografica. Ma poiché lo zero trust privilegia certificati di breve durata e ruotati automaticamente, il volume e la velocità delle operazioni sui certificati non possono che aumentare.

E le conseguenze di un guasto della PKI privata vanno oltre il sito web non raggiungibile. Quando i certificati privati scadono o si rompono, possono fermare linee di produzione, sistemi di tecnologia operativa (OT) e servizi interni su cui si regge la tua attività. Come ha detto McDiarmid: «Non parliamo più solo del tuo sito web che non funziona o della tua API che non risponde. Parliamo della produzione che si ferma.»

La preparazione alla crittografia post-quantistica (PQC) sembra un problema futuro. Le scadenze normative per la migrazione completa si collocano tra il 2030 e il 2033. Ma la preparazione richiede un lavoro notevole, e c'è una minaccia che richiede di agire subito.

Quando verrà costruito un computer quantistico crittograficamente rilevante (CRQC), romperà la crittografia a chiave pubblica oggi largamente diffusa, inclusi RSA e la crittografia a curve ellittiche (ECC), praticamente da un giorno all'altro.

La preoccupazione immediata si chiama «Harvest Now, Decrypt Later». Gli attaccanti possono già oggi catturare dati cifrati (il tuo traffico TLS, i tunnel VPN) e conservarli. Quando un CRQC sarà disponibile, potranno decifrare tutto ciò che hanno raccolto. Per le organizzazioni che gestiscono dati sensibili di lunga durata, questo è un rischio di oggi, non del futuro.

Bhushan Lokhande di Red Sift ha illustrato tre passaggi per costruire la prontezza alla PQC.

• Primo passo: conosci la tua situazione. Non puoi proteggere ciò che non vedi. Costruisci un inventario completo e sempre aggiornato dei tuoi asset crittografici, sia sull'infrastruttura pubblica sia su quella privata interna. Ogni dominio, sottodominio, certificato ed endpoint di rete.
• Secondo passo: individua i punti deboli. Quali sistemi usano algoritmi che i computer quantistici romperanno? Significa trovare tutte le implementazioni RSA ed ECC. Devi anche cercare i sistemi privi di crypto-agility (quelli che non possono passare a nuovi algoritmi senza una riprogettazione significativa).
• Terzo passo: pianifica la migrazione. Non tutto deve essere migrato in una volta. Dai priorità ai dati di lunga durata e ai sistemi ad alto rischio, perché sono quelli con la maggiore esposizione a «Harvest Now, Decrypt Later».

La migrazione ha due parti distinte. Sul fronte dello scambio di chiavi, l'azione più urgente è adottare il TLS ibrido, combinando ECDHE classico e ML-KEM (in precedenza noto come Kyber). Questo affronta direttamente il rischio «Harvest Now, Decrypt Later» mantenendo la retrocompatibilità. Cloudflare, Google e i principali produttori di browser stanno già adottando lo scambio di chiavi ibrido su larga scala. Sul fronte delle firme digitali, le organizzazioni dovrebbero introdurre gradualmente algoritmi post-quantistici standardizzati dal NIST, come ML-DSA e SLH-DSA, man mano che l'ecosistema matura.

La prontezza alla PQC non è un evento singolo. È un processo di migrazione, e dovresti iniziare subito.

Tutti e tre i cambiamenti portano alla stessa esigenza di fondo. Ti serve un inventario completo e aggiornato di continuo di ogni certificato del tuo parco, pubblico e privato, nel momento in cui viene emesso.

I fogli di calcolo non bastano più. Nemmeno le scansioni giornaliere. Serve l'acquisizione in tempo reale dei certificati da più fonti di scoperta: discovery basata sugli hostname, scansione di rete, log di Certificate Transparency, integrazioni con i cloud provider e agent sull'infrastruttura privata.

La maggior parte delle organizzazioni sottovaluta anche la proliferazione delle autorità di certificazione. McDiarmid ha condiviso durante il webinar un'osservazione eloquente: la maggior parte dei prospect che Red Sift prende in carico scopre certificati emessi da 10 o 11 autorità di certificazione diverse, più certificati autofirmati, e questa è solo l'impronta pubblica, prima ancora di guardare dentro la rete.

Ti serve anche visibilità sulla tua postura crittografica: quali endpoint supportano lo scambio di chiavi sicuro contro il quantistico, quali certificati usano algoritmi vulnerabili al quantistico e a che punto è il tuo parco rispetto ai cambiamenti in arrivo nel ciclo di vita.

Uno strumento di CLM (Certificate Lifecycle Management) gestisce emissione e rinnovo. Ma nel 2026 ti serve anche un'assicurazione che affianchi il tuo CLM: qualcosa che si implementa in pochi minuti, offre rilevamento continuo in tempo reale, correla i dati dei certificati con i log CT e il DNS e copre entrambi i lati della rete.

Red Sift Certificates offre il monitoraggio dell'infrastruttura pubblica e privata in un'unica vista, con dashboard dedicate alla prontezza PQC e alla conformità del ciclo di vita dei certificati. L'agent PKI privata della piattaforma individua i certificati nell'infrastruttura interna e li porta nello stesso inventario dei tuoi certificati pubblici.

Tra le nuove funzionalità in arrivo nel 2026 ci sono un'integrazione ADCS (prevista nel secondo trimestre), un'integrazione con HashiCorp Vault più avanti nell'anno e l'accesso MCP (Model Context Protocol), così i team possono interrogare il proprio parco certificati con l'IA.

Vuoi vedere a che punto è il tuo parco? Verifica la postura di sicurezza del tuo dominio con Red Sift Radar Lite per una valutazione gratuita, oppure richiedi una demo di Red Sift Certificates per ottenere piena visibilità sulla tua infrastruttura di certificati pubblica e privata.