Certificate Management Policy Template: Owning, Issuing and Renewing Every Certificate

Certificate outages and certificate misuse almost always trace back to the same gap: nobody wrote down who owns each certificate, which authorities may issue it, how long it may live and what happens when it must be replaced in a hurry. This template gives [Organisation] a ready-to-adopt certificate management policy covering approved certificate authorities, ownership, validity periods, automated issuance and renewal, inventory, private key protection and revocation. It is written for the 2026 to 2029 period in which the CA/Browser Forum is cutting the maximum life of publicly trusted TLS certificates from 398 days to 47 days, which makes manual renewal unworkable. It suits CISOs and policy owners who need a document to approve, and PKI and platform engineers who must implement it. For the discipline behind the policy, see the Machine Identity, PKI and Certificate Lifecycle Guide.

How to use this template

• Replace bracketed text such as [Organisation], [PKI Owner], [Approved public CAs], [Internal CA name] and [Date] with your own values. Values in brackets with numbers, such as [30 days], are suggested defaults to adjust.
• Sections 1 to 7 are the policy. Keep operational detail (tool names, runbooks, renewal job settings) in a separate certificate management standard so the policy does not need re-approval every time a tool changes.
• This policy covers certificates. Key generation, storage and destruction in general are covered by a companion key management policy; see the Cryptographic Key Management Policy Template. Where the two overlap, cross-reference rather than repeat.
• Public TLS rules come from the CA/Browser Forum Baseline Requirements and browser root programmes, which change several times a year. Recheck the validity schedule in section 4.4 at every annual review.

1. Purpose

This policy sets the rules [Organisation] follows to request, issue, deploy, renew, revoke and retire digital certificates and their private keys, so that services stay available, certificates cannot be misused to impersonate [Organisation], and every certificate can be traced to an accountable owner. It supports the organisation's obligations under [ISO/IEC 27001:2022 Annex A 8.24 Use of cryptography], [NIST CSF 2.0 PR.AA-01 and PR.DS-02] and [applicable regulation].

2. Scope

• Certificate types: public TLS server certificates; private (internal CA) TLS server and client certificates, including mutual TLS between services; code signing certificates; S/MIME and document signing certificates; device and workload certificates (for example issued through SCEP, EST, ACME or a service mesh); SSH certificates; and CA certificates operated by [Organisation].
• Environments: all production, non-production, cloud, on-premises, OT and end-user environments, including certificates issued or held by third parties on [Organisation]'s behalf (CDN, load balancer, SaaS custom domains).
• People: all employees, contractors and suppliers who request, manage or deploy certificates, and all automated systems and service accounts that do so.

3. Roles and responsibilities

4. Policy statements

4.1 Approved certificate authorities

• Public certificates for [Organisation] domains shall be issued only by [Approved public CAs]. The [PKI Owner] reviews this list annually and after any CA distrust announcement by a major root programme.
• Every registered domain shall publish DNS CAA records (RFC 8659) naming only approved CAs, and where supported the RFC 8657 accounturi parameter to bind issuance to [Organisation]'s ACME accounts.
• Internal certificates shall be issued only by [Internal CA name] hierarchies operated or approved by the [PKI Owner]. Self-signed certificates are prohibited in production except for root CAs and documented exceptions.
• Offline root CA keys shall be held in a hardware security module (HSM) [validated to FIPS 140-3 Level 3 or equivalent], with root key ceremonies following [Key ceremony procedure].

4.2 Ownership and request

• Every certificate shall have a named owner and a team, recorded in the inventory at issuance. A certificate without a current owner is treated as an incident and assigned within [5 working days].
• Requests shall include the service, environment, deployment locations, owner and business justification. Wildcard certificates require [PKI Owner] approval and shall not be shared across trust boundaries or environments.
• Production and non-production shall use separate certificates and keys.

4.3 Keys and algorithms

• Private keys shall be generated on the system that uses them, or in an HSM or cloud key management service, and shall never be sent by email, chat or ticket.
• Minimum key strength: [RSA 2048-bit, preferably 3072] or [ECDSA P-256 or stronger]. SHA-1 signatures are prohibited.
• Code signing private keys shall be held in an HSM or a managed signing service, with use restricted to the build pipeline identities named in the inventory.
• Private keys shall not be stored in source code repositories or container images. Storage of keys and certificate bundles follows the [Secrets management standard].

4.4 Validity periods

Ballot SC-081v3 also cuts how long a CA may reuse domain validation evidence, from 398 days to 10 days by March 2029, so domain control must be provable automatically. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

4.5 Automation and renewal

