Code Signing Certificate Delivery Methods Explained

If you bought a code signing certificate before 2023, you probably remember downloading a .pfx file, dropping it on a build machine, and moving on with your day. That workflow is gone. Every certificate authority now hands you the certificate through a hardware token, a cloud HSM, or an existing device you already own — and picking the wrong one at checkout can cost you a week of back-and-forth with support.

I’ve set up code signing for teams ranging from a two-person indie studio to a 400-engineer release pipeline, and the delivery method question comes up on nearly every call. This is the explanation I wish existed the first time I had to figure it out.

Why Code Signing Certificates No Longer Ship as Downloadable Files

The shift happened because private keys kept leaking. Malware campaigns like Stuxnet and a string of supply-chain attacks traced back to stolen code signing keys sitting in plain files on developer laptops. Once a key is exposed, every piece of software ever signed with it becomes suspect.

The CA/Browser Forum responded by mandating that code signing private keys live on FIPS 140-2 Level 2 (or Common Criteria EAL 4+) hardware, starting June 2023. That single rule reshaped how every certificate authority delivers certificates, and it’s also behind the shorter validity periods, capped at 460 days, that now apply industry-wide.

Practically, this means the certificate and its private key can never again exist as a portable file you email around. The key has to be generated on, or moved onto, hardware that’s built to resist extraction.

What Are the Main Code Signing Certificate Delivery Methods?

There are three ways a certificate authority gets a code signing certificate into your hands: a USB hardware token they ship to you, a cloud-based HSM you provision remotely, or installation onto hardware you already own. Each fits a different setup.

USB Hardware Token (SafeNet eToken)

This is the default option most CAs steer new customers toward, and it’s the closest thing to the old workflow. The CA generates the key pair directly on a SafeNet eToken, usually the 5110 CC or 5110 FIPS series — and ships it to your address.

The token has to be physically plugged into whatever machine is doing the signing. That’s a strength for a single developer or a small team signing from one workstation, and a genuine limitation the moment signing needs to happen from a build server that no one is sitting in front of.

FIPS 140-2 Level 2 is the baseline compliance standard here, and it’s worth understanding what it actually certifies: role-based authentication, tamper-evidence, and identity-based operator controls on the hardware itself. It’s not a marketing label — it’s the reason a stolen token is far less useful to an attacker than a stolen .pfx file ever was.

Cloud HSM / Cloud Key Storage

Cloud HSM delivery keeps the private key inside a managed hardware security module, DigiCert KeyLocker, Azure Key Vault, AWS CloudHSM, and Google Cloud KMS are the ones I see most often — and lets you authenticate to it remotely instead of plugging in a physical device.

This solves the biggest complaint about tokens: you’re no longer tied to one machine. Multiple build agents, multiple team members, and multiple regions can all sign against the same key, as long as they authenticate correctly.

The tradeoff is cost and setup complexity. Cloud HSM services typically carry a recurring fee on top of the certificate itself, and configuring the connection — CNG providers on Windows, PKCS#11 elsewhere — takes real setup time that a plug-and-play token doesn’t.

Installing on an Existing HSM or Token You Already Own

If your organization already runs a compliant HSM or owns a YubiKey FIPS or Luna device, most CAs will let you generate the certificate directly onto it instead of shipping new hardware. You’ll typically need to submit an attestation confirming the device meets the FIPS or Common Criteria standard.

This path is built for teams with existing infrastructure and security staff who already manage key material elsewhere. It’s rarely the right starting point for a first-time buyer, there’s no support fallback if something on your own hardware misbehaves.

USB Token vs. Cloud HSM: Which Should You Choose?

If you’re signing from a single machine and want the simplest possible setup, the USB token wins — lower ongoing cost, nothing to configure beyond plugging it in. If you need to sign from CI/CD runners, multiple machines, or a distributed team, cloud HSM is the only option that scales without physically mailing a token around.

