Code Signing Policy Template: Govern Signing Keys, Approvals, Timestamps and Revocation

A code signing key tells every customer's operating system that software came from you, so whoever can use that key can ship malware under your name. This template gives you a governing policy for code signing: who may own and use signing keys, where keys must live, how signing requests are approved, how signatures are timestamped and verified, and what happens when a key is lost or compromised. It reflects the CA/Browser Forum Code Signing Baseline Requirements (CSBR) version 3.11.0, which require subscriber keys for publicly trusted certificates to be kept in certified hardware and cap certificates issued on or after 1 March 2026 at 460 days. It is written for CISOs, PKI owners, release engineering leads and auditors. The Code Signing Security Guide explains how to build the controls; this document sets the rules they must meet. Adapt the wording, roles and thresholds, and have the result reviewed by your legal, risk and compliance teams before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [PKI owner] and [X] days, with your own terms and values.
• "Must" marks a mandatory requirement; "should" marks a recommended practice where a documented exception may be justified.
• Apply the policy to every signing use case you have: Windows Authenticode, macOS and iOS, Android, Java, drivers and firmware, container images, packages and internal scripts. Delete statements that do not apply rather than leaving them unenforced.
• Keep the policy short and stable. Put product-specific steps (HSM configuration, signing service commands, CI settings) in standards and procedures that reference the numbered statements below.
• Check the CA/Browser Forum requirements at each annual review, because CSBR versions change key protection, validity and timestamping rules. The Code Signing Certificate Validity Changes guide tracks the current dates.

1. Purpose

This policy sets the requirements for creating, protecting, using and retiring code signing keys and certificates at [Organisation]. Its purpose is to ensure that only authorised, reviewed software is signed in [Organisation]'s name, that signing keys cannot be copied or misused, that signatures remain verifiable for the life of the software, and that a compromised key can be contained quickly.

2. Scope

This policy applies to:

• All code signing certificates issued to [Organisation] or its subsidiaries by public certificate authorities (CAs), including EV and non-EV certificates.
• All internal or private PKI certificates and keys used to sign software, scripts, drivers, firmware, container images, packages, models or configuration consumed by [Organisation] systems or customers.
• Keyless or identity-bound signing (for example short-lived certificates issued against a workload or CI identity) used for [Organisation] artefacts.
• Signing services, hardware security modules (HSMs), cloud key management services and build systems that hold or use signing keys.
• All employees, contractors and third parties (including outsourced developers and build providers) who request, approve, perform or administer signing.

It does not cover TLS server certificates or document signing, which are governed by [Certificate Management Standard].

3. Definitions

• Signing key: a private key used to create code signatures.
• Code signing certificate: a certificate binding a signing key's public key to [Organisation] or a product identity.
• Hardware crypto module: an HSM, cloud HSM or token certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, or a later equivalent, in which keys are generated, stored and used without export.
• Signing service: the approved system through which all production signing requests are made, which authenticates requesters, enforces approvals, calls the hardware crypto module and logs every operation.
• Timestamp: a countersignature from a timestamp authority, typically under RFC 3161, proving that a signature existed at a given time so it can be validated after the certificate expires.
• Key compromise: any event in which a signing key, or access to use it, may have been obtained or used by an unauthorised party.
• Suspect code: code that contains malicious functionality or serious vulnerabilities, as defined in the CSBR.

4. Roles and responsibilities

• [CISO]: owns this policy, approves exceptions and receives reports of key compromise.
• [PKI owner]: maintains the signing key and certificate inventory, manages CA accounts, operates the hardware crypto modules and signing service, and runs key ceremonies.
• Product signing owner: a named person per product or signing identity, accountable for who may request signatures and for responding to CA instructions.
• Release approvers: people authorised to approve production signing requests for a product; they must not be the requester.
• Build and release engineering: integrate the signing service into pipelines and ensure only approved builds reach it.
• [Security operations]: monitor signing logs and lead the response to suspected key compromise.
• [Procurement]: ensures only approved CAs are used and no certificates are bought outside the [PKI owner]'s accounts.

5. Policy statements

5.1 Inventory and ownership

1. Every signing key and code signing certificate must be recorded in the [signing inventory] with its owner, product, CA, key location, algorithm and size, validity dates, signing service and permitted pipelines.
2. Certificates must be ordered only through [Organisation]'s approved CA accounts managed by the [PKI owner]. Certificates bought on personal or team accounts must be transferred or revoked.
3. Each signing identity must have a named owner who is a current employee. Ownership must be reassigned within [X] days of the owner leaving or changing role.
4. The inventory must be reconciled with CA order histories at least [quarterly].

