Self-Hosted HSM and Key Management: SoftHSM vs netHSM vs PKCS#11 Infrastructure 2026

Cryptographic key management is the foundation of any security infrastructure. Whether you’re running a private PKI, encrypting database columns, signing code releases, or securing TLS certificates, the keys that protect your data need to be stored, rotated, and accessed securely. Hardware Security Modules (HSMs) provide tamper-resistant key storage — but dedicated hardware HSMs cost thousands of dollars and require specialized infrastructure.

This guide explores three open-source, self-hosted alternatives for cryptographic key management: SoftHSM (software-based PKCS#11 implementation), netHSM (Nitrokey’s network-attached HSM), and PKCS#11 infrastructure tools for building a software key management layer. These solutions provide HSM-like functionality at zero or low cost, suitable for development, testing, and production environments that don’t require FIPS 140-2 Level 3 certification.

What Is an HSM and Why Self-Host One?

A Hardware Security Module (HSM) is a dedicated device that generates, stores, and manages cryptographic keys. Keys never leave the HSM in plaintext — all cryptographic operations (encryption, decryption, signing, verification) happen inside the device. This prevents key extraction even if the host system is compromised.

Reasons to self-host a software or lightweight HSM:

• Cost: Hardware HSMs (Thales Luna, AWS CloudHSM, Azure Dedicated HSM) cost $5,000-$50,000+. Software alternatives are free
• Development and testing: Reproduce production key management workflows without expensive hardware
• Compliance: Meet regulatory requirements for key separation and access control
• Key lifecycle management: Automated key generation, rotation, and destruction
• Multi-tenant key isolation: Separate key stores for different applications or teams

SoftHSM

SoftHSM is a software implementation of a PKCS#11 cryptographic token, maintained by the OpenDNSSEC project. With over 1,017 GitHub stars and active development, it’s the most widely used open-source software HSM.

SoftHSM implements the PKCS#11 API (Cryptoki), allowing any PKCS#11-compatible application to use it as a key store. It supports RSA, ECDSA, AES, DES, and SHA algorithms, with keys stored in encrypted files on disk.

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

version: '3'
services:
  softhsm:
    image: opendnssec/softhsm:latest
    container_name: softhsm
    volumes:
      - softhsm_tokens:/tmp/softhsm
      - softhsm_config:/etc/softhsm
    environment:
      - SOFTHSM2_CONF=/etc/softhsm/softhsm2.conf
    entrypoint: ["sh", "-c", "softhsm2-util --init-token --slot 0 --label mytoken --pin 1234 --so-pin 12345678 && tail -f /dev/null"]

volumes:
  softhsm_tokens:
  softhsm_config:

Initialize a Token

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Install SoftHSM
apt install softhsm2

# Initialize a token (slot)
softhsm2-util --init-token --slot 0 --label "production-keys" --pin 1234 --so-pin 12345678

# Generate an RSA key pair inside the token
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so   --keypairgen --key-type rsa:2048   --label "web-server-key" --pin 1234

# List keys in the token
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so   --list-objects --type privkey --pin 1234

Configuration File

1
2
3
4
5
6

# /etc/softhsm/softhsm2.conf
directories.tokendir = /var/lib/softhsm/tokens/
objectstore.backend = file
log.level = INFO
slots.removable = false
slots.mechanisms = ALL

Integration with OpenSSL

SoftHSM can be used with OpenSSL via the PKCS#11 engine:

1
2

# Use SoftHSM key for OpenSSL operations
openssl pkeyutl -engine pkcs11   -keyform engine   -inkey "pkcs11:token=production-keys;object=web-server-key;type=private"   -sign -in data.txt -out signature.bin

Key Features

• Full PKCS#11 v2.40 API implementation
• Support for RSA, ECDSA, DSA, AES, DES, SHA-1/256/384/512
• Multiple token (slot) support for key isolation
• PIN-based access control with SO (Security Officer) and User PINs
• Encrypted token storage on disk
• Compatible with OpenSSL, GnuTLS, and any PKCS#11 application

netHSM

netHSM is Nitrokey’s open-source network-attached HSM. Unlike SoftHSM (pure software), netHSM is designed to run on dedicated hardware (Raspberry Pi CM4 with a secure element) but can also run as a software container for development. It provides a REST API for key management, making it accessible from any programming language.

With 100 GitHub stars and active development by Nitrokey, netHSM bridges the gap between pure software HSMs and expensive dedicated hardware.

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

version: '3'
services:
  nethsm:
    image: ghcr.io/nitrokey/nethsm:latest
    container_name: nethsm
    ports:
      - "8443:8443"
    volumes:
      - nethsm_data:/nethsm
    environment:
      - NETHSM_ADMIN_PASS=nethsm-admin-password
    restart: unless-stopped

volumes:
  nethsm_data:

Using the REST API

1
2
3
4
5
6
7
8

# Generate an RSA key
curl -X POST https://localhost:8443/api/v1/keys/my-rsa-key   -H "Content-Type: application/json"   -u admin:nethsm-admin-password   -d '{"mechanisms": ["RSA_SignRawPkcs1"], "type": "RSA", "length": 2048}'

# List all keys
curl -s https://localhost:8443/api/v1/keys   -u admin:nethsm-admin-password | jq

# Sign data with a key
curl -X POST https://localhost:8443/api/v1/keys/my-rsa-key/sign   -H "Content-Type: application/octet-stream"   -u admin:nethsm-admin-password   --data-binary @data.bin   -o signature.bin

PKCS#11 Module

netHSM also provides a PKCS#11 module for compatibility with existing applications:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Install the netHSM PKCS#11 module
apt install libnethsm-pkcs11

# Configure the module
cat > /etc/nethsm/pkcs11.yml << 'EOF'
nethsm:
  - url: https://localhost:8443
    user: operator
    password: operator-password
EOF

# List keys via PKCS#11
pkcs11-tool --module /usr/lib/nethsm/pkcs11/libnethsm_pkcs11.so   --list-objects --type privkey

Key Features

• REST API for key management (generate, list, use, delete keys)
• PKCS#11 module for backward compatibility
• Support for RSA, ECDSA, Ed25519, AES
• Role-based access control (Administrator, Operator)
• Audit logging of all key operations
• Can run on Raspberry Pi CM4 with Nitrokey secure element for hardware-backed security

PKCS#11 Infrastructure Tools

PKCS#11 (Public-Key Cryptography Standards #11) defines a standard API for cryptographic tokens. Building a PKCS#11-based key management infrastructure involves selecting the right components:

Core Components

1. PKCS#11 Provider — the actual cryptographic implementation (SoftHSM, OpenSC, etc.)
2. PKCS#11 Tool — command-line management (pkcs11-tool from OpenSC)
3. PKCS#11 Proxy — network access to local tokens (p11-proxy)
4. Application Integration — OpenSSL engine, GnuTLS PKCS#11 support

OpenSC pkcs11-tool

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Install OpenSC tools
apt install opensc

# List available PKCS#11 modules
pkcs11-tool --list-modules

# Initialize a new token
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so   --init-token --label "backup-keys" --so-pin 12345678

# Generate ECDSA key pair
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so   --keypairgen --key-type EC:prime256v1   --label "tls-signing-key" --pin 1234

# Export public key (for certificate generation)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so   --read-object --type pubkey --label "tls-signing-key"   --pin 1234 > public.key

p11-kit — Unified PKCS#11 Module Loading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Install p11-kit
apt install p11-kit

# List all configured PKCS#11 modules
p11-kit list-modules

# List objects across all tokens
p11-kit list-objects

# Generate keys using p11-kit
p11tool --provider=/usr/lib/softhsm/libsofthsm2.so   --generate --label="new-rsa-key"   --login --set-pin=1234

Comparison Table

Which Should You Choose?

Choose SoftHSM if:

• You need a pure software HSM for development and testing
• You want the most mature and widely supported open-source PKCS#11 implementation
• Your applications already support PKCS#11 (OpenSSL, GnuTLS, Java JCE)
• You don’t need network-accessible key management

Choose netHSM if:

• You want a REST API for programmatic key management
• You need role-based access control (Administrator vs Operator roles)
• You want the option to upgrade to hardware-backed security later
• You’re building a multi-tenant key management service

Choose a PKCS#11 Infrastructure approach if:

• You need to support multiple HSM vendors with a single application interface
• You want to build a custom key management layer on top of standard APIs
• You need fine-grained control over cryptographic operations
• You’re integrating with existing PKCS#11-compatible applications

Why Self-Host Your Key Management Infrastructure?

Cloud-based key management services (AWS KMS, Azure Key Vault, Google Cloud KMS) are convenient but create vendor lock-in and require trust in the cloud provider. Self-hosted HSMs give you full control over key generation, storage, and access policies.

For organizations with compliance requirements (PCI DSS, FIPS 140-2), self-hosted key management ensures keys never leave your infrastructure boundary. Even software HSMs like SoftHSM provide cryptographic isolation that plaintext key files cannot match.

For secrets management alongside key management, the HashiCorp Vault vs Infisical vs Passbolt guide covers application secrets rotation. For certificate automation, the cert-manager vs Lego vs ACME.sh guide covers automated TLS certificate management.

FAQ

What is the difference between an HSM and a key management system?

An HSM (Hardware Security Module) is a physical or virtual device that generates, stores, and uses cryptographic keys. Keys never leave the HSM in plaintext. A Key Management System (KMS) is a broader concept that may include key generation, rotation, backup, and access policy management — it may or may not use an HSM as the underlying key store.

Can SoftHSM be used in production?

SoftHSM is suitable for production use cases that don’t require FIPS 140-2 Level 3 certification. It provides encrypted key storage on disk and PIN-based access control. However, since it runs in software, keys are potentially accessible to anyone with root access to the host system. For high-security environments, a hardware-backed HSM is recommended.

How do I migrate keys from SoftHSM to a hardware HSM?

Keys generated in SoftHSM cannot be directly exported to a hardware HSM because HSMs are designed to prevent key extraction. The recommended approach is to generate new keys on the target HSM and update your applications to reference the new key identifiers. For certificate-based workflows, you’ll need to reissue certificates with the new keys.

What algorithms does netHSM support?

netHSM supports RSA (1024-4096 bit), ECDSA (P-256, P-384, P-521), Ed25519, and AES (128, 256 bit). The supported mechanisms depend on the underlying cryptographic library and can be extended through firmware updates.

How do I backup SoftHSM tokens?

SoftHSM tokens are stored as files in the token directory (configured via directories.tokendir in softhsm2.conf). Back up this directory regularly. The token files are encrypted with the SO PIN, so ensure you have the PIN available for restoration. Test your backup and restore procedure in a non-production environment.

Can multiple applications share the same SoftHSM token?

Yes, multiple applications can access the same SoftHSM token simultaneously using the same PKCS#11 module path. Each application authenticates with the User PIN. For key isolation between applications, create separate tokens (slots) with different PINs.

How does netHSM compare to AWS CloudHSM?

netHSM is an open-source, self-hosted alternative to AWS CloudHSM. While CloudHSM provides FIPS 140-2 Level 3 certified hardware, netHSM offers similar functionality (REST API, key generation, signing) at a fraction of the cost. netHSM on Raspberry Pi hardware with a secure element provides a reasonable middle ground for organizations that need some hardware backing without the $5,000+ cost of certified HSMs.