Resolving Digest Mismatch on Signed Files

A Digest Mismatch on a certificate in the Unified Audit means the file's current contents do not match the contents that were hashed when the file was signed. The signature itself is intact, but the file has changed since signing, so the embedded hash no longer describes the file on disk. Verify this on the endpoint with Get-AuthenticodeSignature before treating the certificate rule as the problem.

Cause of the Digest Mismatch

An Authenticode signature embeds a hash of the file as it existed at the time of signing. When the file is later modified, the hash in the signature no longer matches the file, and the signature fails validation. The certificate is still present and may chain to a trusted root, but it no longer vouches for the current contents.

The common reasons a file is modified after signing are as follows:

An installer or updater patched the binary instead of replacing it
A packaging or build step (repacking, resource editing, compression) ran after the signing step
The file was corrupted during download or copying
The file was tampered with

Verifying the Cause

To verify why the mismatch occurred, run the following in PowerShell on the machine where the file lives, replacing the path with the file from the audit entry:

Get-AuthenticodeSignature .\file.exe

For further details, including the signer and the chain, pipe the result to Format-List using the following in PowerShell:

Get-AuthenticodeSignature .\file.exe | Format-List *

The returned Status field is what you should look for, which will help confirm the Digest Mismatch. Please compare it against the table shown below.

Interpreting the Status

Status	Meaning	Matches the audit?
HashMismatch	The file was modified after it was signed. The embedded hash does not match the current contents.	Yes - This confirms the Digest Mismatch.
Valid	The embedded hash matches the file contents and the certificate chains to a trusted root.	No - The file on this machine is intact; check that you tested the same file the audit reported.
NotSigned	The file has no Authenticode signature.	No - A different condition; certificate rules cannot apply.
UnknownError	The signature is present, but the chain could not be validated (due to an untrusted root or a revoked or expired certificate).	No - A chain problem, not a content change.

Resolution

When the Status is HashMismatch, the certificate rule works as designed: it will not match a file whose contents differ from the signed contents. At this point, you must fix the file, not the rule. To do this:

Confirm the file on disk is the one the audit reported (it should have the same path and hash).
Obtain a clean copy from the vendor and compare its Status. A clean copy that returns Valid confirms the local file was altered after signing.
If the vendor's own installer or updater modifies the file in place, raise it with the vendor; the modified file cannot be trusted by certificate.
If the file cannot be replaced and the application is trusted, approve it by hash or by a policy that does not depend on the certificate.
If the modification is unexpected and no vendor process explains it, treat the file as potentially tampered and investigate before allowing it.