PI Key Management Procedure

1. Purpose

The PKI & Key Management Procedure defines how the organization generates, provisions, stores, distributes, uses, rotates, revokes, recovers, and securely destroys cryptographic keys and digital certificates.

The objective is to ensure that cryptographic keys are:

Generated securely
Protected from unauthorized access
Used only for authorized purposes
Assigned to appropriate owners
Rotated or renewed when required
Revoked when compromised or no longer required
Properly backed up where required
Securely destroyed at the end of their lifecycle
Supported by appropriate evidence

Core Principle

Generate → Assign → Protect → Use → Monitor → Rotate/Renew → Revoke → Retire → Destroy → Verify

2. Scope

This procedure applies to cryptographic keys and certificates used by:

Employees
Administrators
Developers
Security teams
Cloud administrators
Applications
APIs
Databases
Servers
Containers
CI/CD systems
Cloud infrastructure
SaaS applications
Third-party integrations

It covers:

Encryption keys
Decryption keys
Symmetric keys
Asymmetric key pairs
Public keys
Private keys
TLS/SSL certificates
Signing keys
Code-signing certificates
SSH keys
API-signing keys
Encryption certificates
Key-encryption keys
Data-encryption keys
Cloud KMS keys
Certificate Authority (CA) keys
Customer-specific cryptographic keys
Backup encryption keys

3. PKI and Cryptographic Key Management

PKI is the infrastructure used to manage public-key cryptography, certificates, certificate authorities, identities, and trust relationships.

Key management covers the broader lifecycle of cryptographic keys, including keys used for:

Encryption
Decryption
Authentication
Digital signatures
Key exchange
Data protection

PKI is therefore one part of the organization’s overall cryptographic key-management capability.

4. Definitions

Term	Meaning
Cryptographic Key	Value used by a cryptographic algorithm
Symmetric Key	Same key is generally used for encryption and decryption
Asymmetric Key Pair	Public and private key used together
Public Key	Key intended for distribution
Private Key	Secret key requiring strong protection
Digital Certificate	Electronic credential binding an identity to a public key
CA	Certificate Authority that issues/signs certificates
Root CA	Trusted top-level certificate authority
Intermediate CA	Certificate authority operating below a root CA
KMS	Key Management System/Service
HSM	Hardware Security Module
Key Rotation	Replacement of a cryptographic key
Key Revocation	Invalidating a key/certificate before its normal expiry
Key Destruction	Secure removal of a key so it can no longer be used
Certificate Renewal	Replacing/renewing a certificate before or at expiry

5. Key Management Principles

The organization should apply the following principles:

Least Privilege

Only authorized people, systems, and applications should access cryptographic keys.

Key Separation

Keys should be separated based on purpose, environment, application, customer, or risk where appropriate.

Strong Protection

Private keys and high-impact encryption keys require stronger protection than public keys.

Key Lifecycle Management

Keys must have defined lifecycle stages.

Separation of Duties

Key administration and key usage should be separated where the risk warrants it.

No Unnecessary Copies

Private keys should not be copied unnecessarily.

No Hard-Coding

Cryptographic keys must not be hard-coded into source code.

Secure Destruction

Keys must be securely retired or destroyed when no longer required, subject to recovery and legal requirements.

6. Cryptographic Key Lifecycle

The standard lifecycle is:

Requirement → Generation → Registration → Protection → Distribution → Use → Monitoring → Rotation/Renewal → Revocation → Retirement → Destruction

Each stage should have an appropriate owner and evidence.

7. Key Identification and Requirement

Before creating a key, determine:

Why is the key required?
What information or system does it protect?
What type of key is required?
What algorithm is appropriate?
What strength is required?
Who owns the key?
Who will use it?
Where will it be stored?
How will it be rotated?
What is the expected lifetime?
What happens if it is compromised?
What happens when the system is retired?

8. Key Ownership

Every important cryptographic key should have an identified owner.

The owner is responsible for:

Business purpose
Appropriate protection
Access requirements
Lifecycle
Rotation
Revocation
Recovery requirements
Risk management
Retirement

Technical administrators may operate the key-management platform without being the business owner.

9. Key Generation

Cryptographic keys should be generated using approved cryptographic mechanisms.

Keys should:

Use approved cryptographic algorithms.
Use appropriate key strength.
Be generated using secure random generation.
Be generated within approved systems where practical.
Avoid manual creation of sensitive production keys.
Be assigned an owner and purpose.

Production cryptographic keys should not be generated using unapproved online tools or insecure scripts.

