QCecuring vs DigiCert Software Trust Manager: Code Signing Compared (2026)

DigiCert Software Trust Manager is being deprecated on May 1, 2026. If you’re using it today, you have a forced migration ahead — either to DigiCert’s replacement (“DigiCert Binary Signing”) or to a platform that doesn’t tie your signing infrastructure to a single CA.

This comparison breaks down what DigiCert Software Trust Manager offered, what its replacement looks like, and how QCecuring Code Signing takes a fundamentally different approach to enterprise code signing.

The Deprecation Reality

DigiCert announced that Software Trust Manager reaches end-of-life on May 1, 2026. The replacement product is DigiCert Binary Signing — a rebuilt signing service within the DigiCert ONE platform. If you’re currently on Software Trust Manager, you need to migrate regardless. The question is: migrate to DigiCert’s new product, or migrate to something CA-agnostic?

Timeline:

• Now: Software Trust Manager still functional but no new features
• May 1, 2026: Official deprecation — no new enrollments
• Late 2026: Expected end of support (exact date TBD)
• DigiCert Binary Signing: Available now as the replacement

This forced migration is the right time to evaluate whether CA-bundled signing still makes sense for your organization.

Architecture Comparison

The architectural difference is fundamental. DigiCert’s model is vertically integrated: they issue the certificate, they store the key, they perform the signing. QCecuring’s model is horizontally integrated: bring your own CA, bring your own HSM, and QCecuring provides the policy layer and orchestration.

DigiCert Software Trust Manager: What It Was

Software Trust Manager was DigiCert’s enterprise code signing platform within DigiCert ONE. It provided:

Key Features

KeyLocker (Cloud HSM) DigiCert’s cloud-hosted HSM service for storing code signing private keys. Priced at approximately €85.50/year for a single key slot. Keys never leave DigiCert’s infrastructure — signing operations happen server-side.

# DigiCert KeyLocker signing via smctl
smctl sign --keypair-alias my-key \
  --input ./build/app.exe \
  --signature-algorithm SHA256

OpenSSL and Notation Plugins Software Trust Manager provided plugins for OpenSSL (PKCS#11 provider) and Notation (for container image signing):

# OpenSSL plugin for DigiCert KeyLocker
openssl dgst -sha256 -sign \
  "pkcs11:token=DigiCert;object=my-key" \
  -out signature.bin payload.bin

# Notation plugin for container signing
notation sign --plugin digicert-stm \
  --id my-key-id \
  registry.example.com/app:v1.0

CI/CD Integration GitHub Actions, Azure DevOps, and Jenkins plugins that wrapped the signing API:

# GitHub Actions example (DigiCert STM)
- name: Sign Windows Binary
  uses: digicert/stm-sign-action@v1
  with:
    keypair-alias: production-signing-key
    input-file: ./dist/installer.exe
    certificate-fingerprint: ${{ secrets.DC_CERT_FP }}

Limitations That Led to Deprecation

1. CA lock-in: Only DigiCert-issued certificates worked with KeyLocker
2. Limited HSM options: Cloud HSM only — no BYOK for on-premises HSMs
3. Monolithic architecture: Tightly coupled to DigiCert ONE’s older service mesh
4. No policy engine: Signing was binary — you either had access or you didn’t
5. Pricing opacity: Per-operation costs on top of certificate and KeyLocker fees

DigiCert Binary Signing: The Replacement

DigiCert Binary Signing is the successor product. Early documentation suggests:

• Rebuilt on modern microservices architecture
• Continued KeyLocker integration (cloud HSM)
• Expanded signing format support (Authenticode, macOS, APK, NuGet)
• Better API design with OpenAPI 3.0 specs
• Still requires DigiCert-issued certificates for full functionality

The fundamental model hasn’t changed: it’s still a CA-bundled signing service. You sign with DigiCert certificates stored in DigiCert’s HSM using DigiCert’s API.

QCecuring Code Signing: The CA-Agnostic Approach

QCecuring takes the opposite architectural stance. The platform doesn’t issue certificates and doesn’t host HSMs. Instead, it provides:

Policy Engine

Define who can sign what, when, and under what conditions:

# QCecuring signing policy example
policy:
  name: "production-release-signing"
  conditions:
    - requester_role: ["release-engineer", "build-system"]
    - artifact_type: ["exe", "dll", "msi"]
    - branch: "main"
    - ci_pipeline_status: "passed"
  approvals:
    required: 2
    approvers: ["security-team"]
    timeout: "4h"
  signing:
    algorithm: "SHA-256"
    timestamp: true
    timestamp_server: "http://timestamp.digicert.com"

No equivalent exists in DigiCert Software Trust Manager or Binary Signing. DigiCert’s access control is “does this API key have permission to use this keypair?” — there’s no conditional logic, no approval workflows, no artifact-type restrictions.

HSM Agnosticism

QCecuring connects to whatever HSM infrastructure you already have:

DigiCert KeyLocker is a single cloud HSM option. If your security policy requires on-premises key storage or a specific HSM vendor, KeyLocker doesn’t work.

CA Agnosticism

Use code signing certificates from any CA:

• DigiCert EV code signing certificates
• Sectigo EV/OV code signing certificates
• GlobalSign code signing certificates
• Internal CA-issued certificates (for internal binaries)
• Any CA that issues code signing certificates

QCecuring manages the certificate lifecycle (renewal, revocation monitoring) regardless of issuer. DigiCert Software Trust Manager only managed DigiCert-issued certificates.

# GitHub Actions with DigiCert Binary Signing
name: Sign Release
on:
  push:
    tags: ['v*']

jobs:
  sign:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup DigiCert Signing
        uses: digicert/binary-signing-setup@v1
        with:
          api-key: ${{ secrets.DIGICERT_API_KEY }}
          certificate-id: ${{ secrets.DIGICERT_CERT_ID }}
      
      - name: Sign Binary
        run: |
          smctl sign --keypair-alias prod-key \
            --input ./dist/app.exe

# GitHub Actions with QCecuring Code Signing
name: Sign Release
on:
  push:
    tags: ['v*']

jobs:
  sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Request Signing
        uses: qcecuring/sign-action@v2
        with:
          api-token: ${{ secrets.QCECURING_TOKEN }}
          policy: "production-release"
          artifacts: |
            ./dist/app.exe
            ./dist/app.dll
            ./dist/installer.msi
          metadata:
            version: ${{ github.ref_name }}
            commit: ${{ github.sha }}
            pipeline: ${{ github.run_id }}