Code Signing Buyer's Guide: Choosing a Platform

A code signing key is a permission to tell every customer's operating system that software is yours, and attackers who steal one, or get their malware signed through your pipeline, inherit that trust. Since June 2023 the CA/Browser Forum has required publicly trusted code signing keys to live in hardware, which pushed most organisations from files on build servers to tokens, HSMs and cloud signing services, often bought in a hurry and team by team. This vendor-neutral guide helps security, release engineering and PKI teams choose a code signing platform: the categories on the market, requirements, evaluation criteria, pricing models, RFP questions, red flags and a proof of concept. For signing practice itself, timestamping and verification, see the Code Signing Security Guide.

Key takeaways

Key custody is the first decision. Choose between keys you hold in your own HSM, keys held by a signing service, and keyless signing with short-lived certificates; each moves the risk to a different place.
Control who can sign, not only where the key is. Malware can be signed without stealing a key, by abusing legitimate access to a signing pipeline or account; a platform needs per-project authorisation, approvals for release keys and an audit trail of every hash signed.
Pipelines should sign with their own identity. CI/CD integration through federated, short-lived credentials beats a long-lived signing API key stored as a pipeline secret.
Timestamping and revocation are part of the product. Ask how signatures stay valid after certificates expire and how narrowly you can revoke after a compromise.
Coverage decides cost. Count the formats you sign (Windows, macOS, Java, Linux packages, containers, firmware, scripts) before comparing; a platform that misses one leaves a key on a build server.

Define requirements

Write these down before talking to vendors. They decide which category of platform you need and stop the evaluation turning into a comparison of certificate prices.

Inventory of signing today: list every signing key and certificate, where its private key is (file, USB token, HSM, cloud key service), who and what can use it, which products and formats it signs, and its expiry. Include GPG keys for Linux packages and repositories, Apple and Windows certificates, Java keystores, container image keys and firmware keys. Expect to find keys nobody owns.
Trust model per format: separate publicly trusted signing (Windows Authenticode for distributed software, where a publicly trusted certificate is needed) from private trust (internal applications, application control policies, container images verified by your own admission control, firmware verified by your own devices). Private trust does not need a public CA and is often cheaper and faster to rotate.
Hardware rules: the CA/Browser Forum Code Signing Baseline Requirements state that "Effective June 1, 2023, for Code Signing Certificates, CAs SHALL ensure that the Subscriber's Private Key is generated," stored and used in a suitable Hardware Crypto Module (section 6.2.7.4.2). A Signing Service, defined as "An organization that generates the Key Pair and securely manages the Private Key associated with a Code Signing Certificate" on behalf of a subscriber, must use a FIPS 140-2 Level 2 or equivalent module. Certificates issued on or after 1 March 2026 may be valid for no more than 460 days, so plan for annual renewal at least.
Signing volume and latency: how many signatures per day, from how many pipelines and teams, and whether signing sits in the critical path of release. Digest (hash) signing, where only the hash leaves the build system, keeps large artefacts local and fast.
Separation of duties: NIST's code signing white paper (2018) defines the developer, the signer that manages the keys, and the verifier, and recommends that organisations "Separate critical roles for running the CSS and assign them to different people", where the CSS is the code signing system. Decide who approves release signing, who administers keys and who can change policy.
Long-lived device keys: firmware and boot keys may need to be trusted for a decade. NIST SP 800-208 approves the stateful hash-based schemes LMS and XMSS, gives "the authentication of firmware updates for constrained devices" as the example use, and requires key and signature generation in hardware modules that do not allow export. If you sign firmware, include post-quantum readiness in requirements. See the Post-Quantum Readiness Guide.

Size changes the answer. A small software publisher with one Windows product and one pipeline is usually well served by a managed signing service or a single HSM-backed certificate integrated into CI, plus keyless signing for container images. A large enterprise with dozens of product teams, several formats, firmware and acquisitions needs a central signing platform with policy per project, approvals, a common audit trail and keys in HSMs it controls or can attest.

Capability areas and evaluation criteria

Code signing products fall into a few categories that are often combined. Compare like with like.

Category	How keys are held	Suits	Watch for
Certificate on a subscriber token or HSM	You hold the private key in a hardware token or your own HSM; a CA issues the certificate	Small number of releases; full control of keys	Tokens plugged into build servers, shared PINs, no audit of what was signed
Managed signing service	Provider generates and holds keys in its HSMs and signs submitted digests; may also issue the certificate (for example Microsoft Artifact Signing)	Windows publicly trusted signing without running HSMs	How your pipeline authenticates to it; format coverage beyond Windows
Enterprise signing orchestration platform	Keys in your HSMs or cloud key management; the platform enforces policy, approvals and audit across formats	Many teams, formats and keys; central governance	Client tooling per format; dependence on the platform for every release
Keyless, identity-based signing	Ephemeral key per signature, short-lived certificate bound to an OIDC identity, entry in a transparency log (Sigstore)	Container images, open source packages, internal artefacts with your own verification	Not publicly trusted for Windows or macOS; verification must pin identity and issuer
Cloud key management with your own tooling	Asymmetric keys in a cloud key service, signing scripted in pipelines	Private trust, internal artefacts, teams with strong engineering	Approval, policy and audit left to you; key policies drift

