Code Signing Maturity Uncovered: Challenges and Insights

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.

Code signing maturity, defined: the degree to which HSM-backed key custody, RBAC with separation of duties, approval gates, scheduled key rotation, immutable audit logs, tested revocation, mandatory timestamping, and isolated build environments are enforced by infrastructure rather than by policy documents people are trusted to follow, measured across four stages from ad hoc to optimized.

Key Takeaways

• 3CX (2023) is the clearest evidence that maturity, not cryptography, is the usual point of failure: the signature and certificate were both genuine, and the compromise happened because no control stopped an attacker who reached the build environment from triggering a signing operation.
• A policy that isn’t technically enforced isn’t a control; the gap between “we have a signing policy” and “our infrastructure makes the policy impossible to bypass” is the entire distance between Stage 2 and Stage 3.
• Key rotation, revocation readiness, and build isolation are frequently missing even from otherwise mature programs; see “Controls Not to Skip” below for what each requires specifically.
• This page is the diagnostic framework, where does your program stand and what’s the next stage. For a flat, stage-agnostic checklist of individual practices, see Code Signing Best Practices in the SDLC.
• A maturity score is a diagnostic, not a security guarantee; see “Limitations” below before treating a Stage 3 or 4 result as itself sufficient evidence of security.

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

Controls Not to Skip: Rotation, Revocation, Separation of Duties, and Build Isolation

Four controls get skipped even in programs that otherwise look mature, because they don’t show up until something forces the issue. Naming them explicitly, rather than folding them into “key management” or “access control,” makes them easier to check for.

Key Rotation

Storing a key in an HSM answers where it lives, not how long it lives there unchanged. A mature program defines a rotation schedule per key, tied to certificate renewal under the current 460-day validity window at minimum, and treats rotation as a routine, automated event rather than something triggered only by a suspected compromise. If your program can answer “when was this specific signing key last rotated” only by checking when the certificate happened to expire, rotation isn’t actually being managed as its own control.

Revocation Readiness

A documented incident response plan is not the same as a tested one. Revocation readiness means knowing, before an incident, exactly which artifacts a given certificate has signed, being able to produce that list within the hour a compromise is suspected, and having already confirmed that revoking the certificate doesn’t silently break a distribution channel that doesn’t check revocation status. For the specific mechanics of revocation, timestamp implications, and re-signing after a compromise, see Establishing a Firmware Signing Framework for CRA Compliance.

Separation of Duties

RBAC answers who is allowed to sign; separation of duties answers whether any single identity can both request and approve the same signing operation. A program can have granular RBAC and still fail separation of duties if a lead developer’s role includes both permissions. The technical check is straightforward: can one account, acting alone, get an artifact signed without a second identity’s involvement? If yes, that’s a Stage 2 gap wearing Stage 3 tooling.

Build Isolation

This is the control 3CX’s build environment lacked, and it’s the one most maturity self-assessments skip because it lives upstream of the signing operation itself. Build isolation means the environment producing the artifact is ephemeral and single-use, not a persistent build server one compromised run can contaminate for every subsequent build. It’s a build-pipeline control, not a signing-platform control, which is exactly why it’s easy for a signing-focused maturity review to miss. See Strengthening Supply Chain Security with SLSA Level 3 and Code Signing for how SLSA Level 3 formalizes this requirement.

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.

Self-Assessment Scorecard

Score each dimension against the stage that best matches current practice, not the stage you’re working toward. Be specific: “we have RBAC” only counts as Stage 3 if it’s technically enforced and covers separation of duties, not just documented.

Dimension	Stage 1 (Ad Hoc)	Stage 2 (Defined)	Stage 3 (Managed)	Stage 4 (Optimized)
Key custody	Local machine or shared file	Hardware token, individually held	HSM, export disabled	HSM with automated rotation and crypto-agility
Access control	No restriction	Informal, procedure-based	Technically enforced RBAC	RBAC plus rehearsed separation-of-duties testing
Revocation	No plan	Documented but untested	Tested plan, artifact-to-certificate mapping exists	Rehearsed with defined recovery time objectives
Build isolation	Persistent, shared build server	Persistent server, some access hardening	Isolated per build, manually verified	Ephemeral by default, SLSA-aligned
Audit trail	None or informal build logs	Logs exist, not centralized	Centralized, immutable, actively reviewed	Integrated with SIEM and anomaly alerting

How to Run the Assessment

1. Score each dimension in the table above independently; most organizations land at different stages on different dimensions, which is normal and more informative than a single overall score.
2. Identify the lowest-scoring dimension, not the average; a Stage 3 program with Stage 1 revocation readiness has a Stage 1 incident waiting to happen.
3. Cross-check each score against an external deadline that makes it urgent: the 460-day certificate validity window affects key custody and rotation scoring; upcoming NIST SSDF attestation requirements affect audit trail and policy scoring.
4. Build a roadmap that closes the lowest-scoring dimension first, not the easiest one; a quick win on a dimension that was already at Stage 3 doesn’t reduce your actual risk.

Limitations

A maturity score is a self-assessment, not an audit finding, and it’s only as accurate as the honesty of the people scoring it; a technical control review or a red-team exercise (part of Stage 4 itself) will surface gaps a self-assessment misses. Reaching Stage 3 or 4 also doesn’t make an organization immune to compromise, it makes specific, well-understood failure modes (shared keys, unenforced RBAC, unmonitored signing) much harder to exploit, while new or unanticipated attack techniques remain possible regardless of stage.

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.

Frequently Asked Questions

Can an organization be at different maturity stages for different controls?

Yes, and this is the normal case rather than the exception. A program often has strong HSM-backed key custody (Stage 3) while its revocation plan has never been tested (Stage 2) or its build environment isn’t isolated (Stage 1 or 2). Score each dimension independently rather than assigning one overall number.

Is having a written code signing policy enough to reach Stage 3?

No. A written policy that isn’t technically enforced, where nothing actually prevents someone from bypassing it, is a Stage 2 characteristic. Stage 3 requires the controls to be implemented in infrastructure (HSM policy, RBAC enforcement, automated certificate tracking) rather than relying on people following documented procedures.

Why wasn’t build isolation part of the original eight dimensions?

Build isolation sits upstream of the signing operation itself, in the build pipeline rather than the signing platform, which is exactly why signing-focused maturity reviews tend to miss it. It’s the control 3CX’s build environment lacked, and it belongs in any assessment that’s actually trying to prevent that failure mode, not just improve key custody.

What’s the difference between this maturity model and a best-practices checklist?

A checklist lists practices to adopt; a maturity model diagnoses where you currently stand on each one and what the next concrete step looks like, so effort goes to the lowest-scoring dimension first instead of spreading evenly across a flat list. For the flat checklist version, see Code Signing Best Practices in the SDLC.