Code signing after the CA/B Forum hardware mandate: your keys live in an HSM now

For about two decades, getting a code signing certificate worked like this: you paid a certificate authority, proved your organisation existed, and downloaded a PFX file containing your private key. That file went onto a build server, into a source repository (more often than anyone admits), or onto the laptop of whoever set up the pipeline. In June 2023 the CA/Browser Forum ended that era. Subscriber private keys for publicly trusted code signing certificates must now be generated and kept in certified hardware — and no public CA will hand you a software key again.

This chapter of the Luna Field Guide covers what the mandate actually says, how CAs enforce it, the three realistic places your signing key can now live, and why an organisation that already operates a Luna estate should think hard before letting that key live anywhere else. The next chapter is the hands-on companion: Authenticode signing from CI with HSM-held keys.

What actually changed in June 2023

The CA/Browser Forum’s Code Signing Baseline Requirements (version 3.2, via ballot CSC-13) introduced a private key protection rule that took effect on 1 June 2023, after being pushed back from its original November 2022 date to give CAs and subscribers time to comply. The rule: the subscriber’s private key must be generated and stored in a hardware crypto module certified to FIPS 140-2 Level 2 or Common Criteria EAL 4+ (or better), in a way that prevents the key from being exported in the clear.

Two details matter more than the headline. First, the requirement applies to all publicly trusted code signing certificates — OV as well as EV. Hardware protection had been an EV requirement for years; June 2023 extended it to the ordinary organisation-validated certificates that most software vendors actually buy. Second, the CA is obliged to satisfy itself that the requirement is met before issuing. This is not an honour-system clause buried in subscriber terms; it changed how certificates are physically delivered.

The reasoning is straightforward supply-chain security. A private key in a PFX file can be copied without anyone noticing, and stolen code signing keys are premium goods — a signature from a legitimate vendor is precisely what gets malware past application allowlists and warning screens. A key generated inside certified hardware, flagged non-exportable, cannot be quietly duplicated. An attacker must either steal the physical device or compromise a system with live access to it — both noisier, both more recoverable.

How the CAs enforce it

Since the deadline, public CAs have converged on three delivery models, and “download your PFX” is not among them:

• CA-shipped USB token. The default for most retail purchases. The CA generates the key on a certified token (typically a SafeNet/Thales eToken or similar), installs the certificate, and couriers it to you. You never see the key material; you get a PIN.
• Your own HSM, with attestation. You generate the key pair in an HSM you operate, then prove to the CA that the key was generated in — and cannot leave — certified hardware. CAs generally require verifiable key attestation from the device alongside the CSR; some accept an auditor’s or officer’s attestation for certain models. Requirements vary by CA, so confirm the accepted attestation formats for your device before you order.
• Cloud signing service. The key lives in the CA’s (or a cloud provider’s) HSM-backed service and you call an API to sign. DigiCert KeyLocker, SSL.com eSigner, Certum SimplySign and Microsoft’s Azure Trusted Signing (in the process of being rebranded Azure Artifact Signing) all follow this pattern.

Note what died along with the PFX download: casual key duplication. There is no “just copy the cert to the new build server” any more. Wherever the key lands on day one is where your signing process lives — which is why the choice deserves more thought than it usually gets.

The three places your key can live, honestly compared

Each model is legitimate, and each fits a different kind of organisation. The honest comparison:

Model	Fits	Costs you
CA-shipped USB token	Small teams, occasional releases, one or two signers	Manual signing tied to a physical object and a person; painful to automate safely; token PIN lockout can be terminal; no meaningful audit trail
Cloud signing service	Teams with no HSM estate who need CI signing quickly	Ongoing subscription; key custody sits with a third party; service availability and region constraints; per-signature or per-account limits; Azure Trusted Signing signs Windows artifacts only and is available to organisations in a limited set of countries
Your own HSM	Organisations already operating HSMs for PKI or key management	You own the operational burden: partitions, backup, HA, ceremonies — which is only a good trade if you carry that burden already

Azure Trusted Signing deserves a specific honest mention because it is genuinely good at what it does: for roughly ten dollars a month it handles identity validation and issues short-lived certificates — rotated daily, each valid about 72 hours — so a leaked signing capability ages out fast, and timestamped signatures remain valid indefinitely. For a Windows ISV with no hardware estate, it is probably the right answer. But key custody, issuance policy and availability all sit with Microsoft, the service signs Windows artifact formats only, and a certificate that changes daily interacts awkwardly with anything that pins a specific certificate — application-control publisher rules survive rotation only if they are written against the publisher identity rather than a thumbprint. For a regulated organisation that must demonstrate sovereign control of its keys, “Microsoft holds it” may be an unacceptable answer regardless of technical merit.

EV vs OV now that hardware applies to both