10. Approved Cryptographic Mechanisms

The organization should maintain approved cryptographic standards based on:

Current security requirements
System compatibility
Risk
Regulatory requirements
Customer requirements
Industry standards

Obsolete or weak cryptographic mechanisms should not be used for new systems unless formally approved as an exception.

Examples of technologies that may be used depending on requirements include:

AES
RSA
ECC
SHA-2 family
TLS
Digital signatures
Managed cloud cryptographic services

Specific algorithms and key sizes should be defined in the organization’s cryptographic standards where necessary.

11. Symmetric Keys

Symmetric keys may be used for:

Database encryption
File encryption
Backup encryption
Storage encryption
Application data encryption

Symmetric keys must be:

Protected from unauthorized disclosure.
Access-controlled.
Associated with an owner and purpose.
Rotated where required.
Backed up/recoverable where necessary.
Revoked or retired when no longer required.

12. Asymmetric Key Pairs

Asymmetric key pairs contain:

Public key
Private key

The public key may be distributed according to its intended purpose.

The private key must remain protected.

Private keys should:

Never be publicly exposed.
Not be stored in source repositories.
Not be sent through ordinary email.
Not be stored in unsecured documents.
Be accessible only to authorized users/systems.

13. Private Key Protection

Private keys should receive protection appropriate to their risk.

Protection mechanisms may include:

KMS
HSM
Secure key vault
Certificate management platform
Strong access control
MFA for administrative access
Encryption at rest
Access logging
Key usage monitoring

Highly sensitive private keys may require hardware-backed protection.

14. AWS Key Management

For AWS environments, the organization may use:

AWS KMS
AWS CloudHSM where required
AWS Certificate Manager
IAM
CloudTrail
AWS Secrets Manager where the item is a secret rather than a cryptographic key

Example:

Application → IAM Role → AWS KMS → Cryptographic Operation

The application should receive only the permissions required to perform the necessary cryptographic operation.

15. KMS Key Management

For KMS-managed keys:

Assign an owner.
Define the business purpose.
Restrict key administration.
Restrict key usage.
Apply least privilege.
Separate production and non-production keys where appropriate.
Monitor administrative/key-use activity where supported.
Define rotation requirements.
Review permissions periodically.

KMS administrators should not automatically receive permission to use every key for application data.

16. Key Separation

Keys should be separated where required by risk.

Examples:

Production vs development
Customer A vs Customer B
Application A vs Application B
Encryption vs signing
Backup vs production
Environment-specific keys
Different business units

The organization should avoid creating unnecessary keys merely for administrative convenience.

17. Certificate Management

Certificates should be managed throughout their lifecycle.

The organization should maintain visibility over important certificates, including:

TLS certificates
Application certificates
API certificates
Client certificates
Code-signing certificates
Internal certificates
VPN certificates

Certificate records should include:

Certificate ID
Subject
Purpose
System
Owner
Issuer/CA
Issue date
Expiry date
Renewal method
Status

18. TLS Certificate Management

TLS certificates should be:

Issued through approved mechanisms.
Associated with the correct domain/system.
Protected appropriately.
Monitored for expiry.
Renewed before expiration.
Revoked when compromised or no longer required.

Certificate renewal should be tested to prevent service disruption.

19. Certificate Authority Management

Where the organization operates a CA, it should define controls for:

Root CA protection
Intermediate CA protection
Certificate issuance
Certificate approval
Certificate revocation
Certificate renewal
CA backup/recovery
CA key protection
CA administrator access
Certificate records
Audit logging

Root CA private keys should receive particularly strong protection.

20. Certificate Issuance

Certificate issuance should be authorized.

Before issuing a certificate, verify:

Requester
System/application
Domain or identity
Purpose
Environment
Certificate type
Validity period
Approval requirements

Unauthorized certificates must not be issued.

21. Certificate Renewal

Certificates should be renewed before expiration.

The organization should monitor:

Certificate expiry
Renewal status
Failed renewal attempts
Certificate deployment
Service health

Automated renewal should be used where appropriate and safely supported.

22. Certificate Revocation

Certificates should be revoked when:

Private key is compromised.
Certificate is issued incorrectly.
System is retired.
Domain/identity ownership changes.
Certificate is no longer authorized.
Security requirements require revocation.

Revocation status should be recorded where appropriate.

23. SSH Key Management

SSH keys should be individually attributable where practical.

Requirements include:

Private keys protected.
Public keys associated with authorized identities.
Access limited to approved systems.
Periodic review.
Removal when access ends.
Rotation where required.
No private keys committed to repositories.

