Hardware Token & HSM Selection

Why this choice matters for Signotaur

Three constraints narrow the field:

1. CA/Browser Forum Baseline Requirements (effective 1 June 2023) — publicly-trusted code-signing certificates must have their key pair generated and stored on a device meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+ (FIPS 140-3 Level 2 and above also satisfies this). This is a hard requirement that every major CA (DigiCert, Sectigo, GlobalSign, Entrust) enforces at issuance.
2. RSA 3072 minimum — the same CA/B Forum rules require RSA keys of 3072 bits or larger for publicly-trusted code-signing certificates. Older 2048-bit keys are no longer issued.
3. RSA-only signing paths in Signotaur — many of the formats Signotaur signs today require RSA, not ECDSA.

Mapping Signotaur's supported formats to key algorithm requirements

The formats Signotaur signs today and the key algorithm each accepts:

Bottom line for buyers today: pick a token that supports RSA at 3072 bits or larger. ECDSA-only tokens cannot sign five of the seven formats above. This is a snapshot of current requirements — if Signotaur adds formats in future that natively use ECDSA or Ed25519 (for example Linux kernel module signing, SSH signatures, or Ed25519-based container signing), we'll revise the guide. In the meantime, RSA 3072+ is the universal fallback that covers every current and almost every plausible future signing format.

Quick decision tree

• You need to sign with a certificate from a public CA (DigiCert, Sectigo, GlobalSign, Certum, Entrust, etc.)? → You need a FIPS-certified token or HSM. Skip the non-FIPS sections.
• Signing only for internal/in-house use with a self-signed or private-CA certificate? → FIPS is best practice but not a hard requirement. You have more options, including the non-FIPS YubiKey 5 (firmware 5.7) and Nitrokey HSM 2.
• Single signer or small team? → Physical USB token (SafeNet eToken, YubiKey, Certum), or the compact YubiHSM 2 FIPS if you want a Level 3 FIPS device at a similar price point.
• Team of developers or CI pipeline that needs high availability? → Network HSM (Thales Luna, Entrust nShield) or cloud HSM (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). The YubiHSM 2 FIPS is also a viable mid-tier option without built-in HA.
• Running in AWS / Azure / GCP already? → Cloud HSM in the same cloud typically removes networking complexity and gives you audit trails via the cloud provider.

Testing status

We explicitly test a subset of the devices listed below with Signotaur. For the rest, our assessment is based on the token's PKCS#11 specification compliance and public documentation — Signotaur communicates with any token through the standard PKCS#11 interface, so a device that passes PKCS#11 conformance should work, but we haven't exercised it end-to-end.

• Tested by VSoft with Signotaur:
  • Thales SafeNet eToken (5110+ / 5300)
  • YubiKey 5 and YubiKey 5 FIPS
• Verified in production by Signotaur customers:
  • Certum ProID+ / Certum SmartCard
  • YubiHSM 2 FIPS
• Not tested by VSoft — expected to work via PKCS#11 compliance:
  • Thales Luna Network HSM 7
  • Entrust nShield 5c
  • AWS CloudHSM
  • Azure Dedicated HSM
  • Google Cloud HSM
  • Nitrokey HSM 2
  • SmartCard-HSM (CardContact)

Each per-product section below is tagged with its testing status. If you deploy Signotaur with a "not tested" device and hit issues, we're keen to hear about it — please reach out so we can reproduce and, where appropriate, add the device to the tested list.

Physical USB tokens

Thales SafeNet eToken 5110+ / eToken 5300 — Recommended for public code-signing

Testing status: ✅ Tested by VSoft with Signotaur.

Thales SafeNet eToken 5110+ and eToken 5300 are FIPS 140-2 Level 2 or Level 3 certified PKCS#11 tokens, available with Common Criteria EAL 6+ secure elements. They support RSA up to 4096 bits and ECDSA up to P-521. DigiCert, Sectigo, GlobalSign, and Entrust commonly ship these tokens pre-loaded with EV code-signing certificates.

Pros:

• Vendor-backed and CA-recognised — the default choice for EV code-signing cert issuance.
• Supports RSA 3072 and RSA 4096 (meets CA/B Forum requirements).
• Windows PKCS#11 library (eTPKCS11.dll) is mature and well-supported.

Cons:

• Legacy product line — Thales is transitioning to newer families.

PKCS#11 library path (Windows, typical): C:\Windows\System32\eTPKCS11.dll

YubiKey 5 FIPS Series (firmware 5.4) — Not recommended for new public-CA certificates or renewals; existing certificates remain fully functional

Testing status: ✅ Tested by VSoft with Signotaur.

The YubiKey 5 FIPS Series currently shipping at retail is FIPS 140-2 Level 2 certified on firmware 5.4. At that firmware level, the token supports RSA 2048 and ECDSA (P-256, P-384), but does not support RSA 3072 or RSA 4096. This makes it unsuitable for obtaining a new publicly-trusted code-signing certificate, which today must use RSA 3072+.

