PKI RFP Template and Checklist (2026): Requirements for Private CA and Certificate Lifecycle Management

This PKI RFP template is a vendor-neutral set of requirements for buying a private certificate authority (CA) and certificate lifecycle management (CLM) platform. It is organized in the seven groups a PKI response usually needs to cover: CA and issuance, enrollment, visibility and automation, key protection, use cases, governance, and deployment and vendor. Every requirement carries a priority and the evidence to ask for, and every table can be copied into a spreadsheet.

The requirements are things a serious product category can satisfy and be asked to prove. Items that only some architectures offer are labelled Advanced, so you can decide whether they deserve weight in your scoring. If you are still choosing between products, read the best PKI solution buyer's guide first.

---

Table of Contents

1. Who this is for and how to use it
2. Before you write the RFP
3. The PKI requirements checklist
4. Weighted scoring model
5. Vendor questions to ask
6. Red flags in vendor answers
7. Proof-of-concept plan
8. Contract and exit clauses
9. Copy-ready RFP introduction
10. FAQ
11. References

---

Who this is for and how to use it

This guide is for security architects, PKI owners, infrastructure and procurement teams replacing or extending an existing PKI (often Microsoft AD CS), adding certificate lifecycle management, or preparing for shorter certificate lifetimes.

How to use it:

1. Run the scoping questions below and delete every requirement that does not apply to you.
2. Copy the tables into a spreadsheet with the same four columns: ID, Requirement, Priority, Evidence.
3. Convert Must items into pass/fail gates and Should items into scored criteria.
4. Add your own regulatory and internal-policy requirements; this template does not know them.
5. Send the same file to every vendor and require a written answer per ID with documentation links.

Priority legend:

• Must: a gate. Failing it removes the vendor, unless you accept a documented workaround.
• Should: scored. Most mature products satisfy these.
• Advanced: scored, optional. Differentiating capabilities that only some architectures provide. Include them only when your risk model requires them.

---

Before you write the RFP

Scope questions

• Which certificate populations are in scope: servers and load balancers, Kubernetes workloads, Windows endpoints and users, mobile devices, network equipment, IoT or OT devices, S/MIME mailboxes, code signing, SSH?
• Is the platform expected to replace your existing CA, sit in front of it, or broker public CAs as well?
• Which enrollment protocols do your systems already speak? Count them from real configurations, not from memory.
• What is your current certificate count, annual issuance volume and expected growth?
• Which public TLS certificates will need to follow the CA/Browser Forum schedule: 200-day maximum validity from 15 March 2026, 100 days from 15 March 2027, 47 days from 15 March 2029? (The schedule applies to publicly trusted TLS, not to a private CA, but many teams adopt short private lifetimes too.)

Inventory first

Before the RFP goes out, run a discovery pass: scan the network, query AD CS, list cloud provider certificates and read Kubernetes secrets. You will almost always find certificates nobody owns. A vendor cannot size a proposal without this number, and it becomes your PoC baseline.

Stakeholders

Name an owner for each: PKI/security (CA policy), infrastructure and platform teams (deployment targets), identity (AD, MDM), application owners, risk and audit (evidence), legal and procurement (contract, exit), and, if relevant, the OT or product security team that provisions devices.

Decision criteria

Agree the weights before reading any response (see the scoring model below). Decide in advance whether jurisdiction, certifications and key custody are gates or scores.

---

The PKI requirements checklist

Group 1: CA and issuance

Group 2: Enrollment

Group 3: Visibility and automation

Group 4: Key protection

Group 5: Use cases

Group 6: Governance

Group 7: Deployment and vendor

---

Weighted scoring model

Score each Should and Advanced criterion from 0 to 5, multiply by the weight, and sum. Apply Must items as pass/fail gates first.

0-5 scale.

Example weights. These are generic numbers for illustration only; set your own.

