| Previous | Next |
| NTE_ENCRYPTION_FAILURE | NTE_USER_CANCELLED |
NTE_DEVICE_NOT_FOUND
NTE_DEVICE_NOT_FOUND should be read at the missing cryptographic device boundary. The provider configuration refers to hardware or a security device that is not present, enumerated, supported, or reachable on this system. Identify the selected provider and backing device, then verify that the smart card, TPM, HSM, token, reader, or remote key service is enumerated in the failing session.
Locate the first failing stage
The provider is backed by a finite or separately managed device such as a smart card, TPM, HSM, virtual token, reader, or remote key service. Provider installation, device discovery, readiness, object capacity, authentication state, and key policy are separate layers and should be logged separately.
Useful observations, not generic logs
| Record | Why it matters for this code |
|---|---|
| provider-visible device identifier, reader or endpoint, firmware and driver version, and connection state | Shows whether the status follows hardware, middleware, or stored objects. |
| token object inventory, capacity or quota, and whether the target key is persistent | Preserves device capacity and readiness evidence before cleanup. |
| the same operation with another known-good device through the same middleware | Separates provider installation from physical availability. |
Code-specific checks:
- Verify reader, TPM, HSM client, USB device, virtual smart card, and remote-provider installation.
- Compare device identifiers and provider configuration with the host where the key was provisioned.
- Check architecture and session visibility before reinstalling the application.
Build a timeline before changing state
- A known-good control result produced under the same identity, architecture, and provider selection.
Reproduction without destructive cleanup
Keep the application, account, and provider configuration fixed while changing one device variable: reconnect the same token, use another reader or endpoint, then use a known-good token. This reveals whether the status follows hardware, transport, middleware, or stored objects.
- Use one known-good control that changes only the suspected part of the missing cryptographic device path.
- Record where behavior first diverges in the missing cryptographic device path instead of judging only by the final application message.
How this differs from similar failures
NTE_DEVICE_NOT_READY indicates a discovered device that cannot yet operate; this result indicates that no suitable device was located. Deleting token objects before exporting labels, IDs, certificates, and policy information can destroy the only evidence of capacity leaks or failed enrollment cleanup.
For missing cryptographic device, 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.
Regression check
The original provider must discover a ready device and complete the intended operation with stable object inventory; temporary success after selecting unrelated hardware is only isolation evidence.
Technical references
These sources define the HRESULT and the relevant missing cryptographic device interface, protocol, or data format.
Looking for a different code? Search another status or error code.