Which Digital Certificates Require a Hardware Token or HSM

Introduction 

Only a short, closed list of SSL.com certificates requires a hardware token or HSM: code signing certificates and document signing certificates issued at levels that mandate hardware key storage. Every other SSL.com certificate, including S/MIME email certificates at every assurance level, TLS/SSL, and client authentication, supports a customer-supplied CSR and can be issued and downloaded as a PKCS#12 file (.pfx or .p12) 

Getting this distinction wrong has real costs. A business told that its email certificates must live on a USB token may delay rollout, buy hardware it does not need, or abandon secure email altogether. This guide removes that confusion so you can choose the right delivery format the first time and self-serve your download without opening a ticket  

Quick answer 

• Requires a hardware token, HSM, or eSigner cloud HSM: code signing certificates (EV, and OV issued through the token-based path) and document signing certificates at levels that require hardware or HSM issuance. The private key is generated inside the hardware and cannot be exported, so there is no PFX file to download. 

• Supports your own CSR and PFX/P12 download: S/MIME email certificates at every assurance level, TLS/SSL certificates, and client authentication certificates. 

• Rule of thumb: if your certificate signs software or legally significant documents, expect hardware. If it secures a website, email, or user login, expect a file you control. 

Who this guide is for and what each certificate does 

This guide helps anyone who buys, installs, or supports SSL.com certificates decide how a certificate will be delivered before ordering. That includes small business owners who handle their own IT, IT managers, PKI administrators, DevOps engineers, and individual developers. 

Each certificate family protects something different, and that purpose drives its key storage rules: 

• TLS/SSL certificates encrypt traffic to websites, APIs, and servers and prevent browser security warnings that drive visitors away. 

• S/MIME (email) certificates encrypt and digitally sign email so recipients can trust the sender and the message has not been altered. SSL.com offers S/MIME products at multiple validation levels, including mailbox-validated, organization-validated (OV), individual-validated (IV), and combined IV/OV. 

• Client authentication certificates prove the identity of a user or device when logging in to a network, VPN, or application. 

• Code signing certificates (OV and EV) prove that software comes from a verified publisher and has not been tampered with since signing, which reduces operating system and antivirus warnings at install time. 

• Document signing certificates apply trusted, verifiable signatures to PDFs and other documents, giving them legal and evidentiary weight. 

Code and document signing certificates carry the highest impersonation risk: a stolen key lets an attacker publish malware or sign contracts in your name. That is why industry rules require their keys to stay in certified hardware. 

How key storage works 

Where the private key is created decides whether you can ever hold it as a file. Every certificate is paired with a private key, and the delivery format follows from where that key is generated. 

Customer-generated key (CSR path). You generate a key pair on your own server or workstation and send SSL.com a Certificate Signing Request (CSR) containing only the public key. SSL.com validates your request and returns the signed certificate. The private key never leaves your system, so you can install it on your web server or bundle it with the certificate into a PKCS#12 file. 

PKCS#12 (.pfx / .p12) delivery. A PKCS#12 file is a password-protected container that holds the certificate, its private key, and usually the intermediate chain. It is the standard format for importing a certificate into Windows, macOS Keychain, Outlook, Apple Mail, browsers, and many servers. This format is available only when the key is exportable. 

Hardware token or HSM. For code signing, the key is generated inside a FIPS-validated USB token (such as a YubiKey or a Thales/Gemalto SafeNet token) or a hardware security module, and the device is built so the key cannot be copied out. The CA/Browser Forum key storage requirement for code signing took effect June 1, 2023, ending software-based PFX delivery for those certificates. The Code Signing Baseline Requirements name FIPS 140-2 Level 2 (or equivalent) as the minimum; most hardware sold today carries FIPS 140-3 validation instead of, or alongside, FIPS 140-2. 

eSigner cloud signing. eSigner applies the same non-exportable principle using SSL.com’s cloud HSM. Your key is generated and stored in the HSM, and you sign remotely through a web app, CLI, API, or CI/CD integration, so there is no physical token to ship and no PFX to download. 

