Certificate lifecycle management tenders often buy a discovery dashboard when the real need is renewal that runs end to end without a person, on every platform, for certificates that will soon last 47 days. This template is a ready-to-issue request for proposal for a certificate lifecycle management (CLM) platform, with numbered requirements that can each be verified and scored. It covers discovery and inventory, automated issuance, renewal and deployment, CA agility, private PKI, key protection, policy, integrations, the security of the platform itself, and commercials, with mandatory and scored criteria, a weighting model, a proof of concept script and a pricing schedule. It is vendor-neutral and written for PKI owners, platform engineering teams and procurement panels. For how the CLM market works and what to look for, read the CLM Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [number] and [public CA], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example CLM-REN-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Volumes, lifetimes, weights and time targets in brackets are illustrative, not market benchmarks. Set them before issue and do not change them after responses arrive.
- Issue sections 1 to 11 to bidders. The Evaluation method and Implementation guidance sections are for your panel only.
- Complete the inventory table in section 2 honestly, even with estimates. Bidders price and design against it, and an understated count is the most common cause of a contract that does not fit.
1. Purpose and scope
[Organisation] invites proposals for a platform that discovers, inventories, issues, renews, deploys, revokes and reports on digital certificates and their keys across [Organisation]'s environment, with the aim that no in-scope certificate is renewed manually.
- In scope: [public TLS certificates]; [private TLS and mTLS certificates]; [device and user certificates issued through EST or SCEP]; [Kubernetes and service mesh workload certificates]; [code signing certificates]; [SSH certificates, optional].
- Out of scope: [replacement of the existing private CA, unless bid as an option]; [HSM hardware procurement]; [S/MIME, unless bid as an option].
- Drivers: the CA/Browser Forum's Ballot SC-081 reduces the maximum validity of public TLS certificates in stages from March 2026 to 47 days from March 2029, and the reuse period for domain validation data to 10 days; [recent certificate expiry outages]; [audit findings]; [post-quantum migration planning].
- Contract term: [three] years with a [12-month] break clause.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Certificates (estimate) | [number] public TLS; [number] private TLS and mTLS; [number] device and user; [number] code signing; [number] SSH keys or certificates |
| Certificate authorities | [public CAs in use]; [private CAs, for example Active Directory Certificate Services or a cloud private CA]; [CAs run by suppliers] |
| Endpoints that terminate TLS | [load balancers and ADCs]; [web servers]; [CDNs and WAFs]; [API gateways]; [Kubernetes ingress]; [appliances] |
| Cloud and platforms | [cloud providers and accounts]; [Kubernetes clusters]; [service mesh]; [secrets managers] |
| Key storage | [HSMs or cloud KMS in use]; [key storage policy] |
| Current process | [spreadsheet, ticket, partial ACME]; renewals per month [number]; expiry incidents in last 12 months [number] |
| Regulatory context | [PCI DSS, eIDAS, sector rules]; key storage requirements such as [FIPS 140-3 validated modules] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarifications by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Answers: for each requirement state whether it is met natively in the base product, met by an add-on (price it), met by a partner or custom script (name it and who supports it), on the roadmap (give a date) or not met.
- Integrations list: provide your current list of supported CAs, platforms and orchestration targets as a separate attachment, marking each as native, community or professional services.
- Deployment model: state whether the platform is SaaS, self-hosted or hybrid, and list every component that must run inside [Organisation]'s network.
4. Discovery and inventory
| ID | Requirement | Type |
|---|---|---|
| CLM-DSC-01 | Discovers certificates by network scanning of [IP ranges and ports, for example 443, 8443, 636, 993, 5986] without requiring certificates to have been issued through the platform. | M |
| CLM-DSC-02 | Discovers certificates through API integration with [load balancers], [cloud certificate services], [Kubernetes secrets and cert-manager resources], [Windows certificate stores] and [secrets managers]. | M |
| CLM-DSC-03 | Imports issuance records from [private CAs] and monitors Certificate Transparency logs for certificates issued for [Organisation] domains. | S |
| CLM-DSC-04 | Records for each certificate: subject and SANs, issuer, serial, validity, key type and size, signature algorithm, every location where it is installed, owner and business service. | M |
| CLM-DSC-05 | Assigns owners from [CMDB, cloud tags, directory groups] and routes unowned certificates to a queue with escalation. | S |
| CLM-DSC-06 | Reports a cryptographic inventory by algorithm and key length to support post-quantum migration planning. | S |
5. Issuance, renewal and deployment
| ID | Requirement | Type |
|---|---|---|
| CLM-REN-01 | Renews, deploys and verifies certificates end to end without manual steps for [list of top platforms], including binding the new certificate and confirming the served certificate has changed. | M |
| CLM-REN-02 | Supports ACME (RFC 8555) as server and client, including ACME Renewal Information (RFC 9773) so renewal timing can follow the CA's suggested window. | M |
| CLM-REN-03 | Provides an agent, connector or API-driven method for platforms that cannot run an ACME client, with the same verification step. | M |
| CLM-REN-04 | Renewal timing is configurable as a share of lifetime (for example at [two thirds] of validity), so it continues to work as public lifetimes fall towards 47 days. | M |
| CLM-REN-05 | Supports device and user enrolment through EST (RFC 7030) and SCEP (RFC 8894), and integration with [MDM platform]. | S |
| CLM-REN-06 | Issues short-lived workload certificates for [Kubernetes and service mesh] or integrates with [cert-manager] without bypassing policy. | S |
| CLM-REN-07 | Revokes certificates individually and in bulk through the CA, removes them from endpoints, and records the reason. | M |
| CLM-REN-08 | Self-service request portal and API with approval workflows by certificate type, domain and environment. | S |
See the ACME and Automated Certificate Management Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide for the background to CLM-REN-02 and CLM-REN-04.
6. CA agility and private PKI
| ID | Requirement | Type |
|---|---|---|
| CLM-CA-01 | Integrates natively with at least [two] public CAs and with [Organisation]'s private CAs, so issuance can move between them by policy change. | M |
| CLM-CA-02 | Replaces every certificate issued by a named CA, or by a named intermediate, with certificates from another CA in bulk, with progress reporting. State the throughput achieved at [number] certificates. | M |
| CLM-CA-03 | Offers or integrates with a private CA service supporting configurable profiles, CRL and OCSP, and name constraints. State whether it is included or priced separately. | S |
| CLM-CA-04 | Manages trust stores: reports which roots and intermediates are trusted on managed endpoints and can distribute or remove them. | S |
| CLM-CA-05 | Describe your post-quantum roadmap: support for hybrid or ML-DSA certificates as CAs and platforms adopt them, and reissuing at scale when algorithms change. | I |
The CA distrust case in CLM-CA-02 is the single best test of the platform. See the CA Compromise and Mass Certificate Replacement Playbook.
7. Key protection and policy
| ID | Requirement | Type |
|---|---|---|
| CLM-KEY-01 | Generates keys on the target endpoint or in an HSM or KMS where supported, so private keys are not transported. Where the platform does generate or hold keys, state where, how they are encrypted and who can export them. | M |
| CLM-KEY-02 | Integrates with [HSMs through PKCS#11] and [cloud KMS], and supports non-exportable keys for [code signing and CA keys]. | S |
| CLM-KEY-03 | Generates a new key pair on every renewal by default, with exceptions recorded. | S |
| CLM-POL-01 | Enforces policy at request time: allowed CAs, key types and minimum sizes, signature algorithms, maximum lifetimes, permitted domains and wildcard rules, by team and environment. | M |
| CLM-POL-02 | Reports policy violations among discovered certificates (weak keys, SHA-1, self-signed in production, wildcard misuse, lifetime above policy) with owner routing. | S |
| CLM-POL-03 | Code signing: approval workflow per signing request, signing without key export, and a full log of what was signed by whom. | S |
Align CLM-POL-01 values with your Certificate Management Policy Template before issue.
8. Monitoring, reporting and integration
| ID | Requirement | Type |
|---|---|---|
| CLM-MON-01 | Alerts owners at configurable thresholds before expiry, and separately alerts on every failed renewal or deployment, through [email, chat, ticketing]. | M |
| CLM-MON-02 | Streams audit and operational events (issuance, renewal, revocation, policy violation, admin change) to [SIEM] in a documented format. | M |
| CLM-MON-03 | Dashboards and exports for automation coverage, expiring certificates, policy compliance and CA distribution. | S |
| CLM-INT-01 | Full REST API with documented scopes, plus [Terraform provider or Ansible modules] for infrastructure-as-code workflows. | S |
| CLM-INT-02 | Integrates with [ITSM] for requests and changes, and with [CI/CD] pipelines for application certificates. | S |
9. Security of the platform
A CLM platform can issue trusted certificates for your domains and often holds credentials to every load balancer and server it deploys to. It is a tier 0 system.
| ID | Requirement | Type |
|---|---|---|
| CLM-SEC-01 | Administrative access through [Organisation]'s identity provider with phishing-resistant MFA, role-based access with scoped delegation by team, and separation between policy administrators and requesters. | M |
| CLM-SEC-02 | List every credential the platform stores or uses to reach CAs, endpoints and clouds; state how each is stored, whether it can be held in [Organisation]'s secrets manager, and how it is rotated. | M |
| CLM-SEC-03 | Agents and connectors authenticate with unique, revocable credentials, communicate outbound only where possible, and receive signed updates. | M |
| CLM-SEC-04 | Current independent assurance report (for example SOC 2 Type 2 or an ISO/IEC 27001 certificate whose scope covers the service), penetration test summary and vulnerability disclosure policy. | M |
| CLM-SEC-05 | Notifies [Organisation] within [24 hours] of any security incident affecting the service, and supports emergency revocation and reissue if the platform is compromised. | M |
| CLM-SEC-06 | Service availability target [99.9%] for SaaS components and continued operation of renewals for [number] days if the SaaS control plane is unreachable, or a documented manual fallback. | S |
The platform's own service accounts and API keys are non-human identities with broad reach. See the Machine Identity, PKI and Certificate Lifecycle Guide.
10. Implementation and support
| ID | Requirement | Type |
|---|---|---|
| CLM-IMP-01 | Implementation plan with phases, named roles, and a target of [percentage] automated renewal coverage of in-scope certificates by [month]. | S |
| CLM-IMP-02 | Support hours, severity definitions and response times; [24x7] for severity 1 issues that block issuance or renewal. | M |
| CLM-IMP-03 | Two customer references of similar size and platform mix, one of which has completed a CA migration with the platform. | S |
11. Pricing schedule and exit
| Line | Basis | Year 1 | Year 2 | Year 3 |
|---|---|---|---|---|
| Platform licence | [per certificate, per managed endpoint, tiered] | [ ] | [ ] | [ ] |
| Public certificates, if bundled | [per certificate type, DV, OV, EV] | [ ] | [ ] | [ ] |
| Private CA service | [per CA, per certificate] | [ ] | [ ] | [ ] |
| Add-ons (code signing, SSH, IoT) | [ ] | [ ] | [ ] | [ ] |
| Implementation services | [fixed or day rate] | [ ] | n/a | n/a |
| Growth to [2x] certificate count | [ ] | [ ] | [ ] | [ ] |
- Counting rules: state whether a renewed certificate counts again, how short-lived workload certificates are counted, and whether discovered but unmanaged certificates count. Shorter lifetimes multiply issuance volumes, so per-issuance pricing can grow sharply.
- CLM-EXT-01 (M): at exit, exports the full inventory, policies, ownership data and audit logs in documented formats within [30 days] at no extra charge.
- CLM-EXT-02 (M): renewals continue for [90 days] after notice, and no certificate or private key becomes unusable because the contract ends.
Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Automated renewal and deployment (section 5) | [30%] | Proof of concept, integrations list |
| Discovery and inventory quality (section 4) | [15%] | Proof of concept against ground truth |
| CA agility and private PKI (section 6) | [15%] | CA migration test, references |
| Key protection, policy and platform security (sections 7 and 9) | [15%] | Response, assurance reports |
| Monitoring and integration (section 8) | [10%] | Proof of concept, API review |
| Three-year cost (section 11) | [15%] | Pricing schedule at expected volumes |
Scores use 0 to 5: 0 not met; 1 met only by custom scripting the bidder will not support; 3 met; 5 met natively and demonstrated. Any mandatory requirement not met excludes the bid. The proof of concept runs for [four weeks] in [a non-production environment that mirrors production] and follows this script:
- Ground truth: before the trial, [Organisation] lists every certificate in the test scope by hand. Run discovery and count found, missed and duplicate certificates.
- Automated renewal: issue certificates with [a short lifetime, for example 7 days] to [load balancer], [web server], [Kubernetes ingress] and [one appliance without ACME]. Let them renew at least twice without intervention and verify the served certificate each time.
- Failure handling: break one deployment (revoke the platform's credential to a load balancer) and confirm the failed renewal alert reaches the owner within [15 minutes].
- CA migration: move [50] test certificates from CA A to CA B in one action and record time to complete and any manual steps.
- Policy enforcement: request a certificate with a disallowed key size, domain and lifetime; confirm each is rejected and logged.
- Revocation: revoke a compromised test certificate, replace it on every endpoint and confirm through OCSP or CRL.
- Logging and access: trace issuance, renewal and admin changes in [SIEM]; log in as a scoped team user and confirm they cannot see or request outside their domain.
- Clean up: revoke all trial certificates, remove agents and delete stored credentials.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Sequence the rollout: discovery and ownership first, then automate the public certificates on platforms where outages hurt most, then private TLS and mTLS, then device and code signing. Keep a manual renewal runbook per platform until two automated cycles have succeeded.
- Measure from day one: percentage of in-scope certificates renewed automatically; certificates without an owner; expiry-related incidents per quarter; failed renewals detected before expiry; median days of remaining validity at renewal; time to replace all certificates from one CA in a test.
- Treat the platform as tier 0: restrict who can change issuance policy, monitor issuance for unexpected domains, and include the platform in incident response plans for key compromise.
Common failure patterns
- Buying discovery, not automation: an accurate list of what will expire next month does not prevent outages. Weight section 5 highest and test it with short lifetimes.
- Counting ACME as done: issuance through ACME works on web servers; appliances, load balancer bindings and Java keystores often still need custom work. Ask who supports each integration.
- Ignoring CA concentration: a single public CA with no tested second route turns a distrust decision into months of emergency work.
- Per-issuance pricing at old lifetimes: volumes rise as lifetimes fall. Model cost at 47-day public certificates and short-lived workload certificates.
- Platform credentials left broad: one administrator account on every load balancer, stored in the CLM platform, is an attractive target. Scope and rotate them. Incidents where signing keys and certificates were stolen show how much trust these assets carry; see Signing keys and certificates in breaches.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Discovery and inventory (4) | CM-8 | ID.AM-08 |
| Issuance, renewal, CA and policy (5, 6, 7) | SC-17, IA-5(2) | PR.AA-01, PR.DS-02 |
| Key protection (7) | SC-12 | PR.DS-02 |
| Platform security, supplier and exit (9, 11) | SA-4, SA-9 | GV.SC-05, GV.SC-10 |
On the threat side, MITRE ATT&CK T1649 Steal or Forge Authentication Certificates and T1553.002 Code Signing describe what weak certificate and key handling enables; see the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide.
Standards and references
- CA/Browser Forum: Ballot SC-081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods
- IETF: RFC 8555 Automatic Certificate Management Environment (ACME)
- IETF: RFC 9773 ACME Renewal Information (ARI) Extension
- IETF: RFC 7030 Enrollment over Secure Transport
- NIST: SP 1800-16 Securing Web Transactions, TLS Server Certificate Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: CLM Buyer's Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Management Policy Template · PKI and Certificate Lifecycle Maturity Model · Security Vendor Evaluation and RFP Guide