A Microsoft app for iOS and Android devices that enables authentication with two-factor verification, phone sign-in, and code generation
Microsoft Software KSP — authoritative semantics of NCRYPT_KEY_ACCESS_POLICY_PROPERTY
I am looking for an authoritative clarification of the behavior and support scope of NCRYPT_KEY_ACCESS_POLICY_PROPERTY when used with the Microsoft Software Key Storage Provider through CNG/NCrypt.
The property is present in the Windows SDK headers, but the public documentation does not appear sufficient to determine the exact provider behavior.
Could a Microsoft CNG/KSP specialist clarify the following points?
Is NCRYPT_KEY_ACCESS_POLICY_PROPERTY officially supported by the Microsoft Software Key Storage Provider?
If supported, is the property:
readable with NCryptGetProperty,
writable with `NCryptSetProperty`,
or both?
At which stage is it valid to set or query it:
before key finalization,
after key finalization,
on reopening a persisted key,
or only in specific situations?
Does the Microsoft Software KSP actively enforce the value, or is it only metadata exposed by the provider?
With **ECDSA P-256 persisted keys as the primary target**, does the behavior depend on:
the algorithm,
persisted vs. ephemeral key state,
machine vs. user key scope,
Windows version/build? If the answer for ECDSA P-256 also applies to other algorithms, please indicate the scope of that applicability.
If the property is not supported by the Microsoft Software KSP, is that an intentional and stable provider contract, or simply undocumented behavior that applications should not rely on?
Is there an authoritative Microsoft source defining this behavior? If so, please distinguish between:
a **published normative reference or specification**,
an **official product-team statement** describing the supported contract,
and an **informational explanation without a support guarantee**.
What is the exact value representation for `NCRYPT_KEY_ACCESS_POLICY_PROPERTY`:
data type,
buffer layout,
required size,
permitted values,
and any required flags for `NCryptGetProperty` or `NCryptSetProperty`?
What return values or error codes should applications expect when:
the property is unsupported,
the requested operation is unsupported,
the supplied value is invalid,
or the property is accessed at an invalid key lifecycle stage?
If the property is set successfully:
does the value persist after closing and reopening the persisted key,
are specific privileges or access rights required,
and are there any cleanup, reset, or deletion obligations associated with the property?
For context, I am using the definitions from the Windows SDK 10.0.26100.0. I am specifically interested in the Microsoft Software Key Storage Provider, with ECDSA P-256 as the primary target, not third-party KSPs.
I am not looking for experimentally observed behavior alone; I need to distinguish documented/supported provider semantics from implementation behavior that may change between Windows versions.
If the answer is version-dependent, please indicate the applicable Windows versions/builds.
Thank you.