Venafi CodeSign Protect: Enterprise Code Signing, Explained

A note on the name change

CyberArk acquired Venafi in 2024. The product known for years as Venafi CodeSign Protect is now formally CyberArk Code Sign Manager (current version 25.3 as of late 2025). The technology, components, and operational model are the same. Job descriptions, internal docs, and most enterprise teams still say "Venafi CodeSign Protect" — so we use both names interchangeably here.

If you're searching internal wikis or vendor docs, both names point at the same thing. New documentation lives at docs.venafi.com under the Code Sign Manager - Self-Hosted path.

Why code signing needs its own platform

Most PKI conversations start with TLS — server certs, SAN entries, ACME automation. Code signing is the quieter, higher-stakes neighbor. The blast radius of a compromised TLS key is one site or one fleet of services. The blast radius of a compromised code signing key is every customer who runs your software.

That asymmetry drives every design decision in CodeSign Protect:

• • Keys must never leave hardware. Generation, storage, and signing all happen inside an HSM. Developers never touch raw key material.
• • Every signing operation is auditable. Who signed what, when, against which policy, on which build host.
• • Policy gates the signing flow, not just the key. Approvers, allowed signing tools, allowed file types, allowed times, allowed environments — all enforced server-side.
• • Build pipelines call signing as a service, not as a key checkout.

If you've operated Venafi TLS Protect (now CyberArk Certificate Manager), the mental model is similar but the object graph is different. Code signing has its own primary objects, its own client tooling, and its own compliance regime.

Where CodeSign Protect fits

CodeSign Protect runs on top of Venafi Trust Protection Platform (TPP) — now sometimes called Trust Protection Foundation in newer docs. TPP is the on-prem (or self-hosted in cloud) platform that also hosts TLS Protect, SSH Protect, and the policy engine.

Architecturally, CodeSign Protect adds three things to a TPP install:

1. Code Signing module in the TPP web UI — where you configure environments, projects, and policy.
2. Code Sign Clients — agents installed on signing workstations or build hosts that translate familiar signing tool calls into authenticated API calls back to TPP.
3. Code Signing Time Stamp Service — a TPP-hosted timestamping endpoint (RFC 3161) so signatures remain verifiable after the signing certificate expires.

If your shop already has TPP, adding CodeSign Protect is a license + module enable + HSM provisioning exercise — not a separate platform build-out.

Architecture & components

A working deployment has five moving pieces:

Core concepts: Environments, Projects, Templates, Approvers

These four objects are the day-to-day vocabulary of the platform. Get these right and the rest follows.

The signing flow

End-to-end, a signing operation looks like this:

  [Developer or build agent]
        │  signtool sign /n "ACME Code Signing" myapp.exe
        ▼
  [Code Sign Client]    ── authenticates to TPP using configured creds
        │
        ▼
  [TPP / Code Signing module]
        │  - Resolves the cert/key from the Project
        │  - Evaluates policy: tool allowed? file type allowed?
        │    requester allowed? time window? source IP?
        │  - Routes to approver workflow if required
        ▼
  [HSM]
        │  - Performs the cryptographic operation
        │  - Returns signed hash to TPP (key never leaves HSM)
        ▼
  [TPP]
        │  - Calls Time Stamp Service (RFC 3161)
        │  - Records signing event in audit log
        ▼
  [Code Sign Client]    ── returns signed binary to caller
        │
        ▼
  [signtool exits 0, signed file written]

Key thing to internalize: the developer's command line stays the same. signtool, jarsigner, cosign --key — all unchanged. The Code Sign Client makes CodeSign Protect look like a local key store. That's why teams adopt it: zero workflow disruption for developers, full governance for security.

Code Sign Clients & tool integration

Specifics matter here because integration is where teams most often get stuck.

Windows / Authenticode (signtool.exe, PowerShell). The Code Sign Client installs a CSP and KSP that expose CodeSign Protect-managed keys as if they were local. You select the cert by subject name or thumbprint:

signtool sign /sha1 <thumbprint> /tr http://tsa.example.com /td sha256 /fd sha256 myapp.exe

The thumbprint is for the cert object the Code Sign Client publishes locally — the actual private key lives in the HSM and never touches the box.

Java (jarsigner). Uses the PKCS#11 provider. Configuration is via java.security or a runtime config file pointing at the CodeSign Protect PKCS#11 library:

jarsigner -keystore NONE -storetype PKCS11 \
          -providerClass sun.security.pkcs11.SunPKCS11 \
          -providerArg /path/to/codesign-pkcs11.cfg \
          -tsa http://tsa.example.com \
          myapp.jar "code-signing-cert"

Container & artifact signing (cosign). Cosign supports PKCS#11 via its built-in plugin. Point at the PKCS#11 module and reference the key by URI.

