Do I Need a Code Signing Certificate?

What a code signing certificate actually does

A code signing certificate does two jobs at once. It stamps your software with a cryptographic signature that ties the file to a verified organization — yours — and it lets the operating system detect if a single byte changed after you signed. When Windows checks that signature, it can show your real company name instead of "Unknown Publisher," and it can refuse to run a file that was modified in transit. That is the whole value: not a new feature in your app, but a chain of trust from you to the person double-clicking the installer.

The certificate itself comes from a certificate authority that browsers and operating systems already trust. You prove your organization is real, the CA issues the certificate onto approved hardware, and you use it to sign your builds. From then on, anyone who downloads your software can verify — automatically, without contacting you — that it came from you and arrived intact.

One clarification up front, because it trips people up constantly: this is not the padlock certificate on your website. That is a TLS/SSL certificate, and it secures a connection, not a downloaded file. If you want the difference in one line, an SSL certificate vouches for a site; a code signing certificate vouches for a file.

Who needs a code signing certificate

You need one when your software leaves your organization and lands on machines you don't control. The common thread across every "yes" case below is the same: a stranger's computer has to decide whether to trust your code, and without a signature it defaults to suspicion. If any of these describe you, plan on a certificate.

• You distribute a Windows desktop app or installer. Anything users download as an EXE or MSI benefits immediately: your name replaces "Unknown Publisher," and Microsoft Defender SmartScreen has a verified identity to build reputation against.
• You ship command-line tools, PowerShell scripts, or Java applications. Signed PowerShell can run under stricter execution policies, and a signed JAR carries a verifiable publisher. Both reach users who will be warned — or blocked — without a signature.
• You sign Windows kernel-mode drivers. This is a hard requirement, not a nicety: modern Windows won't load an unsigned driver, and the submission path needs an EV certificate to get started.
• You sell software into enterprises. Corporate deployment tools and security policies routinely reject unsigned executables outright. A signature is often the difference between a smooth rollout and a stalled procurement review.
• You publish updates. Auto-updaters that pull new binaries should verify each one is signed by you, so a compromised download server can't push malware to your users under your name.

In our experience running code signing for resellers, the publishers who skip it rarely regret it on day one — they regret it the first time a support queue fills with "Windows says this is from an unknown publisher, is it safe?" messages. Signing is cheaper than that conversation, repeated.

When you don't need one

Plenty of projects don't need a publicly trusted code signing certificate, and it's worth being honest about that before you spend money. If your situation is on this list, a certificate would sit unused. Buying one anyway is a common early mistake we see in support tickets.

• You run a website and nothing else. A site needs a TLS/SSL certificate for HTTPS, full stop. There is no downloaded executable for an operating system to check, so code signing simply doesn't apply.
• Your software only runs on machines you control. For internal line-of-business tools, you can distribute trust through your own internal CA or Group Policy. A public certificate adds cost without adding anything your own environment can't already provide.
• You're shipping a Mac or mobile app. These use Apple's or the app stores' own signing, covered below — a CA-issued code signing certificate won't help and won't be accepted.
• You distribute exclusively through a managed store. If your only channel is the Microsoft Store, Mac App Store, or a Linux package repository, the store's own signing and review typically covers you.

If the tree above lands you on "no cert needed," you're done — don't let anyone upsell you a certificate your distribution model never uses. If it lands you on a platform system, the next section explains which one.

Platform by platform: Windows, macOS, Java, and mobile

"Code signing" means different things on different platforms, and a certificate that's essential on one is useless on another. The single most common misunderstanding we field is a developer buying a Windows-style code signing certificate to sign a Mac app. Here's what each target actually requires.

Windows is the platform this certificate is built for. Signing an EXE, MSI, DLL, or PowerShell script with a publicly trusted certificate is exactly what removes "Unknown Publisher" and gives SmartScreen an identity to trust. Java applications and signed JARs use the same kind of certificate. If you want the mechanics, our guide to signing an EXE with SignTool walks through it end to end.

macOS is different, and this is the trap. Apple does not trust certificates from public certificate authorities for signing Mac software. To distribute a Mac app outside the App Store you need an Apple Developer ID certificate — issued only to members of Apple's paid Developer Program — and you must notarize the app by sending it to Apple for an automated malware scan. Since macOS 10.15, Gatekeeper expects both signing and notarization. None of that uses a Certum or Sectigo code signing certificate, so if you're Mac-only, this guide's certificate isn't what you need.

iOS and Android handle signing through their own ecosystems — Apple's provisioning and, for Android, app signing keys managed with the Play Console. And Windows kernel-mode drivers sit in their own category: they need an EV certificate purely to register for Microsoft's submission process, after which the driver is signed through Microsoft rather than directly. Our Windows driver signing guide covers that path.

If you need one, is it OV or EV?

Once you've decided you need a certificate, there's a second, smaller decision: the validation level. There are two, OV (Organization Validation, usually sold as "standard") and EV (Extended Validation). For most publishers the answer is now OV, and the reason is a change many buyers still haven't caught up with.

For years, EV's selling point was that it skipped the SmartScreen warning instantly. Microsoft removed that shortcut in 2024, so as of 2026 both OV and EV earn SmartScreen reputation the same slow way — through real download history. That leaves only two solid reasons to pay the EV premium: you're registering to sign Windows kernel-mode drivers, or an enterprise customer's procurement policy names EV specifically. Everyone else can use standard OV and get the same end-user experience for less. We break the whole comparison down in EV vs OV code signing, and if the "Unknown Publisher" prompt is your main worry, the guide to fixing that warning explains exactly what signing does and doesn't change.

What getting one involves: hardware, cost, and time

A code signing certificate is not quite a buy-and-download purchase anymore, so it helps to know what you're signing up for before you commit. Three things shape the process today, and all three trace back to the same push to make signing keys harder to steal.

The key lives on hardware. Since June 1, 2023, every publicly trusted code signing certificate — OV and EV alike — must have its private key generated and stored on hardware certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, and the key can't be exported. In practice that means a USB token shipped by the CA, your own compliant HSM, or a cloud signing service. The old software-only PFX file you could copy onto a build server is gone for public code signing. For automated builds, the cloud signing versus USB token trade-off is the decision that matters most.

Validation takes time. Because the certificate vouches for your organization, the CA verifies you're a real, registered business — checking company records and, for EV, more. Budget days, not minutes, for a first issuance, and add shipping time if a physical token is involved. Plan around that so a launch date doesn't hinge on validation you started too late.

Certificates now renew roughly yearly. Under CA/Browser Forum ballot CSC-31, certificates issued on or after March 1, 2026 are capped at 460 days — about 15 months — down from the old 39-month maximum (some CAs began enforcing a 459-day cap slightly earlier). So build a renewal habit, and always timestamp your signatures: a timestamped signature stays valid after the certificate expires, so software you've already shipped keeps verifying. Cost varies by validation level and key delivery, and prices move, so confirm current figures with your CA or reseller rather than a number in an old post.

FAQ