AD CS TPM-attested user certificate enrollment fails with 0x80280084 / 0x80280095

Question

AD CS TPM-attested user certificate enrollment fails with 0x80280084 / 0x80280095

Filip Gronostaj 20

User certificate enrollment with mandatory TPM key attestation fails on multiple Windows clients, both manually and through autoenrollment.

Template configuration: RSA 2048, SHA-256, Microsoft Platform Crypto Provider, non-exportable keys, required attestation using endorsement certificates.

Affected clients include Windows builds 26300.9711 and 26300.9818. Installing KB5127936 did not resolve the issue.

We captured TPM traces from two affected clients:

A SHA-256 policy session is created.
PolicySecret succeeds.
PolicyOR with two 32-byte digests succeeds.
A subsequent PolicyOR on the same session contains two 48-byte digests and fails.
Nuvoton TPM returns 0x80280084; AMD TPM returns 0x80280095.

The failure occurs in the GetEKAuthSession / PerformAIKActivation path. Ordinary TPM-backed RSA key generation and signing succeed.

The same CA and template successfully issue attested certificates to some other clients. Failed requests remain pending with “Challenge Pending” and “Trust Endorsement Certificate” flags.

Please confirm whether this matches a known Windows regression and whether Feature Management override 3436801679, reported publicly as a workaround, is applicable and supported on these builds. Please provide the official KIR package or permanent fix.

0 comments

1 answer

Your answer

Answer 1

Hola Filip,

You've done some excellent troubleshooting here, particularly capturing the TPM command sequence on two different manufacturers' implementations. The PolicyOR behavior you've identified is especially interesting, and I think it gives us a much better direction than treating this as a general AD CS enrollment problem.

The detail that stands out is the transition from 32-byte digests to 48-byte digests within the same SHA-256 policy session. SHA-256 produces 32-byte digests, while SHA-384 produces 48-byte digests. Since the policy session's hash algorithm determines the expected policy digest size, passing 48-byte digests into a SHA-256 session would be inconsistent with TPM 2.0 policy processing.

Microsoft's documented TPM error definitions also align with your findings. Error 0x80280084 corresponds to TPM_20_E_VALUE, indicating an invalid value for the context, while 0x80280095 corresponds to TPM_20_E_SIZE, indicating an incorrectly sized structure.

The fact that both Nuvoton and AMD TPMs encounter problems in the same authorization sequence makes a Windows-side issue plausible, although it doesn't conclusively establish a regression. Your observation that ordinary TPM-backed RSA key generation and signing continue to work is also significant. It suggests that the failure is specific to the attestation process rather than the TPM's general cryptographic functionality.

I looked into KB5127936 as well. Microsoft's October 28, 2026, release notes specifically mention a fix for TPM attestation identity key (AIK) certificate enrollment becoming unresponsive when a non-Microsoft CNG key storage provider reports a malformed algorithm name or fails during provider enumeration.

That's certainly relevant, but the documented fix doesn't specifically mention incorrect policy digest sizes, PolicyOR failures, or the GetEKAuthSession/PerformAIKActivation sequence. Since you've already tested the update without success, I wouldn't assume that it addresses your particular issue.

Regarding Feature Management override 3436801679, I haven't found official Microsoft documentation confirming that this override addresses the failure you're experiencing or that it's supported on builds 26300.9711 and 26300.9818. I also couldn't identify an official KIR package specifically associated with this issue.

Microsoft provides a supported Known Issue Rollback mechanism, but the applicable rollback policies can differ across Windows versions. Their guidance explains that when a relevant KIR hasn't been published, Microsoft Support can work with the Windows product team to identify the appropriate rollback and provide the necessary policy package.

Given the specificity of your TPM traces, I think this warrants escalation to Microsoft Support rather than experimenting with undocumented Feature Management overrides. I'd open a support case referencing the two affected builds, the failed KB5127936 test, and the different TPM error responses, and request confirmation from the Windows security and TPM engineering team about whether the SHA-256/SHA-384 policy digest mismatch is a known regression.

One additional detail I'd be interested in is whether the clients that successfully enroll are running the same Windows builds as the affected machines. If you have a working client on an earlier build, comparing its GetEKAuthSession/PerformAIKActivation sequence with that of the failing clients could provide particularly useful evidence. Specifically, I'd want to know whether the working client uses 32-byte digests throughout the PolicyOR sequence or follows a different authorization path.

I wouldn't recommend clearing the TPM, changing the certificate template's attestation requirements, or deploying an undocumented override at this point. Your existing evidence is specific enough that those changes could introduce additional problems without addressing the underlying cause.

Thanks,

James

Filip Gronostaj 20 Reputation points

2026-10-29T21:55:05.3566667+00:00

Hi James,

I have an update from a controlled test on the same affected computer, against the same issuing CA.

Environment: Windows build 26300.9711, PCPKsp.dll 10.0.26100.9949, AMD TPM.

Results:

User certificate enrollment with attestation disabled succeeds.

User certificate enrollment with mandatory EK-certificate-based attestation fails with 0x80280095.

Computer certificate enrollment with mandatory EK-certificate-based attestation succeeds.

I verified that the computer certificate contains issuance policy 1.3.6.1.4.1.311.21.31 — EK Certificate Verified. Both templates use RSA 2048, SHA-256, Microsoft Platform Crypto Provider, non-exportable keys and the same attestation requirements.

We also captured the successful computer enrollment. It contains two successful TPM2_ActivateCredential operations, so this was not simply an enrollment that skipped AIK activation through caching.

Both successful and failing AIK activation paths execute through the same CryptSvc process. However, their EK authorization sequences differ:

Computer enrollment reaches ActivateCredential successfully, without the problematic PolicyOR containing 48-byte digests.

User enrollment submits the previously identified 48-byte PolicyOR digests within a SHA-256 policy session and fails before reaching ActivateCredential.

Retrying user enrollment after successful computer enrollment still produces 0x80280095.

This further narrows the issue to the user-enrollment attestation path, although it does not conclusively identify the underlying regression.

Can these findings be forwarded to the Windows TPM product team, or linked to an existing known issue? We can provide the paired traces through a secure upload channel.

Thanks, Filip