And What It Actually Takes to Cover Them All

TL;DR

CodeSign Secure signs more than 20 code signing formats across Windows, Apple, Java/Android, Linux, containers, firmware, and virtual appliances, all from one HSM-backed platform with a single RBAC model and M-of-N approval workflow. It natively supports Thales Luna, Entrust nShield, AWS CloudHSM, and Azure Key Vault, so you don’t have to re-architect around a proprietary key store. It also signs with post-quantum algorithms (ML-DSA and LMS) today, not on some future roadmap, and ships a PKCS#11 wrapper so legacy signing tools can keep working against the same HSM. Under CA/Browser Forum Ballot CSC-31, the maximum validity of a publicly trusted code signing certificate drops from 39 months to 460 days on March 1, 2026, which means every one of those formats now needs its certificate touched roughly three times as often as before. Centralizing signing onto one platform is how you handle that without adding headcount.

Why we counted in the first place

Most engineering teams don’t sign in one format. A single product might ship a Windows installer, a macOS app, a container image, and a firmware update in the same release, each signed with a different tool, a different key, and a different person who remembers how it works. That’s fine until the certificate on one of those five tools expires at 2 a.m. and nobody on the current team set it up.

That problem just got more urgent. CA/Browser Forum Ballot CSC-31, adopted November 17, 2025, cuts the maximum validity of a publicly trusted code signing certificate from 39 months down to 460 days, effective March 1, 2026 (CA/Browser Forum). Some CAs are enforcing an even tighter internal cutoff ahead of that date: DigiCert, for example, stops issuing anything longer than 459 days as of February 24, 2026, one day short of the ballot’s own maximum, specifically so it never risks exceeding the limit (DigiCert). So if you’ve seen both “460 days” and “459 days” floating around, that’s why: 460 is the ballot’s ceiling, 459 is one CA’s self-imposed buffer under it. Either way, a certificate that used to last over three years now needs renewing roughly every 15 months, across every format you sign.

That’s the actual reason format count matters. It’s not a vanity metric. It’s a direct count of how many separate places you now have to re-issue, redistribute, and re-test a certificate on a much shorter clock. Below is the full list of what CodeSign Secure signs today, organized by platform.

Quick reference: every format CodeSign Secure signs

Platform	Formats / extensions	Signing tool(s)
Windows	.exe .dll .cab .msi .js .vbs .ps1 .ocx .sys .wsf .cat .msp .cpl .efi .arx .dbx .crx .xsn .deploy .xap .appx/.msix .application .nupkg	SignTool (Authenticode), JSign, PowerShell, Mage (ClickOnce), NuGet, HLK/HCK
Apple	.app .ipa .dmg .pkg .mpkg	codesign, productsign (ProduSign)
Java & Android	.jar .war .sar .ear .apk (v1–v4 schemes)	jarsigner, JSign
Linux	.rpm .deb .xml .asc/.sig, GPG-signed packages	rpm –addsign/rpmsign, GPG2, OpenSSL
Containers	Docker images, OCI images	Docker Notary, Sigstore Cosign
Firmware	.bin .img .hex .fw .dfu	HSM-backed firmware signing
Virtual appliances	.ova .ovf	HSM-backed OVA/OVF signing
Post-quantum	ML-DSA (FIPS 204), LMS (NIST SP 800-208)	PQC detachable signing (.sig files)
Legacy tool bridge	Any PKCS#11-compatible signing tool	PKCS#11 wrapper (Linux, Windows, macOS)

Windows

CodeSign Secure supports Authenticode signing through Microsoft SignTool, the open-source cross-platform tool JSign, PowerShell script signing, Appx/MSIX package signing, ClickOnce manifest signing via Mage/Mage UI, NuGet package signing, and HLK/HCK-certified driver signing (kernel-mode drivers on 64-bit Windows won’t load at all without a valid signature, so this one isn’t optional for driver vendors).

