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

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