You agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

The Importance of Key Rotation for Data Security

Table of content:
Join our newsletter

Your privacy is important to us, privacy policy.


In the modern data-driven world, cryptography plays an integral role in protecting sensitive data for organizations of all sizes. Cryptographic keys help encrypt and decrypt data by enabling the transformation of data from readable plaintext to scrambled ciphertext and vice versa to ensure data has not been tampered with. While such cryptographic keys provide protection from potential attacks, they cannot offer complete assurance against key theft, compromise, or weakening over time.

Given the critical significance of these keys we have to ensure they don’t get lost. Organizations should take proactive measures to secure them and guarantee they continue protecting sensitive data effectively. A recommended practice is regular key rotation - that refers to the process of replacing cryptographic keys at set intervals or following specific events.

In this article, we discuss how key rotations can help maintain a robust security posture, while exploring the implementation steps, challenges and recommended practices for rotating keys and distributing the keys securely.

Our Vault supports a single API to rotate keys, and the rest is fully automatic, unlike what you will read in the rest of this blog about how to implement it on your own. Experiment with a free Vault account.

Why Key Rotation is Important for Data Security

Key rotation is an indispensable practice of data security that involves regularly changing cryptographic keys used for encryption and decryption of data. By enforcing a limited amount of data to be encrypted with the same key, rotating cryptographic keys reduces consequences from the same key being compromised. This approach eventually helps maintain confidentiality, integrity, and availability while decreasing risks related to unauthorized access of encrypted information.


Unfortunately many people confuse key rotation with re-key and re-encryption, let’s sort it out. Key rotation is the general term for creating a new key and starting to encrypt data with it, while retiring the old key, hence the rotation.

Re-keying, on the other hand, involves changing cryptographic keys in an on-going communication channel like in TLS. However, ‘re-key’ can also be used in non-streaming encryption as a way to say ‘rotate key’.

Re-encryption refers to the process of encrypting previously encrypted data using a new key. However, this operation necessitates decrypting the data with the retired key initially, which results in an undesired performance impact. Moreover, the runtime complications associated with simultaneously serving the data during this process further add to the challenge.

Key Rotation & Compliance

Rotating keys is mostly implemented voluntarily by organizations to maintain strong security measures. It is normally provided as part of cloud providers’ infrastructure. It is becoming a best practice and the recommended way to build systems. In addition, there are also guidelines promoting the use of cryptography and key rotation by different frameworks such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and Payment Card Industry Data Security Standards (PCI-DSS). These frameworks provide guidelines on key management practices to assist organizations maintain data confidentiality while reducing the risks of key compromise to comply with relevant laws or standards.

Cryptographic Keys and Their Roles

Cryptographic keys in modern computing play a pivotal role in upholding robust data security and privacy. Cryptographically secure random number generators (CSPRNGs) generate long strings of bits as secure keys which are difficult to predict or reproduce.

For a higher degree of randomness, they utilize different sources such as hardware events or OS randomness as sources of entropy. These keys serve as input parameters of various algorithms and are utilized for various cryptographic operations including encryption, decryption, digital signatures and key exchange.

The two primary categories of cryptographic keys are symmetric and asymmetric keys.

  • Symmetric keys allow one key to both encrypt and decrypt, making these algorithms suitable for fast data encryption due to their efficiency and speed. It is normally used for fast data encryption, for example, in TLS post key-exchange or disk storage.
  • Asymmetric keys (commonly referred to as public key cryptography) employ two individual keys - one publicly shared and the other private that remains secret until shared with its owner's chosen collaborators. As these key algorithms typically require longer key lengths and more compute time than symmetric key algorithms, these are considered unsuitable for storing structured data in runtime, where efficiency and speed are important. Normally used for PKI and keys exchange.

Key Management Lifecycle

Key management encompasses multiple stages, from key generation and distribution through storage, usage and rotation before being destroyed - each essential for maintaining data security and complying with industry regulations. These are the stages:

  • Generation: Generating strong cryptographic keys using a cryptographically secure random number generator.
  • Distribution: Safely transmit them using encrypted channels, such as TLS/SSL or secure file transfer protocols, to authorized parties without risking unintended exposure. 
  • Storage: Utilize key management systems (KMS) to encrypt, store and manage cryptographic keys to protect them from theft or unauthorized access. 
  • Usage: Utilize keys for encryption and decryption with appropriate role-based access controls, multi-factor authentication, and monitoring in place.
  • Rotation: Replace cryptographic keys regularly or according to a policy to limit their exposure and minimize any data exposure impact from potential key compromise.
  • Destruction: Safely delete keys once they are no longer needed to prevent their recovery or misuse.

