# PKI and Certificate Architecture: [Organisation or platform name]

> Architecture for an organisation's public key infrastructure (PKI) and certificate lifecycle: certificate use
> cases, trust model and CA hierarchy, CA roles, key ceremonies and HSMs, certificate profiles, issuance and ACME
> automation, validity and renewal under the CA/Browser Forum schedule, revocation (CRL and OCSP), internal mTLS and
> workload identity (SPIFFE), inventory and monitoring, compromise and recovery, crypto agility and post-quantum
> readiness, and alignment with a certificate policy and certification practice statement (CP/CPS). Certificate and
> CRL profiles follow RFC 5280. The CP/CPS outline follows RFC 3647. Public TLS rules follow the CA/Browser Forum
> TLS Baseline Requirements, including Ballot SC-081v3 (maximum validity 200 days from 2026-03-15, 100 days from
> 2027-03-15, 47 days from 2029-03-15). Automation follows ACME (RFC 8555). Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Write one architecture for the organisation's PKI estate: the public certificates you buy or obtain, and the private CAs you run or rent. A formal CP and CPS, if you need them, are separate documents; section 14 maps this design to their RFC 3647 outline.
- Fill section 2 (use cases) first. Each use case has a different trust anchor, lifetime and revocation need, and most design mistakes come from forcing one hierarchy to serve all of them.
- Assume short lifetimes everywhere. Public TLS lifetimes are falling to 47 days by 2029, so anything that is renewed by hand today will fail. Design for full automation, then handle the exceptions.
- Cross-reference instead of repeating: IAM Solution Design (`security/iam-solution-design`) for smart cards and device identity in sign-in, Zero Trust Architecture Plan (`security/zero-trust-architecture`), Security Architecture (`security/security-architecture`), Supply chain security (`security/supply-chain-security`) for code signing, Cloud Security Reference Patterns (`security/cloud-security-reference-patterns`) for cloud KMS and managed CA services.
- Pitfall: no inventory. Most certificate outages are expiries of certificates nobody knew existed.
-->

## Document control