Table 1: Products that require a hardware token or HSM 

This is a closed list. If a product is not in this table, it does not require a token. 

Table 2: Products that support your own CSR and PFX/P12 download 

Every SSL.com product outside Table 1 is CSR- and PFX-eligible. No hardware token is required. 

Optional hardware is still your choice. You may store an S/MIME or client authentication key on a smart card or token for extra protection, but SSL.com does not require it and the certificate remains available as a PFX/P12. 

Step by step: choose and complete the right delivery path 

Prerequisites 

• An SSL.com account and a certificate order (or the product you plan to buy). 

• For the CSR path: access to the server or workstation where the certificate will be used, plus OpenSSL, IIS Manager, Keychain Access, or a similar tool to generate the key pair. 

• For the token path: a supported FIPS-validated token (YubiKey or Thales/Gemalto SafeNet) or an attested HSM. 

• For the cloud path: an eSigner enrollment on your certificate order. 

• Completed validation for your certificate type (domain, mailbox, individual, or organization). 

Steps 

Identify your product family. Check whether your certificate appears in Table 1. If it is a TLS/SSL, S/MIME, or client authentication certificate, proceed to Path A.  If it is a code signing certificate or a document signing certificate at a hardware-required level, go to Path B. 

1. For TLS/SSL, S/MIME, and client authentication certificates 

1. Generate a CSR, or let SSL.com generate the key. For TLS/SSL, S/MIME, and client authentication, create a key pair and CSR on your own system and paste the CSR into your order. Keeping the key on your own system means it is never transmitted. 
2. Download and install. After validation, download the certificate. If you need a single portable file for Windows, macOS, Outlook, or a load balancer, download or build a PKCS#12 (.pfx / .p12) file and protect it with a strong password.
    

1. For code and document signing certificates

1. Choose hardware or cloud key storage. For code and document signing, pick one: 
2. Hardware token: SSL.com ships a pre-provisioned token, or you generate the key on your own supported token and submit attestation. 
3. Your own HSM: generate the key on a FIPS-validated HSM and provide the attestation SSL.com requires. 
4. eSigner cloud signing: enroll in eSigner and sign from the web app, CLI, API, or CI/CD pipeline, with no hardware to manage. 
5. Sign, don’t export. Point your signing tool (SignTool, jarsigner, Adobe Acrobat, or the eSigner tools) at the token, HSM, or eSigner credential. Do not look for a PFX download for these products; none exists because the key is non-exportable. 

Common questions 

Do S/MIME certificates have to be on a hardware token? No. S/MIME certificates at every assurance level support a customer-supplied CSR and are downloadable as PKCS#12 (.pfx / .p12) 

Can I get my TLS/SSL certificate as a PFX? Yes. TLS/SSL certificates support your own CSR and PFX/P12 delivery, which makes it easy to move a certificate between Windows servers or into a load balancer. 

Why can’t I download a PFX for my code signing certificate? Because the private key was generated inside a token, HSM, or eSigner’s cloud HSM and is designed never to leave it. Industry rules have required hardware key storage for code signing since June 1, 2023.  

I have an older code signing PFX from before 2023. Is it still valid? A previously issued certificate stays usable until it expires or is revoked, but renewals and new orders follow the hardware rule. 

Can I sign code without buying a physical token? Yes. eSigner cloud signing keeps your key in SSL.com’s cloud HSM and lets you sign from anywhere, including automated build pipelines.

Conclusion 

The rule is simple: only code signing and hardware-level document signing certificates require a token or HSM, and everything else, including every S/MIME level, ships with your own CSR and a downloadable PFX/P12. Knowing this before you order avoids unnecessary hardware purchases, speeds up email and website deployments, and sets the right expectations for software and document signing timelines. 

For the products that do require hardware, that requirement works in your favor. A non-exportable key cannot be copied, emailed, or leaked from a build server, which protects your brand from signed malware and forged documents. And with eSigner cloud signing, you get that protection without managing physical devices. Whatever you are securing, SSL.com gives you a delivery path that is compliant, practical, and built for your workflow.