Code Signing Key Attestation: Using Your Own HSM

What key attestation actually is

An attestation is the hardware speaking for itself. Every compliant token or HSM ships with a key pair burned in during manufacture, along with a certificate for it signed by the vendor. When the device generates a new key pair for you, it can sign a short statement about that key — this key was created here, inside this module, with the export flag off — using the factory key. You cannot produce that signature yourself, and neither can anyone holding a copy of your private key on a laptop, which is precisely what makes it evidence.

The Code Signing Baseline Requirements describe the mechanism without much ceremony. Method 2 of section 6.2.7.4.2 is "the Subscriber counter-signs certificate requests that can be verified by using a manufacturer's certificate, commonly known as key attestation, indicating that the Private Key was generated in a non-exportable way using a suitable Hardware Crypto Module". The phrase "commonly known as key attestation" sits in the standard itself, which is unusual and tells you how settled the practice had become before the Forum wrote it down.

What reaches the CA is therefore two files rather than one: the certificate signing request, and an attestation bundle whose format depends entirely on the vendor. A YubiKey emits a small certificate chain from its PIV applet. A Thales or Entrust HSM produces something structurally different. The CA reads whichever it supports, checks the chain back to a vendor root it already holds, and looks at what the statement claims about exportability.

Why your word is not enough

Because a CSR cannot carry the claim. A certificate signing request proves one thing: that whoever assembled it holds the private key matching the public key inside, because the request is signed with that key. Where the key is stored leaves no trace in it. A key generated in a FIPS-validated HSM and a key generated by OpenSSL into a file on a shared build server produce CSRs that are indistinguishable to the CA.

That gap did not matter much until the hardware mandate landed on June 1, 2023, when the Forum made hardware protection compulsory for OV code signing as well as EV. Once the requirement exists, the CA needs a way to check it, and the only honest options are to supply the hardware itself, get the hardware to testify, or get a human to testify that they watched. Those three ideas are what the seven methods reduce to.

The pressure behind the rule is worth remembering when the paperwork feels heavy. Signing keys that sat in files were stolen and used to sign malware that inherited the publisher's good name, and the damage in those cases falls on users who had no way to tell. The rules also bite afterwards: section 4.2.2 bars a CA from issuing a new code signing certificate to an entity it knows has breached the key protection requirements, or that has been the victim of two takeover attacks, unless a software supplier expressly authorises it.

The seven methods a CA may use

Section 6.2.7.4.2 lists seven ways to satisfy the requirement and says one of them must be employed. They are not alternatives you pick from a menu at checkout. The CA decides which it supports and documents that in its certification practice statement, so your real choice is the overlap between this list and the practices of whichever CA you are buying from.

Notice what methods 4, 5 and 6 have in common. None of them asks the hardware to speak. They let a person or a console describe the arrangement instead, which is why a compliant HSM with no attestation interface is an inconvenience rather than a dead end.

Does the hardware you already own qualify?

Two conditions have to hold at once, and buyers usually check only the first. The module must carry a certification at FIPS 140-2 Level 2 or Common Criteria EAL 4+ or better, per section 6.2.7.4.1, and the specific CA you are buying from must accept that model through a method it supports. A drawer full of certified hardware is no use if the CA's process only knows how to read attestations from two vendors.

The device most often brought to this conversation is a YubiKey, and the answer turns on the model. The YubiKey 5 FIPS Series holds a FIPS 140-3 validation at overall Level 2 with Physical Security evaluated at Level 3 — Yubico announced the upgraded series in May 2026 under certificate #5291 — which clears the floor, and its PIV applet can attest to a key it generated. Sectigo documents the enrolment path for customer-owned YubiKeys directly. A standard, non-FIPS YubiKey holds no such validation and does not qualify, regardless of how similar the hardware feels in the hand.

For larger modules the same two-part question applies: Luna network HSMs, comparable on-premises appliances and dedicated cloud HSM tiers are routinely accepted, and the friction is rarely the certificate — it is whether the CA has an intake path for that vendor's attestation format. Check the module's certificate number against the validation programme's own list rather than the datasheet, because vendors frequently validate one firmware revision out of several sold under the same product name. If the standard behind your module has been on your mind lately, the FIPS 140-2 move to NIST's Historical list changed which modules a federal buyer may cite in new procurement, and nothing about whether your token still satisfies this clause.

