Perché Windows 11 insiste su Secure Boot e TPM 2.0
Windows 11 non chiede questi due requisiti per complicare la vita a chi amministra le macchine. Li usa come base minima per ridurre il rischio su avvio, identità del dispositivo e protezione delle chiavi. In pratica: Secure Boot serve a limitare il caricamento di bootloader e componenti non firmati durante l’avvio, mentre TPM 2.0 fornisce un modulo fidato per operazioni crittografiche, misurazioni dell’avvio, BitLocker, Windows Hello e alcune funzioni di protezione credenziali.
Se il tuo obiettivo è installare o mantenere Windows 11 in modo pulito, la domanda non è “posso forzarlo?”, ma “il firmware e l’hardware espongono davvero questi due prerequisiti in modo corretto?”. Il punto è verificare prima, poi attivare, e solo dopo correggere eventuali configurazioni incoerenti nel firmware.
La parte che crea più confusione è che i due requisiti non vivono nello stesso posto: Secure Boot è una funzione del firmware UEFI, TPM 2.0 può essere un chip fisico oppure un TPM firmware integrato nel processore o nella piattaforma. Quindi non basta aprire Windows e cercare un interruttore unico.
Controllo rapido da Windows: capire subito se sei già a posto
Prima di toccare il BIOS/UEFI, conviene leggere lo stato dal sistema operativo. Così eviti cambi inutili e capisci se il problema è davvero hardware o solo di configurazione.
- Apri Win + R, digita
msinfo32e premi Invio. - Nel riquadro Informazioni di sistema, cerca le voci Stato Avvio protetto e Modalità BIOS.
- Se Modalità BIOS indica UEFI e Stato Avvio protetto indica Attivo, Secure Boot è già operativo.
- Se Modalità BIOS indica Legacy o Compatibilità, Secure Boot non può funzionare finché il firmware non viene portato su UEFI puro.
Per il TPM, usa uno di questi due controlli:
- Apri Win + R, digita
tpm.msce premi Invio. - Verifica la sezione Stato: deve indicare che il TPM è pronto all’uso.
- Controlla Versione specifica: per Windows 11 serve 2.0.
In alternativa, da PowerShell amministrativo:
Get-TpmIl risultato utile è guardare i campi TpmPresent, TpmReady e, se disponibile, lo stato del dispositivo. Se TpmPresent è False, il sistema non vede alcun TPM. Se è True ma non è pronto, spesso il problema è nel firmware o in una policy che lo ha disabilitato.
Secure Boot: cosa deve esserci nel firmware UEFI
Secure Boot non si accende da Windows come un servizio. Si abilita nel firmware della scheda madre o del portatile. Il nome dell’opzione cambia spesso: Secure Boot, OS Type, Windows UEFI Mode, Boot Mode, CSM, Legacy Support. La logica però è quasi sempre la stessa.
Per farlo funzionare, servono questi requisiti:
- Firmware UEFI, non Legacy/CSM.
- Disco di avvio GPT nella maggior parte dei casi, soprattutto se il sistema è stato installato in modalità UEFI.
- Chiavi Secure Boot caricate nel firmware, se il vendor le ha cancellate o non sono inizializzate.
Se Windows è stato installato in modalità legacy su disco MBR, non basta attivare Secure Boot nel BIOS: il sistema potrebbe non avviarsi. In quel caso il passaggio va pianificato con attenzione, verificando prima la modalità di partizione del disco e l’eventuale conversione a GPT.
Dal lato Windows puoi verificare il tipo di partizione del disco di sistema con:
diskpart
list diskSe nella colonna GPT compare l’asterisco sul disco di sistema, il disco è già GPT. Se non c’è, e il sistema è in legacy, serve una migrazione prima di cambiare la modalità di boot.
TPM 2.0: chip fisico, firmware TPM e casi ibridi
TPM 2.0 è spesso il punto meno chiaro, perché molti utenti pensano che se non vedono un chip sulla scheda madre allora non esista. In realtà su molte piattaforme moderne il TPM è integrato nel firmware della CPU o del chipset. I nomi commerciali cambiano:
- Intel: PTT spesso indica il TPM firmware.
- AMD: fTPM indica il TPM firmware.
- Alcune workstation/server hanno anche un modulo TPM discreto su header o slot dedicato.
Dal punto di vista di Windows, quello che conta è che il sistema esponga un TPM conforme e inizializzato. Se il firmware lo disabilita, Windows non può inventarselo.
Nel firmware cerca opzioni come:
- TPM Device
- Security Device Support
- Intel PTT
- AMD fTPM
- Trusted Computing
Su alcune macchine l’attivazione del TPM cambia anche il comportamento del boot o richiede un riavvio doppio. Su altre, soprattutto notebook business, compare anche una voce per Restore TPM o Clear TPM. Quella è delicata: cancellare il TPM può rendere inaccessibili chiavi BitLocker e altre credenziali legate al dispositivo. Va fatto solo se sai esattamente cosa stai proteggendo e dopo aver sospeso o messo in sicurezza le chiavi di recupero.
Se BitLocker è già attivo, non “piallare” il TPM per tentativi. Prima salva la recovery key e verifica lo stato di protezione del volume.
Verifica della modalità UEFI: il passaggio che blocca più spesso Secure Boot
La situazione più comune è questa: TPM 2.0 c’è, ma Secure Boot risulta non disponibile o disattivato. Quasi sempre il motivo è che il sistema sta ancora avviando in Legacy BIOS o ha CSM attivo.
Da Windows, controlla con msinfo32 la voce Modalità BIOS. Se non è UEFI, il firmware sta usando un percorso di avvio vecchio. In quel caso la sequenza corretta è:
- Verificare che il disco di sistema sia GPT.
- Valutare la conversione di MBR a GPT, se serve e se il sistema lo consente.
- Disabilitare CSM o Legacy Boot nel firmware.
- Abilitare UEFI puro.
- Solo dopo, attivare Secure Boot.
Se vuoi capire in anticipo il rischio di conversione, controlla lo stato del disco e fai un backup della configurazione prima di intervenire. In ambiente enterprise o su macchine di produzione, il cambio di boot mode va trattato come un change controllato, non come una prova a caso.
Sequenza consigliata per abilitare Secure Boot e TPM 2.0 senza sorprese
La sequenza sotto minimizza il rischio di ritrovarsi con un sistema non avviabile o con BitLocker che chiede la recovery key a ogni accensione.
- Verifica stato attuale in Windows:
msinfo32per Secure Boot e modalità BIOS,tpm.mscoGet-Tpmper TPM. - Salva il recovery key di BitLocker se il disco è cifrato. Se non sai dove sia, recuperala prima di cambiare il firmware.
- Entra nel firmware UEFI e annota le impostazioni attuali, soprattutto Boot Mode, CSM/Legacy, Secure Boot e TPM/PTT/fTPM.
- Abilita TPM 2.0 se presente ma disattivato.
- Disabilita CSM o Legacy se il sistema è pronto per UEFI puro.
- Abilita Secure Boot e, se richiesto dal vendor, carica le chiavi di default.
- Salva e riavvia, poi ricontrolla da Windows lo stato effettivo.
In molti firmware l’opzione non si chiama “Secure Boot Enable” ma compare solo dopo aver disattivato CSM. È normale. In altri casi bisogna prima impostare un profilo di sistema tipo Windows UEFI Mode o OS Type = Windows 10/11 WHQL. Il nome cambia, la sostanza no: il firmware deve accettare il percorso di avvio firmato.
Come leggere i messaggi d’errore più comuni
Quando qualcosa non torna, il problema di solito si manifesta in uno di questi modi:
- “Secure Boot State: Unsupported” in
msinfo32: il firmware è ancora in Legacy o non espone Secure Boot. - TPM non trovato in
tpm.msc: TPM disattivato nel firmware o assente. - TPM presente ma non pronto: firmware non inizializzato, policy bloccante o stato da ripristinare.
- Richiesta chiave BitLocker al riavvio: il cambio di boot o di firmware ha alterato la misura dell’avvio, quindi BitLocker ha reagito come previsto.
Nel caso di BitLocker, non è un guasto in senso stretto: è un effetto collaterale del cambiamento di fiducia sulla catena di avvio. La mitigazione corretta è avere la recovery key prima del cambio e, se necessario, sospendere la protezione temporaneamente durante l’intervento.
Comando utile per vedere lo stato dei volumi:
manage-bde -statusSe il volume di sistema è protetto, verifica che la chiave di ripristino sia archiviata in un posto affidabile, ad esempio account Microsoft, AD, Azure AD o vault aziendale, a seconda del contesto.
Quando il firmware non mostra TPM o Secure Boot
Qui bisogna distinguere tra mancanza reale e opzione nascosta. Alcuni vendor nascondono le impostazioni fino a quando non imposti una password di amministrazione del BIOS, altri le rendono disponibili solo in modalità avanzata.
Se il TPM non compare proprio:
- Controlla il manuale del modello esatto della scheda madre o del notebook.
- Verifica se il TPM è firmware-based e quindi abilitabile come PTT o fTPM.
- Controlla eventuali aggiornamenti BIOS/UEFI, perché su alcune piattaforme il supporto TPM 2.0 è comparso o si è stabilizzato con revisioni successive.
Se Secure Boot non compare:
- Verifica che il firmware sia davvero UEFI e non un layer di compatibilità.
- Cerca l’opzione CSM e disattivala.
- Controlla se esiste una voce per caricare le chiavi di default.
- Su alcuni sistemi, reimpostare il firmware ai default UEFI fa riapparire le opzioni mancanti.
Qui non c’è una scorciatoia universale. Se il produttore non espone il supporto, o il firmware è troppo vecchio, la chiusura del gap passa da un aggiornamento BIOS/UEFI o, nei casi peggiori, da una sostituzione hardware.
Verifiche finali dopo l’attivazione
Dopo il riavvio, non fermarti al fatto che Windows parta. Devi verificare che lo stato sia davvero quello desiderato.
- Apri
msinfo32e conferma Modalità BIOS: UEFI e Stato Avvio protetto: Attivo. - Apri
tpm.msce controlla che il TPM sia pronto e che la versione sia 2.0. - Se usi BitLocker, verifica che il volume sia protetto e che non ci siano richieste di recovery key al boot successivo.
- Se la macchina è gestita, controlla anche eventuali policy di sicurezza o compliance che leggono questi attributi.
Se vuoi una conferma più tecnica da PowerShell, puoi usare:
Get-Tpm
Confirm-SecureBootUEFIIl secondo comando ha senso solo in ambiente UEFI con Secure Boot supportato. Se restituisce errore, il problema è quasi sempre nel contesto firmware, non in Windows.
Nota pratica per ambienti con più macchine
Su un parco macchine misto, la tentazione è uniformare tutto in fretta. Meglio invece separare i casi:
- Macchine già UEFI + TPM 2.0: attivazione e verifica rapida.
- Macchine UEFI ma Secure Boot disattivato: cambio a rischio basso, con controllo BitLocker.
- Macchine Legacy/MBR: intervento più delicato, da trattare come migrazione di boot.
- Hardware non compatibile: non forzare, documenta il limite e pianifica il refresh.
Il valore operativo sta nel classificare bene prima di toccare il firmware. È il modo più semplice per evitare ticket lunghi e riavvii inutili.
Se devi fare una verifica rapida su una singola postazione, il flusso minimo è questo: msinfo32 per UEFI/Secure Boot, tpm.msc per TPM, controllo di BitLocker, poi intervento nel firmware solo se manca qualcosa. Se invece stai preparando un parco macchine per Windows 11, conviene standardizzare il check con strumenti di inventario o script di audit, così non devi aprire il BIOS a ogni singolo endpoint.
In sintesi operativa: Secure Boot dipende dal firmware UEFI e dalla catena di avvio; TPM 2.0 dipende dalla presenza e dall’esposizione corretta del modulo. Se uno dei due manca, la soluzione passa quasi sempre da firmware, modalità di boot e coerenza della partizione di sistema, non da Windows stesso.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.