# Cryptographic Key and Certificate Register: [Organization name]

> Inventory of cryptographic keys and certificates in the ISMS scope:
> what each key protects, its algorithm and length, where it is stored,
> who owns it, its lifecycle state, when it expires or must be rotated,
> and its readiness for post-quantum migration, plus a change log of
> lifecycle events. It is the evidence record for key management under
> ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.8.24 (use of
> cryptography) and implements the inventory duty of
> `security/cryptography-standard`. It never holds key material. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you need to show an auditor or customer which keys and
  certificates you run, who owns them and that none expire unnoticed.
- Fill first: the field definitions in section 2 (agree them once), then
  one row per key or certificate in section 4, starting with public TLS
  certificates, backup encryption keys, database and storage keys,
  signing keys and identity provider certificates.
- Main pitfall: recording secrets in the register. Record identifiers,
  fingerprints and locations only. Private keys, passwords and tokens
  stay in the key management service, HSM or secrets vault
  (`security/secrets-management-standard`).
- Second pitfall: a register filled once for the audit and never
  reconciled. Automate discovery where you can (certificate transparency
  logs, cloud key inventories, scanner output) and reconcile monthly.
- Related templates: `security/cryptography-standard`,
  `security/pki-certificate-architecture`, `security/pqc-migration-plan`,
  `security/secrets-management-standard`, `isms/backup-policy`,
  `isms/data-masking-dlp-standard`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: The register is a living record. Version it monthly or at each reconciliation, and restrict edit rights to key owners and the register owner. -->

| Field | Value |
|---|---|
| Document ID | [DOC-ISMS-070] |
| Version | [2027.01] |
| Status | [Live record] |
| Owner | [@security-engineering-lead] |
| Approvers/reviewers | [@isms-manager], [@ciso], [@platform-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential: reveals infrastructure detail] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.24); ISO/IEC 27002:2022 |
| Governing standard | [Cryptography standard, `security/cryptography-standard`, version and date] |
| Last reconciliation | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Register owner | [@security-engineering-lead] | [Reconciled] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 2027.01 | YYYY-MM-DD | [@owner] | First complete inventory |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## 1. Purpose and scope

<!-- Guidance: Say what kinds of keys are in and out. Questions: Are customer-managed keys in a SaaS product in scope? Are OT device certificates included? Pitfall: listing only public TLS certificates, while backup and database keys, whose loss makes data unrecoverable, are missing. -->

The register covers every key and certificate that protects information
in the ISMS scope ([DOC-ISMS-002]): public and private TLS certificates,
data encryption keys and key encryption keys, backup encryption keys
([DOC-ISMS-061]), pseudonymisation and tokenisation keys
([DOC-ISMS-062]), code and document signing keys, SSH host and
certificate authority keys, identity federation signing certificates,
VPN and device certificates, and HSM or key management service root
keys. Short-lived keys generated and destroyed automatically by a
platform (for example session keys) are covered by recording the
platform and its key policy as one row.

## 2. Register fields

<!-- Guidance: Agree the fields before collecting data. Keep identifiers that let you find the key in the tool (key ID, fingerprint, serial number), never the secret itself. -->

| Field | Content |
|---|---|
| Key ID | Register identifier, format KEY-NNN (keys) or CRT-NNN (certificates) |
| Type | Symmetric key, asymmetric key pair, certificate, CA certificate, HMAC key |
| Purpose | What it protects (data set, service, signature use) |
| Algorithm and length | For example AES-256-GCM, RSA-3072, ECDSA P-256, ML-KEM-768; must be approved in the cryptography standard |
| Location and protection | KMS, HSM, vault, device TPM; protection level (hardware or software) |
| Tool identifier | Key ID, ARN-style resource name, fingerprint or certificate serial number |
| Owner | Named role accountable for the key |
| Custodians | People or roles allowed to administer the key |
| Created | Date of generation or issue |
| Expiry or rotation due | Certificate expiry date or planned rotation date |
| State | Lifecycle state from section 3 |
| Backup or escrow | Where a recoverable copy exists, or "none by design" |
| Quantum-vulnerable? | Yes for RSA, DH and elliptic-curve public-key algorithms; No for symmetric keys of adequate length and approved post-quantum algorithms |
| Linked assets | Asset IDs from [DOC-ISMS-012] |

## 3. Lifecycle states

<!-- Guidance: Use the same states everywhere so reports can count keys per state. Every state change is a log entry in section 8. -->

```mermaid
stateDiagram-v2
  [*] --> Requested
  Requested --> Active: generated or issued
  Active --> Rotating: rotation started
  Rotating --> Active: new version in use
  Active --> Suspended: suspected compromise
  Suspended --> Active: cleared after investigation
  Suspended --> Revoked: compromise confirmed
  Active --> Retired: no new use, decrypt or verify only
  Rotating --> Retired: old version kept for decryption
  Retired --> Destroyed: data re-encrypted or expired
  Revoked --> Destroyed
  Destroyed --> [*]
```

