1 20/10/2026 9 min

Quando il TPM va trattato come un componente operativo, non come un dettaglio hardware

Il TPM non serve solo a “fare BitLocker”. In ambienti Windows moderni è un tassello di fiducia hardware che incide su cifratura, attestazione, protezione delle chiavi e posture di sicurezza basate su Secure Boot, Virtualization-Based Security e protezione credenziali. Se lavori su endpoint, server o immagini standardizzate, sapere quali cmdlet PowerShell usare per leggerne lo stato e per gestirne il ciclo di vita evita interventi manuali inutili e riduce il rischio di errori durante provisioning, remediation e troubleshooting.

La regola pratica è semplice: prima si osserva, poi si cambia. Con il TPM questo significa verificare versione, presenza, stato, readiness e eventuali blocchi prima di tentare inizializzazioni o reset. I cmdlet utili sono pochi, ma vanno usati con criterio perché alcune operazioni possono invalidare chiavi o richiedere riavvii.

Il primo check: capire cosa vede Windows

Il cmdlet di partenza è Get-Tpm. È il modo più rapido per sapere se Windows rileva un TPM, se è pronto all’uso e se ci sono condizioni che impediscono l’operatività. In pratica è il tuo “health check” iniziale.

Su una sessione PowerShell elevata puoi usare:

Get-Tpm

Gli attributi più utili da leggere sono TpmPresent, TpmReady, ManagedAuthLevel, OwnerAuth e, dove disponibile, le informazioni relative a compatibilità e bootstrap. Se TpmPresent è False, il problema non è PowerShell: o il firmware non espone il modulo, o il device è disabilitato nel BIOS/UEFI, o la macchina è una VM senza vTPM abilitato.

Se invece TpmPresent è True ma TpmReady è False, hai un caso tipico da indagare: TPM non inizializzato, ownership da completare, policy che blocca l’attivazione, oppure stato incoerente dopo un cambio firmware o un reset della scheda madre.

Cmdlet fondamentali da conoscere

In ambienti Windows 10/11 e Windows Server recenti, il modulo TPM espone pochi cmdlet ma copre la maggior parte dei casi operativi. La base è questa:

  1. Get-Tpm: legge lo stato del TPM.
  2. Initialize-Tpm: prepara il TPM all’uso, quando il sistema lo consente.
  3. Clear-Tpm: resetta il TPM rimuovendo le chiavi memorizzate.
  4. Set-TPMAutoProvisioning: controlla il provisioning automatico da parte di Windows.
  5. Get-TPMEndorsementKeyInfo o cmdlet equivalenti presenti nel sistema: utili in casi specifici di attestazione e diagnostica, a seconda della versione di Windows.

Non tutti i sistemi espongono esattamente lo stesso set di cmdlet o gli stessi parametri. È un punto importante: prima di automatizzare, verifica il modulo disponibile sul sistema target con Get-Command *Tpm*.

Get-Command *Tpm*

Questo comando ti restituisce l’elenco reale dei cmdlet presenti, evitando di basarti su documentazione generica o su versioni di Windows diverse dalla tua.

Verificare la presenza del modulo e il contesto di esecuzione

Prima di qualsiasi intervento, conviene capire se stai lavorando in una console con privilegi adeguati e se il modulo TPM è effettivamente disponibile. In ambienti gestiti, il blocco più comune non è tecnico ma di contesto: sessione non elevata, endpoint con policy restrittive, oppure PowerShell eseguito in un host con limitazioni.

Get-Module -ListAvailable Tpm
whoami /groups

Se il modulo non compare, è probabile che il sistema non abbia il supporto previsto o che l’immagine sia stata alleggerita in modo aggressivo. Se invece il modulo c’è ma il cmdlet fallisce con access denied, verifica che la console sia elevata e che eventuali restrizioni locali o GPO non stiano bloccando l’accesso al provider di sicurezza.

Leggere lo stato del TPM in modo utile, non solo “presente/non presente”

Get-Tpm da solo è spesso sufficiente, ma in troubleshooting serio conviene trasformare l’output in un controllo leggibile e ripetibile. Un esempio pratico è filtrare le proprietà rilevanti per capire rapidamente se il dispositivo è pronto oppure no.

