Key Management Plan Template

What this template is for

This Key Management Plan (KMP) template provides a structured and standardized format for Application Development Organizations (ADOs) to document the management of cryptographic keys throughout the system lifecycle. This template aligns with the CMS Key Management Handbook and supports compliance with applicable federal laws, regulations, and CMS policies, including FISMA, NIST SP 800-57, and CMS Acceptable Risk Safeguards (ARS).

The template is intended to be tailored by each ADO to reflect the key management practices and technologies implemented within their FISMA system. It outlines procedures and responsible roles across the entire key lifecycle, including generation, distribution, storage, use, rotation, revocation, destruction, archival, and compromise response. 

By completing this document, ADOs will:

• Improve visibility and accountability around cryptographic key usage
• Strengthen security posture and reduce the risk of key compromise
• Support audit readiness and continuous compliance with CMS and federal requirements

The Key Management Plan (KMP) is a living document, and should be reviewed and updated annually, or upon any significant system or cryptographic change. The completed plan should be stored in a location accessible to those designing, operating, or maintaining the system.

KMP template directions

Use this template to record your Key Management Plan and store it in a location familiar to the members of the ADO who design, build, operate, or maintain the FISMA system.

Throughout the template you will find sections to fill in labeled with the content in brackets. For example, if you see “[Name]”, you should replace “[Name]” with the name or acronym of your FISMA System.  In each of the “Where is the function performed” and “How is the function performed” sections there are prompts for different types of key management tools. Remove and edit the prompts as they apply to your system. Sometimes the common AWS tool is listed along with a prompt to enter another tool.

To get started, copy and paste the template below into a document, then fill out the sections with information specific to your system. You should also remove these directions when you are ready to publish your Key Management Plan.

System Information

FISMA System Name: [Name]

CFACTS link: [URL]

Environment overview: [Short description of where the system is located, e.g. AWS for CMS Cloud, contractor-owned and operated data center.  You may include links.]

Document last reviewed: [Date, review at least yearly]

Contact information:

In the event of a key management issue, please contact the [Name] on-call team at:

• [Email address]
• [Pager information]
• [Phone number]

[Note any service level agreement timeframes – estimated response time, non-availability timeframes]

Encryption Inventory

[Name] employs the following types of cryptographic functions that are overseen by the ADO: [remove ones that do not apply, add missing ones]

• Network Traffic encryption via TLS
• Hardware-based cryptography in network appliances (e.g. routers)
• Encryption of Data at Rest via symmetric encryption methods
• Code containing cryptographic functions

Link to detailed inventory which contains the following elements:

• Name of key
• Type of Key
• Intended Use
• Algorithm and length
• Where stored
• Rotation period
• Next rotation date
• Secret manager (individual or role responsible)

Key Management Officer

ADOs are encouraged to designate a Key Management Officer (KMO) to oversee and ensure the execution of all key management activities. This can be done by the ISSO or by a member of the DevSecOps team.

Training and Awareness

The team that operates and maintains [Name] performs the following awareness and training exercises annually: [Remove ones that are not done, add others that align to your organization]

• A key management related tabletop exercise (e.g., yearly Information System Contingency Plan (ISCP) tabletop exercise or compromise-recovery scenario involving cryptographic keys)
• Review the processes and procedures in this document for correctness (also part of Audit)
• Hands-on training for new members of the team
• Review of processes by each team member
• Review log exercises for KMS, secret management tools. 

Standard Operating Procedures

This section contains the procedures for performing basic key management functions.  The functions listed here match the Key Management Lifecycle Best Practices in the CMS Key Management Handbook.

Each of the following sections contain these items for you to fill in for your system: 

• What the key management function is along with why it is performed
• Who can perform the function and what access they need
• Where is the function performed
• When is the function performed
• How the function is performed

Generation of Keys

What and why

Some applications may need to generate the cryptographic keys used in their systems directly.  Procedures here should include the establishment of the initial key(s) as well as any lower-level or replacement keys.  Keys and keying materials need to be generated before they can be used.

