{"id":2136,"date":"2026-06-01T15:10:43","date_gmt":"2026-06-01T13:10:43","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/windows-secure-boot-certificate-transition-giugno-2026-enterprise-checklist\/"},"modified":"2026-06-01T15:10:43","modified_gmt":"2026-06-01T13:10:43","slug":"windows-secure-boot-certificate-transition-giugno-2026-enterprise-checklist","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/windows-secure-boot-certificate-transition-giugno-2026-enterprise-checklist\/","title":{"rendered":"Come Implementare Windows Secure Boot Certificate Transition Giugno 2026: La Mia Enterprise Checklist per Firmware UEFI, TPM 2.0 Verification e Post-Quantum Readiness"},"content":{"rendered":"

Amici, il conto alla rovescia \u00e8 ufficialmente iniziato. Giugno 2026<\/strong> non \u00e8 una data casuale nei vostri calendari: \u00e8 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\u00e0 aziendali sottovalutare questo tipo di transizioni infrastrutturali: il boot funziona ancora, gli update di Windows arrivano, quindi tutto sembra OK. Ma \u00e8 un’illusione pericolosa.<\/p>\n

In questo articolo vi guido attraverso la mia procedura enterprise testata sul campo per gestire questa transizione verso i certificati 2023<\/em>, includendo verifica di firmware UEFI<\/strong>, validazione TPM 2.0<\/strong>, e preparazione verso il futuro post-quantum<\/strong> che arriver\u00e0 nel 2030. Vi mostro come ho strutturato inventory, pilot groups, e mitigazione dei rischi per flotte di centinaia di dispositivi senza sorprese a giugno.<\/p>\n

Cosa Sta Succedendo Davvero a Giugno 2026<\/h2>\n

Partiamo dai fatti. L’organizzazione dovr\u00e0 installare i certificati 2023 prima che i certificati 2011 inizino a scadere a giugno del 2026<\/cite>. Non \u00e8 un aggiornamento banale: Secure Boot usa chiavi crittografiche, note come Certificate Authorities (CAs), per validare che i moduli firmware provengono da una fonte affidabile<\/cite>.<\/p>\n

Ecco cosa accade se non vi preparate:<\/p>\n

    \n
  • I dispositivi perderanno la capacit\u00e0 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<\/cite>.<\/li>\n
  • Il dispositivo non sar\u00e0 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<\/cite>.<\/li>\n
  • Le correzioni di vulnerabilit\u00e0 per l’ambiente di boot iniziale, come le mitigazioni del bypass di BitLocker o le revoche di Secure Boot, non saranno disponibili<\/cite>.<\/li>\n<\/ul>\n

    La parte inquietante? I dispositivi continueranno ad avviarsi normalmente e gli aggiornamenti standard di Windows continueranno a essere installati<\/cite>. Quindi manager e utenti non si accorgeranno nemmeno del problema fino a quando un nuovo attacco a livello di boot emerger\u00e0 e non potrete applicare la patch.<\/p>\n

    La Struttura del Secure Boot: PK, KEK, DB, DBX<\/h2>\n

    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\u00f2 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\u00f2 girare nell’ambiente UEFI prima che l’OS si avvii<\/cite>.<\/p>\n

    Nella mia esperienza di configuration management per ambienti enterprise, il punto critico \u00e8 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\u00f2 essere utilizzato per verificare la configurazione di Secure Boot<\/cite>. Questo collegamento TPM \u2194 Secure Boot \u00e8 essenziale per qualsiasi attestazione o validazione di conformit\u00e0.<\/p>\n

    Phase 1: Inventory e Assessment (Subito, Non Aspettate)<\/h2>\n

    Ho imparato sulla mia pelle che saltare questo step significa essere costretti a improvvisare a maggio 2026. Ecco come lo faccio:<\/p>\n

    Step 1.1: Identificare Dispositivi con Secure Boot Attivo<\/h3>\n

    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<\/cite>.<\/p>\n

    Comando PowerShell rapido per inventario:<\/p>\n

    \n# Esegui su tutti i PC enterprise via GPO o Intune\n$SecureBootStatus = Get-WmiObject -Class Win32_ComputerSystem | Select -ExpandProperty SecureBootState\n$SecureBootCapable = Get-WmiObject -Class Win32_ComputerSystem | Select -ExpandProperty BootupState\n\nif ($SecureBootStatus -eq \"On\") {\n    Write-Host \"Secure Boot: ABILITATO - Questo dispositivo \u00e8 idoneo per la transizione 2026\"\n} elseif ($SecureBootStatus -eq \"Off\") {\n    Write-Host \"Secure Boot: DISABILITATO - Questo dispositivo NON \u00e8 idoneo, verificare il motivo\"\n} else {\n    Write-Host \"Secure Boot: NON SUPPORTATO - Dispositivo legacy BIOS, nessuna azione richiesta\"\n}\n<\/pre>\n
    Ho caricato questo script come Intune Remediation per 500+ dispositivi in una recente engagement enterprise. Il risultato \u00e8 stato sorprendente: il 15% non aveva Secure Boot abilitato per vari motivi (vecchie immagini gold, dispositivi di laboratorio, software legacy incompatibile).<\/p>\n
    Step 1.2: Verificare lo Stato Attuale dei Certificati<\/h3>\n
    Controllare quale certificato \u00e8 attualmente presente sul dispositivo:<\/p>\n
    \n# Controllare il stato dei certificati 2023\n$UEFIStatus = Get-ItemProperty -Path \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\" -Name UEFICA2023Status -ErrorAction SilentlyContinue\n\nif ($UEFIStatus.UEFICA2023Status -eq \"updated\") {\n    Write-Host \"\u2713 Certificati 2023 INSTALLATI - Dispositivo pronto per giugno 2026\"\n} elseif ($UEFIStatus.UEFICA2023Status -eq \"in_progress\") {\n    Write-Host \"\u23f3 Certificati 2023 in transizione - Attendere completamento\"\n} else {\n    Write-Host \"\u2717 Certificati 2023 NON INSTALLATI - Azione richiesta\"\n}\n<\/cite>\n<\/pre>\n
    Questa chiave di registro \u00e8 il vostro single source of truth<\/strong> per il reporting di conformit\u00e0. Il valore testuale della chiave di registro UEFICA2023Status indicher\u00e0 se lo stato di distribuzione del certificato non \u00e8 avviato, in corso, o aggiornato<\/cite>.<\/p>\n
    Step 1.3: Firmware Readiness Check<\/h3>\n
    Questo \u00e8 il passaggio che molti amministratori saltano, e dove iniziano i problemi. Non tutti i firmware UEFI gestiscono bene la transizione certificata. Ho visto:<\/p>\n
      \n
    • ThinkPad X230 (2012) con UEFI firmware antichissimo che non supporta le nuove strutture DB espanse<\/li>\n
    • Dell Latitude 5000 con firmware che resetta i certificati se Secure Boot viene attivato\/disattivato<\/li>\n
    • ASUS workstation dove il firmware non espone correttamente il DBX<\/li>\n<\/ul>\n
      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<\/cite>.<\/p>\n
      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:<\/p>\n
        \n
      1. Verificate il modello esatto e il firmware attuale del dispositivo<\/li>\n
      2. Scaricate il BIOS pi\u00f9 recente dal sito del vendor<\/li>\n
      3. Pianificate un rollout in anelli (pilot \u2192 office standard \u2192 legacy machines)<\/li>\n<\/ol>\n
        Phase 2: TPM 2.0 Verification e Post-Quantum Readiness<\/h2>\n
        Non potete separare questa transizione da una conversazione pi\u00f9 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\u00e0 nel 2030.<\/p>\n
        Verificare la Presenza e il Funzionamento di TPM 2.0<\/h3>\n
        I valori di PK, KEK, DB e DBX sono registrati nel TPM Platform Configuration Register (PCR) 7, e il TPM pu\u00f2 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\u00e0 quote TPM<\/cite>.<\/p>\n
        Nel mio ruolo di infrastruttore, questo significa:<\/p>\n
        \n# Verificare TPM 2.0 e capacit\u00e0 di attestazione\n$TPMInfo = Get-WmiObject -Namespace \"rootcimv2securitymicrosofttpm\" -Class Win32_Tpm\n\nif ($TPMInfo -ne $null) {\n    Write-Host \"TPM 2.0 Presente: $($TPMInfo.SpecVersion)\"\n    \n    # Controllare il registro PCR 7 (Secure Boot State)\n    $PCR7 = tpm2.exe pcrrread pcr:7 -o - 2>&1 | Select-String \"0x\"\n    Write-Host \"PCR 7 (Secure Boot State) Value: $PCR7\"\n    \n    # Verifica di conformit\u00e0 BitLocker\n    $BitLockerVolume = Get-BitLockerVolume -MountPoint C: -ErrorAction SilentlyContinue\n    if ($BitLockerVolume.ProtectionStatus -eq \"On\") {\n        Write-Host \"BitLocker Attivo - Attestazione TPM disponibile\"\n    }\n} else {\n    Write-Host \"AVVISO: TPM 2.0 non rilevato o disabilitato nel UEFI\"\n}\n<\/pre>\n
        Ho scoperto nella mia pratica che molti PC enterprise hanno TPM 2.0 hardware ma disabilitato nel BIOS per compatibilit\u00e0 legacy con software vecchio. Questo deve essere risolto prima della scadenza certificata.<\/p>\n
        Post-Quantum Readiness: Perch\u00e9 Preoccuparsi Ora<\/h3>\n
        Una domanda comune che ricevo: “Ma il post-quantum \u00e8 nel 2030, perch\u00e9 preoccuparcene nel 2026?”. La risposta \u00e8 nella minaccia “Harvest Now, Decrypt Later”. La trasformazione verso la crittografia post-quantum avverr\u00e0 nel 2030, e mentre l’hardware legacy che riceve attualmente i certificati 2023 li manterr\u00e0 fino alla fine della loro vita utile, il nuovo hardware fabbricato negli anni 2030 spedir\u00e0 con certificati Post-Quantum completamente nuovi<\/cite>.<\/p>\n
        Nella mia strategia di preparazione:<\/p>\n
          \n
        • 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 \u00e8 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<\/cite>.<\/li>\n<\/ul>\n
          Nel mio ambiente enterprise, sto gi\u00e0 testando ambienti Ubuntu 26.04 con ML-KEM per SSH. Vi consiglio di iniziare a tracciare le vostre capacit\u00e0 PQC hardware in parallelo con la transizione Secure Boot 2023:<\/p>\n
          \n# Creare una propriet\u00e0 di inventario asset per tracciare PQC readiness\n# Nel vostro CMDB o asset management platform:\n\nPROPERTY: pqc_hardware_capable = (TPM version >= 1.85 AND firmware date >= 2024-Q3)\nPROPERTY: secure_boot_2023_status = (registry UEFICA2023Status)\nPROPERTY: ml_kem_ssh_tested = boolean\n\n# Questo vi permette di segmentare il vostro upgrade path nel 2029-2030\n<\/pre>\n
          Phase 3: Deployment Strategy – Come Ho Fatto in Produzione<\/h2>\n
          Teoricamente, Microsoft dice che la maggior parte degli aggiornamenti avverr\u00e0 automaticamente. Nella pratica, in ambienti enterprise, il controllo \u00e8 essenziale.<\/p>\n
          Opzione A: Optical-In Controllato con Registry (Consigliato)<\/h3>\n
          La linea guida Microsoft per le imprese \u00e8 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<\/cite>.<\/p>\n
          Questo \u00e8 il metodo che ho usato per gestire flotte di 300+ dispositivi senza problemi:<\/p>\n
          \n# Step 1: Set the MicrosoftUpdateManagedOptIn registry key (via Intune\/GPO)\nReg Add \"HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing\" \/v MicrosoftUpdateManagedOptIn \/t REG_DWORD \/d 1 \/f\n\n# Step 2: Verify telemetry is enabled (diagnostic data at minimum \"Required\")\n# Se telemetria \u00e8 disabilitata, Microsoft non pu\u00f2 applicare le safety gates\n\n# Step 3: Trigger the scheduled task manualmente dopo il test pilota\nschtasks \/run \/tn \"MicrosoftWindowsPISecure-Boot-Update\"\n\n# Step 4: Monitorare il registro PCR 7 con l'evento ID 1808 nei log di sistema\nGet-WinEvent -LogName System -FilterXPath \"*[System[EventID=1808]]\" | Select TimeCreated, Message\n<\/pre>\n
          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<\/strong> e di identificare i dispositivi che non avanzano nella transizione.<\/p>\n
          Opzione B: Mitigazione Diretta se Windows Update Non Funziona<\/h3>\n
          Per i dispositivi che rimangono bloccati nello stato “in_progress” anche dopo settimane, se un dispositivo \u00e8 stato sottoposto a opt-in per pi\u00f9 di FallbackDays giorni (predefinito: 30) senza raggiungere la conformit\u00e0, lo script attiva il metodo diretto dalla guida di Microsoft KB5025885 \u2013 noto anche come Mitigation 1+2, che bypassa completamente la pipeline di distribuzione di Windows Update<\/cite>.<\/p>\n
          \n# Mitigation 1: Forzare l'aggiornamento DB (Windows UEFI CA 2023)\nReg Add \"HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing\" \/v AvailableUpdates \/t REG_DWORD \/d 0x40 \/f\nschtasks \/run \/tn \"MicrosoftWindowsPISecure-Boot-Update\"\n\n# Attendere il completamento e il riavvio\n\n# Mitigation 2: Forzare l'aggiornamento Boot Manager (dopo il riavvio)\nReg Add \"HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBootServicing\" \/v AvailableUpdates \/t REG_DWORD \/d 0x100 \/f\nschtasks \/run \/tn \"MicrosoftWindowsPISecure-Boot-Update\"\n\n# Pianificare il riavvio per completare la transizione\n<\/pre>\n
          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.<\/p>\n
          Fase di Pilot: Come Ho Strutturato il Mio Rollout<\/h3>\n
          Imparando dalla mia esperienza con altre transizioni infrastrutturali (BitLocker, Intune migration, ecc.), ho strutturato il rollout in 3 anelli:<\/p>\n
            \n
          • Ring 0 (Pilot)<\/strong>: 30 dispositivi eterogenei \u2013 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).<\/li>\n
          • Ring 1 (Canary)<\/strong>: 150 dispositivi \u2013 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.<\/li>\n
          • Ring 2 (Full Rollout)<\/strong>: Rimanenti 150 dispositivi. A questo punto, avevo playbook ben testato.<\/li>\n<\/ul>\n
            Il timing \u00e8 critico: Microsoft stima che il processo completo richieda circa 48 ore e uno o pi\u00f9 riavvii, e ogni step deve avere successo prima che il prossimo venga eseguito, quindi un dispositivo pu\u00f2 stare a met\u00e0 della sequenza per un po’ se (ad esempio) \u00e8 in attesa di un aggiornamento firmware o di un riavvio pianificato<\/cite>.<\/p>\n
            Phase 4: Monitoring e Troubleshooting<\/h2>\n
            Non \u00e8 “fire and forget”. Ho impostato il monitoraggio continuativo:<\/p>\n
            Dashboard di Conformit\u00e0 Intune<\/h3>\n
            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<\/cite>. Ho creato una Workbook di Azure Monitor che aggrega questi dati e mi avvisa se c’\u00e8 stagnazione nel progress.<\/p>\n
            Event ID da Monitorare<\/h3>\n
              \n
            • Event ID 1808<\/strong> (Windows System log): “Secure Boot certificates applied” \u2013 Questo \u00e8 il segnale di successo che state cercando.<\/li>\n
            • Event ID 1795<\/strong>: “Error during certificate handoff to firmware” \u2013 Se vedete questo, contattate l’OEM per un firmware update.<\/li>\n
            • Event ID 1796<\/strong>: Unexpected Secure Boot failures \u2013 Potrebbe indicare tentative di tampering.<\/li>\n<\/ul>\n
              Registry Keys da Monitorare<\/h3>\n
              \n# Controllare per errori\nReg Query \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\" \/v UEFICA2023Error\n# Questa chiave NON deve esistere (a meno che un errore sia in sospeso)\n\n# Verificare lo stato finale\nReg Query \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\" \/v UEFICA2023Status\n# Dovrebbe essere \"Updated\" alla fine\n\n# Se vedete 0x4104 in AvailableUpdates e rimane, il dispositivo \u00e8 bloccato al KEK\nReg Query \"HKLM:SYSTEMCurrentControlSetControlSecureBootServicing\" \/v AvailableUpdates\n<\/pre>\n
              Considerazioni Speciali: Dual-Boot Linux, Custom Keys, Recovery Media<\/h2>\n
              Nella mia esperienza, questi sono i killer invisibili della transizione:<\/p>\n
              Dual-Boot Windows + Linux (Shim)<\/h3>\n
              La rimozione del certificato Microsoft UEFI CA \u00e8 inusuale poich\u00e9 viene utilizzato per firmare lo Shim del pre-bootloader Linux<\/cite>. 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.<\/p>\n
              Custom Secure Boot Keys<\/h3>\n
              Se avete implementato chiavi Secure Boot custom per hardware security appliances o software specializzato, il processo di transizione certificata pu\u00f2 interferire. Testare su una macchina non-production PRIMA di deployare in flotta.<\/p>\n
              Recovery Media e WinPE<\/h3>\n
              Media di recovery, WinPE e media di installazione creati prima dell’adozione di PCA 2023 potrebbero non riuscire a bootare su firmware aggiornato<\/cite>. Dovr\u00f2 rigenerare tutte le immagini WinPE per deployment e recovery entro maggio 2026.<\/p>\n
              FAQ<\/h2>\n
              Se non aggiorno i certificati entro giugno 2026, il mio PC non bootser\u00e0?<\/h3>\n
              No. Se il vostro dispositivo raggiunge la data di scadenza senza i nuovi certificati, continuer\u00e0 comunque ad avviarsi e operare normalmente, gli aggiornamenti standard di Windows continueranno a installare. Tuttavia, il dispositivo non sar\u00e0 pi\u00f9 in grado di ricevere nuove protezioni di sicurezza per il processo di boot iniziale<\/cite>. \u00c8 un declino graduale, non un crash.<\/p>\n
              Cosa significa “Boot-level security updates”? Davvero mi serve?<\/h3>\n
              S\u00ec, soprattutto se usate BitLocker. Ogni volta che scopri una vulnerabilit\u00e0 nel bootloader Windows (come \u00e8 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.<\/p>\n
              Intune vs. Group Policy \u2013 Quale metodo \u00e8 migliore per il deployment?<\/h3>\n
              Intune, perch\u00e9 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 \u00e8 riuscita o fallita. Se l’aggiornamento causa un problema, un fallimento di boot, un ciclo di recupero BitLocker o un’incompatibilit\u00e0 firmware, il backend di Microsoft lo rileva tramite la telemetria e blocca automaticamente Windows Update dal re-offrire l’aggiornamento a quel dispositivo specifico<\/cite>. Group Policy non vi d\u00e0 questo feedback.<\/p>\n
              Post-Quantum Cryptography nel 2030 \u2013 Posso ignorarlo per ora?<\/h3>\n
              No, dovreste iniziare a pianificare adesso. La transizione post-quantum non \u00e8 solo software \u2013 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”.<\/p>\n
              Sono un single sysadmin, non un’azienda \u2013 Cosa faccio?<\/h3>\n
              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<\/strong>. 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<\/cite>.<\/p>\n
              Conclusione: Giugno 2026 Non \u00c8 Ancora Lontano<\/h2>\n
              Nel mio ruolo di System Administrator, ho imparato che le deadline infrastrutturali silenziose \u2013 quelle che non causano un crash catastrofico immediatamente \u2013 sono le pi\u00f9 pericolose. Un anno fa, questa transizione Secure Boot era considerata tecnica e astratta. Ora siamo a giugno 2026 tra 5 mesi. \u00c8 responsabilit\u00e0 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\u00f2 ricevere l’aggiornamento perch\u00e9 sono state escluse dal servizio normale<\/cite>.<\/p>\n
              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<\/strong>. Questo vi d\u00e0 buffer prima della scadenza e tempo per mitigare i problemi edge-case.<\/p>\n
              Inoltre, usate questa finestra per pianificare la vostra transizione post-quantum 2030. Non \u00e8 una cosa separata \u2013 \u00e8 lo stesso albero di decisioni infrastrutturali. Il certificato Secure Boot 2023 che state distribuendo adesso \u00e8 il ponte tra il paradigma RSA\/ECC di oggi e il mondo ML-DSA\/ML-KEM di domani.<\/p>\n
              Vi ho mostrato la mia procedura testata sul campo. Usatela, adattatela al vostro ambiente, e soprattutto, cominciate adesso<\/strong>. Nel 2026, vi ringrazierete.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Windows Secure Boot Certificate Transition Giugno 2026: La mia enterprise checklist definitiva per firmware UEFI, TPM 2.0 verification e post-quantum readiness. Inventory, pilot, deployment strategy e troubleshooting.<\/p>\n","protected":false},"author":1,"featured_media":2137,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Secure Boot Certificate Transition 2026 | Enterprise Checklist","_seopress_titles_desc":"Guida enterprise alla transizione Secure Boot certificate June 2026: inventory UEFI firmware, TPM 2.0 verification, deployment strategy. Come ho gestito 300+ dispositivi con successo.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[471,871,361,859,870,469],"class_list":["post-2136","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-enterprise-security","tag-post-quantum-cryptography","tag-secure-boot","tag-tpm-2-0","tag-uefi-firmware","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2136","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2136"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2136\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2137"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2136"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}