Cryptographic Key and Certificate Register Template (ISO/IEC 27001 A.8.24)

Key and certificate inventory: field definitions, lifecycle states, register rows, expiry alerts, algorithm checks, post-quantum exposure, change log

ISMS・ISO/IEC 27001標準ISO/IEC 27001:2022 + Amd 1:2024 A.8.24 (cited only); ISO/IEC 27002:2022; NIST SP 800-57 Part 1 Rev. 5cryptographic key register更新 2026/11/01

エディタで開く.mdをダウンロード

使い方: Use it to show which keys and certificates you run, who owns them and that none expire unnoticed. Fill the field definitions first, then one row per key or certificate starting with TLS, backup, database and signing keys. The main pitfall is recording secrets in the register or never reconciling it with the real key stores.

プレビュー

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.

Document control

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

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

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

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

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

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

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

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

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

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

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

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.