Quale metodo di consegna dei certificati di firma del codice scegliere?

Buying a code signing certificate involves one option that behaves differently from every other field on the order form. Long before validation starts, you have to say where the private key is going to live: on a hardware token the Certificate Authority builds and mails to you, or on hardware you already own and operate. That single choice decides what arrives, how long you wait, what it costs, and how much work you do yourself.

It is also the one option you cannot correct afterwards. Once the order is placed, the delivery method is fixed for the life of that order, so the only way out is to cancel and buy again. This guide covers what each route commits you to, which devices qualify, what the shipping fees are, and how the choice interacts with certificate validity.

Why a Code Signing Certificate Has a Delivery Method at All

SSL/TLS certificates have no equivalent of this question. You generate a CSR on your server, the CA sends back a certificate file, and the private key never leaves the machine it was created on. Code signing stopped working that way on June 1, 2023.

From that date, the CA/Browser Forum’s Baseline Requirements for Code Signing (section 6.2.7.4.1) require every subscriber private key to be generated and protected in a hardware crypto module whose form factor is certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+. A compliant cloud key-protection solution or a qualifying signing service counts as well, but a key sitting in a file on a build machine does not. The practical consequence for buyers is blunt: no CA issues a downloadable .pfx or .p12 for code signing any more.

The rule does not stop at requiring the hardware. Section 6.2.7.4.2 also makes the CA verify that the key really is inside a qualifying device, and it lists the accepted ways of doing that. Two of them are the two options on the order form. Either the CA ships a hardware module carrying a key pair it generated itself, or you counter-sign the certificate request with a manufacturer certificate that proves the key was created non-exportably inside your own device, which is what the industry calls key attestation. Other accepted routes exist, including an IT audit and a configuration report from a cloud key-protection subscription, but the shipped module and the attestation are the two that a normal purchase runs through.

So the delivery method is not a shipping preference dressed up as a technical setting. It tells the CA which compliance path your order takes, and the validation team works to that path from the moment the order is placed. Validation itself is a separate process that runs the same way whichever method you pick, and it has its own guides for Sectigo and Comodo and for DigiCert and GoGetSSL.

The Two Options on the Order Form

Every code signing certificate sold by SSL Dragon, at both OV/IV and EV levels, presents the same configurable option, labeled FIPS-compliant token. It has exactly two answers, one of which is priced by shipping speed and destination. Ordering direct from a CA you may see the same two split further, and DigiCert in particular breaks its own hardware option in two and adds a cloud one, but the underlying decision is the same: does the CA supply the hardware, or do you?

Option	Who it suits	What you receive	Extra cost
Token + Shipping	Most buyers, including anyone who has never signed code before	A pre-configured USB token with the key and certificate already on it, delivered by courier	Shipping fee, priced by CA and destination
I already have a FIPS-compliant token	Teams already running a compliant token or HSM and familiar with its software	The certificate only, installed by you onto your own device	None

Option 1: Token + Shipping

The Certificate Authority generates the key pair inside a compliant USB token in its own facility, installs your issued certificate on the same token, and ships the finished device to the address confirmed during validation. Nothing about the key ever exists outside that token, which is why this route satisfies the Baseline Requirements without you having to prove anything about your own equipment.

This is the option to take unless you have a specific reason not to. You are not asked to own hardware, install driver software before you can start, produce an attestation, or judge whether a device you already have qualifies. When the token arrives you plug it in, enter the PIN supplied with it, and sign.

The trade-offs are the ones you would expect from anything physical. The fee is real money on top of the certificate price. You wait for a courier after validation completes rather than finishing the same day. The token has to reach a specific verified address, which is awkward for distributed teams. And because the key is on a physical object, signing happens wherever that object is plugged in, which is the main reason CI/CD pipelines end up on a different route.

Token and shipping fees

The fee covers the hardware itself plus courier delivery, and it is charged once per order, not per year. The amounts below were taken from the SSL Dragon order form on August 4, 2026 and apply identically to the OV/IV and EV versions of each product. Fees do change, so treat the figure shown on the order form when you configure your certificate as the authoritative one.