macOS (codesign). The macOS Code Sign Client integrates with the system Keychain. Once installed, codesign --sign "Developer ID Application: ..." MyApp.app works as if the cert were a local Developer ID identity — the actual signing happens in TPP/HSM.

GPG. The GPG SmartCard daemon makes CodeSign Protect-managed GPG keys appear as a smartcard to GPG. git tag -s, gpg --sign, RPM/DEB signing — all unchanged from the user's perspective.

Microsoft signtool with EV. Per CSBR, EV code signing keys must be on attested hardware. CodeSign Protect-fronted HSMs satisfy this when paired with the right CA — the issuing CA validates the HSM attestation, and the cert is issued as an EV cert tied to that hardware.

HSM integration & FIPS levels

The HSM is the trust anchor of the whole system. Two practical points:

1. Pick the FIPS level deliberately. CSBR requires Level 2 minimum for code signing keys. Level 3 adds tamper-active protection and identity-based access — which is what most banks, large ISVs, and any org with a real key ceremony program will use. Level 3 is also what the CA/B Forum strongly prefers in audit reviews.

2. Plan partition strategy before you build. A single HSM appliance can host multiple partitions. A clean deployment isolates by environment (prod / non-prod) and often by sensitivity class (general signing keys / EV keys / internal-only keys). Each Environment in CodeSign Protect maps to one or more partitions.

If you're in the cloud, Azure Dedicated HSM (Thales Luna 7-based, single-tenant) and AWS CloudHSM are the standard CSBR-compliant options. Azure Key Vault Premium uses an HSM backend but the multi-tenant model historically has not satisfied EV code signing CA requirements — verify with your CA before designing around it.

Microsoft Trusted Signing (formerly Azure Code Signing) is the Microsoft-managed alternative — Azure Key Vault Managed HSM backend, SmartScreen-trusted, designed for the 460-day shift away from USB tokens. Different operational model than CodeSign Protect (managed service vs. self-hosted control plane), so most enterprises with TPP already in place will stay on CodeSign Protect; teams without that footprint may find Trusted Signing the simpler path.

CSBR compliance mapping

The CA/B Forum Code Signing Baseline Requirements (CSBR) set the floor for any publicly-trusted code signing certificate. The June 2023 update changed the game: keys now must be generated and stored on FIPS 140-2 Level 2 (or Common Criteria EAL 4+) hardware. No more soft tokens, no more file-based keystores.

Here's how CodeSign Protect maps to CSBR controls:

The last row is where Compliance-in-a-Box comes in — CSBR compliance isn't just hardware and audit logs. You need a Certificate Policy and Certification Practice Statement that document how your code signing program operates, who's accountable, and how exceptions are handled. CodeSign Protect gives you the controls; the documentation is yours to write.

CI/CD & build pipeline integration

Real-world patterns by platform:

The recurring pattern: the build agent has the Code Sign Client and a TPP-bound service identity. Pipeline YAML calls familiar signing tools. CodeSign Protect handles authorization and audit.

Operations: audit, rotation, key ceremony, emergency revocation

Where this fits in your PKI program

CodeSign Protect doesn't stand alone. It's one of several lifecycle protections in a mature PKI program:

• • TLS Protect (now CyberArk Certificate Manager) — server and machine identity certs.
• • SSH Protect — SSH key lifecycle and policy.
• • CodeSign Protect (now Code Sign Manager) — code signing keys and policy.

If you're scoping a Venafi/CyberArk deployment, treat these as separate product modules with separate operational models — staffing, runbooks, and audit programs don't transfer 1:1 between them.

Common pitfalls

A short list of things teams trip on, in rough order of frequency:

1. Treating CodeSign Protect like TLS Protect. Different objects, different workflows. Onboard CodeSign Protect as its own deliverable, not a config tweak on an existing TPP.
2. Putting prod and non-prod signing keys in the same HSM partition. Always separate. Always.
3. Letting build agents share a TPP service account. Per-agent or per-pipeline service identities scale better and audit better.
4. Forgetting the timestamping URL. Without a TSA, signatures stop verifying once the cert expires — the binary effectively rots.
5. Not aligning CP/CPS with what CodeSign Protect actually does. Your audit will land on the gap. Compliance-in-a-Box exists for this.
6. Skipping disaster recovery for signing keys. HSM cluster + offsite backup HSM with synced partition keys, or an explicit "we will not recover, we will reissue" policy in the CP/CPS. Pick one and document it.
7. Trusting EV certs to Azure Key Vault Premium without verifying CA acceptance. Confirm with the issuing CA before designing a pipeline around it.

Quick reference: vocabulary cheat sheet

Related Resources

→ Browse all Venafi guides in the Venafi category