Cloud-hosted systems, such as AWS KMS, typically have built-in processes for the generation of cryptographic keys that are compliant with FIPS 140-2+, and ADOs would not need to have as detailed procedures for generation as other systems might.

Who performs the function

Key generation can be performed by [Role Name].  They are granted this ability through the [Kion role, or another permissions manager role].

PKI certificates for TLS are obtained from OIT/IUSG using the procedures documented on the CMS Cloud website.  [Role name within ADO] is responsible for requesting new certificates, including when it is time for renewal.

Note: To ensure operational continuity, key generation responsibilities should not be limited to a single individual.

Where the function is performed

Key generation for PKI certificates is performed by OIT/IUSG.

Key generation for asymmetric keys is performed [insert location]

Key generation for symmetric keys is performed [in the AWS service they are being used for | in AWS KMS | other location].

When the function is performed

New keys are generated when a new service is being introduced to the application or when keys to an existing service need to be regenerated because they have expired or have been compromised.

How the function is performed

New PKI certificates from OIT/IUSG are obtained via [insert link to instructions].

[Insert links to KMS or other popular AWS systems so that teams can keep the ones they use and delete the ones not used].

Distribution of Keys

What and why

Once a key is generated, it may need to be moved before use (e.g. distributed). Keys should be distributed in a manner that does not expose the key to unauthorized persons. Keys should be transmitted using out-of-band methods separate from the team’s standard communication platforms. Avoid sharing keys through tools like Slack.

Who performs the function

Key distribution is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Key distribution for [AWS Service] is done automatically after generation by AWS.

Where the function is performed

Key distribution is performed via [Key/Secrets Management System | password manager vault | encrypted email | insert other mechanism].

When the function is performed

Key distribution is performed after a new [type of key] is generated. 

AWS data storage services perform key distribution automatically for the user. 

How the function is performed

Key distribution for PKI certificates from OIT/IUSG should be done via [insert instructions].

Key distribution for symmetric keys is done via [insert instructions].

Storage of Keys

What and why

Once generated, keys along with certificates for SSL/TLS will need to be stored in a location that is accessible to the system so that data at rest and in transit can be encrypted and decrypted.  Some Cloud Service Providers (CSP) may handle key storage along with key generation and key distribution.

Who performs the function

Key storage is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

PKI certificate storage is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Key storage for [AWS Service] is done automatically after generation by AWS.  Keys are stored in [AWS location].

Where the function is performed

PKI certificates are stored in [AWS Certificate Manager or insert other certificate storage tool].

Symmetric keys are stored in [AWS KMS or other system].

When the function is performed

Key storage occurs after generation and distribution.

How the function is performed

To store certificates in AWS Certificate Manager (ACM), follow the directions provided by AWS for importing certificates into ACM. 

To store certificates in [other Certificate manager], follow the directions provided by [Vendor] for importing certificates into ACM.

The following services handle the storage of keys in KMS and do not need intervention once the key is created:

• Databases (RDS, Aurora, DynamoDB, etc.)
• S3
• Elastic Block Storage (EBS)

This system uses Customer Managed Keys with KMS for the following services and will need to store the keys using the “create keys” directions in KMS.

• [Insert list of AWS services that use customer managed keys]

This system uses [other Key Management system] to store keys, and the directions can be found [Link to directions].

Use of Keys

What and why

Encryption keys are needed to encrypt and decrypt data in transit and at rest, but to do so, the keys must be made available to the systems or software that is performing the cryptographic function.

Who performs the function

Key use is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

[Name] does not allow direct access to symmetric keys by staff.

Where the function is performed

Key usage is handled either by the application or by the service that uses the key for encryption.

When the function is performed

Keys are used when data needs to be encrypted or decrypted, such as when the data needs to be used, or when the data is being transported over the internet.

How the function is performed