5.2 Key generation and protection

1. Signing keys for publicly trusted code signing certificates must be generated, stored and used inside a hardware crypto module certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, or in a signing service that meets CSBR section 6.2.7.3, as required by CSBR section 6.2.7.4.
2. Internal signing keys used for production artefacts should meet the same standard.
3. Private keys must be non-exportable. Keys must never be stored in files, source code, CI variables, container images or developer workstations.
4. Keys must use algorithms and sizes that meet the CSBR (RSA at least 3072 bits, or ECDSA on P-256, P-384 or P-521) and [Cryptographic Key Management Policy].
5. Where cloud HSMs are used, the subscription holding the key must log all access, operations and configuration changes, as CSBR section 6.2.7.4.1 requires.
6. A signing key must not be reused with any non-code-signing certificate.
7. Generation of root or high-value signing keys must be performed in a documented key ceremony with at least [two] authorised witnesses.

5.3 Access to signing

1. All production signing must go through the [signing service]. Direct use of keys in the hardware crypto module is limited to the [PKI owner] for administration.
2. Human requesters must authenticate to the signing service with phishing-resistant MFA.
3. Pipelines must authenticate with a workload identity or short-lived credential bound to the specific repository and branch permitted to sign, not with long-lived shared secrets.
4. Access to request signing must be granted per product, reviewed by the product signing owner at least [quarterly], and removed within [24 hours] of a leaver or role change.
5. No individual may both administer the hardware crypto module and approve production signing for the same key.

5.4 Approval and what may be signed

1. Only artefacts built by an approved build system from reviewed source on a protected branch may be signed with production keys.
2. Production signing requests must be approved by a release approver other than the requester, unless the request comes from an approved pipeline whose controls provide equivalent assurance, documented in [Signing Standard].
3. Artefacts must be scanned for malware and checked against [software composition policy] before signing.
4. Test and development builds must be signed with separate test keys that are not trusted outside [Organisation]. Production keys must never sign test builds, third-party code that has not been reviewed, or customer-supplied code.
5. Signing requests should record the artefact hash, build provenance and approver, so each signature can be traced to a build. See the SLSA and Build Provenance Guide.

5.5 Timestamping

1. Every production signature must be timestamped by an approved timestamp authority.
2. Timestamp failures must fail the release, not produce untimestamped signed artefacts.
3. The list of approved timestamp authorities must be maintained in [Signing Standard] and reviewed annually.

5.6 Certificate lifecycle

1. Code signing certificates must not exceed the maximum validity in the CSBR, which is 460 days for certificates issued on or after 1 March 2026.
2. Renewal must begin at least [60] days before expiry and should generate a new key pair.
3. Certificates no longer needed must be revoked and their keys destroyed through a recorded process.
4. Expiry and renewal dates must be monitored, with alerts to the product signing owner and [PKI owner] at [90, 30 and 7] days.

5.7 Verification

1. [Organisation] systems must verify signatures on software before installation or execution where the platform supports it, using [application control, admission control or package verification] as defined in [Endpoint and Platform Standards].
2. Release pipelines must verify each signature and timestamp after signing and before publication.
3. Published artefacts should be accompanied by verification instructions or provenance for customers.

5.8 Logging and monitoring

1. The signing service and hardware crypto modules must log every signing operation with requester, approver, key, artefact hash, timestamp authority response and result.
2. Logs must be sent to [SIEM], protected against tampering and retained for [at least the life of the signed software plus X years].
3. [Security operations] must alert on signing outside approved pipelines or hours, unusual volumes, signing of artefacts with no matching build record, failed authentication to the signing service and changes to key permissions.
4. Signing logs must be reconciled with release records at least [monthly].

5.9 Key compromise and suspect code

1. Any suspected key compromise, unauthorised signature or signed suspect code must be reported to [Security operations] immediately and handled under [Incident Response Procedure].
2. The [PKI owner] must suspend use of the affected key and, where compromise is confirmed or cannot be ruled out, request revocation from the CA. The CSBR requires subscribers to request revocation promptly on key misuse or compromise and requires the CA to revoke within 24 hours of evidence of key compromise.
3. The revocation date requested must be set to the earliest time misuse may have started, so signatures made before that time stay valid and later ones do not. The Compromised Code Signing Certificate Playbook covers this decision.
4. [Organisation] must respond to CA instructions about key compromise or misuse within [the period set in the subscriber agreement].
5. Affected products must be re-signed with a new key, and customers notified where action is needed.