The June 2023 change also quietly rewrote the EV-versus-OV decision. The traditional pitch for EV code signing was twofold: hardware key protection, and instant SmartScreen reputation. The first is now table stakes — OV keys sit in the same class of hardware. The second is gone too: since around March 2024, Microsoft no longer grants EV-signed binaries automatic SmartScreen reputation, and both certificate types build reputation the same way, through clean download history.

What EV still buys you is access: a valid EV code signing certificate remains a requirement for the Microsoft Hardware Program — Partner Center registration and kernel-mode driver signing through WHQL. If you ship drivers, you need EV. If you ship user-mode software, the practical difference between EV and OV is now mostly the vetting depth and the price, and an OV certificate on a properly governed HSM is a defensible choice. Check current CA and Microsoft policy before deciding; this corner of the market has shifted twice in three years.

The case for signing from a Luna estate you already run

If your organisation already operates Thales Luna Network HSMs — for a certificate authority, a key management platform, or a privileged access vault — the calculus tilts firmly toward option three. A Luna 7 appliance is validated to FIPS 140-2 Level 3, comfortably above the mandated floor (newer firmware carries FIPS 140-3 validation; check the certificate for your exact firmware). The marginal cost of a code signing key is one more partition, or one more key in an existing application partition. And you get three things the token and the cloud service cannot give you:

• One root of trust. Your signing key is protected by the same hardware, the same ceremony discipline, the same separation of duties and the same backup and HA arrangements as every other key you defend. No parallel universe of USB tokens with their own undocumented lifecycle. The governance side of this is covered in our chapter on HSM key ceremonies and separation of duties under the ISM.
• A real audit trail. Luna partitions produce audit logs of key usage. When an assessor — or an incident responder — asks what was signed with the release key and when, “here is the HSM audit log correlated with pipeline run history” is an answer. A token in a drawer produces nothing.
• Revocation-response speed. If you suspect compromise, you can disable the partition’s crypto officer credential, kill the NTLS client registration, or deactivate the partition — immediately, from lunash, with an audit record. Compare that with establishing which of five couriered tokens is compromised, where it physically is, and who last held it.

If you are building the estate itself from scratch, start with our comprehensive Luna HSM design and operational guide — code signing should be a tenant of a well-designed estate, not the reason you improvise one.

The token in the drawer

Here is a composite scenario — a pattern we see in regulated environments and that repeats in vendor forums with different logos. An organisation bought an EV certificate years ago; it arrived on a USB token. The token lives in a locked drawer, per policy. The build pipeline is fully automated up to the final step, where the release engineer plugs the token into their laptop, runs the SafeNet Authentication Client, types the PIN and executes the signing script. It works, in the way that anything works until the person it depends on is unavailable.

Then a critical patch release lands in the second week of January. The release engineer is on leave, four hours away. The token is in the drawer, but the PIN is in their head — policy says PINs are never written down, and nobody thought about what that means for a shared signing credential. A colleague finds a PIN in an old handover note and tries it. It is wrong. After a handful of wrong attempts the token locks — and on most CA-shipped tokens, an administrator lockout is permanent. The recovery path is not a helpdesk reset; it is a certificate reissue on a new token, with fresh validation, shipped by courier. The patch that needed to go out on Tuesday ships unsigned to a customer who agreed to suppress the warnings, or ships a week late. Both outcomes end up in a post-incident review.

Nothing in that story involves an attacker. That is the point: the token model converts a routine availability problem into a release-blocking incident, because it binds a business-critical capability to a single physical object and a single person’s memory. HSM-backed signing has failure modes too — but they are the failure modes of infrastructure, with HA, backup and documented recovery, not the failure modes of a drawer.

What this means for suppliers to government

If you sell software into Australian federal government, your signing key is part of your customer’s control environment, whether either of you frames it that way. Essential Eight application control at the higher maturity levels is commonly implemented with publisher certificate rules — Windows Defender Application Control and AppLocker policies that trust “anything signed by this publisher”. Every agency that writes such a rule for your certificate has extended its execution allowlist to everything your key ever signs. Your key custody is their supply-chain exposure, and ISM-aligned assessments increasingly ask software suppliers exactly where and how signing keys are held.

That cuts two ways. A compromised signing key does not just cost you a certificate reissue; it hands an adversary a pass through your customers’ application control. And when the question comes in a supplier assurance questionnaire, “the key was generated in and cannot leave a FIPS 140-2 Level 3 HSM, here is the attestation, here is the ceremony record, here is the usage audit trail” is a categorically better answer than “it’s on a token in the release manager’s drawer”. For organisations holding identity-verification or police-check-class data, the same HSM estate already exists for data protection — the signing key belongs with it.

Where this leaves you

Deciding the key lives in your Luna estate is the easy half. The hard half is operational: your CI pipeline needs to sign every build, unattended, at 2am, without a human presenting anything — which means a CSR generated against an HSM-held key, a KSP registered under the right service account, a partition that survives reboots, and signtool wired to a key it can use but never touch. That walkthrough is the next chapter: Authenticode signing from CI with HSM-held keys. For the rest of the series, see The Luna Field Guide.