On a Windows computer with the TrustedPlatformModule PowerShell module available, Get-Tpm returns information about the local Trusted Platform Module. It is an inspection command, not an instruction to clear, initialize or unlock the chip. Use it to collect precise evidence before making security changes, and keep TPM information separate from questions about a particular drive’s encryption.
A support request saying ‘TPM not working’ is too broad to act on safely. Presence, readiness and lockout state describe different things. None of those fields alone establishes that a disk is encrypted, that recovery keys are available or that a business application is healthy.
Run a deliberately limited local inspection
Use Windows PowerShell on the affected Windows computer, following your organisation’s privilege requirements. This is not a Linux or WSL command. On a managed device, obtain permission before collecting and sharing security configuration information. The following example selects a small set of diagnostic fields rather than dumping every property returned by the cmdlet:
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated, TpmOwned, LockedOut, RestartPending | Format-ListMicrosoft’s documented example includes these status fields. Your machine’s values may differ. Do not paste a vendor example into a ticket as though it were actual output from your device. Record the computer identifier through your approved support system and note when you performed the inspection.
If PowerShell cannot find the cmdlet, stop and check that you are using a supported Windows environment with the appropriate module. A command-discovery error is not evidence that the hardware has no TPM. If access is denied, follow your support team’s authorized elevation procedure rather than weakening policy or trying unrelated reset commands.
Separate chip presence from readiness
TpmPresent reports whether a TPM is present on the current computer. TpmReady is a separate readiness field; Microsoft’s reference describes it in terms of compliance with Windows Server 2012 standards. Do not turn that description into a blanket certification for every newer Windows release, security baseline or application requirement.
The documented output also includes enabled, activated and owned states. Treat these as individual observations to pass to the administrator, not a checklist where every False value should trigger a reset. A device can require product-specific or organisational investigation even when several fields are True.
For a hypothetical support handover, ‘TpmPresent is True and TpmReady is False on this computer’ is more useful than ‘the TPM is missing’. Preserve the actual returned values, any command error and relevant recent maintenance details. Do not invent a cause such as failed firmware solely from one Boolean result.
Handle lockout and restart information cautiously
LockedOut reports a lockout state. Microsoft’s reference also describes LockoutCount, LockoutMax and LockoutHealTime. Those are diagnostic properties, not permission to make repeated authentication attempts or a guarantee that every application will recover after a specific wait. Ask the device administrator to interpret them against the device’s policy and current incident.
The example command includes RestartPending because it appears in Microsoft’s documented output. A pending restart observation is not approval to interrupt a production session. Arrange any restart separately with the user and support team, preserving work and relevant recovery procedures first.
Avoid posting the full object publicly. The cmdlet’s documented properties include OwnerAuth, an owner authorization value. Selecting only the fields needed for the ticket reduces unnecessary disclosure, but the resulting status information still belongs in approved support channels.
Do not use TPM status as a BitLocker verdict
A TPM status report describes the chip, not a volume-by-volume encryption assessment. If the original problem concerns BitLocker recovery prompts, retain that specific symptom and investigate it separately. Clearing the TPM is not an appropriate experiment just to see whether a status field changes: it is a different operation with security and recovery implications.
No rollback is required for the inspection shown here because it does not request a configuration change. If another guide recommends Clear-Tpm, Initialize-Tpm or an unblock operation, treat that as a separate procedure requiring a reviewed recovery plan and explicit authorization. Their existence as related commands in documentation is not a recommendation to run them.
Checklist for a useful support handover
- Confirm that the command ran on the intended Windows computer.
- Capture the selected status values and the observation time.
- Keep command failures distinct from returned False values.
- Describe the original user symptom separately from your interpretation.
- Record whether any change was actually made; for this inspection, none is requested.
- Use approved support channels and omit secrets or recovery material.
If the investigation also needs a separate review of local privileged membership, see listing local administrators using the group SID. That inventory does not establish the TPM’s state or whether your current process is elevated.
Source: Microsoft Learn’s Get-Tpm reference. The command is a documented Windows example; it has not been runtime-tested against Windows hardware here.
This tutorial is for educational purposes. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
