Code-Signing Certificate Hygiene Checklist
A code-signing certificate is a key that makes your software trusted. If that key leaks, an attacker can sign malware your users will install without a warning — so the controls around where the key lives, how it signs, what the signature proves and what you do the day it is compromised matter more than the certificate itself. Work through a scored checklist across key protection, the signing process, supply-chain integrity and incident readiness — grounded in the CA/Browser Forum hardware-key requirement, RFC 3161 timestamping and signed build provenance — and get a weighted 0-100 score with the gaps ranked so you fix the ones that most shrink your blast radius first. Nothing is uploaded, no keys are entered, and it runs entirely in your browser.
Core code-signing controls are absent. A compromised key could sign anything and signatures may silently expire. Start with the key-protection area.
Prioritised gaps
Highest-weight, lowest-scoring controls first — spend remediation effort here.
- Key protection · unanswered
Move code-signing keys into an HSM or FIPS 140-2 L2+ hardware token; this is the CA/Browser Forum baseline for OV/EV code-signing keys since June 2023.
Reference: CA/B Forum code-signing BRs
- Key protection · unanswered
Generate keys on-device as non-exportable; verify no plaintext key or PFX/PKCS#12 with the private key exists on any build host or share.
- Key protection · unanswered
Require MFA or an M-of-N quorum to invoke the key; a single shared PIN in a secrets vault is a single point of failure.
- Key protection · unanswered
Replace file-based pipeline secrets with a managed signing service that keeps the key in hardware and exposes only a sign operation.
- Signing process · unanswered
Add an RFC 3161 timestamp to every signing command; without it, all signatures become invalid the day the cert expires.
Reference: RFC 3161
- Signing process · unanswered
Issue per-run, short-lived credentials (OIDC-federated) to the signer instead of a long-lived standing secret.
- Signing process · unanswered
Separate signing identities (or sub-certs) by product or release channel to contain the blast radius of a key compromise.
- Signing process · unanswered
Gate production signing behind a release approval so an attacker who lands a commit cannot auto-sign a shipped artifact.
+ 8 more gaps in the full export.
Key protection · weight 3
Where the signing private key lives and how hard it is to steal. Since June 2023 the CA/Browser Forum has required OV and EV code-signing keys to be generated and stored in hardware (HSM or a FIPS 140-2 Level 2+ token) — a signing key sitting in a CI secret or a developer laptop is the single biggest exposure.
Signing private keys are generated and held in an HSM or hardware token (never exportable to disk).
Keys are marked non-exportable, so a compromised host cannot copy the key material out.
Access to the signing key requires a second factor / quorum, not a single stored password.
If signing runs in the cloud/CI, the key is in a managed KMS/HSM service (e.g. cloud KMS, Azure Trusted Signing) — not a raw file in a pipeline secret.
Signing process · weight 3
How signatures are produced day to day. Timestamping keeps signatures valid after the certificate expires; least-privilege signing identities and ephemeral CI access limit what a stolen credential can sign.
Every signature is timestamped (RFC 3161) so it remains valid after the signing certificate expires.
CI signing uses short-lived / ephemeral access to the key, scoped to a single pipeline run.
Distinct signing identities exist per product/release channel, so one compromised identity does not sign everything.
Production release signing requires an explicit human approval / change gate, not an automatic trigger on every commit.
Supply-chain integrity · weight 2
Whether a signature actually proves what was built. Reproducible builds and signed provenance/attestation (SLSA, in-toto, Sigstore) connect the signature to a known source and build process rather than to an opaque binary.
Releases ship signed provenance / build attestation (e.g. SLSA provenance, in-toto, Sigstore) linking the artifact to its source and build.
Builds are reproducible (or hash-pinned) so the same source reliably yields the same signed artifact.
An SBOM is generated and associated with each signed release.
Downstream/consumers verify signatures and provenance before trusting an artifact (not sign-and-forget).
Incident readiness · weight 2
What happens the day a signing key is suspected compromised. A revocation plan plus timestamping means you can revoke with an effective date and preserve the validity of pre-compromise signatures; a rehearsed runbook turns a crisis into a procedure.
A documented revocation plan exists, and you understand how revocation-with-timestamp preserves signatures made before the compromise date.
A key-compromise runbook exists and has been walked through (not just written).
You maintain an inventory of every signing certificate, where its key lives, and what it has signed.
Every signing operation is logged to a tamper-evident audit trail.
Educational — general guidance, not legal/compliance advice. Heuristic self-assessment: the area weights are a transparent judgement framework, not a measurement or certification. This tool performs no scan, makes no network calls, and runs entirely in your browser — nothing is uploaded and no keys or secrets should be entered. Named standards (CA/Browser Forum code-signing baseline requirements, RFC 3161 timestamping, SLSA, in-toto, Sigstore, CycloneDX, SPDX) are referenced for orientation only.
What this checklist is
- A free, 100% in-browser scored checklist for code-signing certificate hygiene: answer across key protection, the signing process, supply-chain integrity and incident readiness, and get a weighted 0-100 score with prioritised gaps.
- Key protection carries the most weight because the CA/Browser Forum has required OV and EV code-signing keys to live in hardware (an HSM or FIPS 140-2 Level 2+ token) since June 2023 — a signing key in a CI secret or on a laptop is the biggest single exposure.
- Timestamping (RFC 3161) is the quiet essential: without it every signature becomes invalid the day the certificate expires, and revocation-with-timestamp is what preserves signatures made before a compromise.
- Supply-chain integrity ties the signature to a known build: signed provenance/attestation (SLSA, in-toto, Sigstore), reproducible or hash-pinned builds, an SBOM per release, and consumers who actually verify.
- Nothing is uploaded, no scan runs, no keys or secrets are entered. Export to Markdown or CSV. Educational self-assessment — general guidance, not legal or compliance advice.
Why this matters
A stolen code-signing key is one of the most dangerous things an attacker can get, because a valid signature turns malware into trusted software — it bypasses SmartScreen and Gatekeeper warnings and sails past allow-lists that trust your publisher name. That is why the CA/Browser Forum moved, in June 2023, to require OV and EV code-signing private keys to be generated and held in hardware (an HSM or a FIPS 140-2 Level 2+ token): a key that never leaves hardware cannot simply be copied out of a compromised build host or CI secret.
Hardware is necessary but not sufficient. Timestamping (RFC 3161) keeps signatures valid after the certificate expires and lets revocation preserve pre-compromise signatures; ephemeral, least-privilege signing identities limit what a stolen credential can sign; and signed provenance (SLSA, in-toto, Sigstore) plus reproducible builds and an SBOM connect the signature to a known source and build, so a signature actually means "built by us from this source," not merely "someone signed this binary." Finally, an incident-ready program knows its signing inventory, logs every signing operation, and has rehearsed the key-compromise runbook before it is needed. These are the same supply-chain integrity themes behind the rest of the PlayCISO certificate labs — this checklist focuses them on the keys that sign your releases.
Frequently asked questions
Where should a code-signing private key be stored?
In hardware — an HSM or a FIPS 140-2 Level 2 (or higher) hardware token — generated on-device and marked non-exportable. Since June 2023 the CA/Browser Forum baseline requirements have mandated hardware key storage for OV and EV code-signing certificates. A signing key sitting in a CI pipeline secret, a PFX/PKCS#12 file on a build server, or a developer laptop is the single largest code-signing exposure: anyone who copies it can sign malware that your users will trust. Cloud signing should use a managed KMS/HSM service that exposes only a sign operation, never the raw key.
Why does timestamping matter so much for code signing?
A code signature normally becomes invalid the moment the signing certificate expires. An RFC 3161 timestamp from a trusted timestamping authority records WHEN the signature was made, so the signature stays valid long after the certificate expires — as long as it was signed while the certificate was valid. Timestamping is also what makes revocation survivable: if a key is later compromised, the CA can revoke with an effective (compromise) date, and signatures that were timestamped before that date remain trusted while anything signed after it is rejected. Without timestamps, revocation invalidates everything and expiry breaks already-shipped software.
What is signed provenance and why is a signature alone not enough?
A signature proves that whoever held the key signed this exact artifact. It does not prove the artifact was built from your real source by your real pipeline — a stolen key can sign anything. Signed provenance or build attestation (SLSA provenance, in-toto, Sigstore) binds the signed artifact to a specific source commit and build environment, so a consumer can verify not just "this was signed by X" but "this was built from this source by this pipeline." Combined with reproducible builds and an SBOM, provenance is how you connect a signature to a trustworthy supply chain rather than to an opaque binary. And provenance only helps if downstream consumers actually verify it before trusting the artifact.
Is this a compliance audit or legal advice?
No. It is an educational self-assessment and a transparent heuristic for structured self-reflection — not a security audit, certification, penetration test or legal/compliance advice, and it does not scan or touch any system. The area weights reflect the generally accepted lesson that key protection and the signing process matter most, and are shown openly so you can adjust them to your environment. It runs entirely in your browser and you should not enter any real keys or secrets. Named standards (CA/Browser Forum, RFC 3161, SLSA, in-toto, Sigstore, CycloneDX, SPDX) are referenced for orientation only.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.Educational — general guidance, not legal/compliance advice.