| Previous | Next |
| NTE_UI_REQUIRED | NTE_DEVICE_NOT_READY |
NTE_HMAC_NOT_SUPPORTED
NTE_HMAC_NOT_SUPPORTED should be read at the HMAC capability boundary. The active provider or key type cannot perform the requested keyed-hash construction even though other hash or signing operations may be available. For HMAC capability, the useful diagnostic question is which concrete object and operation caused Windows to select this exact HRESULT—not whether a key, certificate, account, file, or device merely “works.”
What the code establishes
In the path, capability is determined by the selected provider, key type, algorithm implementation, operation mode, and key usage policy. The presence of an algorithm name in Windows does not guarantee that every CSP, KSP, hardware token, or stored key can perform every operation associated with it in a HMAC capability investigation.
Facts to preserve before changing state
| Record | Why it matters for this code |
|---|---|
| provider and key type, algorithm identifier, operation mode, padding, and requested property | Separates platform capability from one provider or key restriction. |
| enumerated provider capabilities and hardware or firmware feature level | Connects the failure to an exact algorithm and operation mode. |
| key usage restrictions and whether the same primitive works with a software key | Avoids silently changing protocol requirements. |
Code-specific checks:
- Confirm that the application requested HMAC rather than a plain hash or asymmetric signature.
- Enumerate the provider algorithms and verify the required hash is exposed for HMAC use.
- Do not substitute an unkeyed hash; use a provider and key object that explicitly support the required MAC.
What to include in an escalation package
Correlate the last successful operation with provider installation or update, key creation or renewal, profile or session changes, device insertion and removal, policy refresh, and the first failing call. The order matters: a provider error that starts immediately after a key migration suggests a different boundary from one that appears only after a service account changes in a HMAC capability investigation.
- a minimal reproducer that names the API, provider, key or container, flags, and nonsecret input sizes.
- In the path, provider, device, profile, and operating-system event records covering the last success and first failure.
- In the path, a known-good control result produced under the same identity, architecture, and provider selection.
Isolation procedure
Test the primitive with a documented software provider and a temporary key of the same algorithm and size in a HMAC capability investigation. Next test the production provider with a minimal supported operation. The two controls separate missing platform functionality from restrictions of one key or device.
- Preserve the original input, identity, provider or protocol selection, and first return Value.
- Use one known-good control that changes only the suspected part of the HMAC capability path.
- reverse the comparison with known-good input on the failing layer where that can be done safely.
- Record where behavior first diverges in the HMAC capability path instead of judging only by the final application message.
Common wrong turns
This is narrower than NTE_NOT_SUPPORTED and should lead directly to provider/algorithm capability checks., changing to another algorithm solely to remove the error can violate protocol, certificate-template, or interoperability requirements. First establish which required capability is missing and where in a HMAC capability investigation.
For HMAC capability, also retain the original numeric value; neighboring constants can encode materially different remediation paths even when an application presents all of them as an authentication, certificate, or security failure.
Proving the intended path works
The intended provider and key must perform the required primitive with the required parameters; a fallback algorithm or different key does not validate the original design. Keep a regression case that uses nonsecret identifiers and expected outcomes, including one negative control that must continue to fail.
Technical references
These sources define the HRESULT and the relevant HMAC capability interface, protocol, or data format.
- Microsoft Open Specifications: HRESULT values.
- Microsoft: CNG primitive cryptography functions.
- NIST FIPS 198-1: The Keyed-Hash Message Authentication Code.
Looking for a different code? Search another status or error code.