Worked example (made-up numbers). Vendor A scores averages of 4, 3, 4, 3, 3, 4, 4 across the seven groups in the order above: 0.15x4 + 0.15x3 + 0.20x4 + 0.15x3 + 0.10x3 + 0.15x4 + 0.10x4 = 0.60 + 0.45 + 0.80 + 0.45 + 0.30 + 0.60 + 0.40 = 3.60 out of 5. Vendor B averages 3, 4, 3, 4, 4, 3, 4: 0.45 + 0.60 + 0.60 + 0.60 + 0.40 + 0.45 + 0.40 = 3.50. A narrow gap like this tells you to let the proof of concept decide.

Tip: if you include Advanced items such as MPC-held CA keys or M-of-N quorum, give them a weight that reflects your risk model. Weighting them heavily when you have no such risk simply biases the result; weighting them at zero when you operate a high-value root is just as wrong.

---

Vendor questions to ask

Ask for written answers with documentation links, per requirement ID.

CA and issuance

1. Which CA hierarchy models do you support (offline root, online intermediates, imported CAs) and how is a CA decommissioned?
2. How do you publish and scale CRL and OCSP, and what is your documented availability for revocation endpoints?
3. Which external CAs can you broker today, and which are only on the roadmap?

Enrollment and automation

4. Which of ACME, EST, SCEP, CMP and Microsoft autoenrollment do you serve natively, and what are the documented limitations of each?
5. Do you support ACME Renewal Information, and does your own ACME client towards public CAs use it?
6. What is the maximum issuance rate you have measured, on what hardware, with what challenge validation, and is the test reproducible?
7. How does renewal behave when a certificate lifetime is shorter than your default renewal window?
8. Which deployment targets do you support, and what happens when a deployment fails mid-way?

Key protection

9. Where are CA keys generated and where do they live? Is any copy ever held in software?
10. Which HSMs and cloud KMS services are supported, and for which key algorithms?
11. How are post-quantum CA keys protected, and does that differ from classical keys?
12. If you offer threshold or MPC key custody, which algorithms does it cover, which does it not, and what is its production status?

Governance

13. Which operations can require multi-person approval, and can you set an M-of-N quorum?
14. How can an auditor verify that the audit log has not been altered or truncated?
15. Which fields appear in audit events, and how do they reach our SIEM?

Deployment and vendor

16. What are the RTO and RPO for each deployment option, and when did you last test a restore?
17. Who at the vendor can access our tenant, our CA data and our keys, under what authorization, and where are they located?
18. Which certifications and audit reports can you provide, with scope and date?
19. What happens to our data and configuration if we terminate, and in what format and timeframe do you return it?
20. Which components of your platform are open-source, third-party or subcontracted, and what is your policy on end-of-life?

---

Red flags in vendor answers

• "Supports all protocols" without a per-protocol documentation link or a note of limitations.
• 47-day readiness described as a trend or a marketing claim, with no tested volume or reproducible conditions.
• Rollback "available" but not demonstrable on a failed deployment.
• CA keys "in an HSM" with no statement about whether a software copy ever exists.
• An audit log described as "immutable" with no way for you to verify integrity.
• Post-quantum "support" that is a roadmap item, or applies only to the test environment.
• Pricing that cannot be estimated for your certificate volume, or that changes with automation volume in ways that penalize short lifetimes.
• No clear answer on who can reach your CA keys, or only a generic privacy policy in response.
• Reference customers who cannot be contacted or are for a different product line.
• A "yes" in the response with no matching line in the public documentation.

---

Proof-of-concept plan

Run a time-boxed PoC (two to four weeks) with pass/fail tests against your own systems. Document conditions and results.

If you included Advanced items, add: create a CA with threshold-held key and sign through it; run a quorum approval with M-of-N approvers; apply an IP- or time-based policy and confirm it denies out-of-policy requests.

---

Contract and exit clauses

• Key custody. The contract states who can use or access CA keys, under what authorization, and that the vendor cannot sign with them without your approval.
• Data export. On request and at termination, the vendor returns CA configuration, certificates, inventory and audit logs in documented open formats within a stated period.
• Key transition. Written support for migrating CA keys or re-issuing from a new CA, including revocation service continuity until the last issued certificate expires.
• Service levels. Availability for issuance and for revocation endpoints, support response times by severity, and credits for breach.
• Security and audit. Right to audit or receive audit reports (ISO 27001, SOC 2 or equivalent) annually, incident notification windows, and breach responsibilities.
• Subprocessors and jurisdiction. Disclosure and notification of changes in subprocessors, data location and governing law.
• Lifetime changes. Commitment to support changes in public certificate lifetimes and algorithm migration without extra licensing for the renewal volume.
• Termination. No penalty for exporting; reasonable transition support.