Key Rotation Strategies

There are mostly two popular use cases for encryption in systems today, network protocols (streams) and storage devices (databases, etc). Practically, rotating keys over network protocols is much easier because you don’t need to keep old keys and rotation is done in run time. In mass storage encryption, sometimes you have to keep old keys along with the old data, because re-encrypting everything is heavy on load. Therefore knowing which key to use when decrypting data requires more engineering (keeping key index, for example). Achieving robust key rotation is hard. Google Tink helps doing it right and it’s open source!

Therefore, we’re about to mention a few strategies that should generically capture both cases.

Time-Based Key Rotation

A time-based key rotation approach helps manage cryptographic keys where new keys are generated periodically and replaced with old ones over a predefined period. Keys may be rotated daily, weekly, monthly or as otherwise specified depending on organizational security policy. Granted, in the event a single key is compromised, the attacker cannot access all of the previously encrypted data since it was encrypted using different keys.


  • Restricts exposure window to reduce compromise data risk
  • Uses an easily manageable schedule to simplify key rotation

Implementation Considerations

  • Diligently plan an effective key management strategy that fits your organization's risk profile
  • Automate key rotation using scripts or existing key management software (KMS)
  • Before disposing of old keys, ensure to securely back up or migrate any data encrypted with those keys to new keys
  • Once data is migrated to be used with new keys, ensure secure storage and disposal of old keys to prevent unapproved access

Usage-Based Key Rotation

This key rotation approach helps organizations adapt according to the amount of data or transactions processed using cryptographic keys. Once a key reaches its usage threshold, it is replaced with a new one. This approach ensures that a single key does not encrypt an excessive amount of data, which could otherwise increase the potential impact of a key compromise.


  • Prevents key compromise by limiting the amount of data that can be encrypted with a single key at any given time 
  • Maintains optimum security levels over periods of high or low volume transactions

Implementation Considerations

  • Determine key usage thresholds based on an organization's risk profile and encryption algorithm strength. For instance, after 1 GB of plaintext data being encrypted or after 1,000 encryption/decryption operations per key.
  • Once encrypted data is backed up or migrated to be used by new keys, dispose obsolete keys when their lifespan ends to prevent data compromise

Incident-Triggered Key Rotation

Incident-triggered key rotation is typically employed manually when there are indications of possible security breach, suspicious activities or modifications to an organization's risk profile. This strategy helps to quickly mitigate key compromise, replacing potentially compromised keys with new ones quickly and swiftly.


  • Faster response to potential key compromises or security incidents
  • Reduces impact by quickly replacing affected keys

Implementation Considerations

  • Implement robust monitoring and alert systems to detect security incidents early
  • Create incident response plans which include key rotation procedures
  • Transmit new key securely to all relevant parties
  • Ensure old keys are safely stored or disposed of to avoid unauthorized entry

Implementing Key Rotation

Key rotation involves regularly updating cryptographic keys used for encryption and decryption to maintain data confidentiality while mitigating key compromise. It is recommended that keys will be rotated automatically by the system you build, reducing human error in running such a process manually. Common approaches used for rotating keys include:

Key Rotation in Symmetric Encryption

Symmetric encryption utilizes one shared key for both encryption and decryption purposes, offering easier key rotation at scale. Key rotation in symmetric encryption requires generating a new secret key and securely distributing it to all relevant parties.

In the following example, we demonstrate key rotation using AES algorithms with Python using its cryptography library.

steps for key rotation and secure distribution

Step 1: Generate a new symmetric key

As the starting point, generate a new symmetric key with a cryptographically secure random number generator using os.urandom(). The new key will then be used to encrypt and decrypt data after the key rotation process is complete.

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import os

backend = default_backend()

darwin_new_key = os.urandom(32)
print(f"New Darwin AES key: {darwin_new_key.hex()}")

Executing the script, returns the output:

New Darwin AES key:

Step 2: Encrypt the new key

