What an Authenticode signature actually proves
A signed binary tells you who published it, not whether it is safe. The distinction matters more than most policies assume.
Signature checks are the most common first-pass control applied to unknown executables, and the most commonly misread. A valid Authenticode signature answers exactly one question: who claims responsibility for this file? It does not answer whether the file is safe, whether it is the version you expect, or whether the publisher is one you have any reason to trust.
What the chain establishes
Authenticode embeds a PKCS#7 structure in the PE file’s certificate table,
referenced from the IMAGE_DIRECTORY_ENTRY_SECURITY entry in the optional
header. Verification computes a hash across the file, deliberately skipping
the checksum field, the certificate table pointer, and the signature block
itself, and compares it against the signed digest.
If those match and the chain terminates in a trusted root, you know two things: the file has not been modified since signing, and a certificate authority was willing to issue a certificate to whoever holds that private key.
That second clause is doing far more work than most people credit.
What it does not establish
Identity validation varies enormously by certificate class. An OV certificate requires the CA to confirm the organisation exists. It does not require any assessment of what the organisation ships. Compromised signing keys are a recurring supply-chain pattern precisely because a valid signature is treated as a terminal verdict rather than one input.
Timestamping complicates it further. A countersignature from a trusted timestamp authority means the signature remains valid after the certificate expires, which is correct behaviour, and also means a binary signed with a key that was later revoked may still validate depending on how revocation is checked.
The practical position
Treat the signature as an attribution signal with a confidence level, not as a boolean. A binary signed by a well-known publisher with a current chain and a valid timestamp is strong attribution. A binary signed by an organisation you have never heard of, issued last month, is attribution with a question attached. An unsigned binary is not necessarily worse than either: it is simply attribution you have to derive from the file itself.
The failure mode to avoid is a policy that reads signed as approved. Those are different questions, and only one of them is answered by the certificate.
More of this
New posts on what a file tells you before you run it: headers, signatures, manifests, overlays, the fields most inventory never reads. Only when there is something worth the write-up.
We intend to offer a tool that does this across every file on an endpoint. You get one message when you can use it.