EV Code Signing Without Hardware Token: Cloud HSM Compliance Explained

If you’ve been asked to set up EV code signing and someone on your team said “no more USB tokens,” you’re probably wondering if that’s even allowed. It is. But the reasoning behind it gets misunderstood constantly, and getting it wrong can cost you a failed audit or a rejected driver submission.

Here’s the short version: you can drop the physical token. You cannot drop the hardware requirement. Those are two different things, and the gap between them is where most of the confusion lives.

What “Without a Hardware Token” Actually Means for EV Code Signing

An EV code signing certificate has never been about the plastic USB stick in your drawer. It’s about where the private key lives and how it’s protected. The Certification Authority/Browser Forum requires that key to sit inside hardware validated to FIPS 140-2 Level 2 or higher, a physical token was simply the easiest way to deliver that in 2015.

A cloud HSM (hardware security module) meets the same validation standard. The hardware still exists. It’s just sitting in a certificate provider’s data center instead of your desk drawer, and you reach it over an authenticated API call instead of a USB port.

So when someone asks for “EV code signing without a hardware token,” what they actually want is EV code signing without a physical token they have to plug in, ship to remote employees, or lose track of during an audit. That’s achievable today. What isn’t achievable is EV signing where the key sits in software with no hardware backing at all, no provider offers that, because the CA/Browser Forum won’t allow it to be issued.

Why Hardware Is Required — The CA/Browser Forum Rule

This requirement isn’t arbitrary. Before mid-2023, some EV code signing and standard code signing keys were stored as software files on developer laptops. Attackers went after exactly those files, and a string of high-profile breaches followed, malware signed with stolen legitimate certificates, which is far more damaging than unsigned malware because it walks past SmartScreen and most endpoint defenses without a second look.

The CA/Browser Forum’s response, effective June 2023, mandated hardware-backed key storage for all code signing certificates, with EV held to the stricter FIPS 140-2 Level 2 standard. The private key must be generated inside the hardware boundary and must never leave it in an exportable form. That single rule closed off the easiest attack path against signed software supply chains.

For teams that already ran a token, this changed nothing operationally. For teams trying to sign from a build server with no one physically present to insert a USB device, it created a real problem, one cloud HSM was built to solve.

Cloud HSM as the Compliant Alternative

A cloud HSM is a hardware security module owned and operated by your certificate provider, shared (in a logically isolated way) or dedicated across customers, and accessed through a signing API or a client tool that mimics local signing commands. Your key is generated inside that module and stays there for the life of the certificate.

Practically, this shifts who’s responsible for the physical security piece. With a token, that’s you, safe storage, controlled access, physical inventory. With a cloud HSM, that responsibility moves to the provider, who’s already running audited, access-controlled infrastructure built for exactly this purpose. You keep the compliance outcome. You lose the physical custody burden.

FIPS 140-2 Compliant Code Signing in the Cloud

Not every cloud HSM is validated to the same level, and this is worth checking before you commit to a provider. FIPS 140-2 Level 2 is the CA/Browser Forum floor for EV. Some providers run Level 3 modules, which add tamper-evidence and stricter access controls, useful if your own security review or a customer’s vendor questionnaire asks for it specifically.

Ask your provider directly which level their cloud HSM is validated to, and ask for documentation you can hand to an auditor. A reputable provider will have this ready without hesitation. If they hedge on the question, that’s a signal worth paying attention to.

EV Code Signing Without USB Token — How the Workflow Changes

The certificate issuance process itself barely changes. You still go through the same organization validation, legal entity checks, phone verification, sometimes a notarized document depending on your jurisdiction. EV validation exists to confirm who you are, and that part of the process is identical whether your key ends up on a token or in a cloud HSM.

What changes is what happens after issuance. Instead of receiving a physical device in the mail, your provider walks you through a key attestation step, essentially proving your cloud HSM setup (whether provider-managed or your own) meets the required hardware standard before they’ll issue against it. Once that’s done, signing happens through a client application or API call rather than a local USB connection.