Encrypting the new key before distribution ensures that it remains confidential during transit. The encrypted new key can only be decrypted and used by parties who possess the old key or a dedicated key-encrypting key - a cryptographic key used for encrypting other cryptographic keys to add an additional layer of protection against data loss during transmission.

In our case, we encrypt the new key using the old key with the AES algorithm in GCM mode.

darwin_old_key = os.urandom(32)

cipher = Cipher(algorithms.AES(darwin_old_key), modes.GCM(os.urandom(12)), backend=backend)
encryptor = cipher.encryptor()
darwin_encrypted_new_key = encryptor.update(darwin_new_key) + encryptor.finalize()
darwin_tag = encryptor.tag

print(f"Encrypted Darwin new key: {darwin_encrypted_new_key.hex()}")
print(f"Darwin Tag: {darwin_tag.hex()}")

Which returns the output:

Encrypted Darwin new key:
Darwin Tag: a6a17e7457c636f23dafebd1aa366e5e

Step 3: Securely distribute the encrypted new key

The next step is to securely distribute the new encrypted key to prevent unauthorized access or interception. This typically involves sending the encrypted key and associated metadata (such as the tag, in the case of AES-GCM) through secure communication channels.

It’s important to make sure that TLS is used on the server side and that the client will verify the domain using an official certificate authority (this is normally the default OS behavior). However, using plain TCP/IP communications without TLS might expose the keys in case of a MITM attack. In such cases, implementing certificate pinning to verify the expected domain of the receiver's certificate is vital.

Step 4: Decrypt the new key

Once authorized parties receive the encrypted new key, they can decrypt it using the old key. Post decryption, they should update their encryption systems to use the new key for encrypting and decrypting data. This ensures that all parties maintain the ability to securely communicate with each other using the updated key.

To update the encryption systems of all authorized parties with the new key, use the following script:

cipher = Cipher(algorithms.AES(darwin_old_key), modes.GCM(os.urandom(12), darwin_tag), backend=backend)
decryptor = cipher.decryptor()

darwin_decrypted_new_key = decryptor.update(darwin_encrypted_new_key) + decryptor.finalize()

print(f"Decrypted Darwin new key: {darwin_decrypted_new_key.hex()}")

Returns the output:

Decrypted Darwin new key:

Once the new key is ready to be used, the old key should now be deleted from any storage mediums, backups, or logs where it may have been recorded. Before disposing of the old key, it is important to ensure the encrypted data is migrated to be used by the new key. In Python, you can use the ctypes library to overwrite the memory contents while securely deleting sensitive information from memory.

Key Rotation in Asymmetric Encryption

Asymmetric encryption, commonly referred to as public key cryptography, involves using two keys - public and private keys. Public keys can be freely distributed for others to encrypt data or validate digital signatures, while private keys remain private to their owner and used only for decrypting messages or signing them.

Using Piiano Vault, you don't need to go through this hassle, create a free Vault account today and use a single API to rotate keys.

Key rotation in asymmetric encryption involves the following steps: 

Step 1: Generate a new key pair

As the initial step, create a new pair of public and private keys to be used with asymmetric encryption. To do so, we are using RSA keys and the Python cryptography library in the example below.

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.backends import default_backend

