| 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, this result means that the protected data needs to be re-protected. A generic success branch is insufficient for it because continuation and output validity remain code-specific.
Where the status is encountered
- DPAPI-protected application settings; log the exact method and object state instead of interpreting the constant outside that contract.
- Profile or credential migration; log the exact method and object state instead of interpreting the constant outside that contract.
- Security maintenance that rotates protection policy; log the exact method and object state instead of interpreting the constant outside that contract.
Because it 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
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 it changes from useful state information into a potentially mishandled result.
A retry decision for it requires evidence about already-completed work and outstanding work.
Evidence and telemetry
- preserve blob version and hash.
- preserve user or machine protection scope.
- preserve optional entropy identifier.
- preserve current protection policy.
- 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 it 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 it 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 it only when a documented input or state has changed. A blind retry of it 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 it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: CryptProtectData — official Microsoft material used to interpret it.
- Microsoft: HRESULT structure
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.