I generally tell smaller teams to start with a token and reassess once signing volume or automation needs grow. Migrating from a token to cloud HSM later means a certificate reissue, but it’s a far smaller project than retrofitting an automated pipeline around a device that has to be physically present.

Compatible Hardware Security Modules by Certificate Authority

Support varies by CA, and it’s worth checking before you buy rather than after. Sectigo publishes a list of supported HSM brands including SafeNet, YubiKey FIPS, and Luna. DigiCert supports its own KeyLocker platform alongside SafeNet USB devices and third-party HSMs meeting FIPS 140 Level 2 or higher.

Azure Key Vault and AWS CloudHSM aren’t proprietary to any single CA — they’re infrastructure you provision yourself, then point your certificate at. That flexibility is exactly why teams already running Azure or AWS tend to gravitate toward cloud HSM delivery instead of a token.

Code Signing Delivery Methods and CI/CD Pipelines

This is the part most delivery-method guides skip, and it’s the part that actually breaks builds. A USB token sitting in a physical machine cannot be reached by a GitHub Actions runner spinning up in the cloud. If your pipeline is fully automated, token-based delivery forces a manual step back into your release process, someone has to plug in a device and sign locally.

Cloud HSM delivery is what makes signing genuinely automatable. With AWS CloudHSM, you configure the CloudHSM KSP client on your build instance and call Microsoft’s SignTool against the key sitting in the HSM, no physical hardware involved. Azure Key Vault and Google Cloud KMS follow a similar pattern through their own CNG or PKCS#11 providers.

If your build pipeline runs on ephemeral cloud agents, budget for cloud HSM delivery from the start. Retrofitting automation around a token later is a bigger rework than most teams expect, and it usually means a certificate reissue on top of the infrastructure changes.

Is Cloud-Based Code Signing as Secure as a Physical Token?

Yes, assuming the underlying HSM meets the same FIPS 140-2 Level 2 or Common Criteria EAL 4+ standard required for tokens. The private key never leaves the HSM boundary in either case, the difference is how you authenticate to reach it, not how well the key itself is protected.

Where cloud HSM setups actually need more scrutiny is access control. A token is protected by physical possession; a cloud HSM is protected by credentials and permissions you configure. Misconfigured IAM policies or shared service accounts are a more realistic risk than the HSM hardware itself.

What Happens If You Choose the Wrong Delivery Method?

Most CAs lock the delivery method once an order is placed, because token generation and cloud provisioning happen immediately after purchase. If you realize the mistake before the token ships or the cloud key is generated, canceling the order through your account dashboard is usually your fastest path to a redo.

If the token has already shipped, expect to pay for a reissue on the correct delivery method rather than a refund on the original. It’s a frustrating but avoidable cost, confirming your signing infrastructure (single workstation vs. CI/CD vs. existing HSM) before checkout saves that entire conversation.

Frequently Asked Questions

Why do code signing certificates now require a hardware token? The CA/Browser Forum mandated FIPS-compliant hardware storage for all code signing private keys starting June 2023, in direct response to a pattern of stolen signing keys being used to distribute malware disguised as trusted software.

What’s the difference between token delivery and cloud key storage for code signing? A token puts the key on physical hardware you must plug into the signing machine. Cloud key storage keeps the key in a managed HSM you authenticate to remotely, which is what makes automated, multi-machine signing possible.

Can I install a code signing certificate on my own HSM instead of using the CA’s token? Yes, most CAs support this for customers who already own a compliant HSM or hardware token, typically requiring an attestation that the device meets FIPS 140-2 Level 2 or an equivalent standard.

Choosing the Right Delivery Method for Your Team

There’s no universally correct answer here, the right delivery method depends entirely on how and where your signing happens. A solo developer signing installers by hand has different needs than a platform team signing releases across a dozen automated pipelines.

Walk through your actual signing workflow before you buy: how many machines need to sign, whether any of that happens without a human present, and what infrastructure your team already manages. That answer points you to the right delivery method faster than any comparison chart can.