darwin_private_key = rsa.generate_private_key(
darwin_public_key = darwin_private_key.public_key()

darwin_pem_public_key = darwin_public_key.public_bytes(

print("New Darwin Public Key (PEM):")

Which generates the new public key as shown below:

New Darwin Public Key (PEM):
-----END PUBLIC KEY-----

Step 2: Sign the new public key with the old private key

Assuming you already have an existing private key (in this example, darwin_old_private_key), you can sign the new public key to establish trust.

from cryptography.hazmat.primitives.asymmetric import padding

darwin_signature = darwin_old_private_key.sign(

print(f"Darwin Signature: {darwin_signature.hex()}")

Once the new public key is signed, the associated signature should be securely transmitted to authorized parties using secure communication channels, such as TLS or secure messaging protocols.

Step 3: Update systems with the new key pair

On the recipient side, verify the new signed public key using the old public key (in our example, darwin_old_public_key):

    print("Darwin signature verified.")
except cryptography.exceptions.InvalidSignature:
    print("Invalid Darwin signature.")

Once the new public key is verified, all parties can update their systems with the new public and private keys as necessary.

Step 5: Revoke and delete the old public key

As the last step, update key servers or certificate authorities with the revocation status of the old public key, ensuring that other parties do not mistakenly use the old public key for encryption or signature verification. Following this, delete the old private key using the ctypes library to overwrite the memory contents.

Quick note: As the cryptography library doesn't expose raw key material for RSA keys, ensure that any files or other storage mediums containing the old private key are securely deleted.

Key Rotation in Cloud Services

You can also utilize your Cloud Service Provider’s (CSP’s) built-in key management systems for key rotation. In most cloud services, Customer Master Keys (CMKs) are used to protect data encryption keys (DEKs). DEKs are actual encryption keys used for data encrypting and decrypting while CMKs add an extra layer of protection by encrypting DEKs. Rotating CMKs helps limit data encryption with one key, subsequently reducing the impact upon potential compromise.

Using Piiano Vault, we have exactly 0 steps for managing keys, create a Vault account today and start protecting sensitive data.

Key rotation through CSP KMS services involves the following steps:

Step 1: Create a new Customer Master Key (CMK)

In this example, while we use Amazon Web Services (AWS) Key Management Service (KMS) and the AWS Command Line Interface (CLI), refer to your respective CSP’s documentation to ensure you follow the right steps for key rotation.

To generate a new CMK in AWS KMS, you can use the create-key command to create a new key that can be used later to replace the old one for encrypting and decrypting data.

aws kms create-key --description "New Darwin Master Key"

Which returns the output:

    "KeyMetadata": {
        "AWSAccountId": "918273645091",
        "KeyId": "efgh5678-b234-789b-b23c-b234d5ef78ij",
        "Arn": "arn:aws:kms:us-east-1:918273645091:key/efgh5678-b234-789b-b23c-b234d5ef78ij",
        "CreationDate": "2023-04-26T18:30:00Z",
        "Enabled": true,
        "Description": "New Darwin Master Key",
        "KeyUsage": "ENCRYPT_DECRYPT",
        "KeyState": "Enabled",
        "Origin": "AWS_KMS",
        "KeyManager": "CUSTOMER",
        "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT"

Step 2: Create an alias for the new CMK

To make it easier to reference the new CMK, you can create an alias using the create-alias command.

aws kms create-alias --alias-name alias/DarwinNewMasterKey --target-key-id efgh5678-b234-789b-b23c-b234d5ef78ij

Step 3: Re-encrypt data with the new CMK

To re-encrypt data with the new CMK, first decrypt the data using the old CMK and then encrypt it with the new CMK.

aws kms decrypt --ciphertext-blob fileb://darwin_ciphertext_blob --output text --query Plaintext | base64 --decode > darwin_plaintext_data
aws kms encrypt --key-id alias/DarwinNewMasterKey --plaintext
fileb://darwin_plaintext_data --output text --query CiphertextBlob | base64 --decode > darwin_ciphertext_blob_new

Once done, ensure all systems, applications, and services that previously used the old CMK are updated to use the new CMK for encryption and decryption. This may include updating configuration files, environment variables, or application code.

Step 4: Disable and schedule deletion of the old CMK

Once you have successfully re-encrypted all data and updated systems with the new CMK, you can disable and schedule the deletion of the old CMK.

aws kms update-key --key-id darwin_old_key_id --enabled false

Schedule deletion of the old CMK using the command:

aws kms schedule-key-deletion --key-id darwin_old_key_id
--pending-window-in-days 30

Which returns the output:

    "KeyId": "darwin_old_key_id",
    "DeletionDate": "2023-05-26T00:00:00Z"

Auditing and Monitoring Key Rotation

Auditing and monitoring key rotation is a crucial aspect of maintaining secure and compliant data encryption practices. The processes collectively involve tracking key-related activities, detecting potential security incidents, and ensuring adherence to organizational policies and industry regulations. 

Most key management systems (KMS) and CSPs provide built-in logging capabilities that record key rotation events. These logs help retain data for a predefined period, depending on organizational policies and regulatory requirements to help ensure traceability and facilitate incident response.

Key logs typically contain details about:

  • Key creation, modification, and deletion
  • Key usage, including encryption and decryption operations
  • Access control changes, such as granting or revoking permissions
  • Key metadata updates, including descriptions and aliases

While logging is considered one of the foundational elements to audit key operations, monitoring is another crucial aspect that allows for timely detection of potential security incidents or policy violations. Monitoring key rotation can be achieved either by using built-in monitoring tools provided by KMS or CSPs, or by integrating with third-party security information and event management (SIEM) solutions.

Monitoring key rotation should involve identifying unusual key access or usage patterns, detecting potential key compromise or unauthorized attempts to rotate keys, and ensuring that key rotation occurs at specified intervals as defined by organizational policies or regulatory requirements

Challenges and Best Practices of Scaling a Key Rotation Solution

As organizations grow, scaling a key rotation solution presents its own set of challenges, from managing numerous keys and systems to ensuring secure key distribution and compliance. However, with the right practices, it is possible to overcome such challenges and maintain a robust security posture. 

The table below lists various challenges and the recommended practices to overcome them.

Challenge Recommended Practice
Increased complexity as the number of keys and systems grow. Adopt a centralized key management solution such as a Hardware Security Module (HSM) or cloud-based KMS to securely manage and control cryptographic keys at scale.
Ensuring secure and timely key distribution and synchronization at scale. Automate key rotation processes to maintain synchronization, reduce human intervention, and minimize errors as the system grows.
Integration with diverse systems and applications with differing requirements and compatibility issues. Establish standardized key rotation policies and procedures across the organization to ensure uniform security practices and streamline integration.
Ensuring compliance with industry regulations and maintaining proper auditing records as the number of keys and systems involved grows. Implement strict access control policies and continuous monitoring of key usage to maintain security, detect potential threats, and ensure compliance in a growing environment.
Performance impact and potential latency introduced by larger-scale key rotation processes. Design and implement a scalable key rotation architecture capable of handling growing demands and limiting performance impairment.
Increased microservice count amplifies the risk of key compromise, posing a grave threat to data security. Implement strict access controls and isolation measures to limit exposure, regularly rotate keys, and ensure automated key usage to minimize the risk of compromise. But eventually that’s the weakest link in the chain.
Copying real data to staging environments may involve multiple individuals accessing the keys, leading to privacy and security risks. Enforce strict access controls and strong encryption measures when transferring data to staging environments, limit employee access to keys, and implement mechanisms to monitor and audit key usage to mitigate risks. Or alternatively, de-identify the data by removing PII when it is copied to dev and staging environments.


Looking forward, as more organizations continue to adopt cloud-based application delivery and other distributed computing models, the importance of key rotation and other key management practices will only increase for stronger data protection. Some key questions, however, will remain pertinent:

  • While implementing key rotation sounds straightforward, technically it complicates the engineering and operating the system - how can we make it robust?
  • Once we rotate a key, do we also re-encrypt everything we already stored with it? What happens if we have huge amounts of data but the key was compromised? Should we rotate keys more often?
  • Ending up giving the keys to engineers to work with the data isn’t acceptable, we might need to build more gated access to the data.
  • Keys will always remain the weakest link in the chain, how do we minimize their use in the system? Distributing the keys is also a mechanism that should be built correctly.
  • Storing keys next to the data might have them tampered with. For example, if they are deleted, you will lose access to the data. Also refer to encryption DEK and KEK.
  • Having redundancy keys is important, but creates more risk to securing the keys. This requires a whole architecture with security by design.

With the above questions answered, the crucial aspects of maintaining key-level security can be addressed readily. Remember that even though keys are meant to secure data, they are equally susceptible to targeted attacks and compromise.

Our vault solution doesn't require working with key. Generally, working with keys directly in various components in the backend only weakens the system in terms of security. Sign up for a free trial Vault account.

Share article

Powering Data Protection

Skip PCI compliance with our tokenization APIs

Skip PCI compliance with our tokenization APIs




It all begins with the cloud, where applications are accessible to everyone. Therefore, a user or an attacker makes no difference per se. Technically, encrypting all data at rest and in transit might seem like a comprehensive approach, but these methods are not enough anymore. For cloud hosted applications, data-at-rest encryption does not provide the coverage one might expect.

John Marcus

Senior Product Owner

const protectedForm = 
pvault.createProtectedForm(payment Div, 
Thank you! Your submission has been received!

We care about your data in our privacy policy

Oops! Something went wrong while submitting the form.