We Counted Every Format CodeSign Secure Can Sign

Ask a release engineer how many signing tools their organization runs and watch them actually stop and count on their fingers. Signtool for the Windows installer. Jarsigner for the one Java service nobody wants to touch. Whatever the mobile team wired up for APKs. A GPG key somebody set up for the Debian repository three engineers ago, and nobody’s fully sure who still has it. That’s not a hypothetical. That’s the average signing footprint at any company that has shipped software across more than one platform for more than two years, and it’s the reason code signing keeps ending up in incident post-mortems that have nothing to do with the code itself.

Here’s the part that makes this urgent right now instead of “someday”: the CA/Browser Forum’s Ballot CSC-31 just cut the maximum validity of publicly trusted code signing certificates from 39 months down to 460 days, effective March 1, 2026. Every scattered signing key an organization has, every USB token sitting in a drawer, every certificate nobody remembers issuing, now needs to be touched roughly three times as often as it did eighteen months ago. Fragmented signing wasn’t a great idea before that ballot passed. It’s an operational liability now.

So we want to answer the question we get asked in almost every CodeSign Secure evaluation call for an enterprise code signing solution: “okay, but does it actually cover our stack?” Below is the honest, specific answer, format by format, with enough technical detail that you can check it against your own release pipeline rather than take our word for it.

Enterprise code signing solution, defined: a centralized platform that generates and stores private signing keys inside HSM-backed hardware, enforces role-based, multi-approver sign-off on every signing request, and produces valid signatures across every format an organization ships, rather than leaving each team to sign with its own local keys and tools.

Key Takeaways

• CodeSign Secure signs 20+ formats, Windows, Apple, Java/Android, Linux, cloud-native, PKCS#11-wrapped, and post-quantum, from one FIPS 140-2 Level 3 HSM-backed platform.
• One RBAC model and one M-of-N approval workflow govern every signing request, regardless of format.
• CA/Browser Forum Ballot CSC-31 cut public code signing certificate validity from 39 months to 460 days, effective March 1, 2026, tripling how often scattered signing keys need reissuing.
• CodeSign Secure supports detachable post-quantum signatures (ML-DSA, LMS) alongside classical RSA/ECDSA signing on the same artifact, so PQC adoption is additive, not a rip-and-replace migration.
• Deployment options include on-premises, cloud, and hybrid HSM models; see the Prerequisites and Known Limitations sections further down before you evaluate.

The Short Version

CodeSign Secure signs more than 20 distinct formats from one HSM-backed platform: Windows binaries and scripts (Signtool, JSign, PowerShell, Appx/MSIX, ClickOnce via Mage, NuGet, HLK/HCK driver signing), Apple binaries, Java and Android artifacts (jarsigner, JSign, APK), Linux and open-source packages (OpenSSL, XML, GPG2, Debian, RPM), cloud-native artifacts (containers, OVA/OVF, firmware), reproducible builds, PKCS#11-wrapped HSM signing, and detachable post-quantum signatures (ML-DSA, LMS). One role-based access control (RBAC) model and one M-of-N approval workflow govern all of it. That last part is the actual point, not the format count. A platform that signs twenty formats through twenty different trust boundaries hasn’t solved the fragmentation problem; it’s just given it a longer feature list.

Want the full map before the details? Here it is.

Category	Formats/Tools Covered	File Extensions
Windows	Signtool (Authenticode), JSign, PowerShell scripts, Appx/MSIX packages, ClickOnce manifests (Mage/Mage UI), NuGet packages, HLK/HCK-certified drivers	.exe, .dll, .sys, .msi, .cab, .ps1, .appx/.msix, .application, .nupkg
Apple	macOS, iOS, and watchOS applications	.app, .ipa
Java & Android	JAR files (jarsigner), cross-platform Authenticode via JSign, APK packages	.jar, .apk
Linux & Open Source	OpenSSL-based signing, XML digital signatures, GPG2, Debian packages, RPM packages	.rpm, .deb, .xml, .asc/.sig
Cloud-Native & Infrastructure	Container/OCI images, OVA/OVF virtualization files, firmware images	N/A (content digest), .ova/.ovf, firmware binaries
Supply Chain Integrity	Reproducible builds	N/A (build attestation, not a single file type)
Post-Quantum	PQC detachable signatures (ML-DSA, LMS)	.sig (detached)
Hardware Interoperability	PKCS#11 wrapper signing for third-party and legacy tools	N/A (protocol-level, not file-specific)