• All public TLS certificates shall be issued and renewed automatically, using ACME (RFC 8555) or an equivalent CA API, by [date]. New services shall not go live with manually renewed certificates.
• Renewal shall start when [one third] of validity remains, and where the CA supports ACME Renewal Information (RFC 9773) clients shall use the suggested window.
• Automation accounts (ACME account keys, DNS API credentials, CA API keys) are non-human identities: each has an owner, least-privilege scope (for example DNS write rights limited to _acme-challenge records where the provider allows), secure storage and rotation. See the ACME and Automated Certificate Management Guide.
• Deployment after renewal shall be automated and verified by checking the certificate actually served, not only the file on disk.

4.6 Inventory and monitoring

• The [PKI Owner] shall maintain a single certificate inventory recording subject and SANs, issuer, serial number, validity dates, key type, owner, service, deployment locations and renewal method.
• The inventory shall be reconciled at least [monthly] against network discovery scans, CA issuance records, cloud certificate services and Certificate Transparency logs for [Organisation] domains.
• Expiry alerts shall go to the owner at [30, 14 and 7 days] before expiry and escalate to the [PKI Owner] at 7 days. Unexpected issuance seen in Certificate Transparency logs shall be investigated within [1 working day]. See the Certificate Transparency Monitoring Guide for Web Teams.

4.7 Revocation and replacement

• A certificate shall be revoked within [24 hours] when its private key is suspected compromised, when it was mis-issued, or when the service is retired, and replaced first where the service must stay up.
• Revocation status shall be published by internal CAs through CRLs [and OCSP], with CRL distribution points reachable by every relying party. See the Certificate Revocation Guide.
• Code signing compromise requires revocation, re-signing of affected releases and customer communication, as in the AnyDesk breach, where a production compromise forced revocation of a code signing certificate and new signed releases.
• [Organisation] shall maintain and test, at least annually, a mass replacement plan for a CA distrust or compromise affecting many certificates at once. See the CA Compromise and Mass Certificate Replacement Playbook.

4.8 Trust stores

• Changes to trust stores on managed devices, servers and container base images shall be controlled through change management. Adding a root requires [PKI Owner] approval. See the Certificate trust stores and root CA management guide.
• Applications shall validate certificate chains and hostnames, and shall not disable validation in production code.

5. Exceptions

Exceptions (for example a legacy appliance that cannot accept automated renewal or short-lived certificates) shall be requested through [Exception process], state the compensating control (such as calendar-driven manual renewal with two named owners and monitoring of the served certificate), be approved by the [PKI Owner], or the [CISO] where rated high risk, and expire after no more than [12 months].

6. Compliance and monitoring

• The [PKI Owner] reports quarterly to [Security governance committee] on the measures in the implementation guidance below.
• Internal audit reviews compliance with this policy [annually], sampling inventory records against deployed certificates.
• Breaches of this policy are handled under [Disciplinary or supplier management process].

7. Review and approval

This policy is reviewed at least annually and after any significant change to CA/Browser Forum requirements, root programme policy, a certificate-related incident or a change of PKI platform. Owner: [PKI Owner]. Approved by: [CISO]. Version [1.0], effective [Date], next review [Date].

Implementation guidance

Where to start: build the inventory before enforcing the rules, because a policy that cannot be measured will not be followed. Run discovery across external domains (Certificate Transparency search) and internal networks in the first month, assign an owner to every certificate found, then set CAA records. Automate the certificates with the nearest expiry and the largest outage impact first, and set 31 December 2026 as an internal deadline to have every public certificate on automated renewal before the 100-day maximum arrives on 15 March 2027.

Testing and rollback: pilot automated renewal on non-production endpoints, then on one production service with a manually issued spare certificate ready. Shorten internal validity in steps (for example 1 year, then 90 days, then 30 days) and watch for renewal failures before each step.

Small and large organisations: a small organisation with a handful of public sites can meet most of this policy with a CA that supports ACME, CAA records and expiry monitoring, and can drop the internal CA sections if it runs none. A large enterprise needs a dedicated PKI function, a certificate lifecycle platform or equivalent tooling, and a separate certificate practice statement for each internal CA.

Threats this policy addresses: theft or forgery of authentication certificates (MITRE ATT&CK T1649), attackers obtaining digital certificates for look-alike domains (T1588.004) and abuse of stolen code signing certificates (T1553.002).

Metrics: percentage of certificates with a named owner; percentage of public certificates renewed automatically; certificates expiring within 14 days without a renewal scheduled; outages caused by certificate expiry per quarter; median validity of issued internal certificates; and time from suspected compromise to revocation.

References: CA/Browser Forum: Ballot SC-081v3 · NIST: SP 1800-16 Securing Web Transactions, TLS Server Certificate Management · IETF: RFC 8555 Automatic Certificate Management Environment · IETF: RFC 9773 ACME Renewal Information · IETF: RFC 8657 CAA Record Extensions for Account URI and ACME Method Binding · Google: Chrome Root Program Policy

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Enterprise PKI Design and CA Hierarchy Guide · Cryptographic Key Management Policy Template · CA Distrust Events