When an employee or contractor leaves, associated SSH access must be reviewed and revoked.

24. Code-Signing Keys

Code-signing keys should receive strong protection because compromise may allow unauthorized software to appear trusted.

Controls may include:

Restricted access
Strong authentication
Hardware-backed storage where appropriate
Separation of duties
Approval before signing
Signing logs
Key rotation
Emergency revocation

Code-signing private keys should never be stored in ordinary source repositories.

25. Digital Signing Keys

Signing keys used for:

Documents
APIs
Software
Transactions
Tokens
Certificates

should be protected against unauthorized use.

Where practical, signing operations should be performed by controlled systems rather than exposing the private key to application users.

26. Key Distribution

Keys should be distributed only through approved secure mechanisms.

Public keys may generally be distributed according to their intended purpose.

Private keys and symmetric keys require controlled distribution.

Keys must not be distributed through:

Public repositories
Public links
Ordinary email
Unapproved chat
Spreadsheets
Unsecured file shares

27. Key Backup and Recovery

Critical keys may require backup and recovery arrangements.

Backup requirements should consider:

Business continuity
Disaster recovery
Legal requirements
Data recovery requirements
Key criticality
Availability requirements

Key backups must receive protection equivalent to or appropriate for the original key.

A backup copy must not become an uncontrolled duplicate.

28. Key Recovery

Where key recovery is required:

Recovery should be authorized.
Identity of the requester should be verified.
Recovery activity should be logged where practical.
Access should be limited.
Recovery should be tested periodically where appropriate.

Recovery procedures should consider the possibility that the original system is unavailable.

29. Key Rotation

Keys should be rotated based on:

Risk
Key type
Cryptographic mechanism
Exposure
Business requirements
Regulatory/contractual requirements
Technology capability

Rotation should also occur when:

Compromise is suspected.
Unauthorized access occurred.
Key ownership changes where appropriate.
Cryptographic requirements change.
A key reaches its defined lifecycle limit.

30. Emergency Key Rotation

For suspected compromise:

Detect → Assess → Revoke/Disable → Generate Replacement → Deploy → Verify → Investigate → Record

Emergency rotation should prioritize containment while minimizing service disruption.

31. Key Revocation

A key or certificate should be revoked or disabled when:

Compromised
No longer required
Unauthorized use is suspected
Associated system is retired
Owner relationship ends
Certificate is invalid
Security requirements change

Revocation should be verified and recorded.

32. Key Destruction

Keys should be securely destroyed when they are no longer required, subject to:

Backup requirements
Legal requirements
Regulatory requirements
Data recovery requirements
Retention requirements

For encrypted information, key destruction may make the information permanently inaccessible. Therefore, destruction must be authorized and carefully planned.

33. Cryptographic Key Compromise

A suspected key compromise should be treated as a security event and escalated according to the Incident Response Procedure.

The organization should:

Identify the affected key.
Determine its purpose.
Determine its permissions.
Assess potential exposure.
Restrict or revoke the key.
Generate replacement key material.
Deploy replacement.
Review logs and key usage.
Assess affected data/systems.
Determine notification requirements.
Document the incident.
Implement corrective actions.

34. Key Access Control

Key access should be controlled through:

Named identities
Least privilege
Role-based access
MFA
Privileged access management
Separation of duties
Environment restrictions
Approval processes
Logging

Key administration rights should be separated from ordinary key-use permissions where practical.

35. Key Usage Monitoring

Where technically possible, monitor important key activity.

Examples:

Key creation
Key deletion
Permission changes
Key usage
Certificate issuance
Certificate revocation
Administrative activity
Unusual cryptographic operations

Suspicious activity should be investigated.

36. Development and Testing

Development environments should use appropriate non-production keys.

Developers should not:

Copy production private keys to laptops.
Use production encryption keys unnecessarily.
Commit private keys to Git.
Share private keys through chat.
Copy production certificates containing private keys into development environments.

Test keys should be clearly separated from production keys.

37. CI/CD Key Management

CI/CD pipelines may require cryptographic keys for:

Code signing
Container signing
Deployment
Infrastructure
Package signing
Cloud access

Keys should be stored in approved secure mechanisms and exposed only to the required pipeline stages.

Build logs must not expose private keys or sensitive cryptographic material.

38. Container and Kubernetes Key Management

Private keys and certificates should not be embedded directly into container images.

Where Kubernetes is used:

Use approved secret-management mechanisms.
Restrict access to secrets.
Avoid unnecessary secret copies.
Monitor access.
Separate environments.
Rotate credentials and certificates appropriately.

