In short
Every publicly trusted code signing key has to live on certified secure hardware — since June 1, 2023, a plain certificate file hasn't been an option. What you're really choosing is whose hardware: a USB token couriered to your desk, the CA's HSM reached through a cloud signing service, or an HSM you operate yourself. Cloud signing has become the practical default because nothing ships, nothing gets lost, and it works the day validation clears. Tokens and self-managed HSMs still earn their keep in specific setups, which this guide walks through.
One scoping note before the comparison: the storage model is independent of the validation tier, so everything below applies to OV and EV certificates equally. It also decides more of your daily workflow than the tier does. The Certum code signing certificates My-SSL sells (from $99/year) are delivered through cloud signing — worth knowing as you read, since the trade-offs below are exactly the ones that choice was made on.
Buying a code signing certificate used to end with a download link. Today it ends with a question most buyers don't see coming: where will the private key physically live? Answer it wrong and you'll feel it for the life of the certificate — a token stuck in customs while your release waits, a build pipeline that can't reach a key plugged into someone's laptop, or an HSM attestation process you didn't budget for. This guide compares the three arrangements the rules actually allow, what each one is like to use day to day, and which one fits the way you ship software.
Why your key must live on hardware
Since June 1, 2023, the CA/Browser Forum's Baseline Requirements for code signing have required every publicly trusted code signing key — OV and EV alike — to be generated and stored on a hardware crypto module certified to FIPS 140-2 Level 2 or Common Criteria EAL 4+, with the key non-exportable. No CA can hand you a .pfx file anymore, so choosing a certificate now means choosing where that hardware sits.
The rule (ballot CSC-17, if you want to read the original) exists because software keys kept getting stolen. A private key sitting in a file on a build server is one compromised machine away from signing malware in your company's name, and that kept happening to real publishers. Locking the key inside dedicated hardware, where it can be used but never copied, closes that particular door. Our code signing certificates explainer covers the change in context; what matters here is the consequence — "certified hardware" turns out to mean three quite different things in practice.
The three compliant options at a glance
You can hold a code signing key in exactly three compliant ways: a USB token the CA ships to you, a cloud signing service where the key sits in the CA's own HSM and you sign remotely, or a certified HSM you operate yourself and the CA verifies before issuing. All three satisfy the same rule; they differ in who runs the hardware and how your tools reach it.
| USB token | Cloud signing | Your own HSM | |
|---|---|---|---|
| Where the key lives | On a device on your desk | In the CA's HSM | In hardware you operate |
| Time to first signature | After courier delivery | Same day as validation | After the CA verifies your HSM |
| Sharing across a team | One machine at a time | Any authorized machine | Whatever you engineer |
| Loss / damage risk | Real — key gone, reissue needed | None on your side | Yours to manage |
| Up-front effort | Drivers + PIN handling | Install an agent, pair a phone | Attestation, audits, key ceremony |
The rest of this guide takes the options one at a time — what daily signing actually feels like on each, and the failure modes the sales pages don't mention.
USB tokens: what daily signing looks like
A token is a smart card in USB form: the CA generates your key on it, couriers it to you, and from then on signing means having that physical object plugged into the machine doing the work. You install the vendor's card drivers once, and each signing session asks for the token's PIN before the key will operate.
For a single developer who signs a release every few months from the same PC, this arrangement is honestly fine. The friction shows up at the edges. The token can only be in one place, so a colleague who needs to sign on Tuesday needs the object itself, not a login. The courier leg adds days or weeks before your first signature — painful when a release is waiting on it. Enter the PIN wrong a handful of times and the token locks. And because the key is non-exportable by design, a lost or broken token means the key no longer exists; you're back to the CA for a reissue, and back to waiting for the mail. None of these are exotic failures — they're the ordinary life of a small object that must not be lost.
How cloud code signing works
In cloud signing, the certified hardware is the CA's: your key is generated inside an HSM in the CA's data center and never leaves it. A small desktop agent presents the certificate to your operating system as a virtual smart card, you approve the session with a one-time code from a mobile app, and your normal tools sign as if a physical card were in a reader.
Certum's implementation, SimplySign, is the version you'll meet if you buy through My-SSL — the code signing certificates we sell are delivered this way, with no physical token involved. The moving parts: SimplySign Desktop is the agent that emulates the card, the SimplySign mobile app generates the one-time codes, and once a session is open, SignTool or jarsigner work exactly as they would against local hardware — the same commands from our SignTool walkthrough apply unchanged, including timestamping against Certum's server at time.certum.pl. As of July 2026, Certum's cloud code signing carries a usage ceiling of 5,000 signatures per month — irrelevant for a team shipping installers, worth knowing if you plan to sign every artifact a busy pipeline produces.
The honest trade-offs: signing requires a network connection to the CA's service, and the person-with-a-phone step that makes the setup secure is also what makes fully unattended automation take extra work — our guide to code signing in CI/CD pipelines covers the patterns teams use for that. What you get in exchange is the whole category of token problems gone — nothing to ship, nothing to lose, nothing that locks after mistyped PINs, and a certificate a distributed team can actually share.
Your own HSM — and Microsoft's Artifact Signing
The third route is bringing your own hardware: a FIPS 140-2 Level 2 (or Common Criteria EAL 4+) certified HSM that you operate, on-premises or as a dedicated cloud HSM. The CA won't take your word for it — before issuing, it verifies the key was generated in compliant hardware, typically through an attestation from the HSM itself or an auditor's letter. This is the most work by a wide margin, and the only option that keeps the key entirely inside your infrastructure.
Organizations choose it when policy demands custody — a security team that already runs key ceremonies, or a compliance regime that forbids third-party key storage. If that doesn't describe your company, it's rarely worth building. Worth a mention in the same breath: Microsoft's Azure Artifact Signing (renamed from Trusted Signing) is a subscription flavor of the cloud model where the HSM is Azure's and certificates are short-lived, with tight GitHub Actions and Azure DevOps integration. As of July 2026 it's limited to organizations in the USA, Canada, the EU, and the UK — individual developers only in the USA and Canada — so for publishers elsewhere, a CA cloud service or token remains the practical menu. And whichever storage you pick, reputation systems treat you the same: SmartScreen builds trust on your certificate, not on where its key sleeps.
How to choose
Pick the key's home by how you ship, not by habit: a solo developer signing by hand can be happy with either a token or cloud signing, a team sharing one certificate across people or machines should default to cloud, unattended pipelines need cloud or an HSM-backed service, and a company that already operates certified HSMs is the one candidate for bringing its own.
Two practical notes as you decide. First, the storage model doesn't change the paperwork: identity validation is the same, and the document checklist shows what the CA will ask for before anything is issued. Second, storage and term length interact — a certificate you can't lose is a certificate you can safely buy for longer, and the three-year terms cost meaningfully less per year than annual renewals while also preserving SmartScreen reputation across a longer stretch.
The bottom line
The hardware rule took away the easy answer, and the three that remain sort themselves quickly: tokens for a single signer who doesn't mind custody of a physical object, your own HSM for organizations with the estate to justify it, and cloud signing for nearly everyone in between. If cloud is where you land, My-SSL's Certum code signing certificates start at $99/year for Standard and $299/year for EV, are issued for one- to three-year terms, and sign through SimplySign from the day validation clears — no courier involved.