| Previous | Next |
| WEP_E_FIXED_DATA_NOT_SUPPORTED | WEP_E_LOCK_NOT_CONFIGURED |
WEP_E_HARDWARE_NOT_COMPLIANT
Treat this HRESULT as a marker, not as a request for a generic restart or reinstall. It is returned when the computer does not meet hardware requirements declared by the installed non-Microsoft encryption provider.
What the status narrows down
Windows Encryption Provider integration has separate gates for provider licensing, hardware readiness, volume support, provisioning, active protection, device-lock configuration, and EAS compliance. WEPHOSTSVC events should therefore be read alongside the third-party provider’s own inventory and logs, not as a replacement for them.
Do not collapse this result into a nearby status. Enabling policy cannot create missing hardware capability, and a software retry cannot fix an unsupported platform. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Capture | Why it matters |
|---|---|
| Provider capability result, TPM/security hardware state, firmware mode, Secure Boot, and storage controller | Creates a stable before/after control. |
| BIOS/UEFI and provider/driver versions | Tests whether the first boundary moves. |
| Hardware identifiers and vendor support matrix | Pins evidence to one attempt. |
| EAS compliance result before attempting encryption | Separates contract failure from environment. |
The goal is reproducibility, not a full data dump. Prefer object IDs, configuration exports, event correlation, and redacted paths over credentials, cryptographic material, or user content.
A controlled diagnostic sequence
- Run the provider readiness check on a known-supported reference device; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Update firmware/provider in a lab while keeping policy constant; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Separate TPM/provisioning readiness from storage/driver compatibility; keep every other input fixed and record the first event that differs from the failing run.
If the failure disappears after a broad restart, treat that as a clue about lifetime or state, not as proof of repair. Reproduce the original hardware capability for third-party device encryption operation with targeted instrumentation before closing the incident.
How to read the outcome
Read the comparison results in this order for hardware capability for third-party device encryption:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | The failure moved to another boundary; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Correction and proof
The corrective action should be narrow: Bring firmware/hardware/provider versions into the vendor-supported matrix or use a supported encryption solution/device. Preserve the pre-change configuration or trace.
Close the incident only when provider readiness passes before provisioning and remains valid across firmware update and resume/reboot tests. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The diagnostic boundaries above are grounded in the following Microsoft specifications and API documentation:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: Exchange ActiveSync Policy Engine overview.
- Microsoft: Windows Encryption Provider Host Service.
- Microsoft: EasClientSecurityPolicy.RequireEncryption.
Looking for a different code? Search another status or error code.