QCecuring vs Keyfactor SignServer: Enterprise Code Signing Compared (2026)

Keyfactor SignServer is the enterprise-grade, self-hosted signing server that’s been around since 2003 (originally as part of EJBCA). It’s Java-based, runs on WildFly, and gives you complete control over your signing infrastructure — at the cost of managing that infrastructure yourself.

QCecuring Code Signing takes the opposite approach: a managed platform where you define policies and connect HSMs, but don’t operate signing servers. Both solve enterprise code signing, but the operational models are fundamentally different.

This comparison helps you decide: do you want to own and operate your signing infrastructure, or do you want signing-as-a-service with enterprise governance?

Company Backgrounds

Keyfactor (SignServer)

SignServer is developed by Keyfactor (formerly PrimeKey). The product has deep roots in the open-source PKI community — PrimeKey created both EJBCA (the most widely deployed open-source CA) and SignServer (the signing counterpart).

Key facts:

• Founded: 2003 (PrimeKey, Sweden); acquired by Keyfactor in 2021
• Model: Open-source Community Edition + commercial Enterprise Edition
• Architecture: Java 21, WildFly 38 application server
• Latest version: SignServer 7.5
• Deployment: On-premises (self-hosted)
• HSM support: PKCS#11 (Thales Luna, Entrust nShield, AWS CloudHSM, YubiHSM)
• PQ support: Post-quantum HSM integration via Entrust nShield 5c
• License: Community (LGPL) / Enterprise (commercial)

SignServer editions:

QCecuring

QCecuring is an enterprise cryptographic security company focused on certificate and signing lifecycle management. No CA business, no HSM hardware — pure management and policy layer.

Key facts:

