What does HRESULT 0x00091012 (CRYPT_I_NEW_PROTECTION_REQUIRED) mean?

 
Previous Next
SEC_I_ASYNC_CALL_PENDING NS_S_CALLPENDING

CRYPT_I_NEW_PROTECTION_REQUIRED

Protected data should be re-protected

CRYPT_I_NEW_PROTECTION_REQUIRED is HRESULT 593938 (0x00091012) from winerror.h. AllStat describes it as “The protected data needs to be re-protected.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.

In the Windows data-protection lifecycle, CRYPT_I_NEW_PROTECTION_REQUIRED means that the protected data needs to be re-protected. A generic success branch is insufficient for CRYPT_I_NEW_PROTECTION_REQUIRED because continuation and output validity remain code-specific.

Diagnostic sequence

  • Capture the raw value 0x00091012 before wrappers, signed-decimal formatting, exceptions, or generic success handling replace CRYPT_I_NEW_PROTECTION_REQUIRED.
  • Identify the operation that returned CRYPT_I_NEW_PROTECTION_REQUIRED, including interface or callback, component build, thread, process, and the state-machine phase.
  • For CRYPT_I_NEW_PROTECTION_REQUIRED, prove the decisive condition: the plaintext is recovered safely and can be protected again under the current policy without losing entropy, scope, or access semantics.
  • Inspect every output, count, status array, buffer, callback, task state, media timestamp, transaction vote, or security token that remains part of the CRYPT_I_NEW_PROTECTION_REQUIRED contract.
  • Compare state immediately before and after CRYPT_I_NEW_PROTECTION_REQUIRED; success severity does not guarantee that optional work or the caller’s intended high-level action completed.
  • Reproduce CRYPT_I_NEW_PROTECTION_REQUIRED with the smallest input that retains the same condition, then alter only the recorded cause before repeating the operation.

Where the status is encountered

  • CRYPT_I_NEW_PROTECTION_REQUIRED can be returned during DPAPI-protected application settings; log the exact method and object state instead of interpreting the constant outside that contract.
  • CRYPT_I_NEW_PROTECTION_REQUIRED can be returned during profile or credential migration; log the exact method and object state instead of interpreting the constant outside that contract.
  • CRYPT_I_NEW_PROTECTION_REQUIRED can be returned during security maintenance that rotates protection policy; log the exact method and object state instead of interpreting the constant outside that contract.

Because CRYPT_I_NEW_PROTECTION_REQUIRED is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.

What must be true before accepting it

For CRYPT_I_NEW_PROTECTION_REQUIRED, verify that the plaintext is recovered safely and can be protected again under the current policy without losing entropy, scope, or access semantics. This boundary is where CRYPT_I_NEW_PROTECTION_REQUIRED changes from useful state information into a potentially mishandled result.

A retry decision for CRYPT_I_NEW_PROTECTION_REQUIRED requires evidence about already-completed work and outstanding work.

Evidence and telemetry

  • For CRYPT_I_NEW_PROTECTION_REQUIRED, preserve blob version and hash.
  • For CRYPT_I_NEW_PROTECTION_REQUIRED, preserve user or machine protection scope.
  • For CRYPT_I_NEW_PROTECTION_REQUIRED, preserve optional entropy identifier.
  • For CRYPT_I_NEW_PROTECTION_REQUIRED, preserve current protection policy.
  • For CRYPT_I_NEW_PROTECTION_REQUIRED, preserve new blob verification and replacement result.

Also record crypt_i_new_protection_required_operation, crypt_i_new_protection_required_state_before, crypt_i_new_protection_required_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Collect CRYPT_I_NEW_PROTECTION_REQUIRED evidence with least disclosure: retain structure, sizes, IDs, and versions rather than secrets.

Difference from nearby results

A decryption failure means the data is unavailable; this informational status says the data was read but its protection should be upgraded.

Branching precisely on CRYPT_I_NEW_PROTECTION_REQUIRED prevents cancellation, pending work, and partial output from sharing one path.

Correct handling and recovery

After successful unprotection, call the current protection API with the intended user or machine scope and entropy, atomically replace the old blob, and verify a fresh decrypt before deleting the previous copy.

Retry CRYPT_I_NEW_PROTECTION_REQUIRED only when a documented input or state has changed. A blind retry of CRYPT_I_NEW_PROTECTION_REQUIRED can duplicate effects or conceal a terminal condition, so require a documented trigger.

Practical scenario

A profile service reads an older DPAPI blob and receives this status. It re-encrypts the value using the current policy, verifies the new blob, and replaces the old file atomically.

A regression test should reproduce CRYPT_I_NEW_PROTECTION_REQUIRED, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.

Developer and administrator guidance

Code should branch on CRYPT_I_NEW_PROTECTION_REQUIRED before a generic SUCCEEDED(hr) path whenever outputs, continuation, cancellation, or recovery differ. Telemetry should retain CRYPT_I_NEW_PROTECTION_REQUIRED, 0x00091012, the producing method, and a correlation ID.

For CRYPT_I_NEW_PROTECTION_REQUIRED, document ownership of retry, cancellation, cleanup, and user messaging. Support engineers handling CRYPT_I_NEW_PROTECTION_REQUIRED should preserve first-failure context before restarting the owning component.

References

Looking for a different code? Search another status or error code.