Now let’s go through what’s actually behind each row, because “we support X” means nothing without the “why it matters” attached to it.

Windows: Where Most Signing Programs Are Born, and Where Most of Them Stall

If your organization signs anything, it almost certainly started with Windows, and it’s usually where the sprawl starts too. Microsoft’s signtool.exe is the reference tool for Authenticode signing, the scheme Windows uses to trust PE files: .exe, .dll, .sys, .msi, .cab, and catalog files. The catch is that Signtool only runs on Windows, and the second your build pipeline includes a Linux container or a mixed CI/CD fleet, that stops being a minor inconvenience and starts being the reason someone keeps a lone Windows VM alive just to sign things. JSign, an open-source cross-platform Authenticode tool written in Java, exists specifically to close that gap, and CodeSign Secure uses it as one of its signing engines so Linux and macOS build agents can produce valid Authenticode signatures without ever spinning up that VM. The private key stays in a FIPS 140-2 Level 3 HSM the entire time, whether the request comes in through Signtool or through JSign.

PowerShell scripts get the same treatment. If your execution policy requires a valid Authenticode signature on every .ps1 file (and it should), CodeSign Secure signs those scripts through the HSM and leaves them verifiable with a plain Get-AuthenticodeSignature call, no signing key ever touching the machine that runs the script.

Then there’s the packaging layer, which is where most Windows signing setups quietly fragment into three or four separate workflows: Appx and MSIX packages, which Windows won’t install without a certificate chaining to a trusted root whether you’re shipping through the Store or sideloading; ClickOnce, the .NET self-updating deployment model whose trust runs on signed manifests generated through Microsoft’s Mage and Mage UI tools (and whose signing keys have a bad habit of ending up in a developer’s local certificate store instead of anywhere a security team can see them); and NuGet packages, which have supported Authenticode-based signing since NuGet 4.6 and really should carry a trusted timestamp so the signature outlives the certificate. CodeSign Secure handles all three the same way it handles the binary itself: one HSM, one audit trail, no exceptions for “it’s just a manifest.”

And then there’s the format that quietly terrifies hardware vendors: HLK/HCK driver signing. Getting a driver certified through the Windows Hardware Lab Kit (the successor to the older Hardware Certification Kit) means submitting signed packages to Microsoft’s Windows Hardware Dev Center, and kernel-mode drivers on 64-bit Windows simply will not load without a signature from a certificate that meets Microsoft’s current EV or hardware-backed key requirements. A rejected HLK submission over a signing technicality costs a hardware team real time. CodeSign Secure supports signing against those requirements directly, which is the difference between a submission that clears review and one that bounces back with a note nobody wants to read.

Apple: One Ecosystem, One Stricter Rulebook

Apple runs a tighter ship than Windows on this front. codesign and Gatekeeper expect every macOS, iOS, and watchOS binary to carry a signature from an Apple Developer certificate, and macOS adds a second check on top through notarization before Gatekeeper will let a user open the app without a warning dialog talking them out of it. The common failure mode here isn’t a missing signature; it’s an Apple Developer ID sitting in an individual engineer’s keychain instead of anywhere a team can rotate or revoke it. CodeSign Secure signs macOS, iOS, and watchOS apps through the standard Apple flow while keeping those certificates in the same HSM-backed vault as every other platform key, so “the person who owns the Apple signing certificate” stops being a single point of failure tied to one laptop.

Java and Android: The Stack Everyone Assumes Someone Else Is Signing