Keys used with the following AWS Services are handled automatically when data is requested of them: 

• Databases (RDS, Aurora, DynamoDB, etc.) [Insert specific Database used]
• S3 [Remove if not part of the system]
• Elastic Block Storage (EBS) [Remove if not part of the system]

The following AWS services are encrypted with Customer Managed Keys:

• Databases (RDS, Aurora, DynamoDB, etc.) [Insert specific Database used]
• S3 [Remove if not part of the system]
• Elastic Block Storage (EBS) [Remove if not part of the system]

PKI Certificates for TLS are used by Elastic Load Balancer (ELB), and a HTTPS listener is set up within ELB.

Escrow and Backup of Keys

What and why

It is essential to have a mechanism for recovering lost cryptographic keys. This can be achieved through key backup—storing a secure copy in a separate location—or, in special cases, through key escrow, where a trusted third party retains a copy of the key.

Key backup is the preferred mechanism to store keys. Key escrow should only be done in special circumstances, such as for re-provisioning of key material to users if the key is lost or corrupted.

Who performs the function

Key backup is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Key escrow is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Where the function is performed

This system relies on AWS KMS for key backup.

This system implements multi-region keys in AWS to enable having multiple copies of the keys.

Key backups are performed [insert location/tool].

Key escrow is performed [insert location/tool].

When the function is performed

Key backups are performed after key generation and distribution.

How the function is performed

No action is needed as AWS KMS handles key backups.

Multi-region keys are created in two stages – establishing the primary key and setting up the replica key.  Refer to AWS documentation for the exact steps.

Key backups are performed by [insert instructions from another tool].

Key escrow is performed by [insert instructions from another tool].

Accountability and Audit of Keys

What and why

Managing cryptographic keys and keying material is a critical responsibility, and those entrusted with this duty must be held accountable through regular review. To ensure separation of duties, audits should be conducted by individuals or teams who are not directly involved in key management activities.

These audits should assess processes related to key generation, distribution, storage, use, and backup. They should examine both human and system access to keys. Additionally, audits may include periodic scans for exposed keys and secrets in source code repositories—for example, using tools like GitHub’s Secret Scanner.

Who performs the function

Key management auditing is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Note: CMS Hybrid Cloud SecOps does not monitor or alert on key usage in AWS or MAG; ADOs are responsible for any monitoring of key usage.

Where the function is performed

Key management auditing is performed in two places: where the processes and procedures are stored and where system logs can be reviewed.

[Name] stores the processes and procedures in the following locations [insert locations].

AWS Security Hub provides monitoring of some KMS settings around access of keys and rotation settings.

Logs for ACM and KMS can be reviewed in AWS CloudTrail.

When the function is performed

Auditing the processes and procedures used for key management should be performed on an annual basis to ensure that the documentation is up to date and ready to use.  It should also be updated after a change to the key management processes.

Auditing of key usage should be done frequently and have both automated and manual audits.  Automated monitoring of key usage should be done continuously to identify potential issues or misuse promptly.  Manual audits, having a designated person review the usage to look for anomalies, should occur monthly.  This can help identify a legitimate person using key material in unusual ways.

How the function is performed

Once a year in [Quarter X], the [Role name] will attempt to follow these procedures and make corrections as needed.

This system uses AWS CloudTrail logs in combination with CloudWatch Alerts to monitor key usage.  Alerts are sent to [email address, CMS Slack channel, or other place they are sent for review].  Alerts include notices about key expiration and key rotation.

Once a month, the [Role name] will view the CloudTrail entries looking for CreateKey and DeleteKey events that are unusual.

Rotation of Keys

What and why

Cryptographic keys are rotated on a regular basis to limit the amount of data protected by the key.  Keys are also rotated when a key has been inappropriately exposed to others.  Keys may also be rotated when an authorized user no longer needs access.  Key rotation is simply replacing an existing key with a new one.  It is a combination of Generation, Distribution, and Storage of Keys. In some cases, it also includes Revocation and Destruction of Keys.