File extensions covered: .exe, .dll, .cab, .msi, .js, .vbs, .ps1, .ocx, .sys, .wsf, .cat, .msp, .cpl, .efi, .arx, .dbx, .crx, .xsn, .deploy, .xap, .appx, .msix, .application, .nupkg, and more.

JSign matters here specifically because it’s Java-based and cross-platform, so a Linux or macOS build agent can produce a valid Authenticode signature without ever touching a Windows machine. If your CI/CD pipeline doesn’t run Windows runners, this is what keeps Windows signing from forcing one on you.

Apple

CodeSign Secure signs macOS, iOS, and watchOS applications and installer packages: .app, .ipa, .dmg, .pkg, and .mpkg, using codesign for apps and disk images. Apple’s Gatekeeper expects every one of these to carry a valid signature before it’ll run without a warning prompt, so this isn’t a nice-to-have either.

Java and Android

Java code-signing certificates sign .jar, .war, .sar, and .ear files through jarsigner. Android APKs (.apk) are signed through the same JarSigner-based flow, and CodeSign Secure supports the full range of Android signing schemes in use today: v1 (inherited from Java JAR signing), v2 and v3 (whole-file APK Signature Scheme), and v4 (the streaming scheme used alongside v2/v3 for incremental app updates). JSign also covers cross-platform Authenticode signing for Java-based build environments that need to produce Windows-valid signatures without a Windows host.

Linux and open source packaging

CodeSign Secure signs RPM packages (rpm –addsign / rpmsign, embedding a GPG key directly in the package header) and Debian packages (.deb), plus GPG2 signing, OpenSSL-based signing, and XML digital signatures (.xml, .asc/.sig). For Debian-based repositories, the repository’s Release file is signed separately from the individual packages, so a package manager can trust the whole repository index rather than checking each .deb one at a time. CodeSign Secure supports both layers.

Docker and container images

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 since. Two approaches are supported, and CodeSign Secure signs from the same HSM in either case:

Docker Notary, the original Docker Content Trust backend. Docker has deprecated Content Trust for its own official images, but plenty of existing pipelines still run on it, and CodeSign Secure keeps signing against it for teams mid-migration.
Sigstore Cosign, which supports either self-managed keys (HSM-backed) or keyless signing through short-lived certificates and a public transparency log.

Cosign binds the signature to the image’s content digest rather than a mutable tag, which is the main security improvement over the original Content Trust model. Supporting both means you’re not forced to migrate your container signing before you’re ready, and you’re not stuck on the deprecated path once you are.

Firmware

CodeSign Secure signs firmware binaries in .bin, .img, .hex, .fw, and .dfu (device firmware upgrade) formats, through the same HSM as every other format on this list. Firmware signing carries more weight than most of these categories because it sits below the operating system: if firmware is tampered with, no OS-level protection catches it. There’s no separate, lower-assurance path for firmware in CodeSign Secure; it goes through the same key protection and approval workflow as everything else.

OVA/OVF virtual appliances

CodeSign Secure signs .ova and .ovf files, the standard packaging formats for virtual machine appliances across VMware and the broader Distributed Management Task Force open virtualization specification, ensuring authenticity and giving downstream consumers a verifiable trail back to the publisher.

Reproducible builds

A reproducible build means compiling the same source with the same build instructions produces the exact same binary, bit for bit, every time. That property lets a third party independently verify that a signed artifact actually came from the source code it claims to, rather than trusting the signature alone. CodeSign Secure’s signing process doesn’t interfere with reproducibility, so teams already building reproducibly can sign without breaking that guarantee. The platform connects with a user’s GitHub repository through the Jenkins CI/CD pipeline, and performs pre- and post-signing hash validation to confirm the artifact hasn’t been altered between submission and return.

Post-quantum signing: ML-DSA and LMS, available now

NIST finalized FIPS 204 (ML-DSA, the Module-Lattice-Based Digital Signature Standard) and FIPS 205 (SLH-DSA, the Stateless Hash-Based Digital Signature Standard) in August 2024. LMS, the stateful hash-based scheme, is standardized separately in NIST SP 800-208 (NIST), and is the algorithm most commonly required for firmware and hardware roots of trust because of its smaller signature size and long track record.

