Updated May 2026 | Category: Code Signing / Developer Education / Supply Chain Security / Software Distribution | Reading time: 10 min
Code signing is often described as something Windows desktop application developers need to worry about. That framing is increasingly outdated. If you write software that other people run, on any platform, code signing is relevant to you in ways that have expanded significantly in the past five years.
This article is not about convincing you to buy a certificate. It is about building the foundational understanding of what code signing is, where you will encounter it in your career regardless of what you build, and why the software supply chain security movement of the early 2020s made it relevant to every developer who publishes software to others.
The Outdated Framing: ‘Code Signing Is for Windows Desktop Developers’
The association between code signing and Windows .exe files is not wrong: Authenticode signing for Windows executables is one of the oldest and most visible applications of code signing. But it is far from the only one. Code signing appears across nearly every software distribution context:
- NuGet packages (.NET): The dotnet nuget sign command lets publishers sign packages with a code signing certificate. NuGet.org displays a verified author badge for signed packages. Enterprise NuGet feeds can be configured to require signed packages.
- npm packages (Node.js): npm has introduced package provenance through GitHub Actions integration. Packages published with provenance attestation carry a cryptographic link back to the source code and build environment that produced them.
- GitHub release artifacts: GitHub artifact attestation (GA since 2024) allows developers to create SLSA-compliant provenance for build artifacts directly from GitHub Actions workflows.
- macOS applications: Every macOS application intended for distribution needs a Developer ID Application certificate and notarization. Without these, Gatekeeper blocks installation.
- iOS and Android apps: App store distribution on both platforms requires platform-specific signing certificates. Google Play enforces minimum APK signature scheme versions.
- PowerShell scripts: Environments running under AllSigned execution policy require all scripts to be signed with a code signing certificate.
- Python packages: PyPI is developing package signing infrastructure. The Python packaging community has discussed mandatory signing for critical packages.
- Container images: Cosign (part of the Sigstore project) enables signing of container images in OCI registries. Supply chain security policies in Kubernetes environments increasingly require signed images.
- Linux packages: RPM and Debian packages have supported GPG signing for decades. Package repositories validate signatures before serving packages.
A web developer building a Visual Studio Code extension, a backend engineer publishing a Go module, a DevOps engineer building container images, a Python developer publishing to PyPI: each will encounter code signing or artifact signing in their distribution workflow. The Windows desktop association is a historical artifact of where code signing was most visible, not a description of its actual scope.
Why the Supply Chain Security Era Made This Relevant to Everyone
The supply chain security crisis of the early 2020s changed how the industry thinks about software distribution trust. Before SolarWinds (2020), most developers thought about security in terms of what their code did: vulnerabilities, injection attacks, access control. The question of whether the software artifact itself could be trusted was largely assumed.
The SolarWinds attack inverted this assumption. Attackers compromised SolarWinds’ build environment and inserted malicious code into a signed software update distributed to approximately 18,000 customers. The update carried SolarWinds’ legitimate signature. Every conventional security check passed. The damage (including deep access to US government systems) was substantial before the compromise was detected.
The XZ Utils backdoor in 2024 reinforced the point. A threat actor spent two years building trusted contributor status in an open-source project before inserting a backdoor into its build process. The project was a core dependency of SSH servers across Linux distributions. The backdoor was discovered not through security scanning but through a performance anomaly observed in an unrelated benchmarking test.
These incidents collectively established that supply chain integrity (knowing that software is what it claims to be, produced by who it claims to have been produced by) is a security problem that cannot be assumed away. Code signing is the foundational mechanism for asserting this claim cryptographically.
The software supply chain security movement produced a set of standards and tools that are now becoming baseline requirements for software distribution in regulated and security-conscious environments. SLSA (Supply Chain Levels for Software Artifacts), SBOM (Software Bill of Materials), Sigstore, and GitHub’s artifact attestation all build on or relate to the same underlying concept: cryptographic provenance of software artifacts. Code signing is the foundation that these higher-level frameworks depend on.
Where You Will Encounter Code Signing in Your Career
Code signing knowledge has become practically relevant in a growing number of developer career contexts:
When you distribute software publicly for the first time
Many developers first encounter code signing when they try to distribute software and their users report unexpected warnings. Windows UAC shows ‘Unknown Publisher.’ macOS Gatekeeper blocks the application. An app store rejects the submission. These are the discovery moments that happen after distribution, and they are significantly less painful when you understand code signing before they occur rather than during a release.
When you join or lead a DevSecOps initiative
DevSecOps has moved signing from a distribution step to a build pipeline control. Modern CI/CD security postures include signing build artifacts as part of the pipeline rather than as a post-build manual step. Understanding what code signing is, which artifacts need to be signed, how keys should be protected, and how signed artifacts are verified in deployment is part of a mature DevSecOps practice.
When enterprise customers evaluate your software
Enterprise security reviews of third-party software increasingly include code signing verification as a standard checklist item. Windows Defender Application Control policies in enterprise environments can block unsigned software entirely. IT administrators evaluating your product for deployment want to see signed artifacts and verifiable publisher identity. Encountering this requirement for the first time during a sales process, rather than before it, creates friction.
When you contribute to or maintain open-source software
Open-source projects distributing signed artifacts or requiring contributors to sign commits (GPG-signed commits) are increasingly common in security-sensitive ecosystems. The OpenSSF (Open Source Security Foundation) and CNCF (Cloud Native Computing Foundation) both publish guidance on supply chain security for open-source projects that includes artifact signing. Contributing to or maintaining such projects involves understanding signing infrastructure.
When you work with regulated software
Healthcare, financial services, defense, and government software contexts increasingly have explicit or implicit code signing requirements. Medical device software, financial trading systems, and government contractor software are evaluated under frameworks that consider signing part of baseline security hygiene. Working in these sectors without understanding code signing puts you at a disadvantage during security assessments.
What Every Developer Should Know (The Minimum)
Code signing knowledge exists on a spectrum: there is a minimum foundation that serves all developers and a deeper expertise that serves those building distribution-facing systems. The minimum:
| Concept | Why it matters to every developer |
| What code signing is | Cryptographic commitment from a publisher that a specific artifact was produced by them and has not been modified since. Distinct from TLS/SSL certificates (which authenticate servers, not software artifacts). |
| The signing/verification split | Signing happens with the private key (at build time, publisher only). Verification happens with the public key (at install/run time, by anyone). The private key is the root of trust; its security determines the value of all signatures. |
| Timestamps and expiry | A signature without a timestamp becomes invalid when the signing certificate expires. A timestamp records that the signature was valid at signing time, preserving it after certificate expiry. Always include timestamps. |
| What ‘Unknown Publisher’ means to users | An unsigned or untrusted-certificate signed application shows this warning. It is a barrier to user trust and, in enterprise environments, a blocker to deployment. |
| Where signing fits in the pipeline | Signing is a build pipeline step, not an afterthought. The artifact is signed before distribution, typically in CI/CD. Keys are protected with hardware (tokens or cloud HSMs) and treated as secrets. |
| Platform-specific signing | Windows uses Authenticode with code signing certificates from public CAs. macOS uses Developer ID certificates from Apple. iOS/Android use platform-managed certificates. NuGet/npm/containers use their own signing infrastructure. Platform requirements are separate. |
The Deeper Knowledge for Distribution-Focused Developers
For developers who build and distribute software directly to users or other developers, the minimum above is insufficient. Additional knowledge worth acquiring:
- Certificate selection: OV vs EV, when each is appropriate, the CA/B Forum requirements, and the 460-day validity period that now applies to all code signing certificates.
- Key management: Hardware storage requirements, physical tokens vs cloud HSMs, key rotation planning, and what key compromise means for all previously signed artifacts.
- Pipeline integration: How signing fits into CI/CD workflows, how to handle certificate credentials as pipeline secrets, and how to verify signatures in downstream deployment pipelines.
- SmartScreen and AV reputation: How reputation builds from download telemetry, what accelerates clearance, and how publisher identity continuity across certificate renewals affects reputation.
- Platform-specific requirements: Kernel driver signing on Windows, macOS notarization, app store signing requirements, and the MSIX publisher name matching requirement.
The Practical Gap: What Happens Without This Knowledge
Developers who first encounter code signing during a distribution crisis are at a disadvantage. Common scenarios:
- A developer launches a Windows application. Users report that Windows is warning them about ‘Unknown Publisher.’ The developer doesn’t understand why, doesn’t know what a code signing certificate is, and doesn’t know the timeline for obtaining and deploying one. The launch is degraded while the developer catches up on concepts that could have been learned before release.
- A developer publishes an npm package with dependencies. The package is included in a downstream project. A supply chain attack modifies the package’s registry entry. Without signing or provenance, there is no cryptographic way to detect the modification. With npm provenance, the modified package’s provenance verification would fail.
- An enterprise customer’s IT team reviews software for deployment. The absence of a code signing certificate appears as a finding. The deal slows while the vendor obtains a certificate and rebuilds their distribution, delaying revenue.
- An open-source contributor’s pull request is to a project that requires signed commits. Without GPG commit signing set up, the contribution cannot be merged. The contributor has to retroactively learn GPG signing to participate.
Each of these scenarios is avoidable with foundational knowledge acquired before the crisis rather than during it. Code signing is not an advanced topic reserved for security specialists. It is a foundational aspect of software distribution that every developer who publishes software will eventually need to understand.
Frequently Asked Questions
I only build web applications. Do I need to know about code signing?
For web applications served from a browser, code signing in the Authenticode sense does not apply. However, if you distribute browser extensions, the browser extension stores (Chrome Web Store, Firefox Add-ons, Microsoft Edge Add-ons) all involve signing. If you publish npm packages that others install, npm provenance and package signing are relevant. If you distribute any tooling, CLI applications, or build artifacts alongside your web application, those artifacts may need signing. The more broadly relevant knowledge is the underlying concept: what it means to cryptographically assert that a software artifact was produced by you and has not been modified.
What is the minimum I need to know to get started with code signing for Windows?
For Windows software distribution: understand what an OV code signing certificate is, obtain one from a trusted CA, install signtool.exe from the Windows SDK, sign your executable with a timestamp, verify the signature with signtool verify, and set up certificate expiry monitoring. This covers the essentials for removing the Unknown Publisher warning and building a signed distribution. The more advanced topics (CI/CD integration, cloud HSMs, SmartScreen reputation) become relevant as your distribution scale grows.
Is code signing the same as encrypting my software?
No. Code signing verifies identity and integrity: it proves who produced the software and that it has not been modified. It does not encrypt the software or make it harder to reverse engineer, decompile, or analyze. Code signing is visible: anyone can inspect the signature and certificate details. It is a transparency mechanism (proving authenticity) rather than a security-through-obscurity mechanism.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.