Indice dell'articolo
Microsoft ha pubblicato gli aggiornamenti di sicurezza di settembre 2026 per Windows 11: KB5124008 per le versioni 24H2 e 25H2 e KB5122880 per la versione 23H2. Per un reparto IT o un MSP, la decisione corretta non è scegliere tra “installare subito” e “aspettare”: è distribuire rapidamente, ma per anelli, con controlli e possibilità di arrestare il rollout.
Il perimetro da verificare prima del deploy
Il primo controllo riguarda l’edizione e lo stato di supporto. Windows 11 23H2 Home e Pro hanno terminato il supporto l’11 novembre 2025; nel 2026, gli aggiornamenti 23H2 restano pertinenti alle edizioni Enterprise ed Education ancora supportate. Una macchina Home o Pro rimasta su 23H2 non va considerata protetta solo perché rileva un pacchetto: deve entrare in un piano di aggiornamento a una versione supportata.
Create quindi un inventario minimo con:
- versione, edizione e build del sistema operativo;
- modello hardware, BIOS/UEFI e driver critici;
- stato di BitLocker e disponibilità della chiave di ripristino;
- software EDR, VPN, cifratura, backup e applicazioni gestionali;
- ultimo riavvio, spazio libero e aggiornamenti in sospeso.
Microsoft distribuisce aggiornamenti cumulativi: il pacchetto più recente incorpora le correzioni precedenti applicabili. Questo semplifica la baseline, ma aumenta l’importanza del test su configurazioni rappresentative.
Rollout in quattro anelli
Anello 0 - laboratorio. Usate macchine o VM che riproducano le immagini aziendali principali. Verificate installazione, riavvio, accesso, rete, VPN, stampa, browser, applicazioni line-of-business e agenti di sicurezza.
Anello 1 - pilota IT. Distribuite a un gruppo piccolo di dispositivi usati quotidianamente dal team tecnico. Monitorate almeno errori di installazione, crash, BitLocker recovery, degrado della rete e ticket anomali.
Anello 2 - utenti rappresentativi. Includete sedi, modelli hardware e funzioni diverse. Evitate di testare solo notebook recenti: i problemi operativi emergono spesso su periferiche, driver o software meno comuni.
Anello 3 - produzione. Estendete il deploy a finestre controllate. Mantenete un limite di errore che sospenda automaticamente la distribuzione se aumentano fallimenti, riavvii inattesi o incidenti applicativi.
Non usate una percentuale universale come soglia. Definite il limite in base alla dimensione del parco, alla criticità dei servizi e alla qualità della telemetria disponibile.
Verifiche dopo l’installazione
L’esito “installato” nella console non basta. Per ogni anello confermate:
- build attesa e assenza di aggiornamenti bloccati;
- riavvio completato e nessun loop di servicing;
- EDR, firewall, VPN e agenti RMM attivi;
- accesso alle applicazioni e alle risorse aziendali;
- BitLocker operativo senza richieste anomale di recovery;
- assenza di nuovi errori ricorrenti nei log e nei ticket;
- backup recente e ripristinabilità invariata.
Conservate un report con dispositivi inclusi, orari, esiti, eccezioni e responsabile della decisione di avanzare all’anello successivo.
Patching e risposta a un incidente non sono la stessa cosa
L’installazione dell’aggiornamento riduce l’esposizione alle vulnerabilità corrette, ma non dimostra che un dispositivo non sia già stato compromesso. Se telemetria EDR, log di autenticazione o indicatori di rete segnalano attività sospetta, aprite un percorso separato di incident response: isolamento, preservazione delle evidenze, verifica delle credenziali e analisi dell’estensione. Non “chiudete” l’incidente solo perché la patch è stata installata.
Piano di rollback
Prima della distribuzione documentate come fermare il rollout e come recuperare una macchina non avviabile. Il piano dovrebbe includere sospensione dalla console di gestione, accesso alle chiavi BitLocker, procedure WinRE, backup verificato e contatti di escalation. La disinstallazione di un aggiornamento è una misura temporanea e aumenta nuovamente il rischio: va usata solo dopo una valutazione tecnica e con una finestra definita per la correzione definitiva.
Azione consigliata oggi
Scaricate i pacchetti esclusivamente dai canali Microsoft, verificate il perimetro delle versioni, avviate il laboratorio e predisponete il pilota IT. Prima di estendere il rollout, consultate sia le note del pacchetto sia il Windows Release Health dashboard per eventuali problemi noti aggiornati dopo la pubblicazione.
Se gestite più sedi o non disponete di un processo di patch management misurabile, contattate MSP In Cloud per impostare un rollout gestito: inventario, anelli di distribuzione, monitoraggio e verifica post-deploy.