No, a valid signature is not an allowlist
One question, one answer, and the reason the answer keeps surprising people.
The question comes up in roughly this form: we only allow signed executables, so are we covered?
No. A signature answers who takes responsibility for a file. It does not answer whether the file should run in your environment.
Those come apart in three ordinary, non-exotic ways.
Signed and unwanted. Every remote access tool, tunnelling client, crypto miner and AI runtime that has caused an incident this decade was properly signed by the company that made it. Signing is table stakes for commercial software distribution, not a statement of alignment with your policy.
Signed by someone you have never assessed. A certificate proves a certificate authority validated an organisation exists. It does not mean you have any relationship with that organisation or any opinion about what they ship. “Signed” collapses a thousand different publishers into one boolean.
Signed, then irrelevant. A countersigned timestamp keeps a signature valid after the certificate expires, correct behaviour, and it means the presence of a valid signature tells you nothing about whether the signing key is still trustworthy today.
The useful reframing is that a signature is an input to identity, not a substitute for it. It tells you who. Whether that publisher’s software belongs on your endpoints is a separate question, and it is the one the policy was actually trying to ask.
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.