One practical difference worth planning for: token-based signing works the moment the token is plugged in, anywhere. Cloud HSM signing requires network access to the signing service, so an air-gapped build environment needs a different plan entirely — that’s a real limitation, not a marketing footnote.

Remote Code Signing for CI/CD Pipelines

This is where cloud HSM earns its keep. A build server doesn’t have hands to insert a token, and passing a physical device between machines defeats the point of automation. Remote code signing solves this by letting your pipeline authenticate to the signing service directly and request a signature as part of the build job.

In practice, this usually means a signing client wraps the existing Windows signing tool your pipeline already calls, so the build script barely changes, you’re mostly swapping a local certificate reference for an authenticated service call. GitHub Actions, Azure DevOps, Jenkins, and GitLab CI all support this pattern without much friction once the initial setup is done.

Headless and Linux Build Environments

Here’s where it gets more specific. If your build agents run Windows, the signing client typically integrates cleanly because it’s built to sit alongside the native Windows signing tool. If you’re signing from Linux runners, you’re usually working directly against the provider’s signing API rather than a wrapped client, which means more setup work upfront and less plug-and-play convenience.

Ask specifically about Linux and headless support before you commit. Some providers handle it well. Others treat it as a secondary use case, and you’ll find that out the hard way mid-integration if you don’t ask first.

Choosing a Cloud-Based Code Signing Certificate

A few things separate a service that works from one that becomes a support ticket queue:

• Validation level support — confirm EV specifically is supported through the cloud HSM path, not just OV. Some providers restrict EV to their higher-tier plans.
• Attestation process clarity — a provider should be able to explain, in plain terms, how they verify your key meets FIPS requirements before issuance.
• API and CI/CD compatibility — check documented support for your specific pipeline tooling before you buy, not after.
• Audit logging — every signing event should be logged with enough detail to satisfy an internal security review or customer audit request.
• Support responsiveness — signing failures block releases. A provider’s response time on signing issues matters more than it does for most other support categories.

Run a small test signing job before migrating your full pipeline over. It catches integration gaps early, when they’re cheap to fix.

Cost Considerations

Pricing for cloud HSM–backed EV code signing certificates typically breaks into two pieces: the certificate itself, priced similarly to token-based EV, and a service or attestation fee tied to the cloud HSM setup. Some providers roll this into a flat annual price; others charge separately for the attestation step, particularly if you’re bringing your own HSM rather than using theirs.

The trade-off worth calculating isn’t just certificate price against certificate price. Factor in what you’re currently spending on token logistics, shipping, replacement tokens for lost or damaged devices, and the staff time spent managing physical inventory across a distributed team. For teams signing frequently from CI/CD, that operational cost often outweighs the difference in certificate pricing itself.

Frequently Asked Questions

Is a hardware token mandatory for EV code signing certificates? No. Hardware-backed key storage is mandatory, a cloud HSM validated to FIPS 140-2 Level 2 or higher satisfies that requirement without a physical USB token.

What’s the difference between a hardware token and a cloud HSM for code signing? Both store your private key inside FIPS-validated hardware. A token puts that hardware in a physical device you control directly. A cloud HSM puts it in provider-managed infrastructure you access through an authenticated signing service.

Which certificate authorities offer EV code signing without shipping a physical token? Several major certificate providers now offer cloud HSM–backed EV signing as an alternative to token delivery. Availability and setup process vary, so confirm EV support specifically, some providers limit cloud signing to OV certificates only.

Is cloud HSM code signing FIPS 140-2 compliant? Yes, when the provider’s HSM is validated to at least FIPS 140-2 Level 2, which meets the CA/Browser Forum’s minimum requirement for EV private key storage. Ask for the specific validation level and documentation before signing up.

---

This article reflects code signing practices and CA/Browser Forum requirements as of publication. Requirements around key storage and validation continue to evolve, so confirm current rules with your certificate provider before making infrastructure decisions.