TPM_E_READ_ONLY (0X8028003E): NV area is read-only

You're running a TPM provisioning tool (like tpm.msc, a BitLocker setup script, or a custom app calling NV_Write) and it spits back 0X8028003E — TPM_E_READ_ONLY. The exact message is “The NV area is read-only and cannot be written to.” This usually happens on Windows 10 or 11 after a firmware update, a BitLocker policy change, or when someone (or something) has already written to a TPM Non-Volatile (NV) index and locked it. The NV index is designed to be written once per boot cycle or permanently. What's actually happening here is the TPM’s hardware protection kicked in: once an NV index is defined with the TPMA_NV_WRITELOCK attribute set, or the index reaches its write limit, the TPM refuses all further writes until the next system reset or until the index is undefined entirely.

The root cause is straightforward: TPM 2.0 devices enforce strict write-once semantics for NV indices to prevent tampering with boot measurements, BitLocker keys, or platform certificates. If your tool tries to write to an index that’s already been locked — either by firmware (e.g., during Secure Boot) or by a previous BitLocker initialization — you get 0X8028003E. There’s no way to “unlock” it without clearing the TPM or undefining the specific index via the TPM owner authorization. The reason step 3 works is that clearing the TPM resets all NV indices to their default “undefined” state, wiping the write-lock.

Diagnose first: is the index locked?

Before nuking everything, check which index is the problem. Open PowerShell as Admin and run:

Get-TpmEndorsementKeyInfo -ErrorAction SilentlyContinue
# Or for detailed NV status:
get-tpm -ErrorAction SilentlyContinue | Format-List *

Look for IsEnabled: True and IsOwned: True. If the TPM is owned and enabled, the NV index is probably a BitLocker or platform one. You can drill into specific indices with Get-TpmEndorsementKeyInfo, but the output is sparse. A better diagnostic tool is tpm.msc — open it, expand “TPM Management on Local Computer” → “TPM Provisioning” and look for error codes. But tpm.msc won’t show NV index details directly.

For serious diagnosis, use the TpmTool from the Windows SDK or a third-party utility like TpmTool. Run:

TpmTool.exe nvlist

This lists all defined NV indices and their attributes. If you see TPMA_NV_WRITELOCK or TPMA_NV_WRITE_STCLEAR set on the index you’re trying to write, you’re stuck — short of a TPM clear.

The fix: clear TPM (and what that means)

Clearing the TPM is the nuclear option. It resets all NV indices to undefined, erases BitLocker keys (so you need your recovery key), and removes platform certificates. Do this only if you’re prepared to re-enroll BitLocker, re-join the domain, and re-configure any TPM-dependent apps. Here’s the exact sequence:

1. Back up your BitLocker recovery key. Search for “BitLocker” in Control Panel, click “Back up your recovery key” and save it to a safe location (not on the drive). If you don’t have one, your machine will be unbootable without it.
2. Open PowerShell as Admin and run:

   Clear-Tpm -Force

   This triggers a TPM clear and requires a reboot. The -Force flag bypasses the “are you sure?” prompt.
3. Reboot immediately. During POST, the firmware will reinitialize the TPM. On most systems, the TPM is automatically enabled and taken ownership of by Windows on the next boot. If not, you’ll need to Initialize TPM from tpm.msc or run:

   Initialize-Tpm -AllowClear -AllowPhysicalPresence

4. Re-enable BitLocker if needed. Use:

   Manage-bde -on C:

   You’ll be prompted for your recovery key from step 1 (yes, the one you saved to a USB or printed).

Note: Some firmware (Lenovo, Dell) require you to press F12 during boot to physically acknowledge the TPM clear. If your system hangs at a blank screen after reboot, that’s why — watch for prompts.

Alternative: undefine a single NV index (advanced)

If you know the exact NV index that’s locked (e.g., 0x01C00000 for BitLocker SRK), you can undefine it without clearing the whole TPM. This requires the TPM owner authorization value (usually empty on Windows 10+). Use TpmTool or the TSS.CAPI API:

TpmTool.exe nvundefine -index 0x01C00000 -auth owner

If it fails with “Access denied” or “Authorization failure,” the owner auth is not empty — you’re back to clearing the TPM. Most consumer Windows systems leave owner auth empty, so this works 90% of the time.

If it still fails

If after clearing and re-provisioning you still get 0X8028003E, the problem is almost certainly firmware-level:

• Check for a firmware TPM lock. Some BIOS/UEFI settings have “TPM Write Protect” or “TPM NV Lock” that can be set permanently. Look in Security → TPM settings for such an option and disable it.
• Verify TPM firmware version. Run tpm.msc and check the “Specification version.” If it’s 2.0 but the firmware is old (e.g., Intel PTT firmware from 2020), update the BIOS to get TPM firmware fixes. Dell and Lenovo have specific TPM firmware updates in their driver catalogs.
• Test with a different operating system. Boot a Linux live USB and use tpm2-tools to query NV indices. If those also show write-lock, the TPM is physically stuck — you need a motherboard replacement. I’ve seen this on early Ryzen systems that shipped with buggy TPM firmware. In that case, disable TPM in BIOS and use a software TPM (e.g., BitLocker without TPM, via Group Policy).
• Corporate devices: If your machine is domain-joined, the IT policy may have written to an NV index during provisioning (e.g., TPM_PPI or TPM_CC). You cannot clear the TPM without re-provisioning through your company’s MDM. Call your IT admin.

Bottom line: 0X8028003E is a hardware-enforced lock. Don’t waste time trying to hack around it — clearing the TPM is the reliable fix. Keep your BitLocker recovery key handy, and you’ll be back in business in 10 minutes.