L’estate del 2026 sarà uno spartiacque per chi gestisce infrastrutture Microsoft. Tra giugno e luglio si concentrano due transizioni che, se prese alla leggera, possono trasformarsi in incidenti di produzione: la scadenza dei certificati Secure Boot del 2011 e la dismissione di RC4 nell’autenticazione Kerberos di Active Directory. Due cambiamenti diversi, ma con un punto in comune: arrivano in modo silenzioso, attraverso aggiornamenti cumulativi, e i loro effetti si manifestano spesso solo quando qualcosa smette di funzionare.
In questo articolo vediamo cosa cambia, perché entrambi i temi meritano attenzione adesso e come affrontare il periodo caldo senza farsi trovare impreparati.
Secure Boot: i certificati del 2011 vanno in pensione
Quando Microsoft introdusse Secure Boot insieme a Windows 8 e ai firmware UEFI, la catena di fiducia che autorizza il codice a girare prima del sistema operativo venne ancorata a tre certificati datati 2011: Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011 e Microsoft Corporation UEFI CA 2011. Da allora, quei certificati hanno protetto il boot di centinaia di milioni di dispositivi. Quindici anni dopo, il loro ciclo di vita arriva al termine: la prima scadenza è prevista per giugno 2026, con un percorso di scadenze che si chiude entro ottobre dello stesso anno.
Per garantire continuità, Microsoft sta distribuendo una nuova generazione di certificati — la chain 2023 — che subentra alla precedente nel KEK e nel database DB del firmware UEFI. La transizione viene gestita in modo automatico tramite Windows Update e un’attività pianificata interna che applica progressivamente le nuove chiavi al firmware. Sui dispositivi più recenti, soprattutto quelli prodotti dal 2024 in poi, i due set di certificati convivono già di fabbrica grazie alla strategia “dual certificate” adottata dai principali OEM.
Cosa succede se non si interviene
Una buona notizia: i PC con Secure Boot attivo continueranno ad avviarsi anche dopo la scadenza dei certificati 2011. La cattiva notizia è che, senza la nuova catena 2023, il dispositivo non riceverà più aggiornamenti del Boot Manager né delle liste di revoca DBX. Significa, in concreto:
- Niente più mitigazioni pre-OS — gli attacchi bootkit e le vulnerabilità della fase di avvio non potranno più essere chiusi con aggiornamenti firmati
- Compatibilità a rischio con strumenti di recovery, dual boot, driver UEFI di terze parti firmati con la nuova chain
- Stato di sicurezza degradato — il dispositivo resta funzionante, ma esce di fatto dalla compliance di Secure Boot
Il punto sensibile non è Windows in sé: è il firmware UEFI della macchina. Se la motherboard non è preparata ad accettare e mantenere i nuovi certificati 2023, l’aggiornamento può essere applicato da Windows ma non venire conservato dal firmware. È in questo gap — soprattutto su parchi PC eterogenei e con macchine pre-2023 — che si annidano i rischi reali per le aziende.
RC4 esce di scena da Kerberos
Il secondo fronte caldo è l’autenticazione di Active Directory. Microsoft sta dismettendo RC4 come algoritmo accettato di default dal Key Distribution Center per i ticket Kerberos, in risposta alla vulnerabilità CVE-2026-20833. RC4 è un cifrario considerato crittograficamente debole da anni: la sua persistenza nelle infrastrutture aziendali ha alimentato attacchi di Kerberoasting, in cui un utente autenticato richiede ticket di servizio cifrati con RC4, li esfiltra e ne fa il cracking offline per ricavare le password degli account di servizio — spesso account con privilegi elevati.
Il piano di dismissione è strutturato in tre fasi:
- Gennaio 2026 — fase audit: gli aggiornamenti introducono nuovi eventi (201–209) sui domain controller per identificare dove RC4 è ancora in uso, senza modificare il comportamento
- Aprile 2026 — fase enforcement: il valore
DefaultDomainSupportedEncTypespassa a AES-SHA1 e il fallback su RC4 viene rimosso per gli account senzamsDS-SupportedEncryptionTypesesplicito. Il rollback è ancora possibile - Luglio 2026 — enforcement definitivo: la modalità audit e le opzioni di rollback vengono rimosse. RC4 funziona solo se configurato esplicitamente per singolo account
Chi rischia davvero di rompersi
La maggior parte degli ambienti Windows moderni usa già AES e non vedrà alcun impatto. I problemi si concentrano in aree specifiche, dove RC4 è rimasto come dipendenza silenziosa nel tempo:
- Service account legacy — account di servizio per SQL Server, application pool IIS, scheduled task creati anni fa senza tipo di cifratura esplicito
- Storage NAS terzi — appliance NetApp, Synology, QNAP joinate al dominio che usano Kerberos verso AD
- FSLogix su SMB — i container dei profili in ambienti Azure Virtual Desktop e RDS on-premises, dove un account computer o di servizio configurato male impedisce ai profili di caricarsi al login
- Dispositivi non-Windows — host Linux, macOS, stampanti di rete, applicazioni con librerie Kerberos legacy
- Sistemi obsoleti — Windows Server 2003 non supporta AES-SHA1 e va isolato o dismesso prima della fase di enforcement
Il pericolo è la natura silenziosa del problema: quando l’enforcement scatta, gli utenti non vedono un messaggio “RC4 deprecato” ma errori generici di autenticazione, profili che non si caricano, job pianificati che falliscono, condivisioni SMB irraggiungibili. Diagnosi che richiedono tempo, tempo che in piena estate spesso non c’è.
L’angolo Inside Technologies
Entrambi i temi condividono la stessa logica di gestione: inventariare, validare, intervenire prima della scadenza. Sui progetti che seguiamo come system integrator, la differenza tra una transizione tranquilla e un incidente di produzione si gioca quasi sempre nelle settimane precedenti, non nel momento dell’aggiornamento.
Sul fronte Secure Boot, il primo passo è verificare via PowerShell quali endpoint hanno già la chain 2023 nel firmware, mappare i modelli e le versioni BIOS, allineare le campagne di firmware update degli OEM e gestire con attenzione i cambi BIOS dove BitLocker è attivo (per evitare richieste di chiave di ripristino impreviste). Su Microsoft Intune e altri sistemi di management, l’aggiornamento può essere distribuito in modo controllato via Settings Catalog o tramite remediation script.
Sul fronte Kerberos, la fase audit di gennaio 2026 è la finestra giusta per fare l’inventario: i log eventi 4768 e 4769 sui domain controller mostrano i ticket emessi con cifratura RC4 (tipo 0x17). Da lì si costruisce la lista degli account, dei device e delle applicazioni che vanno rimediati con configurazione esplicita su msDS-SupportedEncryptionTypes o, dove possibile, con il passaggio definitivo ad AES. Un audit serio fatto a febbraio-marzo evita praticamente tutti gli incidenti di luglio.
Conclusioni
L’estate 2026 condensa due transizioni che Microsoft ha pianificato e comunicato per tempo, ma che richiedono lavoro preparatorio reale negli ambienti di produzione. Non sono notizie urgenti nel senso classico — non c’è una patch da applicare entro venerdì — ma sono cambiamenti strutturali che, ignorati, lasciano i sistemi in uno stato di vulnerabilità progressiva o, peggio, generano disservizi diffusi al momento dell’enforcement. Per le aziende che gestiscono parchi Microsoft di una certa dimensione, il momento giusto per impostare il piano è adesso, mentre la fase audit è ancora aperta e c’è margine per correggere senza fretta.
