For most endpoints, an unsigned binary is a nuisance: a SmartScreen prompt, a slightly higher chance of an antivirus false positive. For an endpoint running application control — Windows Defender Application Control or AppLocker — it is a hard stop. The binary does not run, and no amount of goodwill changes that.
This tends to be exactly the client you least want to fail in front of: regulated, mature, or holding a cyber-insurance policy with an application-control condition attached.
Publisher rules versus hash rules
Application control gives you a few ways to permit software. Two matter here.
A **hash rule** permits one exact file. It is precise, it works on unsigned binaries, and it is a maintenance trap: the hash changes on every rebuild, so every agent update means reissuing the rule across the estate. In practice teams fall behind, and then either the agent stops updating or someone widens a path rule to compensate.
A **publisher rule** permits software signed by a given publisher, and can be scoped across a version range. The agent updates, the signature stays valid, the rule keeps working. This is the difference between configuring application control once and administering it forever.
Publisher rules are only available for signed binaries. That is the entire practical argument for code-signing an agent, and it is a better argument than the SmartScreen one.
Know which rule collection you are in
AppLocker sorts things into distinct rule collections, and a rule in one does not cover another. This trips people up constantly during backup agent deployments.
**Executable** — .exe and .com
**Windows Installer** — .msi, .msp and .mst
**Script** — .ps1, .bat, .cmd, .vbs, .js
**DLL** — .dll and .ocx
**Packaged apps** — appx and msix
A backup agent commonly touches three of these at once: a script that installs it, executables and DLLs that run afterwards, and possibly an MSI. Allowlisting the executables while forgetting the Script collection is the most common reason an install fails on an application-control endpoint after the binaries were correctly permitted.
A related gotcha under WDAC: if script enforcement is on and the installer script is unsigned, PowerShell drops into Constrained Language Mode. The script does not fail loudly — it fails on the specific operations it needs, which for most installers means the ones that create services or expand archives. The symptom looks like a broken installer rather than a policy decision.
What "signed" should mean when a vendor claims it
Ask three questions, because the word covers a wide range.
**Which files?** The binaries that run, the installer, or both? Many products sign the payload and not the installer, or the reverse. Both matter, for different reasons, and a vendor should be able to tell you which without checking.
**Whose certificate?** If a vendor embeds a third-party engine, the signature may belong to that engine’s publisher rather than to the vendor selling you the product. That is entirely legitimate — but you cannot build a publisher rule without knowing the actual subject name on the certificate, so the vendor needs to give it to you. A vendor implying the certificate is theirs when it is not will cost you a failed rollout: you build the rule against the wrong publisher and it matches nothing.
**Is it timestamped?** An RFC 3161 countersignature proves the signing happened while the certificate was valid, so signatures stay verifiable after the certificate expires. Without it, every signature dies on the certificate’s expiry date and every publisher rule with it. This one is worth checking directly rather than taking on trust.
Verify it yourself, in two commands
You do not need to take a vendor’s word for any of this. On a machine with the agent installed:
Get-AuthenticodeSignature on the service binary, formatted as a list, tells you the status and the signing certificate. Status Valid plus a signer subject is what you want. A Valid result on a certificate whose validity window has passed is normal and correct when the signature is timestamped — that is what timestamping is for, and it is not an anomaly.
To check everything at once, pipe Get-ChildItem over the install directory into Get-AuthenticodeSignature and group the results by Status. One group, Valid, is the answer you are looking for. Anything else is a conversation with the vendor before you deploy.
The subject name you get back is what goes into your publisher rule. Ask for it in writing up front and the rule is a five-minute job rather than a support ticket during a rollout.