Every enterprise has at least one internal Java service that’s been quietly running since a JVM the current team barely remembers. jarsigner, shipped with the JDK, signs the JAR files those services depend on so a JVM (or a user) can confirm the archive hasn’t been tampered with and, when the manifest includes it, who actually published it. CodeSign Secure signs JAR files through its normal centralized flow, which matters mostly because JAR signing keys are exactly the kind of credential that gets set up once, forgotten, and never rotated. JSign shows up again here too, letting Linux- and macOS-based CI/CD runners request Windows-format signatures without a dedicated Windows signing host just for that one pipeline stage.

Android is its own story. Every APK has to be signed before installation, and the scheme has evolved four times: v1 (inherited straight from Java’s JAR signing), v2 and v3 (whole-file signing schemes Android introduced in versions 7.0 and 9 specifically to close gaps v1 left open, binding the signature to the exact APK contents instead of just the manifest), and v4 (a streaming scheme used alongside v2/v3 for incremental app updates). CodeSign Secure signs across all of these through APKSigner, routed through its PKCS#11 wrapper on Linux, Windows, and macOS build agents alike, so a mobile release meets current Google Play requirements without a separate, unmanaged mobile signing tool living outside everything else.

Linux and Open Source: The Ecosystem With the Most Signing Conventions, Not the Least

If anyone tells you Linux signing is “just GPG,” they haven’t dealt with RPM, Debian, and repository-level signing as three genuinely different conventions. RPM-based distributions sign with rpm –addsign (or rpmsign), embedding a GPG key directly in the package header. Debian-based packages get signed through tools like dpkg-sig or during the build via debsign. And APT repository metadata, the Release file itself, is signed separately so a package manager can trust an entire repository rather than verifying packages one at a time. Three conventions usually means three GPG keyrings scattered across build infrastructure, each with its own idea of who’s authorized to use it. CodeSign Secure centralizes all three under one key management layer instead.

Two more Linux-adjacent formats round this out. OpenSSL signing covers the cases packaging tools don’t: raw hashes, custom data structures, arbitrary files that need a detached signature and don’t fit a standard package format. CodeSign Secure supports OpenSSL-based signing (dgst -sign and CMS workflows) so those artifacts don’t fall back to “whoever has a local key file handy.” And XML digital signatures, the W3C-standardized XML-DSig format underneath SAML assertions, SOAP messages, and a fair amount of regulated document exchange, get signed to that same specification when a compliance or B2B integration requirement specifically calls for it.

Cloud-Native and Infrastructure: Where Signing Strategies Are Youngest, and Most Likely to Be Skipped

This is the category most legacy signing tools were never built for, and it shows.

Container image signing attaches a cryptographic signature to an image so anyone pulling it can verify who published it and confirm it hasn’t been altered. The ecosystem has mostly converged on two approaches: Sigstore’s Cosign, which supports self-managed keys (HSM-backed included) or keyless signing through short-lived certificates and a public transparency log, and Notation, built on the CNCF Notary v2 specification, which uses PKI-based trust policies and is what Microsoft AKS and Amazon EKS recommend for enterprise Kubernetes. Both bind the signature to the image’s content digest rather than a mutable tag, which is the whole reason tampering is detectable at all. CodeSign Secure signs against these current standards, not the Docker Content Trust model Docker itself has already deprecated for official images.

OVA and OVF signing does the same job for virtual machine appliances, the standard packaging formats across VMware and the broader Distributed Management Task Force open virtualization specification, so a team can verify a VM appliance’s integrity before it goes anywhere near production.

Firmware signing matters more than any of these because firmware sits below the operating system. A compromised firmware image survives an OS reinstall and walks straight past most endpoint security tooling. Signed firmware, checked against a secure boot chain, is the control that stops a modified image from loading in the first place, and it’s exactly the kind of long-lived, high-blast-radius key that should never live in a build script or a vendor’s local tool. CodeSign Secure signs firmware through the same HSM as everything else on this list, no exceptions.

Reproducible Builds: Proving the Binary Actually Matches the Source

A reproducible build means compiling the same source with the same instructions produces the exact same binary, bit for bit, no matter who builds it or when. That property lets someone outside your organization independently rebuild a release and confirm what you shipped actually matches what you published, which is about as strong a defense against a compromised build pipeline as exists right now. CodeSign Secure supports signing workflows built around reproducible build practices, so the signature on a release artifact is tied to a build process that can be checked, not just trusted because the vendor said so. For how this connects to broader supply-chain attestation, see Strengthening Supply Chain Security with SLSA Level 3 and Code Signing.