• Architecture: Spring Boot + MongoDB + Angular, single JAR deployment
• Model: Managed platform (SaaS or self-hosted)
• HSM support: HSM-agnostic (connects to any PKCS#11 or cloud KMS)
• CA support: CA-agnostic (any certificate issuer)
• Focus: Policy engine, approval workflows, CLM integration

Architecture Comparison

The fundamental difference: SignServer is infrastructure you deploy and operate. QCecuring is a service you configure and consume.

SignServer Deep Dive

Deployment Model

SignServer runs as a Java application on WildFly 38 (formerly JBoss). A production deployment looks like:

# SignServer system requirements
# - Java 21 (OpenJDK or Oracle)
# - WildFly 38
# - PostgreSQL 15+ or MariaDB 10.6+
# - HSM with PKCS#11 driver
# - 4+ CPU cores, 8GB+ RAM per node

# Typical deployment
wget https://signserver.org/download/signserver-ce-7.5.0.zip
unzip signserver-ce-7.5.0.zip
cd signserver-ce-7.5.0

# Configure datasource
cp conf/signserver_deploy.properties.sample conf/signserver_deploy.properties
# Edit: database.name=PostgreSQL
# Edit: datasource.jndi-name=java:/SignServerDS

# Deploy to WildFly
bin/ant deploy

# Configure HSM (example: SoftHSM for testing)
bin/signserver setproperty global WORKER1.CLASSPATH org.signserver.module.cmssigner.CMSSigner
bin/signserver setproperty global WORKER1.CRYPTOTOKEN_CLASSPATH org.signserver.server.cryptotokens.PKCS11CryptoToken
bin/signserver reload 1

This is real infrastructure work. You need:

• Java expertise (JVM tuning, garbage collection, memory management)
• Application server knowledge (WildFly configuration, JNDI, datasources)
• Database administration (backups, replication, performance)
• HSM operations (PKCS#11 driver installation, slot management)
• Network security (TLS termination, firewall rules, load balancing)
• High availability (clustering, session replication, failover)

Signing Workers

SignServer uses a “worker” model — each signing operation type is a configured worker:

# Authenticode signing worker
WORKER1.TYPE=PROCESSABLE
WORKER1.IMPLEMENTATION_CLASS=org.signserver.module.authenticode.AuthenticodeSigner
WORKER1.CRYPTOTOKEN=CryptoTokenP11
WORKER1.DEFAULTKEY=code-signing-key-1
WORKER1.DIGESTALGORITHM=SHA-256
WORKER1.TSA_URL=http://timestamp.digicert.com

# JAR signing worker
WORKER2.TYPE=PROCESSABLE
WORKER2.IMPLEMENTATION_CLASS=org.signserver.module.jarsigner.JArchiveSigner
WORKER2.CRYPTOTOKEN=CryptoTokenP11
WORKER2.DEFAULTKEY=jar-signing-key-1
WORKER2.DIGESTALGORITHM=SHA-256
WORKER2.SIGNATUREALGORITHM=SHA256withRSA

API Usage

# Sign a file via REST API
curl -X POST https://signserver.internal:8443/signserver/rest/v1/workers/AuthenticodeSigner/process \
  -H "Authorization: Bearer ${TOKEN}" \
  -F "file=@./build/app.exe" \
  -o ./build/app-signed.exe

# Sign via CLI
bin/signclient signdocument \
  -workername AuthenticodeSigner \
  -infile ./build/app.exe \
  -outfile ./build/app-signed.exe

Post-Quantum Support

SignServer Enterprise 7.5 supports post-quantum algorithms via Entrust nShield 5c HSM:

• ML-DSA (Dilithium) for signing
• Composite signatures (RSA + ML-DSA hybrid)
• PKCS#11 v3.0 interface for PQ key operations

This is a genuine differentiator — SignServer is one of the first signing platforms with production PQ support through hardware HSMs.

QCecuring Deep Dive

Deployment Model

QCecuring deploys as a single JAR or container — no application server, no complex infrastructure:

# QCecuring deployment (self-hosted option)
docker run -d \
  --name qcecuring-signing \
  -p 8443:8443 \
  -e MONGODB_URI=mongodb://db:27017/qcecuring \
  -e HSM_PKCS11_LIBRARY=/usr/lib/softhsm/libsofthsm2.so \
  -v /etc/qcecuring:/config \
  qcecuring/code-signing:latest

Or use the managed SaaS deployment where QCecuring handles all infrastructure.

Policy Engine

The core differentiator. QCecuring’s policy engine goes beyond “who can sign” to “under what conditions”:

# Policy: Production Windows releases
policy:
  name: "windows-production-release"
  description: "EV-signed Windows binaries for public distribution"
  
  conditions:
    requester:
      roles: ["release-engineer", "ci-service-account"]
      mfa_required: true
    artifact:
      types: ["exe", "dll", "msi", "msix"]
      max_size: "500MB"
      virus_scan: required
    source:
      branch: "release/*"
      pipeline_status: "all-checks-passed"
      commit_signed: true
  
  approvals:
    required: 1
    approvers_from: ["security-leads"]
    auto_approve_if:
      - requester_is: "ci-service-account"
      - artifact_hash_matches: "build-manifest.json"
  
  signing:
    key_alias: "ev-code-signing-2026"
    algorithm: "SHA-256"
    timestamp:
      url: "http://timestamp.digicert.com"
      algorithm: "SHA-256"
    counter_sign: true

SignServer has authorization modules, but nothing approaching this level of conditional logic and approval workflows.

CLM Integration

When you use QCecuring for both code signing and certificate lifecycle management, you get unified visibility:

• Signing certificate expiry alerts (before they expire in CI/CD)
• Automatic certificate renewal workflows
• Single dashboard for all cryptographic assets
• Compliance reporting across signing and TLS certificates

SignServer manages signing operations but doesn’t manage the certificates themselves — that’s a separate Keyfactor product (Command/EJBCA).

Single node → ~100 signatures/second (RSA 2048)
Clustered (Enterprise) → Linear scaling with nodes
Each node: WildFly + DB connection + HSM session

# Typical SignServer upgrade (major version)
# 1. Read release notes for breaking changes
# 2. Test in staging environment
# 3. Backup database
# 4. Stop SignServer
# 5. Deploy new version to WildFly
# 6. Run database migration scripts
# 7. Verify worker configurations
# 8. Test signing operations
# 9. Promote to production

# This process takes 2-4 hours per environment