---
name: event-notifications-en-managing-encryption
title: Managing encryption with customer-managed keys
description: By default, customer data in Event Notifications is encrypted at-rest by using a randomly generated key. If your solution requires a higher level of control, you can manage your own encryption by integrating with IBM® Key Protect for IBM Cloud® or Hyper Protect Crypto Services. You must be using the standard pricing plan to bring your own key.
last-updated: 2026-09-02
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/event-notifications?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Managing encryption with customer-managed keys
{: #en-managing-encryption}

By default, customer data in Event Notifications is encrypted at-rest by using a randomly generated key. If your solution requires a higher level of control, you can manage your own encryption by integrating with IBM® Key Protect for IBM Cloud® or Hyper Protect Crypto Services. You must be using the standard pricing plan to bring your own key.
{: shortdesc}

If your solution requires that you manage your own keys for data at rest or that you have explicit control of the full lifecycle of data,including at rest, then you might consider using customer-managed keys. Both Key Protect and Hyper Protect Crypto Services are designed to allow the use of a customer-provided key to control encryption. To compare the services and determine which is best for your solution, see [Which data security service is best for me?](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-secrets-ibm-cloud&format=markdown)

If you delete a custom-managed key without going through the proper process, you could lose access to the data that is stored in your Event Notifications instance.
{: important}

## What is not covered by customer-managed encryption
{: #en-encryption-what}

If customer-managed encryption feature is selected, the user should be aware that **only** customer data is covered by this encryption. Event Notifications encrypts at-rest other data related to the use of the service.

It is not recommended to use confidential information in client metadata.
{: important}

## How customer-managed encryption works
{: #en-encryption-how}

Event Notifications uses a concept called envelope encryption to implement customer-managed keys.

Envelope encryption is the practice of encrypting one encryption key with another encryption key. The key used to encrypt the actual data is known as a data encryption key (DEK). The DEK itself is never stored, but instead is wrapped by a second key known as the key encryption key (KEK) to create a wrapped DEK.

To decrypt data, the wrapped DEK must first be unwrapped to get the DEK. This process is possible only by accessing the KEK, which in this case is your root key stored in either [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about&format=markdown){: external} or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-overview&format=markdown){: external}.

You own the KEK, which you create as a root key in the Hyper Protect Crypto Services or Key Protect service. The Event Notifications service never sees the root (KEK) key. Its storage, management, and use to wrap and unwrap the DEK is performed entirely within the key management service. If you disable or delete the key, the data can no longer be decrypted.

## Enabling a customer-managed key for Event Notifications
{: #en-enabling-encryption}

Complete the following steps to provision your Event Notifications instance to use a customer-managed key:

1. Provision an instance of [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision&format=markdown){: external} or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-provision&format=markdown){: external}.

1. Create an authorization policy to allow the Event Notifications service to access the key management service instance as a Reader. For more information, see [Using authorizations to grant access between services](https://cloud.ibm.com/docs/iam?topic=iam-serviceauth&interface=ui&format=markdown){: external}.

1. Create or import a root key into your key management service instance.

1. Retrieve the Cloud Resource Name (CRN) of the key using the **View CRN** option in the key management service instance GUI.

1. Provision an instance of [Event Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-getting-started&format=markdown#en-cloud-ac). This feature is supported on the Standard plan only.

## Using a customer-managed key
{: #en-using-encryption}

After a customer-managed key is enabled, the cluster operates as normal, but with the following additional capabilities:

### Preventing access to data
{: #en-preventing-access}

To temporarily prevent access, you can disable your root key. As a consequence, Event Notifications can no longer access the data because it can no longer access the key.

To remove access permanently, you can delete the key. However, you must take extreme caution because this operation is non-recoverable. You will lose access to any data stored in your Event Notifications instance. There is no way to recover this data.

In both cases, the Event Notifications instance shuts down and no longer accepts or processes connections. A cloud logs event is generated to report the action. For more information, see [Event Notifications events](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-at_events&format=markdown).

The authorization should remain in place between your Event Notifications and the key management service instance at all times. While removing this authorization prevents Event Notifications from future access to your data, already in-use data will continue to be available for a period of time.
{: note}

You are charged for your instance of Event Notifications until you deprovision it using the IBM Cloud console or CLI. These charges are still applied even if you chose to prevent access to your data.
{: important}

### Restoring access to data
{: #restoring-access}

Access can be restored only if the key was not deleted. To restore access, re-enable your root key. After a short period of initialization, your Event Notifications instance is restarted and starts accepting connections again. All data is retained, subject to the normal retention limits configured in your instance.

A cloud logs event is generated to report the action. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-at_events&format=markdown).

### Rotating the key
{: #rotating-key}

Key Protect and Hyper Protect Crypto Services support the rotation of root keys, either on demand or on a schedule. When this occurs, Event Notifications adopts the new key by rewrapping the DEK as described in [how customer-managed encryption works](#en-encryption-how).

A cloud logs event is generated to report the action. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-at_events&format=markdown).

## Disabling customer-managed encryption
{: #stop-customer-encryption}

After enabling customer-managed encryption, it is not possible to disable it. Instead, you must delete the service instance and create a new instance.

Alternatively, you can use pre-built, open-source, and enterprise-ready Terraform IBM Modules (TIM) to provision your infrastructure through [Event Notifications](https://registry.terraform.io/modules/terraform-ibm-modules/event-notifications/ibm/latest){: external} module, see comprehensive [example](https://registry.terraform.io/modules/terraform-ibm-modules/event-notifications/ibm/latest/examples/advanced){: external} that demonstrates creating a Key Protect instance with a root key, provisioning an Event Notifications instance with bring-your-own-key (BYOK) encryption, and Configuring the authorization policy between services.
{: tip}