Always timestamp Authenticode signatures. Microsoft's documentation says that without a timestamp, a signature becomes invalid when the signing certificate expires and Windows treats the binary as unsigned. With a timestamp, the signature stays verifiable after the certificate expires, because it proves the file was signed while the certificate was valid.
What a timestamp actually adds
A code signing certificate has a validity window. Your installer was signed on a day inside that window, but users run it months or years later. Without extra evidence, a verifier only knows what time it is now, and now the certificate may be expired.
A timestamp is a countersignature from a timestamp authority. It signs your original signature together with the time. Microsoft describes it as a PKCS #7 countersignature that lets a verifier know when the signature was affixed and trust it if the certificate was valid then.
The documentation also says the countersignature method lets signatures verify after the certificate has expired or been revoked. Treat the revoked case with care: a timestamp helps old releases keep verifying, but it does not replace a response plan if a key is stolen.
What to set when you sign
Microsoft's current guidance in that page is short:
- Use SHA-256 for the file digest.
- Use an RFC 3161 timestamp server with a SHA-256 timestamp digest, rather than the legacy timestamp protocol.
- Do not use SHA-1 as the only algorithm for new releases.
- Dual-signing with SHA-1 is only a consideration for very old Windows versions, and Windows 7 SP1 or later is fine with SHA-256 only.
With SignTool the shape is /fd SHA256 for the file digest, /tr with a timestamp server URL, and /td SHA256 for the timestamp digest. Pick a timestamp authority your certificate provider documents, and keep a fallback server in your build script, since a signing step that fails because one server is down will tempt someone to skip the timestamp.
Common ways timestamps go missing
- The timestamp URL is wrong or blocked from the build runner, and the tool is run in a mode that warns and carries on.
- A separate step re-signs a file and drops the timestamp.
- Only the installer is timestamped, while the executables inside it are not.
- Someone signs by hand for a hotfix and forgets the flags.
The fix is to make the build fail when the timestamp is absent, and to check the output rather than trusting the command.
How to check a release
Open the file properties on Windows, go to Digital Signatures, select the signature and open Details. A countersignature section shows the timestamp. SignTool can also verify a file with its verify command. Run the check on a clean machine, after the certificate you used has aged, if you can, because a pipeline that always runs the day it signs will not reveal the problem.
Add a calendar reminder for your certificate expiry too. Timestamps protect old releases, but new builds still need a valid certificate on the day you sign them.
What a signature does not tell you
A valid, timestamped signature says who signed the file and that it has not changed since. It does not say the build was clean. The SolarWinds case shows a signed update can still carry a compromise. See also what to do about a SmartScreen warning on an unsigned installer.
For the dependencies inside your app, Safeguard offers SBOM and dependency scanning, and a free scan at https://gold.safeguard.sh/scan.
Quick check
Does a timestamp make an expired certificate safe to use for new releases?
No. The timestamp keeps an existing signature valid after expiry. New releases must be signed with a certificate that is valid on the day of signing.
Is SHA-1 still acceptable as a second signature?
Microsoft says not to use SHA-1 as the sole algorithm for new releases. Dual-signing is only a consideration for Windows versions that cannot validate SHA-256.
Sources
Last reviewed: 19 October 2026.
