The short version
In June 2023 the CA/Browser Forum changed the rules for publicly trusted code-signing certificates: the private key can no longer live on a developer’s laptop or a build server disk. It must be generated and kept in certified hardware, either a hardware token or a hardware security module that meets FIPS 140-2 Level 2 or Common Criteria EAL4+. Standard OV certificates now carry the same hardware requirement that only Extended Validation certificates had before.
The reason is theft. Stolen signing keys have been used to sign malware that sails through defenses because it carries a trusted signature. Driver signing abuse and several supply-chain incidents all traced back to a key that should never have been copyable. A key that cannot leave its hardware cannot be stolen by copying a file.
The mandate solves key theft and creates an operational problem. A key locked in hardware is a key that is not on the build server, and getting signatures to happen reliably, at team scale, without a human carrying a token to every release is the work this guide is about.
| Signing type | Hardware required | Who mandates it |
|---|---|---|
| Public OV and EV code signing | Yes, since June 2023 | CA/Browser Forum |
| Windows kernel-mode drivers | Yes, EV plus attestation signing through Microsoft | Microsoft |
| Apple notarization | Keys on Apple-controlled infrastructure or in your keychain or HSM | Apple |
| Internal code signing from your own CA | Your policy, but hardware is best practice | You |
What the mandate actually requires
Three things, for any publicly trusted code-signing certificate issued since the change.
The key is generated in hardware. The certificate authority will only issue against a certificate signing request that originated in a qualifying device, and many now verify this with an attestation from the device itself. You cannot generate a key in software and move it in.
The key never leaves. Signing happens by sending the data to be signed into the hardware and getting a signature out. The private key stays inside for its whole life. There is no export.
The hardware is certified. A USB token such as a YubiKey or a SafeNet eToken for a single signer, or a hardware security module, on-premises or in a cloud, for a team. The certificate is FIPS 140-2 Level 2 or higher, or the Common Criteria equivalent.
If you bought a code-signing certificate before mid-2023 and have a key sitting in a file or a software certificate store, it was issued under the old rules. At renewal it will become a hardware key, and your signing process has to change with it. Plan the renewal as a migration, not a formality.
The platforms differ, and the differences matter
Windows
Authenticode signing with signtool is the baseline. For a team, the key lives in an HSM and signtool reaches it through a CNG provider or a PKCS#11 bridge, so the build server never holds the key, only the right to ask the HSM to sign.
Kernel-mode drivers are stricter. Since Windows 10, production drivers must be submitted to the Microsoft Partner Center and signed by Microsoft’s attestation or WHQL process; your own signature alone is not enough to load a driver on a modern, secure-booted system. That means an EV certificate, a Partner Center account, and a submission step in the release pipeline, not just a signing call.
SmartScreen reputation is the quiet part. A brand-new certificate, even a valid one, carries no reputation, so freshly signed installers may still warn users until the certificate builds history. EV certificates start with better standing. Budget for a reputation ramp when you rotate certificates.
Apple
Apple never allowed exportable signing in the way Windows did, so the hardware mandate is less of a shock, but the model is different. Signing identities live in your keychain, protected by the Secure Enclave on modern Macs, or in an HSM for a team. Distribution outside the App Store also requires notarization: you upload the signed build to Apple, their service scans it and returns a ticket, and you staple that ticket to the artifact. A signature alone is no longer enough for Gatekeeper to let software run without friction.
For a team this means the signing identity and the notarization credentials both need to be reachable from the build system, and the notarization step needs to be in the pipeline with its own retries, because it is a network call to Apple that can fail or queue.
Containers and artifacts
Container images, software packages, and other build artifacts increasingly use Sigstore and its tool cosign, which can sign with keys in an HSM or KMS and supports keyless signing tied to a workload identity with a transparency log. This is a different trust model than a certificate from a public CA, built for CI pipelines rather than for shipping a signed executable to end users. Many organizations run both: a public code-signing certificate for the installer a customer downloads, and Sigstore for the internal supply chain.
Firmware and long-lived devices
Firmware signing is its own world and connects to the post-quantum migration. A root of trust burned into a device verifies firmware signatures for the device’s entire service life, so the signing key and algorithm have to last a decade or more. This is where the stateful hash-based schemes, LMS and XMSS, matter, and where getting the HSM and key ceremony right the first time is non-negotiable, because you cannot patch a root of trust in the field.
The operational problem, and how to solve it
A key in hardware is secure and inconvenient. The failure modes are predictable: a single token that one person owns and that blocks every release when they are on leave, a shared token passed around an office, or a build pipeline that cannot sign at all so someone signs manually at the end. Each of these trades the security you paid for, or the velocity you need, or both.
The pattern that works is a signing service. The key stays in a networked HSM. A signing service sits in front of it, authenticates the build system or the person asking, enforces policy about what may be signed, performs the signature inside the HSM, and logs every request. Developers and pipelines call the service; nobody handles the key.
What a good signing setup gives you:
- The key never moves and never copies, satisfying the mandate by construction.
- Signing is available to every authorized pipeline without a physical token in a drawer, with no single person as the bottleneck.
- Access is controlled and logged. You can answer who signed what, when, and whether it was authorized, which is the question that matters after an incident and the one auditors ask.
- Approval fits the risk. Routine internal builds sign automatically under policy; a production release can require a second approver. The control lives in the service, not in who happens to hold the token.
- Timestamping is applied at signing, so signatures remain valid after the certificate expires. Without a trusted timestamp, everything you signed stops verifying the day the certificate lapses. This is easy to forget and expensive to discover.
The building blocks are an HSM sized for your signing volume, on-premises or a cloud offering such as Azure Key Vault Managed HSM, AWS CloudHSM, or Google Cloud HSM; a signing orchestration layer, whether a commercial product, a cloud signing service, or a service you build on PKCS#11; integration into CI so signing is a pipeline step with the same logging as the rest of the build; and a key ceremony and documented recovery procedure for the signing keys, treated with the same seriousness as a CA key, because that is effectively what they are.
A readiness checklist
- Inventory every signing key you have: Windows Authenticode, Apple identities, driver signing, firmware, container and package signing, and any internal signing. Record where each key lives and whether it is already in hardware.
- Find the software keys. Any publicly trusted code-signing key still in a file or software store is a renewal-time migration waiting to happen, and a theft risk until then.
- Decide tokens or HSM. One signer who signs occasionally can use a token. A team, a pipeline, or more than one product needs an HSM and a signing service. Most organizations outgrow tokens faster than they expect.
- Confirm timestamping is applied to every signature, from a trusted timestamp authority, so signatures outlive the certificate.
- Put signing in the pipeline, not at the end by hand. Manual signing is where keys get mishandled and releases get blocked.
- Log and review. Every signature should be attributable and auditable. Decide which releases need a second approver.
- Plan the key ceremony and recovery for signing keys as carefully as for a CA. Know how you would recover if an HSM failed, and test it.
- Account for reputation and notarization in release timelines: SmartScreen ramp on Windows, the notarization round-trip on Apple.
Questions we get
Does this apply to our internal tools that never leave the company? The CA/Browser Forum mandate applies to publicly trusted certificates. Code signed by your own internal CA follows your policy. But internal signing keys are a prime theft target precisely because internal code is trusted, so hardware protection is strongly advised even where it is not required.
Can we keep signing in software until our certificate expires? You can until renewal, but you are carrying the theft risk the mandate exists to remove, and the renewal will force hardware anyway. Better to migrate deliberately than under deadline.
Will a cloud HSM satisfy the requirement? Yes, when it meets the certification level and the CA accepts it. The major cloud HSMs are built for this and remove the burden of running hardware yourself. Confirm the specific service tier is validated.
What happens to everything we already signed if the key is compromised? Timestamped signatures made before the compromise remain valid; this is exactly why timestamping matters. The certificate is revoked, the key is destroyed, and you re-key. Without timestamps, revocation can invalidate everything retroactively.
Where we can help
A code-signing assessment inventories your signing keys across Windows, Apple, drivers, firmware, and the build pipeline, finds the keys still in software, and designs a signing service around an HSM so signing is both compliant and fast. Because we run key ceremonies and HSM deployments as our core work, the signing keys get treated with the seriousness they deserve. If firmware signing is in scope, we fold in the post-quantum choices so the root of trust you set now lasts.