Who performs the function

Key rotation is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Where the function is performed

Key rotation is performed in the same location as Generation, Distribution, and Storage of Keys, occasionally with some Revocation and Destruction of Keys.

When the function is performed

CMS requires that all keys be rotated at least once every year.

PKI certificates should be replaced before the existing ones expire.

Keys will also need to be rotated when they have been inappropriately exposed.

How the function is performed

AWS will manage routine rotation of keys of AWS-managed keys in KMS.  Customer managed keys can also be automatically rotated by KMS once set up.

PKI certificates require manual intervention because a new certificate pair needs to be requested from IUSG/DOM as in Generation of Keys and then stored in the corresponding Certification Manager.  Begin this process 30 days before the existing keys expire.

This system uses [Key Management Tool] for the Generation, Distribution, and Storage of Keys.  Refer to those sections for specific instructions.

In the event of an incident involving the exposure of an encryption key, the data that is encrypted with the impacted key will need to be re-encrypted with a new key to prevent unintentional exposure. Refer to AWS's documentation on how to accomplish this.

Revocation of Keys

What and why

When a shared key such as PKI certificates for TLS or a symmetric key used by two different parties is no longer valid, it needs to be revoked so that it can no longer be used and will mitigate the risk of key compromise.  This can be done for routine reasons such as after a key rotation or in exceptional circumstances such as after a key compromise.

Who performs the function

Key revocation is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Where the function is performed

Revocation of PKI certificates is performed at the Certificate Authority.

When the function is performed

The revocation of keys is performed when a key is no longer valid either through routine expiration or after a key compromise.

How the function is performed

Contact IUSG/DOM to have them request revocation of PKI certificates obtained through them before expiration. [Insert Instructions]

[Document how revocation of other keys is performed]

Destruction of Keys

What and why

When a system is completely done with a key, it should be deleted or destroyed.  The system is completely done with the key either when the data that is encrypted is no longer needed, or there is no more data encrypted with that key. If the keys are recoverable (because they were not destroyed), it might lead to unauthorized re-use or a data breach.

Who performs the function

Key destruction is performed by [Role name]. They are granted this ability through the [Kion role, or another permissions manager role].

Where the function is performed

Deletion of keys occurs where the key is stored, unless physical keying material was used.  Then the physical material must also be destroyed.

When the function is performed

Destruction of keys happens when there is no longer data encrypted by the key, or the data is no longer needed.

How the function is performed

In AWS KMS, Customer managed keys can be deleted after a waiting period.  AWS managed keys can be disabled but not deleted.  Refer to AWS documentation for additional details. 

PKI certificates stored in ACM can be deleted once the certificate is no longer being used by any service.  Refer to AWS documentation for additional details.

[Document how to destroy keys and certificates in the tool the system uses]

Archival and Recovery of Keys

What and why

Sometimes encrypted data is archived, and the keys are stored somewhere safe as well to prevent additional use of the keys.  The keys may need to be retrieved from archival if the data is needed in the future.

Who performs the function

Key archival and recovery is performed by [Role name]. They get this ability through the [Kion role, or another permissions manager role].

Where the function is performed

Key archival and recovery is performed in the key management tool used by the system [Tool].  

To archive a PKI certificate, store it in [Tool].

When the function is performed

Archival is done when the data is not needed for a long period of time.  Recovery is done when the data is needed again.

How the function is performed

Key archival in AWS KMS is done by “disabling” the key, and recovery is done by “enabling” the key.  While “disabled”, the key cannot be used for encryption or decryption.

To archive a PKI certificate pair, identify a long-term storage location and document how the keys are stored.

[Document how to archive and recover keys and certificates in the tool the system uses]

Compromise Recovery Plan

The team follows the existing general incident response plans and procedures for connecting with the CCIC in the event of a key compromise.  The team also establishes these additional steps specific to key compromise: [Insert any steps specific to responding to a key compromise]