Certificate Authority	Shipping option	Fee (USD)
Sectigo and Comodo	Token + Standard Shipping (USA)	$95.00
Sectigo and Comodo	Token + Expedited Shipping (USA)	$147.00
Sectigo and Comodo	Token + International Shipping	$137.00
DigiCert and GoGetSSL	Token + Shipping (USA and International)	$126.00

Two details in that table are worth reading twice. Sectigo and Comodo price international shipping below expedited domestic shipping, so a buyer outside the United States is not paying the highest rate. And DigiCert and GoGetSSL charge one flat fee everywhere, which makes them the cheaper token route from most of the world and the more expensive one for a US buyer who is happy with standard delivery.

Weigh the fee against the term the certificate now carries rather than against the old three-year one. Since the maximum validity dropped to 460 days in March 2026, described in more detail below, a token fee is amortized over roughly fifteen months at most. The delivery choice is made again on each new order, so before renewing, ask support whether the token you already hold can be carried over, since that answer decides whether the fee recurs.

Option 2: I Already Have a FIPS-Compliant Token

Choose this and no hardware ships. You generate the key pair on your own device, submit whatever evidence the CA asks for, and install the issued certificate yourself when it comes back. On the Sectigo and Comodo order forms this route is also described as Install on Existing HSM. Whether you submit a CSR depends on the device and the CA, so read the order form rather than assuming: an HSM order generally needs a CSR generated on the HSM, while a listed USB token is often selected by model with no CSR at all.

The saving is not only the shipping fee. There is no courier leg at all, so issuance finishes as soon as validation does, and the key ends up on hardware your team already administers, backs up and monitors. For an organization that already runs an HSM under an existing key-management policy, adding a code signing key to it is far less disruptive than introducing a USB token that lives in someone’s drawer.

The cost is that everything hardware-side becomes your responsibility. Neither SSL Dragon nor the Certificate Authority supports external HSMs and tokens, so if your device does not produce an attestation the CA accepts, or the certificate will not import, that is between you and the device vendor. The order also stalls until you supply valid evidence, and an attestation that does not match the CSR you submitted is the usual reason a code signing order sits unfulfilled.

Pick this route only if all three of the following are true: you own a device on the supported list below, you are comfortable with its key-generation tooling, and you can produce the attestation material the CA asks for. Owning a YubiKey is not by itself a qualification, since only the FIPS models count.

What the attestation has to prove

Attestation is the device vouching for its own key. The hardware signs a statement, using a manufacturer key burned in at the factory, saying that the key in your CSR was generated inside that device and cannot be exported from it. The CA validates that statement against the manufacturer’s certificate chain, which is how it satisfies the verification requirement without ever touching your hardware.

What the CA expects in practice is a Base64 blob submitted with the order. For a YubiKey that blob is the attestation certificate matching your CSR plus the device intermediate certificate; for a Luna HSM it is a DER-encoded PKCS #7 public key confirmation package. Encoding details matter more than they should, and Sectigo’s attestation service in particular wants the Base64 with no PEM header or footer lines. The exact commands differ by device, and the two sibling guides below walk through the process end to end for the two most common ones:

• Generate a CSR and attestation package on a YubiKey 5 FIPS
• Generate a CSR on a Luna Network Attached HSM
• Install the issued certificate on a YubiKey

Which Devices the Existing-Hardware Route Accepts

The floor is the same for every Certificate Authority, because it comes from the Baseline Requirements rather than from the CA: the device must be certified to FIPS 140-2 Level 2 or Common Criteria EAL 4+ or better. Above that floor each CA maintains its own list of models it has actually tested, and a device that clears the certification bar but is not on the list can still be refused. Check the current list with the CA before you buy, since these lists are revised as models are added and retired.

Sectigo and Comodo

Sectigo’s supported list is longer than it used to be, and older articles on this subject still name only the first two entries. The current list covers:

• YubiKey 5 FIPS Series. The FIPS-certified line only. A standard YubiKey 5 from the same family will not do, because the non-FIPS models carry no FIPS 140-2 Level 2 validation to attest to.
• Thales Luna, both the on-premises network-attached HSM and Luna Cloud HSM, including the Federal Luna variant. The Luna line reached Thales through SafeNet and Gemalto, so older documentation and some product labels still say SafeNet.
• YubiHSM 2, in FIPS-approved mode.
• Entrust nShield.
• Fortanix DSM.
• Google Cloud KMS.

One constraint on that list catches people out. On a YubiKey, Sectigo supports ECC keys only for code signing, so generate ECCP256 or ECCP384 in the PIV application rather than an RSA key. Pick a different device if your build tooling needs RSA.

Sectigo requires an attestation for the device before it will issue against it, which is the step the two CSR guides linked above exist to cover. One trap worth naming: AWS CloudHSM and Azure Key Vault are not on Sectigo’s code signing attestation list, even though Sectigo documents both for document signing, so instructions found for one product do not transfer to the other.

DigiCert e GoGetSSL

These two accept a supported USB token or a qualifying HSM, and they are stricter than Sectigo about it: a certificate cannot be installed on a device that is not on the published list, even if it meets the certification bar. The list is built around the SafeNet eToken 5110 family, identified by Common Criteria part number, and each entry carries its own key-type limit:

• SafeNet eToken 5110 CC (940), for RSA 4096-bit and ECC P-256.
• SafeNet eToken 5110 + CC (940B), for ECC P-256 only.
• SafeNet eToken 5110 + CC (940C), for RSA 4096-bit and ECC P-256.
• SafeNet eToken 5110 FIPS, which DigiCert’s table lists twice, once for ECC P-256 only and once for RSA 4096-bit and ECC P-256.

Two things to take from that. Only RSA 4096 and ECC P-256 appear anywhere in the token table, so do not assume P-384 will be accepted on a token, whatever DigiCert’s older token setup article says about picking a curve. And because one model name appears against two different key types, confirm the exact part number stamped on your device against the key you plan to generate rather than going by the model name alone. You select the model from the Platform menu during the order, and no CSR is needed for the token route.

The HSM route works differently and does need a CSR, generated on the HSM before you submit the order. DigiCert requires a minimum of RSA 3072-bit or ECC P-256 there, and the CSR must carry the BEGIN NEW CERTIFICATE REQUEST and END NEW CERTIFICATE REQUEST tags rather than the more common BEGIN CERTIFICATE REQUEST form. Expect one extra step that is easy to miss: DigiCert emails the requester an agreement about private key protection, and will not issue the certificate until somebody replies to it. If a code signing order looks stalled after validation passed, that email is the first place to look.

Cloud HSMs

A cloud HSM you operate yourself goes through the same existing-hardware option, not a separate one. The Baseline Requirements permit a cloud key-generation and protection solution provided the key is created, stored and used entirely inside the service’s hardware crypto module, and provided the subscription is configured to log all access, operations and configuration changes to the resources holding the key. Sectigo accepts Google Cloud KMS, Luna Cloud HSM and Fortanix DSM on this basis.

This is the route that suits automated build pipelines, since a signing key reachable by an API does not need a USB token plugged into a build server. The logging condition is not optional, though, and the evidence a CA accepts for a cloud subscription may be a configuration report rather than a device attestation, so confirm what your CA wants before you commit an order to it. Note that the CA’s accepted-service list is narrower than “any cloud HSM”, so check the specific service rather than assuming it qualifies.

The Third Route: CA-Operated Cloud Signing Services

There is a way to sign code with no hardware of your own and nothing shipped to you. It does not appear as a third radio button on the SSL Dragon order form for the products above, but it is real, and treating this page’s two options as the whole universe would be misleading.

In a signing service the Certificate Authority generates and holds the private key in its own cloud HSM, and you call the service to sign rather than holding a key at all. The Baseline Requirements treat this as its own compliance path in section 6.2.7.3, and hold it to a higher bar than subscriber hardware: a signing service must protect keys in a module conforming to at least FIPS 140-2 Level 3, against Level 2 for a token or HSM you own, and must require multi-factor or server-to-server authentication before it will sign anything.