Yubico has submitted firmware 5.7.4 (which does support RSA 3072/4096) to NIST's Cryptographic Module Validation Program for FIPS 140-3 Overall Level 2 / Physical Level 3 certification. As of April 2026 that validation is still in the CMVP queue — no firmware 5.7+ FIPS-certified YubiKey is available for purchase.

Pros:

• Affordable, portable, and widely available.
• Mature Windows PKCS#11 support via ykcs11.dll from Yubico.
• Good fit for internal signing, test environments, or continuing to use an existing publicly-trusted certificate.

Cons:

• The shipping FIPS variant cannot sign with RSA 3072 → disqualifies it for new CA/B Forum–compliant public code-signing certificates or renewals.
• No fixed timeline for the 5.7.x FIPS firmware becoming available.

PKCS#11 library path (Windows): ykcs11.dll (installed with the Yubico PIV Tool)

YubiKey 5 Series non-FIPS (firmware 5.7) — OK for internal use; not acceptable for public code-signing

Testing status: ✅ Tested by VSoft with Signotaur (same hardware family as the FIPS variant, firmware differences exercised separately).

The standard (non-FIPS) YubiKey 5 on firmware 5.7 adds RSA 3072 and RSA 4096 support along with Ed25519 and X25519. It's a good token for internal code-signing where FIPS isn't a compliance requirement, but it cannot be used to obtain a publicly-trusted EV code-signing certificate because it doesn't meet the CA/B Forum FIPS 140-2 Level 2 hardware rule.

Certum ProID+ / Certum SmartCard — Bundled with Certum code-signing certificates

Testing status: ✅ Verified in production by a Signotaur customer.

Certum ships a proprietary smart card with its EV code-signing certificates, aimed at the Polish and broader European market. It supports RSA up to 4096. Public FIPS/CC certification documentation is thin compared to the Thales and Yubico lines; if you're buying a Certum certificate this is typically what you'll receive, and it works with Signotaur via Certum's crypto3PKCS.dll. Outside of that bundled-cert use case there's little reason to choose it over a SafeNet eToken.

YubiHSM 2 FIPS — Compact server-side HSM; suitable for public code-signing

Testing status: ✅ Verified in production by a Signotaur customer.

The YubiHSM 2 is a compact USB-form-factor HSM from Yubico — a separate product line from the YubiKey 5 authenticator tokens above. The YubiHSM 2 FIPS variant is FIPS 140-2 Level 3 certified (a step above the Level 2 certification of the smart-card-class tokens) and supports RSA 2048/3072/4096, ECDSA (P-224/P-256/P-384/P-521), Ed25519, and secp256k1. It stores up to ~127 keys in a nano form factor and is designed for server-side signing workloads rather than per-user authentication — which makes it a natural fit for a Signotaur deployment.

Pros:

• FIPS 140-2 Level 3 — higher than the Level 2 FIPS rating of the smart-card-class tokens and acceptable to CAs for EV issuance.
• Supports RSA 3072/4096 at a FIPS-certified level today (unlike the YubiKey 5 FIPS, which is awaiting the 5.7 firmware CMVP certification).
• Confirmed by a Signotaur customer to work end-to-end in production.
• Small form factor — plugs into a server USB port; no rack space required.
• Priced between smart-card tokens and rackmount HSMs (~ USD 650 for the FIPS variant).

Cons:

• No built-in high availability or clustering — redundancy requires manual backup/restore to a second device.
• Management is CLI-driven via yubihsm-shell — less polished than enterprise HSM admin consoles.
• Key attestation for EV certificate issuance: confirm with your CA before purchasing that they accept YubiHSM 2 FIPS attestation.

PKCS#11 library path (Windows): yubihsm_pkcs11.dll (installed with the YubiHSM 2 SDK; configuration file yubihsm_pkcs11.conf points the library at the connected device).

Enterprise on-premises HSMs

Thales Luna Network HSM 7 — Enterprise standard

Testing status: ⚠ Not tested by VSoft. Expected to work via the standard PKCS#11 interface.

A rackmounted network HSM. Luna 7 is the first HSM family to achieve FIPS 140-3 Level 3 validation. Supports every relevant algorithm (RSA 2048/3072/4096, ECDSA, post-quantum candidates) and is the default pick for enterprise PKI.

Pros:

• Highest applicable certification (FIPS 140-3 Level 3).
• Multi-tenant partitioning, HA clustering, audit trail built-in.
• PKCS#11 library is mature and well-documented.

Cons:

• Enterprise pricing (starting around USD 20k+ for a unit, plus support).
• Deployment and care-and-feeding require a dedicated HSM admin.

Entrust nShield 5c — Purpose-built for code-signing

Testing status: ⚠ Not tested by VSoft. Expected to work via the standard PKCS#11 interface.

Entrust nShield 5c is FIPS 140-3 Level 3 certified and explicitly positioned for code-signing workloads. nShield Connect (the predecessor) is still widely deployed at FIPS 140-2 Level 3. Both expose PKCS#11 via the Security World client software.