Post-Quantum Signing: The One Most Teams Aren’t Thinking About Yet

Here’s an uncomfortable fact: every RSA and ECDSA signature backing code signing today is exactly the kind of thing a sufficiently capable quantum computer would break. NIST didn’t leave this theoretical. FIPS 204 (ML-DSA, the Module-Lattice-Based Digital Signature Standard) and FIPS 205 (SLH-DSA, the Stateless Hash-Based Digital Signature Standard) were finalized in August 2024, alongside the stateful hash-based LMS and XMSS schemes specified in NIST SP 800-208. CodeSign Secure supports PQC detachable signing using ML-DSA and LMS, meaning a post-quantum signature can sit alongside, or instead of, a classical RSA/ECDSA signature on the same artifact. Nobody has to rip out their existing signature scheme to start this. That’s the entire value of “detachable”: crypto-agility you can start building into a pipeline today instead of during a scramble later. It’s also where this connects to a bigger question most teams haven’t answered yet, which is simply knowing which signing algorithms are actually in use across their environment in the first place. That’s a CBOM Secure conversation more than a code signing one, but the two start from the same inventory.

PKCS#11: Making Sure Legacy Tools Don’t Become the Excuse

A huge amount of existing signing tooling, especially anything older, was written directly against PKCS#11, the standard cryptographic API most HSMs and smart tokens expose. Rather than making every one of those tools someone’s problem to replace, CodeSign Secure presents itself as a PKCS#11 provider, so existing scripts and third-party tools that expect direct hardware access keep working exactly as written. The difference is what happens behind that interface: every signing operation still routes through CodeSign Secure’s centralized policy, logging, and approval layer instead of talking to raw hardware unsupervised.

In practice, the PKCS#11 wrapper is what CodeSign Secure’s own signing engines ride on top of, and it runs across every major build platform:

• APK signing — Linux, Windows, and macOS
• OpenSSL-based signing — Linux and Windows
• XML digital signatures — Linux and macOS
• JSign-based signing — Linux, Windows, and macOS
• Jarsigner (JAR) signing — Linux, Windows, and macOS
• GPG2, Debian, and RPM package signing — Linux

How CodeSign Secure Is Architected

Strip away the per-format detail above and the architecture is the same for every one of them: a hardware root of trust, a set of signing engines that speak each format’s native tooling, and a policy layer that every request has to clear before a key operation happens.

• Hardware root of trust: private keys are generated and held in a FIPS 140-2 Level 3 HSM, deployed on-premises, in the cloud, or as a hybrid of both, so the key material itself never leaves validated hardware regardless of format.
• Format-specific signing engines: Signtool and JSign for Authenticode, jarsigner and APKSigner for Java/Android, codesign for Apple, and Cosign/Notation-aligned signing for containers, each calling out to the HSM rather than holding a local key copy.
• PKCS#11 interoperability layer: a PKCS#11 provider interface lets existing scripts and third-party tools that expect direct hardware access keep working unmodified, while every call still routes through the policy layer below.
• Centralized policy and approval layer: RBAC and M-of-N multi-approver workflows sit in front of every signing engine, so one compromised build credential can’t produce a trusted signature on its own.
• Integration points: CI/CD pipeline plugins, an API/CLI, and the PKCS#11 interface above cover the ways build systems typically request a signature; confirm the exact supported CI/CD platforms and OS versions for your environment against CodeSign Secure’s current deployment documentation before finalizing an architecture.

Security Controls Behind Every Signature

The format list matters less than what happens underneath it. Every signing event, no matter which of the 20+ formats above triggers it, passes through the same set of controls:

• Key custody: private keys are generated and remain inside a FIPS 140-2 Level 3 HSM; no format’s signing engine gets a local copy of the key.
• Role-based access control: who can request a signature, for which format, and under which certificate, is defined per role rather than per individual credential.
• M-of-N approval: higher-risk signing operations (a new HLK driver submission, a firmware image, a production container) can require sign-off from a defined quorum of approvers rather than a single developer’s say-so.
• Centralized, immutable audit trail: every signing event across every format lands in one log, the control most fragmented signing setups are missing entirely, rather than one log per tool (or no log at all).

What You Need Before You Deploy an Enterprise Code Signing Solution

None of the above works without a few things in place first. Before evaluating or deploying a centralized signing platform, confirm you have:

• An HSM that meets FIPS 140-2 Level 3 (on-premises, cloud, or via HSM-as-a-Service if you don’t already operate one).
• Build agents or CI/CD runners for every platform you sign for (Windows, Linux, macOS) that can reach the signing platform’s API, CI/CD plugin, or PKCS#11 interface.
• Certificates issued from a CA appropriate to each use case: a publicly trusted CA for Authenticode and Apple Developer signing, and, where policy allows, an internal CA for internal-only Java, XML, or package-repository signing.
• An identity source (existing directory or IdP) to map named approvers into the RBAC and M-of-N approval workflow.
• For container signing specifically, a registry that supports OCI signature attachment so Cosign- or Notation-style signatures bind to the image digest.

Exact supported operating system versions, CI/CD platforms, and network requirements vary by deployment model; confirm the current list against CodeSign Secure’s deployment documentation or with your evaluation contact rather than assuming from this post alone.

Known Limitations

An honest coverage list includes what centralizing signing does not do, not just what it does:

• Centralizing the key doesn’t remove the need for platform-native tooling to prepare the artifact first. Xcode’s toolchain for Apple notarization submission, the Windows Hardware Lab Kit’s packaging tools for driver certification, and similar tools still run on the build agent; CodeSign Secure supplies the trusted key operation, not the packaging step.
• An on-premises deployment still requires the organization to provide or connect a FIPS 140-2 Level 3-capable HSM (or consume it as HSM-as-a-Service); CodeSign Secure is a signing and policy layer, not a replacement for the HSM itself.
• The PKCS#11 wrapper is documented above for six specific workflows (APK, OpenSSL, XML, JSign, jarsigner, and GPG2/Debian/RPM signing); a legacy tool outside that list should be confirmed directly with CodeSign Secure’s team before you assume coverage.
• Detachable PQC signing adds a second signature alongside the classical one; it doesn’t remove or replace the RSA/ECDSA signature your existing clients still verify against today, so treat it as additive crypto-agility, not a completed migration.

Here’s the Part We’d Actually Tell You in a Call

The number of formats a signing platform supports is not the interesting number. We say this in almost every evaluation conversation, and it surprises people less experienced with the space than you’d think. The interesting number is how many of an organization’s signing keys currently sit outside a single, HSM-backed control plane, each with its own access list, its own audit trail (or complete lack of one), and its own renewal calendar that nobody’s tracking centrally.

That number just got a lot more expensive to ignore. Under the new 460-day maximum validity window, every one of those scattered keys needs reissuing and redeploying roughly three times as often as it did before March 2026. A manual, per-tool signing workflow that was merely annoying eighteen months ago is now something that eats real engineering time every single quarter, and it’s worst for anyone still shipping physical USB tokens around for signing rather than routing through a networked or cloud HSM.

So the fix isn’t picking whichever tool has the longest feature list on its website. It’s making sure every signing format an organization actually uses sits behind one HSM, one RBAC model, and one M-of-N approval workflow, so a compromised build server or a phished developer account can’t produce a trusted signature no matter which of the twenty-plus formats above it tries.

Evaluation Checklist for an Enterprise Code Signing Solution

Use these questions, in order, when comparing a centralized signing platform against your own list of formats and tools:

1. Does every format you actually ship route through one HSM-backed trust root, or does the format count hide a separate key store per tool?
2. Is RBAC and M-of-N approval enforced across every format, or only on the handful IT set up first?
3. Can you pull an audit trail for one specific signing event on demand, across any format, without checking a second or third tool’s logs?
4. Does the platform support detachable post-quantum signing today, or is that still “on the roadmap”?
5. Does the deployment model, on-premises, cloud, or hybrid, match your HSM ownership and data-residency requirements?
6. For any tool your teams rely on that expects direct PKCS#11 hardware access, does the vendor publish exactly which workflows are supported today, rather than a generic “PKCS#11 compatible” claim?