CodeSign Secure supports PQC detachable signing using ML-DSA and LMS today, generating a separate .sig detachable signature file. Whether that PQC signature can be embedded or appended within the artifact depends on the capabilities of the signing tool being used. That matters for the “harvest now, decrypt later” risk model driving PQC migration timelines like CNSA 2.0: an attacker capturing a signed artifact today shouldn’t be able to forge a valid signature on a future artifact once quantum-capable attacks arrive.

PKCS#11 wrapper for legacy tools

Not every signing tool speaks CodeSign Secure’s native API. The platform ships a PKCS#11 wrapper on Linux, Windows, and macOS so tools that already expect a standard PKCS#11 interface — including APK signing, OpenSSL-based signing, XML digital signature tools, JSign, jarsigner, and GPG2/Debian/RPM package signing — can route their key operations through the same HSM without being rewritten. This is the difference between “rip and replace every signing script” and “point your existing scripts at a different key store.”

Works with the HSMs you already run

CodeSign Secure doesn’t require ripping out your existing key infrastructure to get any of the above. It natively integrates with Thales Luna, Entrust nShield, AWS CloudHSM, and Azure Key Vault, so keys stay non-exportable inside FIPS 140-2 Level 3 hardware you may already have deployed, while CodeSign Secure adds the policy layer, audit trail, and format coverage on top.

Frequently Asked Questions

How many file formats does CodeSign Secure support?
More than 20 distinct formats across Windows, Apple, Java/Android, Linux, Docker/container images, firmware, and OVA/OVF virtual appliances, all signed through one HSM-backed platform with a shared RBAC model and approval workflow.

Does CodeSign Secure support post-quantum code signing?
Yes. CodeSign Secure supports detachable post-quantum signatures using ML-DSA (FIPS 204) and LMS (NIST SP 800-208) today, generating a separate detachable .sig file. Whether the PQC signature can be embedded or appended alongside a classical RSA or ECDSA signature on the same artifact depends on the signing tool being used, as not all tools currently support appending PQC signatures.

What changed with code signing certificate validity in 2026?
CA/Browser Forum Ballot CSC-31 cut the maximum validity of publicly trusted code signing certificates from 39 months to 460 days, effective March 1, 2026. Some CAs enforce a slightly shorter internal limit (DigiCert uses 459 days) ahead of that date to stay safely under the cap.

Does CodeSign Secure support Docker Notary and Sigstore Cosign for container image signing?
Yes. CodeSign Secure supports Docker Notary and Sigstore Cosign, accessed through the PKCS#11 wrapper, so teams can keep an existing Notary-based pipeline running or adopt Cosign on their own timeline.

Does CodeSign Secure require replacing our existing HSM?
No. CodeSign Secure integrates natively with Thales Luna, Entrust nShield, AWS CloudHSM, and Azure Key Vault, so existing hardware or cloud key stores can stay in place.

What to do with a signing footprint that already spans three or more of these

If your organization already touches more than two or three of the formats above across different tools, 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, especially with certificate renewal cycles about to triple in frequency.

See how CodeSign Secure centralizes every format above under one HSM, one RBAC model, and one approval workflow, or read our breakdown of what changed with the new code signing certificate validity rules if you’re still mapping out what the 460-day cycle means for your renewal calendar. If you’re comparing signing tools generally before committing to a platform, our code signing tools roundup is a neutral starting point. For teams whose HSM strategy is still an open question, EC’s HSM-as-a-Service is worth a look before, not after, picking a signing platform. And if post-quantum migration timing is the more pressing question, our PQC Advisory team’s 9-phase roadmap is built for exactly that planning stage.

Talk to a code signing specialist about which of these formats apply to your current pipeline, and where the gaps are.

We Counted Every Format CodeSign Secure Can Sign (And What It Actually Takes to Cover Them All)