5.10 Third parties

1. Third parties must not hold [Organisation] production signing keys. Where an external build provider or contractor needs to sign, they must request signatures through the [signing service] under this policy.
2. Software signed by suppliers for use at [Organisation] must be verified against expected publisher identities before deployment.
3. Contracts with signing service, HSM and CA providers must cover key protection, logging, incident notification and support for revocation.

6. Control mapping

7. Exceptions

Exceptions must be requested by the product signing owner, risk assessed by [Security team], approved by the [CISO], recorded with compensating controls and an expiry date of no more than [12] months, and reviewed before expiry. No exception may permit export of a publicly trusted signing key from a hardware crypto module.

8. Compliance

Compliance will be checked through inventory reconciliation, signing log review, access reviews and internal audit. Keys or certificates found outside this policy may be suspended or revoked. Breaches of this policy by staff may be handled under [disciplinary procedure]. The following measures will be reported to [governance forum] each [quarter]:

• Percentage of signing keys held in a certified hardware crypto module or approved signing service (target 100%).
• Certificates found outside the inventory or approved CA accounts (target zero).
• Production signatures without a matching approved build record (target zero).
• Untimestamped production signatures (target zero).
• Certificates within 30 days of expiry without a renewal in progress (target zero).
• Time to suspend a signing key in the annual compromise exercise.

9. Related documents

• [Information Security Policy]
• [Cryptographic Key Management Policy]
• [Certificate Management Standard]
• [Signing Standard and signing service procedures]
• [Secure Software Development Policy]
• [Incident Response Procedure]
• [Third-Party Risk Management Procedure]

10. Review

This policy is owned by the [CISO] and will be reviewed at least annually, after any signing key compromise, and when the CA/Browser Forum publishes a CSBR version that changes key protection, validity, timestamping or revocation rules.

Implementation guidance

Common failure patterns the policy is designed to prevent, and where to find the implementation detail:

• Keys on build servers and laptops: signing keys exported to files or CI secrets can be copied without trace. Section 5.2 requires non-exportable hardware keys; see the HSM Deployment and Operations Guide.
• Pipelines that sign anything: a signing step reachable from any branch or pull request signs whatever an attacker can get built. Section 5.3 binds signing to specific repositories and branches; see the CI/CD Pipeline Identity Security Guide.
• Forgotten certificates: certificates bought by individual teams expire unnoticed or survive after the team has gone. Sections 5.1 and 5.6 require a reconciled inventory and expiry alerts; see the Machine Identity, PKI and Certificate Lifecycle Guide.
• Missing timestamps: untimestamped signatures stop validating when the certificate expires or is revoked. Section 5.5 makes timestamping a release gate.
• Slow compromise response: organisations that have never rehearsed revocation struggle to choose a revocation date and re-sign products. Section 5.9 and the annual exercise in section 8 address this; see the Compromised Code Signing Certificate Playbook.
• Keyless signing: where identity-bound signing replaces long-lived keys, the controls in sections 5.3 and 5.8 apply to the CI identity instead of the key. See the Sigstore Guide.

Rollout order that NHI Mgmt Group recommends for most organisations (our guidance, not a standard requirement):

1. Build the inventory from CA order histories, HSM key lists and pipeline configurations.
2. Move publicly trusted keys into a certified hardware crypto module or signing service, and revoke any certificate whose key was ever held in software.
3. Put the signing service in front of every key, with approvals and logging, piloting one product before others.
4. Turn on timestamp and verification gates in release pipelines.
5. Connect signing logs to the SIEM and run a key compromise tabletop exercise.

Small organisations with one product can meet most of this policy with a single cloud HSM or signing service and one approver per release. Large organisations should run a central signing service, separate test and production keys per product line, and report the section 8 measures to their governance forum.

Standards and references

• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates
• CA/Browser Forum: Code Signing Working Group requirements
• NIST: Security Considerations for Code Signing (CSWP)
• IETF: RFC 3161 Time-Stamp Protocol (TSP)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Code Signing Security Guide · Code Signing Buyer's Guide · Cryptographic Key Management Policy Template · Software Supply Chain Security Guide