Where you meet it depends on the CA. Ordering direct from DigiCert, DigiCert KeyLocker is a fourth provisioning method sitting alongside the shipped token, your own token and your own HSM, chosen at order time with no CSR required, although the option only appears once the account holds a KeyLocker subscription. Each certificate comes with an allowance of 1,000 signatures that you can top up. DigiCert describes KeyLocker as providing FIPS 140-2 Level 3 private key storage, and it is a separate thing from DigiCert Software Trust Manager, the enterprise platform, whose code signing DigiCert deprecated in May 2026 in favor of DigiCert Binary Signing. GoGetSSL sells a Cloud Code Signing product, powered by DigiCert, that needs no token and no shipping. SSL.com eSigner is the equivalent from that CA. Sectigo’s position is different: its documented routes are the shipped token and customer-generated keys, and its cloud coverage comes from you subscribing to a supported cloud HSM under the attestation route rather than from a Sectigo-hosted signing service. Comodo-era Code Signing on Demand material describing a hosted signing service is still reachable on sectigo.com, but it predates the 2023 hardware rules and does not describe what Sectigo sells now.

Two things follow. First, if what you want is signing inside a CI/CD pipeline with no physical object anywhere in the chain, the answer is a cloud signing product, and buying a token-based certificate and then trying to bend it into that workflow is the wrong order of operations. Second, this is a decision about which product to buy, taken before the delivery-method question appears, so it does not rescue an order you have already placed.

How the Choice Affects Certificate Validity

This is where advice on the subject written before 2026 has gone stale, and where two different numbers get confused with each other. Older guidance said a Sectigo or Comodo certificate ran one year on a CA-supplied token but up to three years on your own HSM, while DigiCert and GoGetSSL issued one year either way. The certificate half of that is now obsolete.

CA/Browser Forum ballot CSC-31, adopted in November 2025, amended section 6.3.2 of the Code Signing Baseline Requirements so that a certificate issued on or after March 1, 2026 may not exceed 460 days of validity, roughly fifteen months, down from the previous 39-month ceiling. Certificates issued before that date keep the term they were issued with. Some CAs issue one day inside the limit, at 459 days, so they can never overshoot it, and Sectigo and DigiCert both moved early: Sectigo began enforcing 459 days on February 23, 2026 and DigiCert on February 24, 2026, when it also stopped accepting requests longer than that and removed its 2-year and 3-year options. The change applies to OV and EV alike.

So keep the two numbers apart when you read an order form:

• The product term is what you pay for. It can still be multi-year.
• The certificate validity period is what is written into the certificate, and it is capped at 460 days regardless of anything you choose.

A multi-year order therefore delivers a sequence of certificates reissued inside the term rather than one certificate spanning it, and reissuance is work you have to do rather than something that happens by itself.

The delivery method no longer buys you a longer certificate, then, but at Sectigo it does still affect which product terms are on offer. Sectigo discontinued the multi-year token-based product in February 2026: multi-year terms continue, but only through the customer-generated key route, which means supported hardware and an attestation. Token-based Sectigo code signing is sold as a one-year product, and you can watch the order form enforce that: choose a two-year or three-year Sectigo or Comodo term and the three Token + Shipping choices are disabled, leaving I already have a FIPS-compliant token selected for you. DigiCert dropped its 2-year and 3-year options outright, so its code signing is a single-certificate purchase whichever route you take.

Worth noting in passing that “one year” is now imprecise in both directions. A 459-day or 460-day certificate runs about three months longer than a year, while a three-year order no longer contains a three-year certificate. Read the two numbers separately every time.

Do not read that as a reason to pick your own HSM, though. A multi-year term now implies hardware of your own, but the certificate inside it is no longer than anyone else’s. Pick your own HSM because you already run the hardware, not in the hope of a longer certificate.

One consolation for the shorter term: code you have already signed does not stop being trusted when the certificate expires, provided the signature carried a timestamp from a timestamping authority. The timestamp proves the signature existed while the certificate was valid, so shipped software is unaffected and only your renewal cadence changes.