---

Copy-ready RFP introduction

[Organization] is seeking a platform for private PKI and certificate lifecycle management covering [number] certificates across [servers, workloads, endpoints, devices, signing]. The solution must operate private certificate authorities with CA keys protected in hardware or a managed key service, serve the enrollment protocols listed in Group 2, discover and inventory certificates from all sources, automate renewal and deployment at validity periods of 47 days or less, provide role-based governance with a verifiable audit trail, and be deployable as [SaaS / on-premises / hybrid] under [jurisdiction]. Vendors must answer each numbered requirement in writing with documentation references, state any limitation, and take part in a proof of concept using [organization]'s systems. Responses will be scored on the weighted criteria in Appendix [X]; requirements marked Must are mandatory.

---

FAQ

What should a PKI RFP include? It should include scope and volumes, requirements grouped by CA and issuance, enrollment protocols, visibility and automation, key protection, use cases, governance, and deployment and vendor terms. Add a scoring model, a PoC plan and exit clauses. This template provides each of these.

How do I write PKI requirements that are vendor-neutral? Write each requirement as a capability you can test (for example "ACME per RFC 8555 with dns-01") rather than a product feature name, and ask for evidence. Mark differentiating capabilities as Advanced so they are scored, not required.

Which items should be mandatory in a PKI RFP? Typically HSM- or KMS-protected non-exportable CA keys, revocation, the enrollment protocols you already use, discovery and automated renewal, RBAC, an exportable audit log with SIEM forwarding, HA/DR, and a data-export clause. Everything else depends on your estate and risk.

How should I test 47-day certificate readiness? Run a staging test at 47-day validity with at least a few hundred certificates, measure renewal success, alert volume and issuance rate, and check that renewals do not loop. The CA/Browser Forum schedule applies to public TLS, but the same automation requirement applies to any short-lived certificate.

Should I require post-quantum certificates in a PKI RFP? Include them as Should for private CAs, with ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) support, ideally hybrid or composite, and ask how PQC CA keys are protected. Public TLS does not accept them yet, so do not require them there.

Should MPC or threshold custody of CA keys be mandatory? Only if your threat model requires that no single HSM, administrator or host can use a CA key. It is a differentiating capability that only some vendors offer, so score it as Advanced rather than rejecting vendors on it.

How long should an RFP response period be? Allow three to four weeks for written responses and two to four weeks for a PoC with the shortlisted vendors. Shorter PoCs rarely cover discovery, renewal at volume and failure testing.

Can I turn these tables into a spreadsheet? Yes. Copy each table into your spreadsheet tool, keep the ID column, and add columns for each vendor's answer, score and evidence link.

---

Conclusion

A good PKI RFP is a list of testable requirements, a clear scoring model and a short proof of concept that tries to break the vendor's claims. Use the Must items to filter, the Should items to differentiate, and the Advanced items only where your risk model justifies them. Then verify every response in your own environment.

DuoKey publishes its PKI capabilities against these same criteria on the comparison pages and in the buyer's guide. To run the PoC plan above on DuoKey, start a trial or see the certificates management product page.

---

References

• CA/Browser Forum: Baseline Requirements for publicly trusted TLS server certificates (Ballot SC-081)
• NIST FIPS 204: ML-DSA
• NIST FIPS 205: SLH-DSA
• RFC 8555: ACME
• RFC 7030: EST
• RFC 8894: SCEP
• RFC 4210: CMP and RFC 9483: Lightweight CMP Profile
• RFC 6960: OCSP
• RFC 3161: Time-Stamp Protocol
• RFC 9881: ML-DSA in X.509
• Microsoft Learn: Active Directory Certificate Services overview
• DuoKey Docs: PKI and SSL overview
• DuoKey Docs: Enrollment protocols