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: “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.

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.

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

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.

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.

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.

Not ready for that conversation yet? Start smaller: read how the 2026 certificate validity change affects your renewal cycle in Understanding the New Code-Signing Certificate Validity Change, then come back when you’re ready to talk about mapping your signing footprint before your next renewal forces the issue anyway.