| Previous | Next |
| TPM_E_NO_NV_PERMISSION | TPM_E_KEY_NOTSUPPORTED |
TPM_E_REQUIRES_SIGN
Technical interpretation
TPM_E_REQUIRES_SIGN (0x80280039) belongs to TPM 1.2 nonvolatile-storage policy. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the NV or delegation operation requires a signed command path, but the submitted TPM 1.2 request lacks the required signature proof.
The first producer to identify for this HRESULT is the TPM 1.2 NV permission and lifecycle checks. TPM 1.2 NV indices combine permissions, authorization mode, locality masks and lock semantics. Two indices of the same size can behave differently because those attributes were fixed when each index was defined.
Inputs and state to capture
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | the NV or delegation operation requires a signed command path, but the submitted TPM 1.2 request lacks the required signature proof |
| Which layer owns the result? | The TPM 1.2 NV permission and lifecycle checks. |
| What must be correlated? | command ordinal, target index or delegation object, signature fields, signing key identity, nonce, and the policy attribute requiring a signed update |
| What is the controlled comparison? | build a test request with the specified signing key and verify the signed digest fields before submission |
Record the original command or API call before this result retry logic mutates its nonces, handles, buffers or state. Also retain the full HRESULT as 0x80280039; signed decimal logging can hide the result TPM/TBS facility and make searches less precise.
Validate without broad changes
- Establish the result baseline with the same device, Windows build, account and TPM generation.
- Perform one narrow experiment: build a test request with the specified signing key and verify the signed digest fields before submission.
- Compare raw this result inputs and the first response, not only the final application dialog.
- Stop after the first changed the checkpoint; a later error means this boundary was passed even if the whole workflow still fails.
Neighboring response codes
| Result | Different diagnostic question |
|---|---|
TPM_E_KEY_NOTSUPPORTED | Wrong operation to load an NV key — a separate checkpoint when compared with this result. |
TPM_E_NO_NV_PERMISSION | The permission to manipulate the NV storage is not available — a separate checkpoint when compared with it. |
TPM_E_AUTH_CONFLICT | NV_LoadKey blob requires both owner and blob authorization — a separate checkpoint when compared with it. |
The decisive distinction for this HRESULT is that TPM_E_NO_NV_PERMISSION is a general permission failure, while this code says which authorization form is mandatory. The short platform wording — “The operation requires a signed command.” — does not supply that differential diagnosis by itself.
Fix and verify
The corrective direction is to construct the signed command exactly as defined for the object policy; an owner password is not a substitute when signature authorization is required. Do not undefine a production NV index until its public attributes and authorization policy have been recorded. NV policy is established at definition time, and destructive recreation can remove counters, certificates or provisioning state.
A verified it repair reproduces the original request with the same intended security policy and passes this checkpoint. Replacing it with a broader wrapper status, silently falling back to software keys, or suppressing verification is not proof of success.
Technical references
- TCG: TPM 1.2 Main Specification — source for the checkpoint.
- TCG: TPM 1.2 Part 2 — NV structures and permissions — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — NV commands — source for the checkpoint.
- Microsoft: Win32_Tpm class — source for the checkpoint.
Looking for a different code? Search another status or error code.