---
name: cloud-databases-reference-hpcs
title: Hyper Protect Crypto Services integration
description: IBM Cloud&reg; is transitioning the dedicated key management services from Hyper Protect Crypto Services to IBM&reg; Key Protect Dedicated. Migrate existing Hyper Protect Crypto Services (HPCS) root keys to IBM&reg; Key Protect Dedicated (Single Tenant) before HPCS End of Life (EOL) on March 20, 2027 to ensure continued service availability. After that date any remaining instances will be terminated. To ensure continued service availability and support, you must migrate all existing HPCS root keys to IBM Key Protect Dedicated (Single Tenant) before the EOL date. Learn how to migrate your root keys.
last-updated: 2026-03-31
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/cloud-databases?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.

# Hyper Protect Crypto Services integration
{: #hpcs}


IBM Cloud&reg; is transitioning the dedicated key management services from Hyper Protect Crypto Services to IBM&reg; Key Protect Dedicated. Migrate existing Hyper Protect Crypto Services (HPCS) root keys to IBM&reg; Key Protect Dedicated (Single Tenant) before HPCS End of Life (EOL) on March 20, 2027 to ensure continued service availability. After that date any remaining instances will be terminated. To ensure continued service availability and support, you must migrate all existing HPCS root keys to IBM Key Protect Dedicated (Single Tenant) before the EOL date. [Learn how to migrate your root keys](#migrating_hpcs_to_kp).
{: deprecated}

The data that you store in Cloud Databases is encrypted by default by using randomly generated keys. If you need to control the encryption keys, you can Bring Your Own Key (BYOK) through [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started&format=markdown), and use one of your own keys to encrypt your databases. Take note that Hyper Protect Crypto Services for IBM Cloud&reg; Databases backups is currently not supported for the majority of regions and not recommended to be used without careful considerations of the impact to disaster recovery.

To get started, you need [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services) provisioned on your IBM Cloud account.

## Creating or adding a key in Hyper Protect Crypto Services
{: #create-key}

Navigate to your instance of Hyper Protect Crypto Services and [generate or enter a key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started&format=markdown).

## Granting service authorization
{: #grant-auth}

Authorize Hyper Protect Crypto Services for use with Cloud Databases deployments:

1. Open your IBM Cloud dashboard.
2. From the menu bar, click **Manage** > **Access (IAM)**.
3. In the side navigation, click **Authorizations**.
4. Click **Create**.
5. In the **Source service** menu, select the service of the deployment. For example, **Databases for PostgreSQL** or **Messages for RabbitMQ**
6. In the **Source service instance** menu, select **All instances**.
7. In the **Target service** menu, select **HPCS**.
8. Select or retain the default value **`Account`** as the resource group for the **Target Service**
9. In the Target service **Instance ID** menu, select the service instances to authorize.
10. Enable the **Reader** role.
11. Click **Authorize**.

If the service authorization is not present before provisioning your deployment with a key, the provision fails.

## Using the HPCS key
{: #use-hpcs}

After you grant your Cloud Databases deployments permission to use your keys, you supply the [key name or CRN](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-keys&format=markdown) when you provision a deployment. The deployment uses your encryption key to encrypt your data.

If provisioning from the catalog page, select the HPCS instance and key from the drop-down menu.

In the CLI, use the `disk_encryption_key_crn` parameter in the parameter's JSON object.

```bash
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-NAME> standard us-south \
-p \ '{
  "disk_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'
```
{: codeblock}

In the API, use the `disk-encryption-key` parameter in the body of the request.

```curl
curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "my-instance",
    "target": "blue-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-x-standard",
    "disk_encryption_key_crn": "crn:v1:<...>:key:<id>"
  }'
```
{: codeblock}

If you provision a deployment through the CLI or API, the HPCS key must be identified by its full CRN, not just its ID. An HPCS CRN has the format `crn:v1:<...>:key:<id>`.
{: .tip}

## Using the HPCS key for backup encryption
{: #use-hpcs-backups}

This feature is only supported in the eu-es and br-sao regions. Encrypting backups with HPCS in a single region renders the backups inaccessible, if availability of HPCS is disrupted in this region. Taking a backup and restoring from backups will fail for the period that HPCS is unavailable. Therefore, encrypting backups with HPCS is not recommended. Use IBM&reg; Key Protect to encrypt backups.
{: .note}

If you encrypted the backup with HPCS, encrypt the disk also with HPCS.
{: .tip}

After you grant your Cloud Databases deployments permission to use your keys, you supply the [key name or CRN](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-keys&format=markdown) when you provision a deployment. The deployment uses your encryption key to encrypt your data.

If you provision from the Catalog, select the HPCS instance and key from the drop-down menu.

In the CLI, use the `backup_encryption_key_crn` parameter in the parameter's JSON object.

```bash
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-NAME> standard eu-es \
-p \ '{
  "backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'
```
{: codeblock}

In the API, use the `backup-encryption-key` parameter in the body of the request.

```curl
curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "my-instance",
    "target": "blue-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-x-standard",
    "parameters": {
      "backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
    }
  }'
```
{: codeblock}

If you provision a deployment through the CLI or API, the HPCS key must be identified by its full CRN, not just its ID. An HPCS CRN has the format `crn:v1:<...>:key:<id>`.
{: .tip}

## Key rotation
{: #hpcs-rotation}

HPCS offers manual and automatic [key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-rotation-policy&format=markdown) and key rotation is supported by Cloud Databases deployments. When you rotate a key, the process initiates a _Syncing KMS state_ task, and your deployment is reencrypted with the new key. The task is displayed on the _Tasks_ panel on your deployment's _Overview_ and the associated HPCS and Cloud Databases events are sent to Activity Tracker.

## Deleting the deployment
{: #deleting-deployment}

If you delete a deployment that is protected with an HPCS key, the deployment remains registered against the key during the soft-deletion period (up to 9 days). If you need to delete the key in the soft-deletion period, you must [force delete](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys&format=markdown) the key. After the soft-deletion period, the key can be deleted without the force. You can check the [association between the key and your deployment](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-key-details&format=markdown) to determine when you can delete the key.

## Cryptoshredding
{: #cryptoshredding}

Cryptoshredding is a destructive action. When the key is deleted, your data is unrecoverable.
{: .important}

Hyper Protect Crypto Services enables [initiation of a force delete](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys&format=markdown) of a key that is in use by IBM Cloud&reg; services, including your Cloud Databases deployments. This action is called cryptoshredding. Deleting a key that is in use on your deployment locks the disks that contain your data and disables your deployment. You are still able to access the UI and some metadata such as security settings in the UI, CLI, and API but you are not able to access any of the databases or data that is contained within them. Key deletion is [sent to the Activity Tracker Event Routing](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-at-events&format=markdown) as `hs-crypto.secrets.delete`.

## Migrating from Hyper Protect Crypto Services (HPCS) to Key Protect Dedicated (KP-ST)
{: #migrating_hpcs_to_kp}

During the migration from Hyper Protect Crypto Services (HPCS) to Key Protect Dedicated (KP‑ST), the following occurs:

- Each KMS instance maintains its own unique root keys. Migration involves re‑associating the service with a new Key Protect Dedicated root key.
- Existing data encryption keys (DEKs) are securely re‑wrapped.
- During the transition, both Hyper Protect Crypto Services to Service and Key Protect to Service access policies must remain in place.
- Encrypted data is not re‑encrypted or moved.
- Service availability is maintained.

### Pre-requisites
{: #migrating_hpcs_to_kp_prereqs}

Before starting the migration, ensure you have:

- A Key Protect Dedicated (Single Tenant) instance.
- A root key created in that Key Protect Dedicated (KP‑ST) instance.
- Permissions to manage keys and service access policies.

### Migration steps
{: #migrating_hpcs_to_kp_steps}

1. Identify the existing Hyper Protect Crypto Services root key in use. The key must exist in an Hyper Protect Crypto Services instance and the service must already have access to it.
1. Create or select a Key Protect Dedicated root key. The key must be in the appropriate Key Protect Dedicated (Single Tenant) instance and accessible to the service.
1. Create a migration intent linking the two keys. The migration intent maps the current Hyper Protect Crypto Services key (source) to the new Key Protect Dedicated key (target). For more information about Key Protect migration, see [Migrating from Hyper Protect Crypto Services (HPCS) to Key Protect Dedicated](https://cloud.ibm.com/docs/key-protect?topic=key-protect-migrate-st&format=markdown#migrate-hpcs-usage).
1. Allow 1-2 business days for the migration to be executed. Event Streams securely re‑associates and re-wraps DEKs where applicable, without re‑encrypting or moving data.
1. Verify migration completion. The service must now reference the Key Protect Single Tenant root key. Key Protect Single Tenant root key should be visible and active and the Hyper Protect Crypto Services association should be removed.