Microsoft's Artifact Signing (formerly Trusted Signing) illustrates the managed model: Microsoft describes it as "a Microsoft fully managed, end-to-end signing solution", with certificates that "are renewed daily and are valid for only 72 hours", keys that cannot be imported or exported, and a statement that "time stamp countersigning is critical for a signature to be valid beyond the life of the signing certificate". Short-lived certificates allow revocation that Microsoft says can be "as acute as a single day". Sigstore illustrates the keyless model: its certificate authority (Fulcio) "issues a short-lived certificate bound to the provided identity and public key", and the signature is recorded in the Rekor transparency log.

Weight the criteria to your requirements. An illustrative split for a multi-team publisher: 25% key custody and protection, 20% policy and approvals, 20% CI/CD integration, 15% format coverage, 10% audit and detection, 10% commercial terms.

Criterion	What good looks like	Weak signs
Key custody	Non-exportable keys in validated hardware (FIPS 140-2 or 140-3 at the level you require), key generation evidence or attestation available to the CA and to you, separate keys per product or environment	Keys exportable "for backup", software keystores, one key for every product
Format coverage	Windows Authenticode, macOS, Java, Linux packages and repository metadata, container images and attestations, scripts, firmware; native tool integrations rather than wrappers	Windows only, with other formats "on the roadmap"
CI/CD integration	Pipelines authenticate with federated, short-lived workload identity; signing bound to a specific repository, branch and workflow; digest signing	A long-lived signing API key or token PIN stored as a pipeline secret
Policy and approvals	Per-project rules on who and what may sign with which key; approval or M-of-N for release keys; pre-signing checks such as provenance, malware scan or SBOM present	Anyone with access to the key signs anything
Timestamping	RFC 3161 timestamping by default, with a choice of timestamp authorities and monitoring of TSA availability	Timestamping optional or off by default
Revocation and recovery	Documented process to revoke, re-key and re-sign; ability to scope revocation by date; inventory of what each key signed	No record of which binaries a compromised key signed
Audit and detection	Immutable log of every signing event with requester, workload identity, artefact hash, key and approval; export to your log platform; alerts on unusual volume or requesters	Logs only key use, not what was signed
Verification support	Helps consumers verify: application control policies, container admission policies, provenance checks, published public keys or identities	Signs but leaves verification to chance
Crypto agility	Algorithm and key size changes without re-architecture; LMS and XMSS for firmware; a stated plan for the NIST post-quantum signature standards	Hard-coded RSA key sizes and no roadmap

For provenance, SLSA Build Level 3 requires the build platform to prevent "secret material used to sign the provenance from being accessible to the user-defined build steps"; apply the same principle to code signing keys. See the SLSA and Build Provenance Guide.

Pricing models

Code signing pricing mixes certificate fees, platform subscriptions and hardware. Compare total cost for three years at today's signing volume and at double.

Model	What is counted	Watch for
Per certificate per year	Publicly trusted code signing certificates, with or without a token	Validity now capped at 460 days; extra cost for each product team's certificate
Per signing volume	Signatures or signing requests per month	Pressure to sign less often or batch artefacts; overage charges
Subscription tier	Accounts, certificate profiles or feature tiers in a managed service	Limits on profiles or signatures per tier
Per key, project or user	Keys under management, projects, signers or approvers in an orchestration platform	Per-user pricing that discourages separation of duties
Hardware and support	HSMs, partitions or cloud HSM capacity, plus support	High availability needs two or more units; key ceremony and audit effort

Where identity fits

Every signing key is a privileged machine identity, and so is every pipeline allowed to use it. Treat both that way: named owners, least privilege, short-lived credentials and monitoring. The GitHub code signing certificate theft began with a machine account's token, not with an HSM failure. Require that the platform authenticates pipelines through workload identity federation rather than stored secrets, and that human signers use phishing-resistant authentication. See the CI/CD Pipeline Identity Security Guide.

