Supported TPM 2.0 NV Counter and Extend provisioning on Windows 10/11

Under the stated constraints, Microsoft does not document a supported general-purpose Windows application route for creating those application-owned TPM 2.0 NV Counter and NV Extend indices on a normally provisioned Windows 10/11 device.

1. TBS command admission

TBS provides a raw command transport through Tbsi_Context_Create and Tbsip_Submit_Command; successful submission only means TBS accepted the request—the TPM can still return an error in the response buffer.^1^

• On Windows 8 and later, standard users and administrators can create TBS contexts. Therefore, elevation by itself is not the general TBS access boundary.^2^
• TBS separately applies command blocking. For TPM 2.0 it uses an allowlist, and beginning with Windows 10 version 1809 that allowlist is fixed in the TPM driver and cannot be expanded through the documented registry mechanism.^3^
• The Windows TPM 2.0 hardware profile includes StartAuthSession, FlushContext, NV_DefineSpace, NV_ReadPublic, NV_Read, and NV_Increment. NV_Extend is optional, so its presence cannot be assumed across Windows-compatible TPMs.^4^

That hardware profile is not a per-version TBS admission guarantee. The published material supplied here does not provide a Windows 10/11 build-by-build and caller-class matrix proving that every listed command is admitted by TBS. In particular, TPM implementation support for optional NV_Extend and TBS admission are separate checks.

A desktop process can request a TPM 2.0 context as follows:^5^

TBS_CONTEXT_PARAMS2 p{};
p.version = TPM_VERSION_20;
p.includeTpm20 = 1;

TBS_HCONTEXT context{};
TBS_RESULT result =
    Tbsi_Context_Create(
        reinterpret_cast<PCTBS_CONTEXT_PARAMS>(&p),
        &context);

if (result != TBS_SUCCESS) {
    // Handle TBS_E_TPM_NOT_FOUND or another TBS error.
}

Actual deployment qualification must submit the intended command set on every supported Windows build and distinguish:

1. a TBS rejection;
2. a TPM authorization failure;
3. an unsupported TPM command;
4. an NV allocation or attribute error.

2. Initial hierarchy authorization

TPM2_NV_DefineSpace still requires authorization for the selected hierarchy or a policy satisfying that hierarchy. Being Administrator, SYSTEM, or an installer does not supply that TPM authorization.

Tbsi_Get_OwnerAuth is only a retrieval API: it returns authorization if it is available in the local registry, and otherwise returns TBS_E_OWNERAUTH_NOT_FOUND.^6^ It is not an API that grants hierarchy authority or provisions an application-specific delegation.

This is decisive for normally provisioned systems:

• Windows automatically initializes and takes ownership of the TPM.^7^
• Starting with Windows 10 version 1607, Windows does not retain the TPM owner password during normal provisioning; it sets a random high-entropy value and discards it.^8^
• The documented policy can retain additional authorization, but that requires changing OSManagedAuthLevel, which the question explicitly excludes.^9^

No documented API in these sources asks Windows to perform an application’s arbitrary NV_DefineSpace, supplies the missing storage-hierarchy authorization, or installs an applicable hierarchy policy on the application’s behalf. Consequently, first-time creation cannot be made generally supported merely by elevating the installer.

3. Authorization after creation

If an index had already been created by an authorized provisioning authority, its later authorization would be separate from hierarchy authorization:

• The hierarchy authorization controls initial definition and hierarchy-level lifecycle operations.
• The index’s authValue and/or authPolicy, together with its attributes, control later NV_Read, NV_Increment, or NV_Extend operations.
• NV_ReadPublic can recover public metadata and the NV Name; it does not recover a secret authorization value.

The application would therefore need to generate an independent high-entropy per-index secret, set the required index attributes at definition time, and persist that secret under access control appropriate to the service or user. The available Microsoft documentation does not define a Windows-managed secret-provisioning or reopening API specifically for arbitrary application NV indices. Raw TBS leaves TPM command construction, sessions, secret storage, handle discovery, Name validation, and update migration to the application.

This post-creation design does not solve the missing authorization for the initial NV_DefineSpace.

4. Installer, allocation, and lifecycle

There is no supported “elevated installer” exception to the hierarchy boundary. Elevation may be needed for ordinary machine-wide installation tasks, but it neither changes the TPM authorization value nor bypasses the TPM 2.0 command allowlist.

NV allocation is also device-dependent. TPM errors distinguish insufficient NV space, an already-defined index, invalid size, locked state, and authorization failure.^10^ The supplied documentation does not assign a third-party application NV-handle range, reserve NV capacity, or specify a Windows lifecycle contract for arbitrary application indices. An installer therefore cannot assume that a chosen handle or sufficient NV storage is available.

5. Binding and TPM Clear/replacement detection

A supported way to obtain an application key tied to the current TPM is the Microsoft Platform Crypto Provider. It creates TPM-protected keys whose private material is non-removable and unique to that TPM.^11^

An application protocol can have that key sign a record containing both NV Names and retain or remotely register the signed record. After TPM Clear or replacement, the original private key is unavailable; clearing destroys TPM-created keys and protected data.^12^

However:

• Microsoft does not document a direct Windows API that cryptographically attaches arbitrary NV Names to a CNG key.
• A signed binding record only prevents silent recreation if the prior key identity or signed record is anchored somewhere that cannot also be replaced—such as a remote service, administrator-controlled store, or independently protected state.
• Purely local state that is recreated along with the TPM key cannot, by itself, distinguish legitimate reprovisioning from silent recreation.

Therefore, TPM-backed key binding can support clear/replacement detection at the application-protocol level, but it does not supply the hierarchy authorization needed to create the two NV indices. Under all the listed restrictions, the complete provisioning route is not publicly documented as supported.

References

1. Tbsip_Submit_Command function (tbs.h)
2. Using TBS
3. Command Blocking
4. TPM V2.0 Command and Signal Profile
5. Tbsi_Context_Create function (tbs.h)
6. Tbsi_Get_OwnerAuth function (tbs.h)
7. Trusted Platform Module Technology Overview
8. Change the TPM owner password
9. TPM Group Policy settings
10. COM Error Codes (TPM, PLA, FVE)
11. How Windows uses the Trusted Platform Module
12. Troubleshoot the TPM