39. Backup Encryption Keys

Backup encryption keys must be protected independently from the backup data.

The organization should consider:

Key availability during disaster recovery
Recovery procedures
Key backup
Access restrictions
Key rotation
Recovery testing

Loss of the encryption key may make backups unusable.

40. Customer-Specific Keys

Where customer-specific encryption keys are used:

Assign ownership.
Define customer/system relationship.
Restrict access.
Maintain lifecycle information.
Define rotation requirements.
Address customer offboarding.
Retain or destroy keys according to contractual requirements.

Customer-specific keys should not be reused across customers where separation is required by risk or contract.

41. Third-Party Key Management

When cryptographic keys are managed by a third party:

Identify the service provider.
Assess security requirements.
Review contractual controls.
Understand key ownership.
Understand key access.
Understand key location where relevant.
Understand backup/recovery.
Understand incident notification.
Understand termination and key deletion.

Relevant third-party risks should be reflected in supplier/security risk management.

42. Key Management Register

Important keys and certificates should be tracked.

Field	Description
Key/Certificate ID	Unique identifier
Type	KMS key, TLS certificate, SSH key, etc.
Purpose	Encryption, signing, authentication
System/Application	Associated system
Environment	Dev/Test/Production
Owner	Business owner
Technical Custodian	Managing team
Algorithm	Approved algorithm
Key Strength	Applicable key size/parameter
Creation Date	Date created
Expiry Date	If applicable
Rotation Requirement	Defined lifecycle
Last Rotation	Date
Next Rotation	Planned date
Storage	KMS/HSM/Vault/etc.
Access Scope	Authorized users/services
Backup	Yes/No/Method
Status	Active/Retired/Revoked
Related Asset	Asset ID
Related Risk	Risk ID
Evidence	Supporting record

Private keys and actual secret key material must never be stored in the register.

43. Certificate Register

A separate certificate register may be maintained for larger environments.

Example fields:

Field	Description
Certificate ID	Unique identifier
Certificate Type	TLS/API/Code Signing/etc.
Subject	Certificate subject
Domain/System	Associated service
Owner	Certificate owner
Issuer	CA
Issue Date	Date issued
Expiry Date	Expiration
Renewal Method	Manual/Automated
Environment	Production/Test
Private Key Location	Secure storage reference only
Status	Active/Expired/Revoked
Last Reviewed	Review date

44. Periodic Key Review

Key reviews should verify:

Key still required
Owner still valid
Purpose still valid
Access still appropriate
Permissions remain least privilege
Key has not exceeded its lifecycle
Rotation is current
Certificates are not approaching expiry
Backup/recovery remains appropriate
Retired keys are disabled
Unused keys are removed

45. Key Reconciliation

The organization should periodically compare:

Key Register

against:

Cloud KMS
HSM
Certificate Manager
Servers
Applications
Kubernetes
Source repositories
CI/CD
Certificate inventories
Infrastructure-as-Code

Reconciliation Process

Discover → Compare → Identify Unknown Keys → Assign Owner → Assess → Secure → Update Register → Verify

46. AWS SaaS Example

A SaaS company operates an application on AWS.

Encryption

Application → KMS → Encrypted RDS/S3 Data

TLS

Client → TLS Certificate → Application Load Balancer

Application Secret

Application → IAM Role → Secrets Manager

Signing

CI/CD → Controlled Signing Key → Signed Release

Monitoring

CloudTrail → Key Administration/Usage Events → Security Monitoring

The organization should maintain clear ownership and lifecycle controls for each important key and certificate.

47. Key Management During System Development

Requirements

Identify cryptographic requirements.

Design

Select appropriate algorithms, keys, certificates, and storage.

Development

Use non-production key material.

Testing

Verify encryption, certificate validation, key access, rotation, and failure handling.

Deployment

Configure production keys through approved mechanisms.

Operation

Monitor, review, rotate, and renew.

Retirement

Revoke, archive where required, and securely destroy keys according to approved requirements.

48. Roles and Responsibilities

Role	Responsibility
Key Owner	Defines purpose, risk and lifecycle
Security/ISMS	Defines cryptographic requirements
Cloud/IT	Operates KMS/HSM/certificate services
Engineering	Implements secure cryptographic usage
DevOps	Manages CI/CD certificates and signing mechanisms
Application Owner	Ensures appropriate application key usage
System Owner	Ensures keys support system requirements
Certificate Administrator	Manages certificate lifecycle
Internal Audit	Independently verifies control effectiveness
Management	Approves significant risks/exceptions

