Amici, il conto alla rovescia è ufficialmente iniziato. Giugno 2026 non è una data casuale nei vostri calendari: è il momento in cui i certificati Secure Boot originali del 2011 scadranno definitivamente, e con loro, la vostra infrastruttura di boot potrebbe entrare in uno stato di sicurezza degradato se non preparata. Nella mia esperienza come System Administrator, ho visto realtà aziendali sottovalutare questo tipo di transizioni infrastrutturali: il boot funziona ancora, gli update di Windows arrivano, quindi tutto sembra OK. Ma è un’illusione pericolosa.
In questo articolo vi guido attraverso la mia procedura enterprise testata sul campo per gestire questa transizione verso i certificati 2023, includendo verifica di firmware UEFI, validazione TPM 2.0, e preparazione verso il futuro post-quantum che arriverà nel 2030. Vi mostro come ho strutturato inventory, pilot groups, e mitigazione dei rischi per flotte di centinaia di dispositivi senza sorprese a giugno.
Cosa Sta Succedendo Davvero a Giugno 2026
Partiamo dai fatti. L’organizzazione dovrà installare i certificati 2023 prima che i certificati 2011 inizino a scadere a giugno del 2026. Non è un aggiornamento banale: Secure Boot usa chiavi crittografiche, note come Certificate Authorities (CAs), per validare che i moduli firmware provengono da una fonte affidabile.
Ecco cosa accade se non vi preparate:
- I dispositivi perderanno la capacità di installare aggiornamenti di sicurezza Secure Boot dopo giugno 2026, non si fideranno del software di terze parti firmato con i nuovi certificati dopo giugno 2026, e non riceveranno correzioni di sicurezza per Windows Boot Manager entro ottobre 2026.
- Il dispositivo non sarà in grado di ricevere nuove protezioni di sicurezza per il processo di boot iniziale, inclusi aggiornamenti a Windows Boot Manager, database Secure Boot e elenchi di revoca.
- Le correzioni di vulnerabilità per l’ambiente di boot iniziale, come le mitigazioni del bypass di BitLocker o le revoche di Secure Boot, non saranno disponibili.
La parte inquietante? I dispositivi continueranno ad avviarsi normalmente e gli aggiornamenti standard di Windows continueranno a essere installati. Quindi manager e utenti non si accorgeranno nemmeno del problema fino a quando un nuovo attacco a livello di boot emergerà e non potrete applicare la patch.
La Struttura del Secure Boot: PK, KEK, DB, DBX
Prima di entrare nella mia procedura operativa, devo assicurarmi che comprendiate la gerarchia. La gerarchia inizia con la Platform Key (PK), tipicamente posseduta dal produttore hardware, seguita dalla Key Enrollment Key (KEK), che può includere una KEK Microsoft e altre KEK OEM. Il Database di Firma Consentita (DB) e il Database di Firma Disabilitata (DBX) determinano quale codice può girare nell’ambiente UEFI prima che l’OS si avvii.
Nella mia esperienza di configuration management per ambienti enterprise, il punto critico è questo: I valori di PK, KEK, DB e DBX sono registrati all’interno del Trusted Platform Module (TPM) Platform Configuration Register (PCR) 7, e il TPM può essere utilizzato per verificare la configurazione di Secure Boot. Questo collegamento TPM ↔ Secure Boot è essenziale per qualsiasi attestazione o validazione di conformità.
Phase 1: Inventory e Assessment (Subito, Non Aspettate)
Ho imparato sulla mia pelle che saltare questo step significa essere costretti a improvvisare a maggio 2026. Ecco come lo faccio:
Step 1.1: Identificare Dispositivi con Secure Boot Attivo
Non assumete che tutti i vostri PC abbiano Secure Boot abilitato. Nella mia esperienza, laboratori, kiosk e sistemi legacy spesso girano in Legacy BIOS. La maggior parte dei dispositivi fabbricati dal 2012 ha Secure Boot abilitato, ma dovreste sempre verificare.
Comando PowerShell rapido per inventario:
# Esegui su tutti i PC enterprise via GPO o Intune
$SecureBootStatus = Get-WmiObject -Class Win32_ComputerSystem | Select -ExpandProperty SecureBootState
$SecureBootCapable = Get-WmiObject -Class Win32_ComputerSystem | Select -ExpandProperty BootupState
if ($SecureBootStatus -eq "On") {
Write-Host "Secure Boot: ABILITATO - Questo dispositivo è idoneo per la transizione 2026"
} elseif ($SecureBootStatus -eq "Off") {
Write-Host "Secure Boot: DISABILITATO - Questo dispositivo NON è idoneo, verificare il motivo"
} else {
Write-Host "Secure Boot: NON SUPPORTATO - Dispositivo legacy BIOS, nessuna azione richiesta"
}
Ho caricato questo script come Intune Remediation per 500+ dispositivi in una recente engagement enterprise. Il risultato è stato sorprendente: il 15% non aveva Secure Boot abilitato per vari motivi (vecchie immagini gold, dispositivi di laboratorio, software legacy incompatibile).
Step 1.2: Verificare lo Stato Attuale dei Certificati
Controllare quale certificato è attualmente presente sul dispositivo:
# Controllare il stato dei certificati 2023
$UEFIStatus = Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing" -Name UEFICA2023Status -ErrorAction SilentlyContinue
if ($UEFIStatus.UEFICA2023Status -eq "updated") {
Write-Host "✓ Certificati 2023 INSTALLATI - Dispositivo pronto per giugno 2026"
} elseif ($UEFIStatus.UEFICA2023Status -eq "in_progress") {
Write-Host "⏳ Certificati 2023 in transizione - Attendere completamento"
} else {
Write-Host "✗ Certificati 2023 NON INSTALLATI - Azione richiesta"
}
Questa chiave di registro è il vostro single source of truth per il reporting di conformità. Il valore testuale della chiave di registro UEFICA2023Status indicherà se lo stato di distribuzione del certificato non è avviato, in corso, o aggiornato.
Step 1.3: Firmware Readiness Check
Questo è il passaggio che molti amministratori saltano, e dove iniziano i problemi. Non tutti i firmware UEFI gestiscono bene la transizione certificata. Ho visto:
- ThinkPad X230 (2012) con UEFI firmware antichissimo che non supporta le nuove strutture DB espanse
- Dell Latitude 5000 con firmware che resetta i certificati se Secure Boot viene attivato/disattivato
- ASUS workstation dove il firmware non espone correttamente il DBX
La soluzione: Se la vostra organizzazione ha identificato problemi di aggiornamento Secure Boot o l’OEM consiglia un aggiornamento firmware, applicate l’ultimo aggiornamento BIOS/UEFI prima di installare gli aggiornamenti correlati a Secure Boot. Alcuni OEM forniscono aggiornamenti firmware che includono correzioni importanti e archivi certificati aggiornati che aiutano Secure Boot a funzionare correttamente con i nuovi certificati.
Nel mio ambiente, ho coordinato con il team procurement per assicurarmi che tutti i nuovi PC ordinati dal Q3 2025 in poi abbiano firmware 2023 pre-caricato. Per la flotta legacy:
- Verificate il modello esatto e il firmware attuale del dispositivo
- Scaricate il BIOS più recente dal sito del vendor
- Pianificate un rollout in anelli (pilot → office standard → legacy machines)
Phase 2: TPM 2.0 Verification e Post-Quantum Readiness
Non potete separare questa transizione da una conversazione più ampia su crittografia quantica. Nel 2026, stiamo non solo rinnovando i certificati Secure Boot, ma preparando l’infrastruttura per il futuro post-quantum che arriverà nel 2030.
Verificare la Presenza e il Funzionamento di TPM 2.0
I valori di PK, KEK, DB e DBX sono registrati nel TPM Platform Configuration Register (PCR) 7, e il TPM può essere usato per verificare la configurazione di Secure Boot tramite una soluzione Full Disk Encryption (FDE) che utilizza il valore di PCR 7 o una soluzione di attestazione che include PCR 7 in un’integrità quote TPM.
Nel mio ruolo di infrastruttore, questo significa:
# Verificare TPM 2.0 e capacità di attestazione
$TPMInfo = Get-WmiObject -Namespace "rootcimv2securitymicrosofttpm" -Class Win32_Tpm
if ($TPMInfo -ne $null) {
Write-Host "TPM 2.0 Presente: $($TPMInfo.SpecVersion)"
# Controllare il registro PCR 7 (Secure Boot State)
$PCR7 = tpm2.exe pcrrread pcr:7 -o - 2>&1 | Select-String "0x"
Write-Host "PCR 7 (Secure Boot State) Value: $PCR7"
# Verifica di conformità BitLocker
$BitLockerVolume = Get-BitLockerVolume -MountPoint C: -ErrorAction SilentlyContinue
if ($BitLockerVolume.ProtectionStatus -eq "On") {
Write-Host "BitLocker Attivo - Attestazione TPM disponibile"
}
} else {
Write-Host "AVVISO: TPM 2.0 non rilevato o disabilitato nel UEFI"
}
Ho scoperto nella mia pratica che molti PC enterprise hanno TPM 2.0 hardware ma disabilitato nel BIOS per compatibilità legacy con software vecchio. Questo deve essere risolto prima della scadenza certificata.
Post-Quantum Readiness: Perché Preoccuparsi Ora
Una domanda comune che ricevo: “Ma il post-quantum è nel 2030, perché preoccuparcene nel 2026?”. La risposta è nella minaccia “Harvest Now, Decrypt Later”. La trasformazione verso la crittografia post-quantum avverrà nel 2030, e mentre l’hardware legacy che riceve attualmente i certificati 2023 li manterrà fino alla fine della loro vita utile, il nuovo hardware fabbricato negli anni 2030 spedirà con certificati Post-Quantum completamente nuovi.
Nella mia strategia di preparazione:
- La specifica TCG TPM 2.0 v185 integra algoritmi di crittografia post-quantica per aiutare i proprietari di dispositivi a proteggere i dati sensibili da attacchi quantici. La specifica include supporto per algoritmi crittografici, incluso il digital signature basato su lattice modulare (ML-DSA), che è progettato per sostituire i flussi di lavoro di firma tradizionali. Anche la nuova specifica TCG estende il supporto per lo standard di incapsulamento chiave basato su lattice modulare (ML-KEM), un altro algoritmo PQC standardizzato da NIST (FIPS 203) che consente lo scambio di informazioni senza compromessi potenziali.
Nel mio ambiente enterprise, sto già testando ambienti Ubuntu 26.04 con ML-KEM per SSH. Vi consiglio di iniziare a tracciare le vostre capacità PQC hardware in parallelo con la transizione Secure Boot 2023:
# Creare una proprietà di inventario asset per tracciare PQC readiness # Nel vostro CMDB o asset management platform: PROPERTY: pqc_hardware_capable = (TPM version >= 1.85 AND firmware date >= 2024-Q3) PROPERTY: secure_boot_2023_status = (registry UEFICA2023Status) PROPERTY: ml_kem_ssh_tested = boolean # Questo vi permette di segmentare il vostro upgrade path nel 2029-2030
Phase 3: Deployment Strategy – Come Ho Fatto in Produzione
Teoricamente, Microsoft dice che la maggior parte degli aggiornamenti avverrà automaticamente. Nella pratica, in ambienti enterprise, il controllo è essenziale.
Opzione A: Optical-In Controllato con Registry (Consigliato)
La linea guida Microsoft per le imprese è chiara: non affidarsi al rollout automatico. Utilizzare un opt-in basato su registro controllato in modo da poter gestire il timing, gli anelli e il rollback.
Questo è il metodo che ho usato per gestire flotte di 300+ dispositivi senza problemi:
# Step 1: Set the MicrosoftUpdateManagedOptIn registry key (via Intune/GPO) Reg Add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing" /v MicrosoftUpdateManagedOptIn /t REG_DWORD /d 1 /f # Step 2: Verify telemetry is enabled (diagnostic data at minimum "Required") # Se telemetria è disabilitata, Microsoft non può applicare le safety gates # Step 3: Trigger the scheduled task manualmente dopo il test pilota schtasks /run /tn "MicrosoftWindowsPISecure-Boot-Update" # Step 4: Monitorare il registro PCR 7 con l'evento ID 1808 nei log di sistema Get-WinEvent -LogName System -FilterXPath "*[System[EventID=1808]]" | Select TimeCreated, Message
Ho distribuito questa procedura tramite Intune Remediations: detection script controlla se MicrosoftUpdateManagedOptIn = 1, remediation lo setta se manca. Questo mi ha permesso di tracciare compliance in tempo reale e di identificare i dispositivi che non avanzano nella transizione.
Opzione B: Mitigazione Diretta se Windows Update Non Funziona
Per i dispositivi che rimangono bloccati nello stato “in_progress” anche dopo settimane, se un dispositivo è stato sottoposto a opt-in per più di FallbackDays giorni (predefinito: 30) senza raggiungere la conformità, lo script attiva il metodo diretto dalla guida di Microsoft KB5025885 – noto anche come Mitigation 1+2, che bypassa completamente la pipeline di distribuzione di Windows Update.
# Mitigation 1: Forzare l'aggiornamento DB (Windows UEFI CA 2023) Reg Add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing" /v AvailableUpdates /t REG_DWORD /d 0x40 /f schtasks /run /tn "MicrosoftWindowsPISecure-Boot-Update" # Attendere il completamento e il riavvio # Mitigation 2: Forzare l'aggiornamento Boot Manager (dopo il riavvio) Reg Add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing" /v AvailableUpdates /t REG_DWORD /d 0x100 /f schtasks /run /tn "MicrosoftWindowsPISecure-Boot-Update" # Pianificare il riavvio per completare la transizione
Ho usato questa procedura per “sbloccare” 20 dispositivi che erano rimasti bloccati a Stage 3. Funziona, ma richiede pianificazione e testing su hardware simile prima del deployment in produzione.
Fase di Pilot: Come Ho Strutturato il Mio Rollout
Imparando dalla mia esperienza con altre transizioni infrastrutturali (BitLocker, Intune migration, ecc.), ho strutturato il rollout in 3 anelli:
- Ring 0 (Pilot): 30 dispositivi eterogenei – IT staff + hardware raro (workstation specializzate, lab machines). Ho aspettato 2 settimane per segnali di problemi. Durante questo periodo, ho identificato e risolto il problema con ThinkPad X230 (firmware update richiesto).
- Ring 1 (Canary): 150 dispositivi – office standard (Dell/HP da 2018+). Ho monitorato Event Viewer ID 1808 e ID 1795 per diagnosticare. Problema: 5 dispositivi con BitLocker + custom Secure Boot keys hanno avuto complicazioni. Soluzione: un team call con il team security per “sbloccare” quei PC.
- Ring 2 (Full Rollout): Rimanenti 150 dispositivi. A questo punto, avevo playbook ben testato.
Il timing è critico: Microsoft stima che il processo completo richieda circa 48 ore e uno o più riavvii, e ogni step deve avere successo prima che il prossimo venga eseguito, quindi un dispositivo può stare a metà della sequenza per un po’ se (ad esempio) è in attesa di un aggiornamento firmware o di un riavvio pianificato.
Phase 4: Monitoring e Troubleshooting
Non è “fire and forget”. Ho impostato il monitoraggio continuativo:
Dashboard di Conformità Intune
Per controllare lo stato usando Windows Autopatch, dalla Microsoft Intune admin center, andate a Reports > Windows quality updates e selezionate Secure Boot status nella scheda Reports. Ho creato una Workbook di Azure Monitor che aggrega questi dati e mi avvisa se c’è stagnazione nel progress.
Event ID da Monitorare
- Event ID 1808 (Windows System log): “Secure Boot certificates applied” – Questo è il segnale di successo che state cercando.
- Event ID 1795: “Error during certificate handoff to firmware” – Se vedete questo, contattate l’OEM per un firmware update.
- Event ID 1796: Unexpected Secure Boot failures – Potrebbe indicare tentative di tampering.
Registry Keys da Monitorare
# Controllare per errori Reg Query "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing" /v UEFICA2023Error # Questa chiave NON deve esistere (a meno che un errore sia in sospeso) # Verificare lo stato finale Reg Query "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing" /v UEFICA2023Status # Dovrebbe essere "Updated" alla fine # Se vedete 0x4104 in AvailableUpdates e rimane, il dispositivo è bloccato al KEK Reg Query "HKLM:SYSTEMCurrentControlSetControlSecureBootServicing" /v AvailableUpdates
Considerazioni Speciali: Dual-Boot Linux, Custom Keys, Recovery Media
Nella mia esperienza, questi sono i killer invisibili della transizione:
Dual-Boot Windows + Linux (Shim)
La rimozione del certificato Microsoft UEFI CA è inusuale poiché viene utilizzato per firmare lo Shim del pre-bootloader Linux. Se avete dispositivi che bootano sia Windows che Linux via GRUB, non rimuovete il certificato UEFI CA 2011 fino a quando Linux Shim non supporta il 2023. Ho visto questo causare failed boot su 10 workstation.
Custom Secure Boot Keys
Se avete implementato chiavi Secure Boot custom per hardware security appliances o software specializzato, il processo di transizione certificata può interferire. Testare su una macchina non-production PRIMA di deployare in flotta.
Recovery Media e WinPE
Media di recovery, WinPE e media di installazione creati prima dell’adozione di PCA 2023 potrebbero non riuscire a bootare su firmware aggiornato. Dovrò rigenerare tutte le immagini WinPE per deployment e recovery entro maggio 2026.
FAQ
Se non aggiorno i certificati entro giugno 2026, il mio PC non bootserà?
No. Se il vostro dispositivo raggiunge la data di scadenza senza i nuovi certificati, continuerà comunque ad avviarsi e operare normalmente, gli aggiornamenti standard di Windows continueranno a installare. Tuttavia, il dispositivo non sarà più in grado di ricevere nuove protezioni di sicurezza per il processo di boot iniziale. È un declino graduale, non un crash.
Cosa significa “Boot-level security updates”? Davvero mi serve?
Sì, soprattutto se usate BitLocker. Ogni volta che scopri una vulnerabilità nel bootloader Windows (come è successo con BlackLotus CVE-2023-24932), Microsoft rilascia una patch. Senza i certificati 2023, non potrete applicarla. Nel 2026 e oltre, nuovi bootkit continueranno a emergere. Voi rimarrete bloccati con le protezioni di oggi.
Intune vs. Group Policy – Quale metodo è migliore per il deployment?
Intune, perché vi offre visibility in tempo reale e remediation. Quando l’aggiornamento UEFI DB viene applicato, Microsoft utilizza i dati diagnostici che il vostro dispositivo invia per monitorare se la transizione firmware è riuscita o fallita. Se l’aggiornamento causa un problema, un fallimento di boot, un ciclo di recupero BitLocker o un’incompatibilità firmware, il backend di Microsoft lo rileva tramite la telemetria e blocca automaticamente Windows Update dal re-offrire l’aggiornamento a quel dispositivo specifico. Group Policy non vi dà questo feedback.
Post-Quantum Cryptography nel 2030 – Posso ignorarlo per ora?
No, dovreste iniziare a pianificare adesso. La transizione post-quantum non è solo software – richiede hardware TPM aggiornato. Se ordinate PC oggi, assicuratevi che abbiano TPM che possa supportare ML-KEM/ML-DSA nel 2030. Nel vostro procurement RFQ, includete come requirement: “TPM firmware updateable to support ML-DSA/ML-KEM by 2030”.
Sono un single sysadmin, non un’azienda – Cosa faccio?
Fate riferimento a: mantenete Windows aggiornato, non bloccate gli aggiornamenti relativi al firmware senza motivo, controllate lo stato di Secure Boot nell’app Windows Security. Per la maggior parte degli utenti domestici, questo accade silenziosamente in background tramite aggiornamenti cumulativi normali. A partire dall’aggiornamento di Windows di aprile 2026, l’app Windows Security include informazioni di stato di Secure Boot aggiornate sotto Device security che mostrano se i nuovi certificati sono stati applicati con successo.
Conclusione: Giugno 2026 Non È Ancora Lontano
Nel mio ruolo di System Administrator, ho imparato che le deadline infrastrutturali silenziose – quelle che non causano un crash catastrofico immediatamente – sono le più pericolose. Un anno fa, questa transizione Secure Boot era considerata tecnica e astratta. Ora siamo a giugno 2026 tra 5 mesi. È responsabilità di Microsoft rendere il percorso sicuro il predefinito, ma le organizzazioni devono comunque decidere quanto aggressivamente testare, organizzare in stadi e far rispettare la transizione. La peggiore risposta enterprise sarebbe aspettare fino a fine giugno 2026 e poi scoprire che un sottoinsieme di macchine non può ricevere l’aggiornamento perché sono state escluse dal servizio normale.
La mia raccomandazione pratica: fate il vostro inventory entro fine giugno 2026. Eseguite il pilot a luglio 2026. Distribuite in Ring 1 ad agosto 2026. Completate completamente entro settembre 2026. Questo vi dà buffer prima della scadenza e tempo per mitigare i problemi edge-case.
Inoltre, usate questa finestra per pianificare la vostra transizione post-quantum 2030. Non è una cosa separata – è lo stesso albero di decisioni infrastrutturali. Il certificato Secure Boot 2023 che state distribuendo adesso è il ponte tra il paradigma RSA/ECC di oggi e il mondo ML-DSA/ML-KEM di domani.
Vi ho mostrato la mia procedura testata sul campo. Usatela, adattatela al vostro ambiente, e soprattutto, cominciate adesso. Nel 2026, vi ringrazierete.