What “You Cannot Change This Later” Means in Practice

The delivery method is bound to the order, not to your account, so there is no setting to flip once the order exists. If you picked the wrong one, the remedy is to cancel the order through your account dashboard and place a new one with the option you meant, within the refund window. That is recoverable but it costs you the validation time already spent, and SSL Dragon’s published refund policy does not spell out how a token that has already been dispatched is treated, so ask support where you stand before you reorder rather than after.

Five things are worth settling before you configure the order rather than after:

1. Do you already own qualifying hardware? Not “a YubiKey” or “an HSM”, but a specific model on your CA’s supported list. If you are unsure, you do not, and the shipped token is the right answer.
2. Can you produce an attestation from it? Try generating a test key and attestation before ordering, not after. A device that cannot attest cannot be used for this route no matter what it is certified to.
3. Where will the token be delivered? It goes to the address confirmed during validation, and that address has to be one you can receive a courier package at.
4. Who signs, and from where? One developer on one machine is a good fit for a USB token. Several people, or an automated pipeline, is not, and that points to a network HSM, a cloud HSM, or a signing service.
5. Which key type does your tooling need? Relevant only if you are supplying your own device, and easy to get wrong: Sectigo supports ECC keys only on a YubiKey, and some SafeNet eToken part numbers on DigiCert’s list are ECC-only too. Check the model against the key type before you order, not after.

The Hardware Terms Used on the Order Form

Cos’è un token elettronico?

In a code signing context an electronic token, or e-token, is a small USB cryptographic device that generates a key pair inside itself and will never release the private key. It is not the same kind of token as an authentication fob that displays one-time passwords, and the distinction matters here: what you are buying is a key store that performs signing operations on request, not a device that logs you in to something.

Using one is deliberately simple. You plug it in, your signing tool addresses it through a standard interface such as PKCS #11 or the Windows certificate store, and every signature is computed on the token after you supply the PIN. The signed file comes back to your computer; the key stays where it was born. Losing the token or forgetting its PIN means losing the ability to sign, which is why the PIN and any recovery material belong in your password manager the day the token arrives.

What is a hardware security module (HSM)?

An HSM is the same idea at a larger scale: a tamper-resistant device dedicated to generating, storing and using cryptographic keys, built so that keys cannot be read out of it. Where a USB token serves one person at a desk, an HSM is typically a rack-mounted or network-attached appliance serving applications across an organization, with its own access controls, roles and audit log. Finance, government, healthcare and any regulated environment tend to have one already.

The line between the two categories is blurrier than it used to be. A YubiKey 5 FIPS is physically a USB token and the CAs list it under HSM options, while a Luna Network HSM is a network appliance, and a cloud HSM is a service. What they have in common is the property the rules care about, which is that the private key is created inside a certified boundary and cannot leave it.

What the hardware actually protects against

The threat this rule was written for is key theft, and specifically the kind that leaves no trace. A code signing key held in a file can be copied by malware on the build machine, by an insider with filesystem access, or out of a backup, and the owner has no way of knowing it happened. Every signature made with the stolen copy carries the owner’s verified identity, so the attacker’s binary is trusted by Windows as if the publisher had shipped it.

Hardware closes that off in four concrete ways rather than in the abstract:

• The key cannot be copied. It is generated inside the device and marked non-exportable, so there is no file to steal and no second copy to make.
• Signing happens inside the device. Your computer sends a hash in and gets a signature back, so the key is never present in the memory of a machine that could be compromised.
• Physical tampering destroys the key. These devices are built so that opening them or attacking them physically wipes the stored material rather than exposing it.
• Theft becomes visible. Stealing a key now means stealing an object or breaking an access-controlled service, both of which someone notices, which is the difference between a compromise you can respond to and one you never learn about.

It also explains why the CA will not simply email you a key file if you ask nicely. The requirement is on the CA, audited, and it applies to every publicly trusted code signing certificate from every Certificate Authority.

Frequently Asked Questions

Once your hardware is in hand, the next steps are covered in the code signing tutorials.