Threat or requirement	Reference	Platform control
Stolen or purchased signing certificates	ATT&CK T1588.003 Obtain Capabilities: Code Signing Certificates	Non-exportable keys, per-product keys, monitoring of issued certificates
Malware signed to subvert trust	ATT&CK T1553.002 Subvert Trust Controls: Code Signing	Pre-signing checks, approvals, signing only from attested pipelines
Signed components and integrity	NIST SP 800-53 CM-14 Signed Components; SI-7 Software, Firmware, and Information Integrity	Signing and verification policy for every format you ship or deploy
Separation of duties and key management	NIST SP 800-53 AC-5, SC-12; ISO/IEC 27001:2022 Annex A 8.24 Use of cryptography	Distinct admin, approver and signer roles; key lifecycle records
Release integrity	NIST SSDF (SP 800-218) PS.2; ISO/IEC 27001:2022 Annex A 8.25 Secure development life cycle	Signed releases with timestamps and published verification material

Questions to ask vendors

Ask every shortlisted vendor the same questions in writing, and have them demonstrated in the proof of concept.

Where are private keys generated and stored, which validation (FIPS 140-2 or 140-3, level) does the module hold, can keys ever be exported or backed up outside hardware, and how do you prove key generation to a CA?
Which formats do you sign natively today, and with which tools: Authenticode, macOS, Java, RPM and DEB packages and repository metadata, container images and attestations, PowerShell and other scripts, firmware?
How does a pipeline authenticate to you? Can we bind signing rights to one repository, branch and workflow through federated identity, with no stored secret?
Can we require approval, or M-of-N approval, for release keys while allowing automatic signing for test builds? Can policy require provenance or a clean malware scan before signing?
Do you sign digests so artefacts never leave our build environment?
How is timestamping applied, which timestamp authorities do you use, and what happens to signing if a TSA is unavailable?
If a key or account is compromised, how do we find every artefact it signed, how narrowly can certificates be revoked, and how quickly can we re-key and re-sign?
What is logged for each signing event, how long is it retained, and can we stream it to our log platform in real time?
What is your plan for post-quantum signatures, and do you support LMS or XMSS for firmware today?
Who at your company can access our keys or sign on our behalf, and how would you notify us of a compromise?
What exactly is counted for pricing, and what does doubling our signing volume or number of teams cost?

Red flags

Keys that can be exported "for disaster recovery" outside hardware, or a token that must stay plugged into a shared build server.
No record of which hashes a key signed. When keys leak, as in the NVIDIA code-signing certificate theft where leaked keys were used to sign malware, you need to know what is legitimate.
One key for every product and environment, so a single compromise forces revocation and re-release across the whole portfolio. The AnyDesk breach shows how disruptive revoking and replacing even one code signing certificate is.
Firmware or boot keys with no rotation or revocation story; the MSI signing keys leak exposed keys that devices cannot easily stop trusting.
CI integration that relies on a long-lived API key or token PIN in pipeline variables. Pipeline secrets are routinely harvested, and the HashiCorp GPG key exposure followed a CI tool compromise.
Keyless signing offered for publicly trusted Windows or macOS software, or keyless verification that does not pin the expected identity and issuer.
Timestamping left optional.

Proof of concept

Choose representative work: one Windows product, one Linux package or repository, one container image and, if relevant, one firmware image. Define success: every artefact signed, timestamped and verified, with no long-lived secret in any pipeline.
Baseline: record current keys, where they live, who can use them, signing time per release and how verification happens today.
Set up custody: generate test keys in the vendor's or your HSM, obtain key generation evidence, and confirm keys cannot be exported. Use test or private-trust certificates, not production publicly trusted ones.
Integrate one pipeline with federated identity: bind signing to one repository and branch, then try to sign from another branch, a fork and a developer laptop. All three should fail and be logged.
Exercise policy: require approval for a release key, sign a test build automatically, and submit an artefact without provenance or with a test malware signature to confirm pre-signing checks block it.
Verify at the consumer: check signatures and timestamps on Windows, the package manager, and in container admission policy; for keyless signing, verify with the expected certificate identity and OIDC issuer pinned.
Simulate compromise: declare a test key compromised, list every artefact it signed from the audit log, revoke, re-key and re-sign, and time each step.
Roll back cleanly: keep existing signing in place throughout the trial, revoke test certificates and federation trust, delete trial keys with the vendor's written confirmation, and confirm no pipeline still references the trial endpoint.

Roll out by risk: publicly trusted release keys first (move them into hardware with approvals), then private-trust and container signing, then firmware. Run new signing in parallel with the old for one release cycle before retiring old keys, so rollback means switching a pipeline step back. Measure: signing keys outside hardware (target zero), share of releases signed and timestamped, share of signing events from an approved pipeline identity, signing events outside approved pipelines, artefacts failing verification at deployment, keys without a named owner, and time to revoke and re-sign in exercises.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Code Signing Buyer’s Guide: Choosing a Code Signing Platform