When your HSM cannot attest

You fall back to a human or a report. Method 6 is the one CAs have productised: an auditor the CA approves watches the key generation ceremony and signs a letter describing what they saw. SSL.com publishes this as Bring Your Own Auditor and lists what the letter must state — that the key was generated in a module certified to at least FIPS 140-2 Level 2, that the module was operating in that mode, that the private key is marked non-extractable and sensitive under PKCS#11, that authentication is required for every use of the key, and that the auditor was present for the entire ceremony with no sign of compromise.

The auditor cannot be a colleague you trust. The CA sets the bar, and SSL.com's wording asks for a certification path from an established security body — the CSBR itself speaks of an auditor approved by the CA with IT and security training, or a CISA. Budget for a scheduled appointment and a professional fee, and for the fact that the ceremony has to happen before the certificate can be issued rather than alongside it.

Method 4, the IT audit route, is quieter and often cheaper for organisations that already sit inside an audit regime. It answers at the level of practice — this company generates code signing key pairs only in suitable modules — rather than per key, so it suits a team issuing several certificates a year. Ask the CA which report formats it accepts before commissioning anything, because a report written for a different framework may not map onto what the CA needs to see.

The route that skips attestation entirely

Method 7 removes the question from your side of the table. Sign an agreement that you will use a Signing Service meeting section 6.2.7.3, and the key is generated and held inside the operator's module, evidenced by the operator's audit rather than by anything you produce. No attestation file, no ceremony, no auditor invoice. Certum's SimplySign, SSL.com's eSigner and DigiCert's KeyLocker all sit in this category, as does Microsoft's subscription-based Azure service.

The detail that rarely gets airtime is the level. Section 6.2.7.3 holds a Signing Service to at least FIPS 140-2 Level 3, a full level above the Level 2 floor that applies to hardware you keep yourself. Whatever else you give up by not holding the key, you are not stepping down in certification terms — the case for custody has to rest on control and jurisdiction, not on the strength of the box.

What you trade is a service dependency and an authentication flow that has to fit your build process, which is the real decision rather than the compliance one. Our comparison of cloud code signing against a USB token walks through what each option does to an unattended build, and code signing in CI/CD pipelines covers the patterns teams use once the key lives somewhere they cannot touch.

Do you attest again at renewal?

At a full-term renewal, expect to. Section 4.2.1 permits reuse of a private key protection validation carried out no more than 13 months before the certificate is issued. Since March 1, 2026 a code signing certificate runs for at most 460 days, which is about two months longer than that window, so a certificate renewed when the old one expires sits just outside the shortcut and the verification is done again.

Where the clause earns its keep is mid-term. A second certificate for another product line, a reissue after a name change, or an early renewal at month ten all fall inside the 13 months, and the CA may lean on the verification it already has. Teams that batch their certificate purchases get more out of this than teams that order one at a time, which is a small argument for aligning renewal dates if you hold several.

One wrinkle to raise with your CA rather than assume: the reuse sentence names methods 4, 5 and 7 of section 6.2.7.4.1, which is the key protection clause, while the verification methods themselves are numbered separately in 6.2.7.4.2. The cross-reference reads oddly against a clause whose current subscriber options are numbered 7 to 9, so ask how your CA applies it before planning a purchase around the shortcut. The renewal rhythm itself follows the 460-day validity cap, which is now the date most publishers diary.

What to settle before you pay

Four questions, asked in the CA's support queue, remove almost every way this goes wrong. Which verification methods do you support? Is my exact module and firmware on your accepted list? What attestation format do you read, and is there a sample? And if I have to go the auditor route, whose credentials do you accept? Getting those answers in writing costs an afternoon and saves the situation where a certificate is paid for and the key cannot be verified.

Order matters too. Generate the key pair and produce the attestation before or during enrolment, never after — a key that already exists outside the module cannot be retrofitted into compliance, and a CA that has issued against the wrong evidence has a revocation problem rather than a support ticket. If the enrolment tooling is unfamiliar, the walkthroughs for what a CSR contains and for the documents a code signing order needs cover the rest of the paperwork that runs in parallel.

And be honest with yourself about why you want custody. Keeping the key in hardware you control is the right answer when policy or jurisdiction demands it, and an expensive habit when it does not. The attestation machinery exists to make that choice possible, not to make it compulsory.