<!-- Guidance: Identify the PKI estate, its owner and the policy authority. A new root CA, a change of HSM platform or a change of algorithm family is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [PKI-ARC-001] |
| PKI name | [Name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@pki-architect] |
| Policy authority | [*Example:* PKI policy board chaired by the CISO] |
| Approvers/reviewers | [@ciso], [@infrastructure-lead], [@platform-lead], [@internal-audit] |
| Public CAs used | [CA vendor or ACME service] |
| Private CA platform | [Product or managed service, HSM model and validation level] |
| Related CP/CPS | [Document IDs, or "not required" with reason] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| PKI policy authority | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Infrastructure and platform | [@name] | [Decision] | YYYY-MM-DD |
| Internal audit (consulted) | [@name] | [Comments] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added 200/100/47-day renewal plan and ACME coverage targets |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; new offline root ceremony scheduled |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, drivers and principles](#1-scope-drivers-and-principles)
2. [Certificate use cases](#2-certificate-use-cases)
3. [Trust model and CA hierarchy](#3-trust-model-and-ca-hierarchy)
4. [CA roles, key ceremonies and HSMs](#4-ca-roles-key-ceremonies-and-hsms)
5. [Certificate profiles](#5-certificate-profiles)
6. [Issuance, validation and automation](#6-issuance-validation-and-automation)
7. [Validity, renewal and rotation](#7-validity-renewal-and-rotation)
8. [Revocation and status checking](#8-revocation-and-status-checking)
9. [Internal mTLS and workload identity](#9-internal-mtls-and-workload-identity)
10. [Inventory, discovery and monitoring](#10-inventory-discovery-and-monitoring)
11. [Compromise, incident and recovery](#11-compromise-incident-and-recovery)
12. [Crypto agility and post-quantum readiness](#12-crypto-agility-and-post-quantum-readiness)
13. [Operations, roles and metrics](#13-operations-roles-and-metrics)
14. [CP/CPS alignment](#14-cpcps-alignment)
15. [Roadmap, risks and acceptance](#15-roadmap-risks-and-acceptance)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope, drivers and principles

<!-- Guidance: State what the PKI covers and why the design is being done now. Questions: Did an expiry outage, an audit, a CA distrust event or the falling public lifetimes trigger it? Pitfall: scoping only web TLS and forgetting devices, code signing and internal service certificates. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Public TLS for customer-facing domains | Customer-held certificates in B2B integrations (interface only) |
| *Example:* Private CA for internal TLS, mTLS, devices, smart cards | Personal email encryption keys held by users |
| *Example:* Code signing for internal software and container images | Third-party SaaS certificates managed by the vendor |
| [Item] | [Item] |

### 1.2 Drivers

| ID | Driver | Consequence for the design |
|---|---|---|
| PKD-001 *(Example)* | CA/Browser Forum Ballot SC-081v3 cuts public TLS lifetime to 200, then 100, then 47 days | Every public certificate must renew automatically; manual renewals end before 2027-03-15 |
| PKD-002 *(Example)* | Two production outages from expired internal certificates last year | Central inventory, expiry alerts and ownership |
| PKD-003 *(Example)* | Public CAs removing client authentication from public TLS certificates, following browser root program policy | mTLS client certificates move to the private CA |
| PKD-004 *(Example)* | Post-quantum migration guidance from national agencies | Algorithm inventory and agility plan (section 12) |
| [PKD-NNN] | [Driver] | [Consequence] |

### 1.3 Principles

| ID | Principle | Consequence |
|---|---|---|
| PKP-001 *(Example)* | Public trust only where the relying party is outside our control | Internal services never use public certificates |
| PKP-002 *(Example)* | One hierarchy per trust purpose | Separate issuing CAs for internal TLS, client and device, workload identity and code signing |
| PKP-003 *(Example)* | Automate issuance and renewal; humans approve policy, not certificates | ACME or platform-native issuance for at least 95% of certificates |
| PKP-004 *(Example)* | Short lifetimes instead of reliance on revocation | Internal workload certificates live hours to days |
| PKP-005 *(Example)* | Private keys never leave their protected boundary | CA keys in HSMs; workload keys generated on the workload |
| [PKP-NNN] | [Principle] | [Consequence] |

## 2. Certificate use cases

<!-- Guidance: List every use case with its relying party, trust anchor, lifetime and volume. Questions: Who validates this certificate and what trust store do they use? How many certificates per year? Pitfall: mixing server and client authentication in one certificate profile. -->

| ID | Use case | Relying party | Trust anchor | Typical lifetime | Volume per year |
|---|---|---|---|---|---|
| UC-001 *(Example)* | Public web and API TLS | Browsers, customer systems | Public CA in browser root stores | Public maximum (section 7.1) | 1,200 |
| UC-002 *(Example)* | Internal service TLS | Internal clients | Private root distributed to managed devices and images | 30 days | 40,000 |
| UC-003 *(Example)* | Service-to-service mTLS | Service mesh sidecars | Mesh or SPIFFE trust bundle | 1 to 24 hours | Millions (automated) |
| UC-004 *(Example)* | Partner B2B mTLS | Partner gateways | Private client CA, pinned by partner | 1 year (partner limit) | 150 |
| UC-005 *(Example)* | Device identity (laptops, mobiles, IoT) | Network access control, VPN, IdP | Private device CA | 1 year, renewed automatically | 15,000 |
| UC-006 *(Example)* | Smart card or derived credential for staff | IdP, Windows sign-in | Private user CA | 3 years | 3,000 |
| UC-007 *(Example)* | Code and container signing | Build pipeline verifiers, endpoints | Private code-signing CA or a public code-signing CA for distributed software | Private CA: 1 to 3 years; public code-signing CA: at most 460 days (CA/B Forum Code Signing Baseline Requirements, for certificates issued from 2026-03-01); timestamp every signature | 50 |
| UC-008 *(Example)* | Email signing and encryption (S/MIME) | Mail clients | Public S/MIME CA under the CA/B Forum S/MIME requirements | Per S/MIME rules | 500 |
| [UC-NNN] | [Use case] | [Relying party] | [Anchor] | [Lifetime] | [Volume] |

## 3. Trust model and CA hierarchy

<!-- Guidance: Draw the hierarchy and explain why each CA exists. Questions: Is the root offline? Which issuing CAs are name-constrained? Who distributes the root to trust stores? Pitfall: one online root signing everything, so any compromise means rebuilding all trust. -->

### 3.1 Hierarchy

The private hierarchy has an offline root and purpose-specific issuing CAs; public certificates come from external CAs and never chain to the private root.

```mermaid
flowchart TB
  ROOT[Private root CA, offline, HSM, 20-year validity]
  ROOT --> TLS[Issuing CA: internal TLS, name-constrained to internal domains]
  ROOT --> CLI[Issuing CA: client and device]
  ROOT --> USR[Issuing CA: staff smart cards]
  ROOT --> CS[Issuing CA: code signing]
  TLS --> ACME[Internal ACME service]
  CLI --> MDM[Device management enrolment, SCEP or EST]
  ROOT --> WLI[Issuing CA: workload identity intermediate]
  WLI -.->|upstream authority| WL[Workload identity issuer, SPIFFE trust domain]
  PUB[Public CA via ACME] --> WEB[Public web and API endpoints]
```

### 3.2 CA register

| CA | Type | Key algorithm | Validity | Online or offline | Constraints | Owner |
|---|---|---|---|---|---|---|
| Private root *(Example)* | Root | ECDSA P-384 | 20 years | Offline, powered on only for ceremonies | None | PKI policy authority |
| Internal TLS issuing CA *(Example)* | Subordinate | ECDSA P-256 | 5 years | Online, HSM | Name constraints to `corp.example` and `internal.example`; serverAuth EKU only | PKI team |
| Client and device issuing CA *(Example)* | Subordinate | ECDSA P-256 | 5 years | Online, HSM | clientAuth EKU only | PKI team |
| Workload identity intermediate *(Example)* | Subordinate | ECDSA P-256 | 2 years | Online, HSM or cloud KMS | URI SAN constraint to approved SPIFFE trust domains; serverAuth and clientAuth EKUs | Platform team with PKI oversight |
| Code-signing issuing CA *(Example)* | Subordinate | RSA 3072 | 5 years | Online, HSM with dual control for issuance | codeSigning EKU only | PKI team and release engineering |
| [CA] | [Type] | [Algorithm] | [Validity] | [Mode] | [Constraints] | [Owner] |

### 3.3 Trust distribution

| Trust store | How the private root is distributed | Owner |
|---|---|---|
| Managed laptops and servers *(Example)* | Device management and configuration management baseline | Endpoint team |
| Container base images *(Example)* | Added at image build; images rebuilt on root change | Platform team |
| Language runtimes with their own stores (Java, Python, Node) *(Example)* | Image build step that adds the root to each runtime store | Platform team |
| Partner systems *(Example)* | Root and client issuing CA certificate shared out of band, fingerprint confirmed by phone | Integration owner |
| [Store] | [Method] | [Owner] |

## 4. CA roles, key ceremonies and HSMs

<!-- Guidance: Define who can do what on the CAs and how CA keys are generated, stored, backed up and used. Questions: Can one person issue a code-signing certificate alone? Where are the root key backups? Pitfall: an HSM partition whose admin credentials sit in one engineer's password manager. -->

### 4.1 Trusted roles

| Role | Responsibilities | Separation rule |
|---|---|---|
| Policy authority *(Example)* | Approves CP, profiles, new CAs, exceptions | Not a CA operator |
| CA administrator *(Example)* | Configures CA software, templates and profiles | Cannot approve own changes |
| CA operator or registration officer *(Example)* | Approves non-automated requests (code signing, partner mTLS) | Cannot administer CA configuration |
| HSM custodian *(Example)* | Holds one share of HSM activation credentials | M of N, for example 3 of 5; custodians in at least two locations |
| Auditor *(Example)* | Reviews logs and ceremony records | Read-only; independent of PKI team |
| [Role] | [Responsibilities] | [Rule] |

### 4.2 Key ceremony requirements

- Script every ceremony in advance, run it with at least [*Example:* two custodians, one witness and one auditor], record it on video where policy requires, and keep signed minutes.
- Generate CA keys inside the HSM; never import a CA key generated elsewhere.
- Back up the root key only as HSM-encrypted backups split across custodians and stored in [two] secure sites.
- Keep the offline root powered off and in a safe between ceremonies; plan ceremonies for issuing CA renewals and CRL signing (section 8.2).

### 4.3 HSM and key storage

| Item | Design |
|---|---|
| HSM validation *(Example)* | FIPS 140-3 Level 3 validated modules for root and issuing CAs (check the NIST CMVP certificate for the exact firmware) |
| Cloud option *(Example)* | Managed private CA service backed by provider HSMs for issuing CAs; root stays on premises |
| Key usage logging *(Example)* | Every sign operation logged to SIEM; alerts on signing outside the CA service account |
| Key lifetimes *(Example)* | Set per SP 800-57 Part 1 Rev. 5 cryptoperiod guidance and the CA validity in section 3.2 |
| [Item] | [Design] |

## 5. Certificate profiles

<!-- Guidance: Define one profile per use case with fields per RFC 5280. Questions: Which extensions are critical? Which subject fields are allowed? Pitfall: putting personal or internal data in the subject that then appears in public CT logs. -->

| Profile ID | Use case | Key | Validity | Key usage | Extended key usage | Subject and SAN rules | Status pointers |
|---|---|---|---|---|---|---|---|
| PRF-001 *(Example)* | UC-001 public TLS | ECDSA P-256 or RSA 2048+ | Public maximum | digitalSignature (keyEncipherment also permitted for RSA keys) | serverAuth | DNS SANs only; no internal names | CRL distribution point from the public CA |
| PRF-002 *(Example)* | UC-002 internal TLS | ECDSA P-256 | 30 days | digitalSignature | serverAuth | Internal DNS SANs within name constraints | CRL; OCSP not provided |
| PRF-003 *(Example)* | UC-003 workload mTLS | ECDSA P-256 | 1 hour | digitalSignature | serverAuth, clientAuth | URI SAN with SPIFFE ID, for example `spiffe://prod.example/ns/payments/sa/api` | None (short-lived) |
| PRF-004 *(Example)* | UC-005 device | ECDSA P-256 in TPM or secure enclave | 1 year | digitalSignature | clientAuth | Device ID in SAN; no user names | CRL |
| PRF-005 *(Example)* | UC-007 code signing, private CA | RSA 3072 in HSM | 3 years (a public code-signing certificate is limited to 460 days) | digitalSignature | codeSigning | Organisation name | CRL; timestamp each signature |
| [PRF-NNN] | [Use case] | [Key] | [Validity] | [KU] | [EKU] | [Rules] | [Pointers] |

Profile rules for every profile: unique serial numbers with at least 64 bits of randomness where the CA/B Forum requirements apply, Basic Constraints set correctly, Authority and Subject Key Identifiers present, and no deprecated algorithms (SHA-1, RSA under 2048). The TLS Baseline Requirements restrict public TLS keys to RSA of at least 2048 bits and ECDSA on P-256, P-384 or P-521.

## 6. Issuance, validation and automation

<!-- Guidance: Define how each profile is requested, validated and delivered, and which protocol automates it. Questions: How does a team get a certificate in under five minutes without a ticket? How is domain control validated for public certificates? Pitfall: wildcard certificates copied to dozens of servers because issuance is slow. -->

### 6.1 Issuance channels

| Profile | Channel | Validation | Approval |
|---|---|---|---|
| PRF-001 *(Example)* | ACME (RFC 8555) client on load balancers and ingress controllers; DNS-01 through DNS provider API | Domain control validation by the public CA | Automatic within CAA policy |
| PRF-002 *(Example)* | Internal ACME service or Kubernetes certificate controller | Requester's workload identity and namespace policy | Automatic |
| PRF-003 *(Example)* | SPIFFE Workload API (section 9) | Node and workload attestation | Automatic |
| PRF-004 *(Example)* | EST (RFC 7030) or SCEP through device management | Device enrolment record | Automatic for managed devices |
| PRF-005 *(Example)* | Signing service in the pipeline; key never leaves HSM | Pipeline identity plus release approval | Two-person approval |
| [Profile] | [Channel] | [Validation] | [Approval] |

### 6.2 Public CA controls

- Publish DNS CAA records (RFC 8659) that name only the approved public CAs, and, where the CA supports it, restrict issuance to your ACME account.
- Keep ACME account keys in a secrets manager, one account per environment, rotated on staff change.
- Plan for domain validation reuse periods that shrink with SC-081v3 (section 7.1): automate DNS-01 or HTTP-01 so revalidation needs no human.
- Use at least two public CAs, configured and tested, so a CA outage or distrust event does not stop renewals.

## 7. Validity, renewal and rotation

<!-- Guidance: Set lifetimes per profile and make renewal automatic and early. Questions: What happens to a certificate that fails renewal? How long before expiry does renewal start? Pitfall: renewal at 30 days left on a 47-day certificate, which leaves no time to fix a failure. -->

### 7.1 Public TLS schedule (CA/Browser Forum Ballot SC-081v3)

| Certificates issued on or after | Maximum validity | Maximum reuse of domain or IP validation | Design consequence *(Example)* |
|---|---|---|---|
| 2026-03-15 | 200 days | 200 days | Renew every 4 months at most; already in force |
| 2027-03-15 | 100 days | 100 days | Renew about every 2 months; manual processes no longer viable |
| 2029-03-15 | 47 days | 10 days | Renew about monthly; domain validation effectively per issuance, so DNS automation is mandatory |

The ballot also limits reuse of validated subject identity information (organisation details) to 398 days from 2026-03-15. Certificates issued before each date keep their original term. Check the current TLS Baseline Requirements (section 6.3.2 for validity, section 4.2.1 for reuse) at cabforum.org before relying on these values.

### 7.2 Renewal policy

| Profile | Renew when remaining life is below | Retry and alert | Rotation of key |
|---|---|---|---|
| PRF-001 *(Example)* | One third of lifetime, or as directed by the CA through ACME Renewal Information (ARI, RFC 9773) | Retry hourly; alert owner at half the renewal window; page at 7 days | New key every renewal |
| PRF-002 *(Example)* | One third of lifetime | Platform alert at 7 days | New key every renewal |
| PRF-003 *(Example)* | Half of lifetime | Workload API pushes new SVID | New key every renewal |
| PRF-004 *(Example)* | 30 days | Device management compliance report | New key in TPM |
| [Profile] | [Threshold] | [Alert] | [Rotation] |

### 7.3 Hard-coded trust and pinning

List every system that pins a certificate or a public key, because shorter lifetimes break pinning. Replace leaf pinning with trust-anchor configuration or pin to the issuing CA with a documented backup pin.

## 8. Revocation and status checking

<!-- Guidance: Define how revocation works per use case, how fast, and how relying parties check status. Questions: Who can request revocation at 03:00? Does any relying party fail closed when status is unavailable? Pitfall: depending on OCSP for public TLS after public CAs have stopped running it. -->

### 8.1 Status mechanisms

The CA/Browser Forum made OCSP optional and CRLs mandatory for publicly trusted TLS CAs (Ballot SC063, effective March 2024), and some public CAs have stopped OCSP; Let's Encrypt ended its OCSP service on 2025-08-06. Design public TLS on CRLs and short lifetimes. For the private PKI, choose per use case:

| Use case | Mechanism | Publication or freshness | Behaviour when unavailable |
|---|---|---|---|
| Public TLS *(Example)* | CRL from the public CA; browsers use their own revocation sets | Per Baseline Requirements | Browser-controlled |
| Internal TLS *(Example)* | CRL from the issuing CA, published to two HTTP locations | Every [24] hours; immediately on key-compromise revocation | Fail open for 24 hours, then fail closed on critical systems |
| Workload mTLS *(Example)* | None: lifetime of 1 hour is the revocation control; remove the workload's registration entry to stop renewal | Not applicable | Not applicable |
| Device and VPN *(Example)* | CRL checked by VPN and network access control; OCSP responder if the access product requires it | Every [4] hours | Fail closed |
| Code signing *(Example)* | CRL with timestamp-aware validation | Every [24] hours | Fail closed for install-time checks |
| [Use case] | [Mechanism] | [Freshness] | [Behaviour] |

### 8.2 Revocation process

| Reason | Who may request | Target time to revoke | Evidence |
|---|---|---|---|
| Private key compromise *(Example)* | Owner, security operations, PKI team | 4 hours internal; public CAs must act within 24 hours under the Baseline Requirements | Incident ticket |
| Workload decommissioned *(Example)* | Owner or automation | 1 business day | Change record |
| Misissuance *(Example)* | PKI team | 24 hours | Investigation record |
| [Reason] | [Requester] | [Time] | [Evidence] |

The offline root signs its CRL at each ceremony; set its next-update interval long enough (*Example:* 12 months) to reach the next scheduled ceremony with margin.

## 9. Internal mTLS and workload identity

<!-- Guidance: Define how services prove identity to each other. Questions: Do you run a service mesh? Do workloads span clusters and clouds? Pitfall: one long-lived shared client certificate for all services in a namespace. -->

| Topic | Design |
|---|---|
| Identity format *(Example)* | SPIFFE ID per workload: `spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>` (one trust domain per environment, so the environment is not repeated in the path), for example `spiffe://prod.example/ns/payments/sa/api` as in PRF-003 |
| Issuer *(Example)* | SPIRE server per trust domain (SPIFFE and SPIRE are CNCF graduated projects); mesh control plane consumes SPIRE or uses its built-in CA, chained to a dedicated workload intermediate under the private root (not to the serverAuth-only internal TLS CA, whose EKU and name constraints do not fit workload SVIDs) |
| Attestation *(Example)* | Node attestation by cloud instance identity or Kubernetes service account token; workload attestation by namespace, service account and image digest |
| Document types *(Example)* | X.509-SVID for mTLS; JWT-SVID only where a proxy breaks TLS, with short expiry and audience |
| Trust bundles and federation *(Example)* | One trust domain per environment; federation between production clusters in different clouds through SPIFFE bundle endpoints |
| Authorisation *(Example)* | mTLS proves identity; an authorisation policy decides which SPIFFE IDs may call which service (see `system-design/design-authorization-service`) |
| Cloud federation *(Example)* | Exchange JWT-SVIDs for cloud credentials through workload identity federation, removing static cloud keys |
| [Topic] | [Design] |

The IAM Solution Design (`security/iam-solution-design`, section 11) owns the policy for non-human identities; this section owns the certificate mechanics.

## 10. Inventory, discovery and monitoring

<!-- Guidance: Know every certificate, its owner and its expiry. Questions: Can you list every certificate that expires in the next 14 days, with its owner? Pitfall: an inventory built once by a scan and never reconciled. -->

### 10.1 Inventory fields

| Field | Source | Notes |
|---|---|---|
| Subject, SANs, serial, issuer, validity *(Example)* | CA records, network scans, cloud certificate services | Reconcile daily |
| Key algorithm and size *(Example)* | Same | Feeds section 12 |
| Owner team and service *(Example)* | Service catalogue tag on the deploying resource | Required at issuance |
| Deployment locations *(Example)* | Load balancers, ingress, hosts, appliances | One certificate in many places is a risk flag |
| Issuance channel and auto-renewal status *(Example)* | ACME client, controller, manual | Manual certificates tracked to zero |
| [Field] | [Source] | [Notes] |

### 10.2 Monitoring

| ID | Monitor | Threshold | Action |
|---|---|---|---|
| MON-001 *(Example)* | Expiry of any production certificate | 14 days (7 for public TLS once at 47 days) | Page owner |
| MON-002 *(Example)* | Certificate Transparency logs for our domains (RFC 6962, CT v2 in RFC 9162) | Any certificate from a CA not in CAA, or unknown SAN | Security investigation |
| MON-003 *(Example)* | Renewal failures in ACME clients and controllers | Two consecutive failures | Ticket to owner |
| MON-004 *(Example)* | CRL publication freshness | Older than next-update minus 6 hours | Page PKI on call |
| MON-005 *(Example)* | HSM health and sign errors | Any error | Page PKI on call |
| [MON-NNN] | [Monitor] | [Threshold] | [Action] |

## 11. Compromise, incident and recovery

<!-- Guidance: Plan for key compromise at each level of the hierarchy, CA distrust and mass revocation. Questions: How long to replace every certificate under one issuing CA? Pitfall: a recovery plan that assumes manual reissue of thousands of certificates. -->

| Scenario | Impact | Response | Target recovery |
|---|---|---|---|
| Leaf key compromise *(Example)* | One service | Revoke, reissue with new key, investigate | 4 hours |
| Issuing CA key compromise *(Example)* | All certificates under that CA | Revoke issuing CA at root ceremony; stand up a new issuing CA from pre-staged ceremony script; mass reissue through automation | 48 hours for automated profiles |
| Root key compromise *(Example)* | Entire private PKI | Build new root; redistribute trust; reissue everything; remove old root from all stores | [Weeks]; rehearse annually |
| Public CA distrusted by browsers *(Example)* | All public certificates from that CA | Switch ACME configuration to secondary CA (section 6.2); reissue | Before distrust date |
| Mass revocation by a public CA after misissuance *(Example)* | Many public certificates within days | Reissue through ACME; ARI signals early renewal | Within the CA's revocation window |
| [Scenario] | [Impact] | [Response] | [Target] |

Link the scenarios to the Incident Response Plan (`compliance/incident-response-plan`) and the Disaster Recovery Plan (`ops/disaster-recovery-plan`), including HSM backup restore.

## 12. Crypto agility and post-quantum readiness

<!-- Guidance: Make algorithm change routine and plan the move to post-quantum algorithms. Questions: Which systems cannot handle a new algorithm? Which data must stay confidential for 10 years or more? Pitfall: waiting for a deadline before building the inventory. -->

- Keep algorithms in configuration, not code: profiles, ACME clients and libraries must switch algorithm without a release where possible.
- Maintain the algorithm inventory from section 10 and rank systems by how long their data or signatures must stay trustworthy.
- Track NIST post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), published August 2024. NIST IR 8547, an initial public draft (November 2024) at the time of writing, sets out a proposed transition timeline for quantum-vulnerable algorithms; check its current status at csrc.nist.gov.
- Prioritise key establishment first (hybrid post-quantum key exchange in TLS, which protects against harvest-now-decrypt-later), then signatures where long-lived trust is needed (roots, code signing, firmware).
- Public TLS certificates can use only the algorithms the Baseline Requirements allow; follow browser root program announcements for post-quantum certificates rather than issuing them ahead of support.

| ID | System | Current algorithm | Constraint | Target | Date |
|---|---|---|---|---|---|
| PQC-001 *(Example)* | Private root and issuing CAs | ECDSA P-384 / P-256 | HSM firmware support for ML-DSA | Parallel ML-DSA hierarchy for pilot | YYYY-MM-DD |
| PQC-002 *(Example)* | Internal TLS key exchange | X25519 | Library versions | Hybrid key exchange enabled | YYYY-MM-DD |
| [PQC-NNN] | [System] | [Current] | [Constraint] | [Target] | YYYY-MM-DD |

## 13. Operations, roles and metrics

<!-- Guidance: Name who runs the PKI day to day and how health is measured. Pitfall: the PKI run by one person who also holds every HSM credential. -->

### 13.1 RACI

| Activity | PKI team | Platform team | Service owners | Security operations | Policy authority |
|---|---|---|---|---|---|
| Profile and CA changes *(Example)* | R | C | I | C | A |
| Automated issuance and renewal *(Example)* | A | R | I | I | I |
| Certificate ownership and deployment *(Example)* | C | C | A, R | I | I |
| Revocation on compromise *(Example)* | R | C | C | A | I |
| CT and expiry monitoring *(Example)* | A | R | I | R | I |
| Key ceremonies *(Example)* | R | I | I | C | A |

### 13.2 Metrics

| ID | Metric | Target |
|---|---|---|
| PKM-001 *(Example)* | Certificates issued through automation | 95% (public TLS 100% before 2027-03-15) |
| PKM-002 *(Example)* | Production incidents caused by expiry | Zero per quarter |
| PKM-003 *(Example)* | Certificates without owner in inventory | Zero |
| PKM-004 *(Example)* | Median time to issue an internal TLS certificate | Under 5 minutes |
| PKM-005 *(Example)* | Time to reissue all certificates under one issuing CA (rehearsal) | Under 48 hours |
| [PKM-NNN] | [Metric] | [Target] |

## 14. CP/CPS alignment

<!-- Guidance: If you publish or audit against a CP and CPS, map this design to the RFC 3647 outline so reviewers find each topic. Pitfall: a CPS copied from another organisation that describes practices you do not follow. -->

RFC 3647 defines a nine-part outline for certificate policies and certification practice statements. Map each part to this design and to the operational documents that hold the detail.

| RFC 3647 part | Topic (paraphrased) | Where it is covered |
|---|---|---|
| 1 | Introduction: PKI participants, certificate usage, policy administration | Sections 1, 2, 4.1 |
| 2 | Publication and repository responsibilities | Section 8.1 (CRL locations), 3.3 (trust distribution) |
| 3 | Identification and authentication of subscribers | Section 6.1 (validation per profile) |
| 4 | Certificate life-cycle operational requirements | Sections 6, 7, 8 |
| 5 | Facility, management and operational controls | Sections 4, 13; site security documents |
| 6 | Technical security controls (keys, HSMs, cryptographic modules) | Sections 4.3, 5, 12 |
| 7 | Certificate, CRL and OCSP profiles | Section 5, 8.1 |
| 8 | Compliance audit and other assessments | [Internal audit plan; public CA audit reports for external CAs] |
| 9 | Other business and legal matters | [Legal and contract documents] |

## 15. Roadmap, risks and acceptance

<!-- Guidance: Plan the work to reach the target, list the risks and define acceptance criteria. Pitfall: treating the 2027 and 2029 lifetime dates as far away; appliance and legacy renewals take the longest. -->

### 15.1 Roadmap

| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| 1: Inventory *(Example)* | Discovery across networks, clouds and CAs; owners assigned | 100% of production certificates owned | YYYY-MM-DD |
| 2: Public automation *(Example)* | ACME for every public endpoint; second CA configured; CAA records | No manual public renewals | Before 2027-03-15 |
| 3: Private PKI rebuild *(Example)* | New offline root, purpose-specific issuing CAs, internal ACME | Old internal CA retired | YYYY-MM-DD |
| 4: Workload identity *(Example)* | SPIFFE issuer in production clusters | 90% of service calls on mTLS | YYYY-MM-DD |
| 5: Agility and PQC pilot *(Example)* | Hybrid key exchange; ML-DSA pilot hierarchy | Pilot report approved | YYYY-MM-DD |

### 15.2 Risks

| ID | Risk | Mitigation | Owner |
|---|---|---|---|
| RSK-001 *(Example)* | Appliances that cannot run ACME | Vendor automation API, front with automated load balancer, or replace | [@infrastructure-lead] |
| RSK-002 *(Example)* | Partner systems pin our certificates | Move pins to CA level; notify partners 90 days ahead | [@integration-lead] |
| RSK-003 *(Example)* | HSM custodian unavailable for emergency ceremony | 3 of 5 quorum across two sites; deputies trained | [@pki-architect] |
| [RSK-NNN] | [Risk] | [Mitigation] | [@owner] |

### 15.3 Acceptance criteria

| Req ID | Requirement | Verification | Acceptance criterion |
|---|---|---|---|
| PKI-REQ-001 *(Example)* | Public certificates renew without humans | Inventory report and ACME logs | 100% of public certificates issued by ACME in the last 90 days |
| PKI-REQ-002 *(Example)* | Expiry never causes an outage | Incident records | No expiry incidents for two quarters |
| PKI-REQ-003 *(Example)* | Issuing CA compromise is recoverable | Rehearsal | All automated profiles reissued under a new CA in under 48 hours |
| PKI-REQ-004 *(Example)* | Only approved CAs issue for our domains | CAA check and CT monitoring | CAA present on all zones; no unexplained CT entries |
| [PKI-REQ-NNN] | [Requirement] | [Method] | [Criterion] |

## 16. Glossary and references

<!-- Guidance: Define terms and record exact versions consulted, with the date checked. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| CA | Certification authority that signs certificates |
| CP, CPS | Certificate policy (what is required) and certification practice statement (how a CA meets it) |
| ACME | Automatic Certificate Management Environment protocol (RFC 8555) |
| ARI | ACME Renewal Information, which lets a CA suggest when to renew (RFC 9773) |
| CAA | DNS record naming the CAs allowed to issue for a domain (RFC 8659) |
| CRL, OCSP | Certificate revocation list; Online Certificate Status Protocol |
| CT | Certificate Transparency, public append-only logs of issued certificates |
| HSM | Hardware security module that protects private keys |
| SVID | SPIFFE Verifiable Identity Document (X.509 or JWT) |
| DCV | Domain control validation |
| ML-KEM, ML-DSA, SLH-DSA | NIST post-quantum key encapsulation and signature algorithms (FIPS 203, 204, 205) |

### 16.2 References

| Reference | Version or date | Use |
|---|---|---|
| RFC 5280, Internet X.509 PKI Certificate and CRL Profile | May 2008, with updating RFCs | Certificate and CRL profiles |
| RFC 3647, Certificate Policy and Certification Practices Framework | November 2003 (Informational) | CP/CPS outline |
| CA/Browser Forum, TLS Baseline Requirements, cabforum.org | Version 2.3.1 (checked 2026-10-23) | Validity, reuse, revocation, key rules |
| CA/Browser Forum Ballot SC-081v3 | Adopted April 2025 | 200, 100 and 47-day schedule |
| CA/Browser Forum Ballot SC063 | Effective March 2024 | OCSP optional, CRLs required |
| CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates (section 6.3.2, Ballot CSC-31) | Version 3.11.0 (checked 2026-10-23) | 460-day maximum for public code-signing certificates from 2026-03-01 |
| Let's Encrypt, "OCSP service has reached end of life" | 2025-08-06 | Industry move to CRLs |
| RFC 8555 (ACME), RFC 9773 (ARI), RFC 7030 (EST), RFC 8659 (CAA) | 2019, 2025, 2013, 2019 | Automation and issuance control |
| RFC 6962 and RFC 9162, Certificate Transparency | 2013, 2021 (both Experimental) | CT monitoring |
| SPIFFE specifications, spiffe.io; SPIRE | Current; CNCF graduated 2022 | Workload identity |
| FIPS 140-3, Security Requirements for Cryptographic Modules | March 2019 | HSM validation |
| NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management | May 2020 | Cryptoperiods |
| FIPS 203, 204, 205; NIST IR 8547 (initial public draft) | August 2024; November 2024 | Post-quantum planning |
| [Internal CP/CPS] | [Version] | [Use] |

## Standard and licence note

Based on RFC 5280, RFC 3647, RFC 8555, RFC 9773, RFC 7030, RFC 8659, RFC 6962 and RFC 9162 (IETF), the CA/Browser Forum TLS Baseline Requirements and Ballots SC-081v3 and SC063, the CA/Browser Forum Code Signing Baseline Requirements, the SPIFFE specifications, and NIST FIPS 140-3, SP 800-57 Part 1 Rev. 5 and FIPS 203, 204 and 205 (works of the US Government). The RFC 3647 outline is listed by part number with paraphrased topics; no specification or requirement text is reproduced. This template is original text written for this collection. Product names belong to their owners. Public CA and browser root program rules change several times a year: check the current Baseline Requirements and root program policies at the official sites before use. Template licence: MIT.