Independent Validation

Don’t take the format list on this page as the only evidence. Cross-check it against sources outside Encryption Consulting:

• ABI Research named CodeSign Secure among the code signing market leaders in its independent market assessment; see ABI Research Names CodeSign Secure Among the Code Signing Market Leaders.
• The certificate-validity change driving this post’s urgency is documented directly by the standards body: CA/Browser Forum Ballot CSC-31: Maximum Validity Reduction.
• The post-quantum signature standards referenced above, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), are published directly by NIST, not summarized secondhand.
• Encryption Consulting’s own security posture (ISO/IEC 27001:2022, SOC 2, PCI DSS) is documented on the Trust Center, independent of any single product’s claims.

If You Made It This Far

Twenty-plus formats isn’t a vanity metric; it’s just an honest reflection of how many different ways a modern software organization actually ships things: code, scripts, packages, containers, firmware, and now post-quantum signatures, often out of the same release pipeline. The teams that get hurt aren’t the ones missing a signing tool. They’re the ones running six of them, each with a key sitting somewhere nobody’s watching, right as certificate lifespans got three times shorter.

If your own signing footprint already touches more than two or three of the formats above, that’s usually the point where consolidating onto one HSM-backed platform stops being a someday project and starts being the thing standing between a routine release and a very bad week.

See how CodeSign Secure centralizes every one of these workflows: explore the CodeSign Secure platform.

Frequently Asked Questions

Does CodeSign Secure require a different HSM for each signing format?

No. Every format CodeSign Secure supports, from Authenticode to container images to PQC detachable signatures, runs through the same centralized HSM infrastructure, deployed on-premises, in the cloud, or as a hybrid, so an organization manages one hardware trust root instead of one per tool.

Can CodeSign Secure sign both classical (RSA/ECDSA) and post-quantum signatures on the same artifact?

Yes. CodeSign Secure supports detachable PQC signatures using ML-DSA and LMS alongside classical signing, so a post-quantum signature can be added to a release without removing the classical signature clients still depend on for verification.

Why does HLK/HCK driver signing need a dedicated workflow instead of standard Authenticode signing?

Windows Hardware Lab Kit submissions carry their own certificate and submission requirements tied to Microsoft’s Windows Hardware Dev Center, and kernel-mode drivers on 64-bit Windows won’t load without a signature meeting those specific requirements, so the signing workflow has to match Microsoft’s driver certification process rather than generic Authenticode rules.

Is Docker Content Trust still a supported way to sign containers?

Docker has deprecated Content Trust for official images, and current practice has moved to Sigstore Cosign or Notation (Notary v2), both of which bind signatures to an image’s content digest. CodeSign Secure signs against these current standards rather than the deprecated model.

What changed with code signing certificate validity in 2026?

Under CA/Browser Forum Ballot CSC-31, the maximum validity for publicly trusted code signing certificates dropped from 39 months to 460 days, effective March 1, 2026, significantly increasing how often certificates need reissuing, particularly for organizations still relying on physical hardware tokens instead of centralized HSM signing.

What do I need before deploying an enterprise code signing solution like CodeSign Secure?

At minimum, a FIPS 140-2 Level 3 HSM (on-premises, cloud, or as a service), build agents or CI/CD runners for each platform you sign for, appropriately issued certificates for each use case, and an identity source to map approvers into the RBAC and M-of-N workflow. Exact supported OS versions and CI/CD integrations should be confirmed against current deployment documentation.

Does centralizing code signing remove the need for platform-specific signing tools?

No. Tools like Xcode’s toolchain for Apple notarization or the Windows Hardware Lab Kit’s packaging tools for driver certification still run on the build agent to prepare the artifact. CodeSign Secure changes where the private key lives and how the signing request is authorized, not the platform-native packaging step itself.