Pending generation (PENDING_GENERATION):
(Applies to asymmetric keys only.) This key version is still being generated. It
may not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service will
automatically change the state to enabled as soon as the version is ready.
Pending import (PENDING_IMPORT):
(Applies to imported keys only.) This key version is still being imported. It
may not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service will
automatically change the state to enabled as soon as the version is ready.
Enabled (ENABLED): The key version is ready for
use.
Disabled (DISABLED): This key version may not
be used, but the key material is still available, and the version can be
re-enabled.
Scheduled for destruction
(DESTROY_SCHEDULED): This key version is scheduled for destruction and will be
destroyed soon. While a key version is in this state, it can't be used for
cryptographic operations, and requests to use the key fail. The key version can
be restored into the disabled state
within the scheduled destruction period. This state corresponds with
Stage 2 - Soft Deletion
in the data deletion pipeline.
Destroyed (DESTROYED): This key version is
destroyed, and the key material is no longer stored in Cloud KMS.
If the key version was used for asymmetric or symmetric encryption, any
ciphertext encrypted with this version is not recoverable. If the key version
was used for digital signing, new signatures cannot be created. Additionally,
for all asymmetric key versions, the public key is no longer available for
download. A key version may not leave the destroyed state once entered, except
when re-imported.
This state corresponds with
Stage 3 - Logical Deletion from Active Systems
in the data deletion pipeline, meaning key material is deleted from all active
Cloud KMS systems. It takes 45 days from destruction time for key
material to be deleted from all Google active and backup systems. See
Cloud KMS's deletion timeline
for more information.
Import failed (IMPORT_FAILED): This key
version could not be imported. See Troubleshooting failed
imports for additional information
about the conditions that cause import failures.
Changing states of a key version
The following describes how a key version can change states:
When a key version for an asymmetric key is created, it starts with a state of
pending generation. When Cloud KMS finishes generating the key
version, its state automatically changes to enabled.
When a key version for a symmetric key is created, it starts with a state of
enabled.
A key version which is scheduled for destruction can be reverted to disabled
using
RestoreCryptoKeyVersion
and interfaces to this method. For examples, see
Restore a key version.
The following diagram shows the allowable states for a key version.
Note that only key versions for asymmetric keys start in the pending generation
state. Key versions for symmetric keys start in the enabled state.
Impact of key version state on cryptographic operations
The impact of key version state on cryptographic operations depends on whether
the key is used for:
Symmetric encryption
Asymmetric encryption or digital signing
Symmetric encryption
Each symmetric encryption key has a designated
primary version which is used at that point in time to encrypt data. In
order for a key to be available for use to encrypt data, it needs to have a
primary key version which is enabled.
When a key is used to encrypt plaintext, its primary key version is
used to encrypt that data. The information as to which version was used to
encrypt data is stored in the ciphertext of the data. Only one version of a
key can be primary at any given point in time.
If the primary key version is disabled, that key version cannot be used to
encrypt data. Note that an enabled primary key version can be disabled,
scheduled for destruction or destroyed, and a version which is not enabled can
be made the primary version.
Which key version is primary does not impact the ability to decrypt data.
A key version can be used to decrypt data as long as it is enabled.
Asymmetric encryption or digital signing
Each time an asymmetric key is used for encryption or digital signing, a key
version must be specified. In order for the key version to be available for
asymmetric encryption or digital signing, the key version must be enabled. You
can retrieve a key version's public key only if the key version is enabled.
Variable duration of the scheduled for destruction state
By default, keys in Cloud KMS spend 30 days in the Scheduled for
destruction (soft deleted) state
before the key material is
logically deleted
from the system. This duration may be configured, with the following caveats:
The duration is only configurable during key creation.
Once specified, the duration for the key cannot be changed.
The duration applies to all versions of the key created in the future.
The minimum duration is 24 hours for all keys, except for import-only keys
which have a minimum duration of 0.
The maximum duration is 120 days.
The value is configured using the destroy_scheduled_duration field of the
CryptoKey
in the CreateCryptoKeyRequest.
We recommend that you use the default duration of 30 days for all keys unless
you have specific application or regulatory requirements that require a
different value.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[],[],null,["# Key version states\n\nA key version has a\n[state](/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions#CryptoKeyVersion.CryptoKeyVersionState):\n\n- *Pending generation* (`PENDING_GENERATION`):\n (Applies to asymmetric keys only.) This key version is still being generated. It\n may not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service will\n automatically change the state to enabled as soon as the version is ready.\n\n- *Pending import* (`PENDING_IMPORT`):\n (Applies to imported keys only.) This key version is still being imported. It\n may not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service will\n automatically change the state to enabled as soon as the version is ready.\n\n- *Enabled* (`ENABLED`): The key version is ready for\n use.\n\n- *Disabled* (`DISABLED`): This key version may not\n be used, but the key material is still available, and the version can be\n [re-enabled](/kms/docs/enable-disable#enable_a_disabled_key_version).\n\n- *Scheduled for destruction*\n (`DESTROY_SCHEDULED`): This key version is scheduled for destruction and will be\n destroyed soon. While a key version is in this state, it can't be used for\n cryptographic operations, and requests to use the key fail. The key version can\n be [restored into the disabled state](/kms/docs/destroy-restore#restore)\n within the scheduled destruction period. This state corresponds with\n [Stage 2 - Soft Deletion](/security/deletion#stage_2_-_soft_deletion)\n in the data deletion pipeline.\n\n- *Destroyed* (`DESTROYED`): This key version is\n destroyed, and the key material is no longer stored in Cloud KMS.\n If the key version was used for asymmetric or symmetric encryption, any\n ciphertext encrypted with this version is not recoverable. If the key version\n was used for digital signing, new signatures cannot be created. Additionally,\n for all asymmetric key versions, the public key is no longer available for\n download. A key version may not leave the destroyed state once entered, except\n [when re-imported](/kms/docs/importing-a-key#re-import_a_previously_destroyed_key).\n This state corresponds with\n [Stage 3 - Logical Deletion from Active Systems](/security/deletion#stage_3_-_logical_deletion_from_active_systems)\n in the data deletion pipeline, meaning key material is deleted from all active\n Cloud KMS systems. It takes 45 days from destruction time for key\n material to be deleted from all Google active and backup systems. See\n [Cloud KMS's deletion timeline](/kms/docs/destroy-restore#timeline)\n for more information.\n\n- *Import failed* (`IMPORT_FAILED`): This key\n version could not be imported. See [Troubleshooting failed\n imports](/kms/docs/troubleshooting-failed-imports) for additional information\n about the conditions that cause import failures.\n\n| **Note:** Keys do not have states, only key versions have states.\n\nChanging states of a key version\n--------------------------------\n\nThe following describes how a key version can change states:\n\n- When a key version for an asymmetric key is created, it starts with a state of\n pending generation. When Cloud KMS finishes generating the key\n version, its state automatically changes to enabled.\n\n- When a key version for a symmetric key is created, it starts with a state of\n enabled.\n\n- A key version can move from enabled to disabled and from disabled to\n enabled using\n [`UpdateCryptoKeyVersion`](/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/patch)\n and interfaces to this method. For examples, see\n [Enabling and disabling key versions](/kms/docs/enable-disable).\n\n- A key version which is enabled or disabled can move to scheduled for\n destruction using\n [`DestroyCryptoKeyVersion`](/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/destroy)\n and interfaces to this method. For examples, see\n [Schedule a key version for destruction](/kms/docs/destroy-restore#schedule_a_key_version_for_destruction_destroy_a_key_version).\n\n- A key version which is scheduled for destruction can be reverted to disabled\n using\n [`RestoreCryptoKeyVersion`](/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/restore)\n and interfaces to this method. For examples, see\n [Restore a key version](/kms/docs/destroy-restore#restore_a_key_version).\n\nThe following diagram shows the allowable states for a key version.\n\nNote that only key versions for asymmetric keys start in the pending generation\nstate. Key versions for symmetric keys start in the enabled state.\n\nImpact of key version state on cryptographic operations\n-------------------------------------------------------\n\nThe impact of key version state on cryptographic operations depends on whether\nthe key is used for:\n\n- Symmetric encryption\n- Asymmetric encryption or digital signing\n\n### Symmetric encryption\n\nEach symmetric encryption key has a designated\n*primary version* which is used at that point in time to encrypt data. **In\norder for a key to be available for use to encrypt data, it needs to have a\nprimary key version which is enabled.**\n\nWhen a key is used to encrypt plaintext, its primary key version is\nused to encrypt that data. The information as to which version was used to\nencrypt data is stored in the ciphertext of the data. Only one version of a\nkey can be primary at any given point in time.\n\nIf the primary key version is disabled, that key version cannot be used to\nencrypt data. Note that an enabled primary key version can be disabled,\nscheduled for destruction or destroyed, and a version which is not enabled can\nbe made the primary version.\n\nWhich key version is primary does not impact the ability to decrypt data.\nA key version can be used to decrypt data as long as it is enabled.\n\n### Asymmetric encryption or digital signing\n\nEach time an asymmetric key is used for encryption or digital signing, a key\nversion must be specified. **In order for the key version to be available for\nasymmetric encryption or digital signing, the key version must be enabled.** You\ncan retrieve a key version's public key only if the key version is enabled.\n\nVariable duration of the *scheduled for destruction* state\n----------------------------------------------------------\n\nBy default, keys in Cloud KMS spend 30 days in the *Scheduled for\ndestruction* ([soft deleted](/security/deletion#stage_2_-_soft_deletion)) state\nbefore the key material is\n[logically deleted](/security/deletion#stage_3_-_logical_deletion_from_active_systems)\nfrom the system. This duration may be configured, with the following caveats:\n\n- The duration is only configurable during key creation.\n- Once specified, the duration for the key cannot be changed.\n- The duration applies to all versions of the key created in the future.\n- The minimum duration is 24 hours for all keys, except for import-only keys which have a minimum duration of 0.\n- The maximum duration is 120 days.\n\nThe value is configured using the `destroy_scheduled_duration` field of the\n[CryptoKey](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys#resource:-cryptokey)\nin the `CreateCryptoKeyRequest`.\n\nWe recommend that you use the default duration of 30 days for all keys unless\nyou have specific application or regulatory requirements that require a\ndifferent value."]]