$tpm = Get-Tpm
$tpm | Select-Object TpmPresent, TpmReady, ManagedAuthLevel, OwnerAuth

Se TpmReady è falso ma il dispositivo è presente, i casi più frequenti sono tre: TPM disabilitato nel firmware, provisioning non completato, oppure stato sporco dopo una migrazione hardware. In tutti e tre i casi, il cmdlet utile non è subito il reset: prima conviene capire se Windows può completare il provisioning da solo.

Abilitare o disabilitare il provisioning automatico

Set-TPMAutoProvisioning è il comando da usare quando vuoi decidere se Windows deve gestire automaticamente il provisioning del TPM. È particolarmente utile in immagini standard, durante deployment massivi o in scenari dove vuoi evitare che il sistema tocchi il TPM in modo opportunistico prima che siano applicate tutte le policy richieste.

Esempio di controllo dello stato corrente:

Get-TPMAutoProvisioning

Per modificarlo, la sintassi può variare leggermente in base alla versione, quindi il modo corretto è verificare l’aiuto locale prima di applicare parametri automatici in produzione:

Get-Help Set-TPMAutoProvisioning -Full

Il punto operativo è questo: se lavori in un contesto dove il TPM deve essere inizializzato solo dopo l’applicazione di baseline e policy, disabilita il provisioning automatico durante le fasi iniziali e riabilitalo quando il sistema è pronto. Se invece stai recuperando endpoint standard e vuoi che Windows completi la configurazione, mantieni il provisioning automatico attivo.

Inizializzare il TPM quando il sistema è pronto

Initialize-Tpm serve quando il TPM è presente ma non è ancora pronto all’uso. È un’operazione da eseguire con attenzione, perché il prerequisito non è solo tecnico: devi sapere se il sistema ha già chiavi o flussi che dipendono dal TPM, per esempio BitLocker, certificati protetti dal modulo o configurazioni di sicurezza che fanno affidamento su di esso.

Prima di inizializzare, controlla lo stato:

Get-Tpm

Se il TPM non è pronto ma è presente, puoi tentare l’inizializzazione solo dopo aver verificato che non esistano vincoli operativi o di policy. In molti casi il sistema richiede riavvio o interazione fisica/firmware. Il risultato atteso è che lo stato passi verso TpmReady = True.

Se il cmdlet fallisce, non forzare subito il reset. Controlla prima eventi di sistema, configurazione UEFI e l’eventuale presenza di un TPM già ownership-locked da un precedente asset o da una reinstallazione incompleta.

Reset del TPM: quando serve davvero e cosa rompe

Clear-Tpm è il cmdlet più delicato di questa famiglia. Va usato solo quando hai chiarito il blast radius: il reset elimina le chiavi memorizzate nel TPM e può rendere inaccessibili dati o funzionalità legate a quelle chiavi. In pratica, è un’operazione da fare solo con backup, piano di recupero e consapevolezza del sistema coinvolto.

Prima di eseguirlo, verifica almeno questi punti:

  1. BitLocker è sospeso o gestito con recovery key disponibile.
  2. Non ci sono certificati o credenziali che dipendono dal TPM per la loro protezione locale.
  3. Il device può essere riavviato e riconfigurato senza impatto non accettabile.

La sintassi base è semplice, ma l’uso non lo è:

Clear-Tpm

Su alcuni sistemi, il comando richiede conferme o una sequenza di autorizzazione aggiuntiva. Non automatizzarlo alla cieca su flotte di endpoint senza prima aver validato il comportamento su un singolo dispositivo di test e senza un processo di rollback documentato.

Una sequenza operativa sensata per troubleshooting e remediation

Se un endpoint mostra problemi con BitLocker, credential guard, attestation o provisioning, una sequenza coerente è più utile di un tentativo casuale di reset. L’obiettivo è ridurre i cambiamenti non necessari e arrivare a una causa verificabile.

  1. Leggi lo stato con Get-Tpm e salva l’output in un file per confronto successivo.
  2. Controlla quali cmdlet TPM sono presenti con Get-Command *Tpm*.
  3. Verifica il provisioning automatico con Get-TPMAutoProvisioning.
  4. Se il TPM è presente ma non pronto, prova a capire se il problema è firmware, policy o stato sporco.
  5. Solo se il sistema è compatibile e non ci sono dipendenze attive, valuta Initialize-Tpm.
  6. Usa Clear-Tpm solo come ultima risorsa e solo con piano di recupero.

