| Previous | Next |
| WEP_E_HARDWARE_NOT_COMPLIANT | WEP_E_PROTECTION_SUSPENDED |
WEP_E_LOCK_NOT_CONFIGURED
WEP_E_LOCK_NOT_CONFIGURED — 0x88010004
A productive investigation starts at device-lock prerequisites for encryption policy. The status means that device encryption cannot satisfy EAS lockout behavior because the required device-lock/recovery configuration is absent.
Start with the failing layer
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. Volume encryption being active does not by itself prove that policy-driven device lock and recovery are configured. Compare lifecycle, identity, caller, and first API.
Preserve before retrying
| Record | How it narrows the cause |
|---|---|
| Provider lock capability, recovery material escrow, and device-lock configuration | Pins evidence to one attempt. |
| EAS failed-attempt and RequireEncryption policies | Separates contract failure from environment. |
| Boot/recovery environment state and provider management policy | Creates a stable before/after control. |
| WEPHOSTSVC/provider events identifying the missing prerequisite | Tests whether the first boundary moves. |
Collect the smallest evidence set that identifies the attempt and object. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead.
Three useful comparisons
- Configure lock/recovery on a disposable encrypted device; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Exercise a safe simulated lockout using vendor guidance; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Verify recovery-key access before enabling enforcement; keep every other input fixed and record the first event that differs from the failing run.
A retry becomes evidence only when one controlled variable changes. In the device-lock prerequisites, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
Decision points
Use the outcomes to narrow the layer rather than to accumulate unrelated fixes for device-lock prerequisites for encryption policy:
| 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. |
A defensible fix
Repair the failed contract rather than the surrounding system: Configure the provider’s lockout and recovery prerequisites through an approved management workflow before applying the EAS policy. Preserve the pre-change configuration or trace.
Close the incident only when a controlled lock test enters the expected protected state and authorized recovery restores access without data loss. 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.