| State | Meaning |
|---|---|
| Requested | Approved, not yet generated or issued |
| Active | In use for encryption, signing or authentication |
| Rotating | A new version is being rolled out; both versions exist |
| Suspended | Use stopped pending investigation of possible compromise |
| Revoked | Certificate revoked or key withdrawn after compromise |
| Retired | Kept only to decrypt or verify existing data |
| Destroyed | Key material destroyed; record kept |

## 4. Key and certificate register

<!-- Guidance: One row per key or certificate (or per platform policy for automated keys). Sort or filter by the expiry column in your working copy so the next expiry is at the top. Auditors sample rows and ask to see the key in the tool with matching owner, algorithm and expiry. -->

| Key ID | Type | Purpose | Algorithm and length | Location | Owner | Expiry or rotation due | State | Backup or escrow | Quantum-vulnerable? |
|---|---|---|---|---|---|---|---|---|---|
| CRT-001 *(Example)* | Public TLS certificate | app.[domain] customer portal | ECDSA P-256 | Cloud load balancer, automated renewal | [@platform-lead] | 2027-04-20 | Active | Not needed: reissued automatically | Yes |
| CRT-002 *(Example)* | Federation signing certificate | Identity provider SAML signing | RSA-3072 | Identity provider | [@it-lead] | 2027-09-30 | Active | None by design: new certificate issued | Yes |
| KEY-001 *(Example)* | Key encryption key | Production database encryption | AES-256 | Cloud KMS, hardware-backed | [@platform-lead] | Rotation 2027-06-01 (annual) | Active | Provider-managed durability; multi-region replica | No |
| KEY-002 *(Example)* | Key encryption key | Backup encryption, separate backup account | AES-256 | Cloud KMS in backup account | [@backup-custodian] | Rotation 2027-06-01 (annual) | Active | Escrow export in sealed offline store, two custodians | No |
| KEY-003 *(Example)* | HMAC key | Pseudonymisation of customer IDs for analytics | HMAC-SHA-256, 256-bit key | Secrets vault | [@data-platform-lead] | Rotation 2028-01-15 | Active | Vault backup | No |
| KEY-004 *(Example)* | Signing key pair | Release artefact signing | ECDSA P-384 | HSM-backed signing service | [@eng-lead] | Rotation 2027-11-01 | Active | HSM backup in second region | Yes |
| KEY-005 *(Example)* | Key encryption key | Old database encryption, before migration | AES-256 | Cloud KMS | [@platform-lead] | Destroy after 2027-03-31 | Retired | Provider-managed | No |

## 5. Expiry tracking and alerts

<!-- Guidance: Expired certificates cause outages and, for signing certificates, broken trust. Set alert thresholds by renewal method. Pitfall: alerts sent to one person's mailbox. -->

| Item type | Alert at *(Example)* | Alert to | Action |
|---|---|---|---|
| Public TLS, automated renewal | Renewal failure, or 14 days before expiry if not renewed | Platform on-call channel | Fix automation, renew manually if needed |
| Public TLS, manual | 30 and 14 days before expiry | Owner and platform channel | Renew, deploy, verify, log |
| Federation and signing certificates | 60 and 30 days | Owner and identity team | Coordinate with relying parties before switch |
| Keys with planned rotation | 30 days before due | Owner | Rotate per cryptography standard |

Maximum validity of publicly trusted TLS server certificates is
shrinking under CA/Browser Forum Ballot SC081v3 (voting closed
2025-04-11): 398 days before 2026-03-15, then 200 days for certificates
issued on or after 2026-03-15 (already in force), 100 days from
2027-03-15 and 47 days from 2029-03-15. The period for reusing domain
validation shrinks on the same dates, to 10 days from 2029-03-15. The
schedule applies to publicly trusted certificate authorities only;
certificates from a private CA follow your own cryptography standard.
Manual renewal will not keep pace; record the renewal method for every
public certificate and plan automation. Check the current Baseline
Requirements on cabforum.org.

## 6. Algorithms and lengths

<!-- Guidance: The register records what is deployed; the cryptography standard says what is allowed. Flag every row that uses an algorithm the standard marks deprecated. -->

Each row must use an algorithm and length approved in
`security/cryptography-standard` section 4. Rows that use deprecated
algorithms (section 5 of that standard) are flagged at each
reconciliation and either migrated or covered by an exception
(`security/security-exception-request`) with a risk score and expiry
date. Report the count of flagged rows to the ISMS manager monthly.

## 7. Post-quantum readiness note