Questa progressione riduce il rischio di trasformare un problema di configurazione in una perdita di chiavi o in un incidente operativo più ampio.

Automazione: come integrare i controlli in script e task di remediation

In ambienti gestiti, spesso conviene incorporare questi controlli in script di compliance o remediation. L’idea non è “riparare tutto”, ma classificare rapidamente gli endpoint in base allo stato del TPM e intervenire solo dove serve.

$tpm = Get-Tpm
if (-not $tpm.TpmPresent) { Write-Output "TPM assente o non esposto dal firmware"
} elseif (-not $tpm.TpmReady) { Write-Output "TPM presente ma non pronto"
} else { Write-Output "TPM pronto"
}

Uno script del genere è utile per inventario, reporting o gating di una pipeline di configurazione. In un contesto più maturo, puoi aggiungere logica per verificare l’auto-provisioning e per segnalare i dispositivi che richiedono intervento manuale.

Attenzione però a non confondere osservazione e azione: uno script che legge lo stato è sicuro; uno script che inizializza o resetta il TPM no. La differenza è il rischio operativo e il livello di autorizzazione richiesto.

Integrazione con BitLocker e altri componenti di sicurezza

Il TPM diventa davvero interessante quando è parte di una catena di fiducia più ampia. Il caso più comune è BitLocker, ma lo stesso vale per scenari con protezione di chiavi, attestazione e funzioni di sicurezza di Windows che dipendono dall’hardware trust anchor.

Se BitLocker risulta in recovery dopo un cambio di stato TPM, il primo sospetto non è il disco: è il mismatch tra chiavi attese e stato effettivo del modulo. Per questo i cmdlet TPM vanno letti insieme agli strumenti di protezione disco e ai log di sistema. In pratica, il TPM non si diagnostica in isolamento.

Un approccio utile è correlare l’output di Get-Tpm con il comportamento del sistema dopo un reboot. Se il TPM passa da non pronto a pronto, ma il servizio o la policy di sicurezza continua a fallire, il problema potrebbe essere altrove: policy locale, configurazione di dominio, o dipendenze di attivazione non ancora allineate.

Errori comuni e lettura corretta dei sintomi

Un errore frequente è trattare ogni stato anomalo come se richiedesse un reset. Non è così. Ecco come leggere i sintomi in modo più utile:

  • TPM assente: controlla firmware, BIOS/UEFI, presenza di vTPM sulle VM.
  • TPM presente ma non pronto: controlla provisioning, policy e riavvio richiesto.
  • Cmdlet non trovato: verifica modulo disponibile con Get-Command *Tpm* e versione del sistema.
  • Access denied: controlla elevazione della sessione e restrizioni locali.
  • Dopo reset il sistema non si avvia come prima: attiva il piano di recovery, soprattutto se erano presenti chiavi protette dal TPM.

Questa classificazione è più utile di una guida generica perché ti dice subito dove guardare: firmware, Windows, policy o dipendenze applicative.

Checklist minima da tenere in tasca

Se devi ricordare solo una sequenza, tieni questa:

  1. Get-Command *Tpm* per sapere cosa è disponibile davvero.
  2. Get-Tpm per leggere presenza e readiness.
  3. Get-TPMAutoProvisioning per capire chi sta gestendo il provisioning.
  4. Initialize-Tpm solo se il TPM è presente e il sistema è pronto a usarlo.
  5. Clear-Tpm solo come ultima risorsa, con recovery e rollback pianificati.

In pratica, i cmdlet PowerShell per il TPM sono pochi ma coprono bene osservazione, configurazione e remediation. Il valore non sta nel singolo comando, ma nel fatto di usarli in sequenza, con controllo dello stato e attenzione agli effetti collaterali. Se li tratti come strumenti di amministrazione a basso rischio, sbagli approccio: il TPM è un punto di fiducia e va gestito come tale.