49. Evidence

Potential evidence includes:

Key Management Register
Certificate Register
AWS KMS configuration
HSM configuration
IAM policies
KMS key policies
CloudTrail records
Certificate issuance records
Certificate renewal records
Certificate revocation records
Key rotation records
Key access reviews
Key compromise incidents
Recovery testing
Change records
Cryptographic standards
Risk assessments

Actual private keys or sensitive cryptographic material must never be provided as audit evidence.

50. Exceptions

Exceptions should be:

Documented
Risk assessed
Approved
Assigned an owner
Supported by compensating controls where appropriate
Time limited where practical
Periodically reviewed

Examples:

Legacy system using an older cryptographic mechanism
Third-party platform with limited key-management capabilities
Customer-specific cryptographic requirement
Technical limitation preventing automated rotation

51. Metrics

The organization may monitor:

Number of active keys
Number of active certificates
Certificates approaching expiry
Keys overdue for rotation
Number of unmanaged keys
Number of unauthorized key-access attempts
Number of key-related incidents
Percentage of production keys with identified owners
Percentage of critical certificates under automated renewal
Key-management exceptions

Metrics should support risk-based improvement.

52. Startup-Friendly Implementation

A startup can implement a practical key-management model without immediately building its own PKI infrastructure.

Minimum Model

1. Identify

Inventory important keys and certificates.

2. Centralize

Use managed KMS/certificate services where appropriate.

3. Protect

Restrict access using IAM/RBAC and MFA.

4. Separate

Keep production and non-production key material appropriately separated.

5. Monitor

Enable relevant logging.

6. Rotate

Define risk-based rotation and certificate renewal.

7. Revoke

Quickly disable compromised or unnecessary keys.

8. Review

Periodically review owners, permissions and lifecycle.

53. Quick Audit Checklist

Key Management

Cryptographic keys identified
Key owners assigned
Key purposes documented
Approved cryptographic mechanisms defined
Key lifecycle documented

Key Protection

Private keys protected
KMS/HSM/Vault used where appropriate
Access restricted
MFA used for privileged administration
Least privilege implemented
Key material not stored in source code

Certificates

Certificates inventoried
Owners assigned
Expiry monitored
Renewal process defined
Revocation process defined

Rotation

Rotation requirements defined
Rotation performed as required
Compromised keys can be replaced
Retired keys revoked/disabled

Monitoring

Key administration logged
Key usage monitored where appropriate
Suspicious activity investigated

Lifecycle

Key creation controlled
Key access reviewed
Backup/recovery considered
Unused keys identified
Retired keys securely handled

54. Relationship with Other ISMS Documents

This procedure connects with:

Cryptography Policy
Secrets Management Procedure
Authentication & Password Policy
Identity Management Policy
Access Control Policy
Privileged Identity Management Procedure
Privileged Access Register
Service Account Register
Cloud Asset Inventory
Secure Development Checklist
Security Architecture Review
Security Testing Checklist
Change Management Procedure
Backup and Recovery Procedure
Incident Response Plan
Security Incident Management Procedure
Information Classification Policy
Data Handling Guidelines
Supplier Security Assessment
Third-Party Access Procedure
Risk Assessment Procedure

Control Chain

Cryptographic Requirement

→ Key/Certificate

→ Generation

→ Secure Storage

→ Access Control

→ Use

→ Monitoring

→ Rotation/Renewal

→ Revocation

→ Retirement/Destruction

→ Evidence

55. ISO 27001 Connection

This procedure supports applicable ISO/IEC 27001 requirements and controls relating to:

Cryptographic controls
Authentication information
Access control
Identity management
Privileged access
Secure development
Cloud security
Logging and monitoring
Backup and recovery
Supplier security
Incident management

The specific controls applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).

56. Final Audit Trail

For an important production cryptographic key, the organization should be able to demonstrate:

Why does the key exist?

→ What does it protect?

→ Who owns it?

→ Where is it stored?

→ Who or what can use it?

→ Are permissions least privilege?

→ How is the private/key material protected?

→ Is key usage monitored?

→ When is the key rotated?

→ What happens if it is compromised?

→ How is the key revoked?

→ How is recovery handled?

→ When can it be destroyed?

→ What evidence demonstrates that the lifecycle was controlled?

Final Principle

Cryptographic security is not only about selecting a strong algorithm. The organization must control the entire key lifecycle — from generation and protection through use, monitoring, rotation, revocation, and secure retirement.