<!-- Guidance: Use the register as the starting inventory for the migration plan. Questions: Which data must stay confidential beyond 2035? Which signing keys protect long-lived artefacts? -->

NIST IR 8547, Transition to Post-Quantum Cryptography Standards (final,
2026-10-27), deprecates all quantum-vulnerable public-key algorithms
(RSA, finite field and elliptic-curve schemes for digital signatures and
key establishment, at every security strength) after 2030 and disallows
them under NIST standards and guidelines after 2035. US federal agencies
face earlier dates under Executive Order 14412 and OMB Memorandum
M-26-15, as cited in the report (most sensitive systems:
post-quantum key establishment by 2030-12-31, digital signatures by
2031-12-31); private organizations are not bound by it but customers may
ask for the same pace. Post-quantum algorithms are published in FIPS 203
(ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205
(SLH-DSA, hash-based signatures), all dated 2024-08-13. Use the "Quantum-vulnerable?" column to count exposure, and
prioritise rows protecting data with long confidentiality needs and keys
that sign long-lived artefacts. Plan the migration in
`security/pqc-migration-plan`. Other jurisdictions publish their own
timelines; follow the ones that apply to you.

Example exposure count from section 4: 3 of 7 rows (CRT-001, CRT-002,
KEY-004) are quantum-vulnerable; the 4 symmetric and HMAC rows are not.

## 8. Change log

<!-- Guidance: Log every lifecycle event with a ticket reference. Auditors trace one rotation or revocation from the log to the change ticket and the tool's audit trail. -->

| Log ID | Date | Key ID | Event | From state | To state | Performed by | Approved by | Ticket |
|---|---|---|---|---|---|---|---|---|
| KLG-001 *(Example)* | 2027-01-12 | KEY-002 | Escrow export verified by test restore | Active | Active | [@backup-custodian] | [@isms-manager] | OPS-388 |
| KLG-002 *(Example)* | 2027-02-03 | KEY-005 | Replaced by KEY-001 after database migration | Active | Retired | [@platform-lead] | [@ciso] | CHG-219 |
| KLG-003 *(Example)* | 2027-02-20 | CRT-001 | Automated renewal | Active | Active | Renewal automation | Not required (standard change) | Auto |

## 9. Size tiers

<!-- Guidance: Show proportionate effort. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Typical size *(Example)* | About 30 rows, mostly cloud KMS keys in two regions and automated TLS certificates | About 150 rows, including colocation HSM and hospital integration certificates | Several thousand items including OT device certificates, held in a certificate management tool with this register as the summary |
| Owner | Head of Engineering Operations (0.5 FTE ISMS manager) with the platform engineer | Security team of 3 | CISO office PKI team, site custodians |
| Reconciliation | Monthly, against cloud key inventory and certificate transparency logs | Monthly, automated discovery plus manual check of the colocation HSM | Continuous discovery, monthly summary per site |

## 10. Records and evidence

<!-- Guidance: Register these in `isms/control-evidence-matrix` against A.8.24. -->

| Record | Owner | Location *(Example)* | Retention *(Example)* |
|---|---|---|---|
| This register (monthly versions) | Register owner | ISMS document store, restricted | 3 years |
| Change log with tickets | Register owner | Section 8 and change system | 3 years after key destruction |
| Reconciliation results | Register owner | Reconciliation notes | 3 years |
| KMS and HSM audit logs | Platform lead | Central logging | Per `security/security-logging-standard` |
| Destruction records | Key owner | Change log and tool audit trail | 3 years |

## 11. References

<!-- Guidance: Recheck at each review. -->

- ISO/IEC 27001:2022 + Amd 1:2024, Annex A control A.8.24:
  https://www.iso.org/standard/82875.html
- ISO/IEC 27002:2022: https://www.iso.org/standard/75652.html
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1,
  General (May 2020)
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards (final,
  2026-10-27): https://csrc.nist.gov/pubs/ir/8547/final
- FIPS 203, FIPS 204 and FIPS 205 (August 2024)
- CA/Browser Forum Ballot SC081v3, Introduce Schedule of Reducing Validity
  and Data Reuse Periods (April 2025), https://cabforum.org/
- Related templates: `security/cryptography-standard`,
  `security/pki-certificate-architecture`, `security/pqc-migration-plan`,
  `security/secrets-management-standard`, `isms/backup-policy`,
  `isms/control-evidence-matrix`

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control
A.8.24) and ISO/IEC 27002:2022. Control numbers are cited only; no ISO or
IEC text is reproduced, and you need the official standards to implement
and audit the control. NIST publications are US government works; the
CA/Browser Forum ballot is cited by number and dates only. Field
definitions, states and examples are original. Check the current
editions and the current Baseline Requirements before use.

Template licence: MIT.