Safeguard
Developer Tools•

Where to keep code signing keys: hardware tokens or cloud signing

Public code signing keys must sit in hardware crypto modules since June 2023. Compare tokens, HSMs and cloud signing for a release pipeline.

Safeguard Security Team
3 min read

For publicly trusted code signing certificates, the CA/Browser Forum requirements say the private key must be generated, stored and used in a suitable hardware crypto module from 1 June 2023. So a key file on a build server is not an option for new certificates. Your real choice is between a token, an HSM or a managed cloud signing service.

What the baseline requirements say

The Code Signing Baseline Requirements state that, from 2023-06-01, the subscriber's private key must be generated, stored and used in a suitable hardware crypto module. Before that date, CAs could propose other protection methods, and after it only approved methods apply. The exact module standards sit in sections of the document that you should read yourself before buying, because details differ by method.

Three common approaches

USB hardware token. The key lives on a device that the CA ships or you buy. It is simple and cheap. It is also awkward in CI, because someone has to plug it in and unlock it, and a single device is a single point of failure.

Your own HSM or network HSM. The key stays inside a hardware module you control, and the build calls it to sign. It suits larger teams with existing key management, and it costs more to run.

Managed cloud signing. A service holds the key and signs digests your pipeline sends. Microsoft describes its own signing service as needing no hardware token and integrating with CI systems, with identity validation first. Other providers offer similar models. You trade control of the hardware for convenience, so read the access model carefully.

What matters more than the form factor

A hardware key can still be abused if anyone can ask it to sign anything. Focus on these controls.

  1. Restrict who and what can call the signing operation. Tie it to a protected release branch or tag.
  2. Log every signing request and review it.
  3. Separate the signing identity from developer machines.
  4. Sign only artifacts built by your pipeline, never files handed over by hand.
  5. Prepare a recovery plan before you need one. Our checklist on key compromise recovery is a good start.

Choosing

Small team, few releases: a token with a documented release procedure may be enough. Frequent releases or several repos: a managed service or an HSM with policy checks saves pain. Whichever you pick, test the failure case, such as a lost token or an expired certificate, on a calm day.

Quick check

Can I keep a PFX file in CI secrets for a public code signing certificate?

For newly issued publicly trusted certificates, the baseline requirements call for hardware protection of the key, so check with your CA. A PFX in a secret store is also a theft target.

Does hardware storage stop a malicious build from being signed?

No. It protects the key from being copied. You still need controls on who can trigger signing.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.