Cloud-hosted HSMs (via PKCS#11)

Cloud HSMs give you a FIPS-certified key store without managing physical hardware. Signotaur can talk to them through the vendor's PKCS#11 library, the same way it talks to a USB token — you simply point the Library path at the cloud client library instead of a local DLL.

AWS CloudHSM

Testing status: ⚠ Not tested by VSoft. Expected to work via the standard PKCS#11 interface provided by the AWS CloudHSM Client SDK.

FIPS 140-2 Level 3 certified (Thales Luna HSM backend). Single-tenant or cluster-managed. PKCS#11 via the AWS CloudHSM Client SDK.

Azure Dedicated HSM

Testing status: ⚠ Not tested by VSoft. Expected to work via the standard PKCS#11 interface provided by the Luna client.

FIPS 140-2 Level 3 (Thales Luna backend, managed by Microsoft). PKCS#11 via the Luna client installed alongside Signotaur.

Important distinction: Azure Dedicated HSM exposes PKCS#11. Azure Managed HSM and Azure Key Vault do NOT expose PKCS#11 — they're REST-only services. If you want to use Signotaur with Azure-hosted keys via PKCS#11, you need Dedicated HSM, not Key Vault.

Google Cloud HSM

Testing status: ⚠ Not tested by VSoft. Expected to work via the standard PKCS#11 interface provided by Google's Cloud KMS PKCS#11 library.

FIPS 140-2 Level 3. Multi-tenant with optional single-tenant pricing. PKCS#11 is available through Google's Cloud KMS PKCS#11 library.

Open-source / research-grade (internal use only)

Nitrokey HSM 2

Testing status: ⚠ Not tested by VSoft. Expected to work via OpenSC's opensc-pkcs11.dll PKCS#11 module.

Based on the NXP JCOP 4 secure element, which carries Common Criteria EAL 6+ certification at the chip level. Supports RSA up to 4096, ECDSA P-256/P-384/P-521. The Nitrokey HSM 2 is not itself a FIPS-certified product, so public CAs will not accept it as the key-storage device for an EV code-signing certificate.

Good choice for internal PKI or research environments where you want an open-source token without vendor lock-in. On Windows it is driven via OpenSC's opensc-pkcs11.dll.

SmartCard-HSM (CardContact)

Testing status: ⚠ Not tested by VSoft. Expected to work via OpenSC's PKCS#11 module.

Similar story to Nitrokey HSM 2 — modest cost, RSA up to 4096, ECDSA up to 521, accessed via OpenSC. No FIPS certification. Popular with some European CAs as a bundled token.

Summary verdict table

Platform notes

The Signotaur server currently runs on Windows only. Every token and HSM listed above ships a supported Windows PKCS#11 library (.dll), and all of our testing is on Windows. SafeNet, YubiKey, Certum, Nitrokey, and each of the enterprise and cloud HSMs provide signed Windows installers and driver tooling that work with Signotaur out of the box.

Operational gotchas

• Attestation for EV issuance. CAs now require proof that the private key was generated on, and never left, a FIPS-certified device. Tokens shipped by the CA handle this automatically; Bring-Your-Own-HSM usually requires an attestation step using vendor tooling before the cert can be issued.
• FIPS mode must be enabled. Many HSMs (Luna, nShield, AWS CloudHSM) ship with FIPS mode off by default for testing. Public code-signing requires FIPS mode enabled, which often means a one-time admin action at provisioning.
• PIN policy. Some tokens enforce strict PIN policies (length, complexity, retry limits). Signotaur stores the PIN (encrypted) so the service can authenticate to the token unattended — choose a PIN that satisfies both your policy and your incident-response tolerance for rotation.
• Token connectivity. Signotaur runs the PKCS#11 module server-side. The token must be physically connected to (or, for network/cloud HSMs, reachable from) the Signotaur server host. USB tokens on a dev laptop will not work for a server-hosted Signotaur.

Signotaur-specific considerations

• Registration flow. Use the Hardware tab in the Add New Certificate dialog to select the PKCS#11 library path, enter the token PIN, and pick a certificate from those present on the token. Full steps at Hardware Certificates (library.md).
• Library path. The PKCS#11 library .dll must be present on the Signotaur server and reachable by the Signotaur service account. For cloud HSMs this means installing the vendor's Windows client library on the server host first. (When Linux server support ships, .so files will apply too.)
• Enumeration. Signotaur enumerates certificates on the token and greys out any that lack a matching private key or a Code Signing EKU, with a tooltip explaining why.
• Algorithm filtering. Only RSA and ECDSA certificates are accepted at registration. DSA is rejected (see Code Signing Certificates).

Looking ahead

The format set Signotaur signs today is RSA-centric. If and when we add Linux kernel module signing, macOS codesign support, container image signing, or Ed25519-based formats, the token requirements may change — some of those accept ECDSA or Ed25519 keys that an RSA-only token can't produce. We'll revise this guide when that happens. For today's purchase decisions, choose RSA 3072+: that choice covers every currently supported format and remains the universally-accepted fallback for any plausible future one.

Related pages

• Code Signing Certificates — fundamentals of certificate types, key algorithms, and the CA/Browser Forum requirements.
• Hardware Certificates (library.md) — how to register a PKCS#11 token with Signotaur after you've selected one.
• File Certificates and Store Certificates — the non-HSM alternatives.