Ask most development teams whether they do code signing, and the answer is yes. Ask whether they have a centralized signing policy, a documented key management procedure, an audit trail of every signing event, and an automated process that handles certificate renewals before they expire and the answer gets more complicated.
The gap between “we sign code” and “we have a mature code signing program” is wider than most organizations realize. And in 2026, that gap is more consequential than ever. Supply chain attacks are at record levels, and as per the Verizon 2026 Data Breach Investigations Report, analyzing over 22,000 confirmed breaches across 145 countries, found that third-party involvement now accounts for 48% of all breaches, a 60% increase from the previous year.
CA/Browser Forum Ballot CSC-31 has reduced code signing certificate validity from 39 months to 460 days, effective March 1, 2026. NIST released an initial public draft of SSDF Version 1.2 (SP 800-218 Revision 1) in December 2025, raising the bar for what constitutes demonstrably secure software development. And regulators across sectors are moving from guidance to enforcement.
We will look into a practical Code Signing Maturity Model: four stages that describe how organizations evolve from fragmented, ad hoc signing practices to fully automated, policy-governed, and future-ready programs. Wherever your organization is today, understanding where you stand and what the next stage looks like is the starting point for getting there.
Why Code Signing Maturity Matters More Than Ever
Code signing exists for a single, fundamental reason: to give software users and platforms a way to verify that a binary was produced by a known, trusted party and has not been modified since it was signed. When it works correctly, it is the primary mechanism through which software identity is established and software integrity is assured.
When it fails, could be because a signing key is stolen, a certificate is used without authorization, or a signing operation happens outside of any governance framework, the consequences can be severe and far-reaching.
Let’s look at one of the most significant supply chain attacks in recent history to see exactly what happens when code signing is abused:
3CX (2023): The North Korea-linked Lazarus Group executed a cascading supply chain attack in which a compromised financial software package led to the compromise of 3CX’s build environment. The 3CX desktop application, used by approximately 600,000 organizations, was then signed with 3CX’s own legitimate certificate and distributed to customers as a routine update. Neither the signature nor the certificate was fraudulent. The signed artifact itself was malicious.
This attack shares an important lesson: a valid signature on malicious code is not a security control failure at the cryptographic level; it is a governance and process failure. Neither the key nor the certificate was stolen or forged. The signing process simply had no controls that would have prevented an attacker who had already reached the build environment from triggering a signing operation.
What Is a Code Signing Maturity Model?
A maturity model is a framework that describes how a capability evolves from initial, informal practice to fully optimized operation. The Capability Maturity Model (CMM), originally developed by Carnegie Mellon’s Software Engineering Institute, established the foundational pattern, which required organizations to progress through defined stages, each representing a higher level of process discipline, repeatability, and resilience.
Here are all the criteria’s that matter for code signing maturity:
| Dimension | What It Covers |
|---|---|
| Key Management | How private signing keys are generated, stored, protected, and rotated |
| Access Control | Who can sign, what they can sign, and what oversight governs that access |
| Policy and Governance | Whether signing policies are documented, enforced, and reviewed |
| Certificate Management | How certificates are tracked, renewed, and revoked across the organization |
| Pipeline Integration | Whether signing is embedded in CI/CD workflows or performed manually |
| Audit and Monitoring | Whether every signing event is logged, reviewed, and anomalous events are alerted |
| Incident Response | Whether the organization has a plan for compromised keys or unauthorized signing |
| Future Readiness | Whether the program accounts for post-quantum cryptography and evolving standards |
The Four Stages of Code Signing Maturity
Stage 1: Ad Hoc — Signing Without Structure
The first stage is where most organizations where code signing just happens, but it is not managed as a proper dedicated system. This includes:
- One or a small number of developers hold the code signing certificate and private key, often stored on a local machine, a USB token, or as a file on a shared build server.
- There is no formal policy documenting who is authorized to sign, what can be signed, or under what conditions signing should proceed.
- Certificate expiry is tracked informally where a developer remembers (or doesn’t) and renewal is reactive, often prompted by a signing failure rather than proactive management.
- If asked “what did you sign last quarter?”, the answer would require manually searching through build logs, if those logs and audit trail exist at all.
- Signing is a manual step, performed by a developer when it comes time to prepare a release and not integrated into any automated pipeline.
- There is no plan for what happens if the certificate is compromised or the developer who holds the signing key leaves the organization.
At this stage, the signing infrastructure is essentially unprotected. Private keys in software-accessible locations are vulnerable to any attacker who reaches the developer’s workstation or the build server. There is no separation of duties, the same person who writes code can sign it without any independent review. There is no visibility into signing events, so unauthorized signing would go undetected. And because there is no documented policy, there is nothing to audit against.
This is the environment that attackers exploited in SolarWinds and 3CX attacks. Not sophisticated zero-day attacks against the cryptographic algorithms but unguarded access to the signing step in an unmonitored build environment.
Stage 2: Defined — Policies Exist, But Gaps Remain
Organizations at Stage 2 have recognized that ad hoc code signing is a risk and have taken steps to formalize it. There is a policy document, and keys are stored more securely. But the practices are not consistently enforced, and gaps remain, particularly in automation, audit coverage, and certificate lifecycle management. This stage has the following:
- A written code signing policy exists, describing key storage requirements, who is authorized to sign, and how certificates should be managed. However, compliance with the policy is inconsistent as it is enforced through awareness and convention rather than technical controls.
- Private keys have been moved off developer machines. Keys may be stored on USB hardware tokens compliant with FIPS 140-2 Level 2, which meets CA/Browser Forum requirements but introduces logistics challenges, especially under the new 460-day certificate validity period, where tokens must be replaced approximately every 15 months.
- There is some access control where not everyone can sign, and certain certificates are designated for specific environments (development vs. production). However, this control is not granular and is not enforced at a technical level and it relies on developers following documented procedures.
- Certificate inventory exists in some form, such as a spreadsheet, a shared calendar reminder, or a ticket in a project management system, but it is manually maintained and prone to becoming outdated.
- Signing may be partially integrated into build pipelines for some products, but manual signing steps persist for others, particularly legacy products or products managed by smaller teams.
- Some audit logging exists where signing events may be captured in build logs but these are not centralized, not actively monitored, and not used to detect anomalies.
The primary risk at Stage 2 is the gap between policy and practice. Policies that are not technically enforced are not really controls. When a policy says “keys must not be stored on developer workstations” but nothing prevents a developer from copying a key file to their laptop for convenience, the policy provides false assurance. Similarly, an access control model that relies on people following documented procedures is vulnerable to both insider threat and external compromise.
Stage 3: Managed — Centralized, Controlled, and Audited
At Stage 3, code signing has evolved from a documented policy into a technically enforced, centrally managed discipline. The controls are not just written down; they are implemented in infrastructure and systems. Access is governed by RBAC that is configured and enforced in a signing platform with keys in HSMs and not in tokens. It also has a comprehensive and actively monitored audit trail.
- Private signing keys are generated inside and never leave FIPS 140-2 Level 3 certified Hardware Security Modules. The physical or cloud HSM is managed by the security team, not held by individual developers. Key export is technically disabled at the HSM policy level.
- A centralized signing platform enforces Role-Based Access Control with designated roles with defined permissions govern who can request a signing operation, who must approve it, and what artifacts can be signed with which certificate.
- Code Signing Certificate lifecycle management is systematic, with an inventory of all signing certificates, with expiration dates, assigned owners, and associated products and pipelines, which is maintained in a management system, not a spreadsheet. Renewal alerts are automated and triggered well in advance of expiry.
- Signing is integrated into CI/CD pipelines for all production artifacts and is a controlled, policy-enforced stage in the release pipeline, not a manual step initiated by a developer with RFC 3161 timestamping being applied consistently on all signing operations.
- Every signing event produces an immutable audit log entry capturing the artifact hash, certificate used, timestamp, requesting identity, and approval chain. Logs are centralized, actively reviewed, and anomalous signing events generate real-time alerts.
- There is a documented incident response plan for signing key compromise, covering which keys can be revoked and replaced through software mechanisms, which require hardware replacement, and what the communication and remediation timeline looks like.
At Stage 3, the signing infrastructure is genuinely difficult to abuse. An attacker who compromises a developer account can be locked and stopped from performing a signing operation. An insider threat who attempts to sign an unauthorized artifact will generate an anomaly alert. A certificate that is approaching expiry will trigger an automated renewal workflow rather than silently expiring and causing a production failure. With a proper audit trail, it allows any historical signing event to be reviewed, traced, and investigated.
Stage 4: Optimized — Automated, Resilient, and Future-Ready
Organizations at this level have not just implemented strong controls, they have built a signing program that is continuously improving, adapts proactively to industry changes, and is designed to remain resilient through future developments, including post-quantum cryptography migration and ongoing regulatory evolution.
- The signing infrastructure is fully automated with Certificate discovery, renewal, deployment, and revocation being handled by integrated systems without manual intervention.
- The organization has implemented crypto-agility in its signing infrastructure. Algorithm and key size migrations can be executed across the certificate fleet without requiring individual pipeline updates or manual reconfiguration.
- Post-quantum cryptography signing is in production or in active pilot for long-lifecycle artifacts. NIST finalized algorithms such as ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and LMS (NIST SP 800-208) as approved post-quantum signature algorithms.
- The code signing program participates in the organization’s broader supply chain security framework, integrating with Software Bill of Materials (SBOM) generation, binary provenance tracking, and vulnerability management processes.
- The organization conducts regular adversarial testing of its signing infrastructure, such as red team exercises that attempt to bypass RBAC controls, introduce unauthorized signing events, or extract key material, to validate that controls function as designed under realistic attack conditions.
- Key compromise response plans are rehearsed through exercises, with documented recovery time objectives for each category of signing key and certificate.
At Stage 4, the signing program is not just protecting against known attack patterns but it is architecturally resilient against the attacks that are coming. The post-quantum transition that will require significant infrastructure work for most organizations in the late 2020s is already underway. Regulatory changes that demand demonstrable compliance evidence, such as NIST SSDF attestation, audit logs for federal software contracts, and sector-specific requirements, can be satisfied from operational data rather than requiring retroactive documentation.
How Encryption Consulting’s CodeSign Secure Can Help?
CodeSign Secure is Encryption Consulting’s centralized, policy-enforced code signing platform. It is designed to support organizations at every stage of the maturity journey, providing the infrastructure and controls needed to reach Stage 3 and the advanced capabilities required to achieve Stage 4.
CodeSign Secure gives organizations coming from ad hoc or partially defined signing practices an immediate path to the foundational controls that characterize Stage 3:
HSM-backed key management: Private signing keys are generated inside and never leave FIPS 140-2 Level 3 certified Hardware Security Modules. CodeSign Secure integrates with Thales Luna, Entrust nCipher, Utimaco, Securosys, and cloud HSMs from AWS and Azure. Key export is disabled at the policy level. The USB token model and all of its renewal logistics and access management challenges are replaced by a centralized, API-accessible signing infrastructure.
Enforced RBAC and approval workflows: CodeSign Secure’s Role-Based Access Control model lets administrators define precisely who can request a signing operation, what they can sign, which certificate is used, and what authorisation steps must be matched before signing proceeds. These controls are programmatically enforced and not dependent on people following documented procedures.
Code Signing Certificate management: The platform maintains a centralized inventory of all certificates under management, with automated renewal alerting configured to give teams sufficient lead time under the new 460-day validity period.
For organizations that have already established foundational controls and are building toward optimization and Stage 4:
CI/CD pipeline integration: CodeSign Secure integrates natively with Azure DevOps, Jenkins, GitLab CI, and other major pipeline systems. Signing operations are API-driven by integration with third party signing tools with enforcement of RFC 3161 timestamping.
Post-quantum cryptography support: CodeSign Secure v3.02 introduces production-ready support for ML-DSA (FIPS 204, available at ML-DSA-44, ML-DSA-65, and ML-DSA-87 security levels) as detachable signatures, enabling organizations to begin the PQC transition.
Audit logging and reporting: Every signing event in CodeSign Secure generates an immutable log entry capturing artifact hash, certificate, timestamp, requesting identity, and approval chain. Logs integrate with SIEM platforms such as Splunk and Grafana Loki via Opentelemetry for real-time anomaly detection.
Whether you are starting from Stage 1 and need to establish foundational controls quickly, or you are at Stage 3 and building toward full automation and post-quantum readiness, CodeSign Secure provides the infrastructure to support that journey.
Conclusion
Code signing maturity is not a destination but a procedure to attain. Every organization is somewhere on the journey, and every stage of improvement meaningfully reduces risk and operational exposure.
At Encryption Consulting, we built CodeSign Secure to make that transition practical at every stage of the journey. The question “are your code signing processes mature?” does not have a binary yes or no answer. But it does have a specific, actionable one: identify where you are across, identify which components are lagging most, and build a prioritized roadmap to close the gaps.
In 2026, the urgency of that roadmap is defined by industry developments such as 460-day certificate validity that makes manual lifecycle management untenable, supply chain attacks which continue to exploit weak signing governance, NIST SSDF requirements that demand demonstrable secure development practices, and the approaching post-quantum transition that will require infrastructure changes most organizations have not yet begun.
