Key version states

A key version has astate:

  • Pending generation (PENDING_GENERATION):(Applies to asymmetric keys only.) This key version is still being generated. Itmay not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service willautomatically 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. Itmay not be used, enabled, disabled, or destroyed yet. Cloud Key Management Service willautomatically change the state to enabled as soon as the version is ready.

  • Enabled (ENABLED): The key version is ready foruse.

  • Disabled (DISABLED): This key version may notbe used, but the key material is still available, and the version can bere-enabled.

  • Scheduled for destruction(DESTROY_SCHEDULED): This key version is scheduled for destruction and will bedestroyed soon. While a key version is in this state, it can't be used forcryptographic operations, and requests to use the key fail. The key version canberestored into the disabled statewithin the scheduled destruction period. This state corresponds withStage 2 - Soft Deletionin the data deletion pipeline.

  • Destroyed (DESTROYED): This key version isdestroyed, and the key material is no longer stored in Cloud KMS.If the key version was used for asymmetric or symmetric encryption, anyciphertext encrypted with this version is not recoverable. If the key versionwas used for digital signing, new signatures cannot be created. Additionally,for all asymmetric key versions, the public key is no longer available fordownload. A key version may not leave the destroyed state once entered, exceptwhen re-imported.This state corresponds withStage 3 - Logical Deletion from Active Systemsin the data deletion pipeline, meaning key material is deleted from all activeCloud KMS systems. It takes 45 days from destruction time for keymaterial to be deleted from all Google active and backup systems. SeeCloud KMS's deletion timelinefor more information.

  • Import failed (IMPORT_FAILED): This keyversion could not be imported. SeeTroubleshooting failedimports for additional informationabout the conditions that cause import failures.

Note: Keys do not have states, only key versions have states.

Changing states of a key version

The following describes how a key version can change states:

The following diagram shows the allowable states for a key version.

Key version states

Note that only key versions for asymmetric keys start in the pending generationstate. 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 whetherthe key is used for:

  • Symmetric encryption
  • Asymmetric encryption or digital signing

Symmetric encryption

Each symmetric encryption key has a designatedprimary version which is used at that point in time to encrypt data.Inorder for a key to be available for use to encrypt data, it needs to have aprimary key version which is enabled.

When a key is used to encrypt plaintext, its primary key version isused to encrypt that data. The information as to which version was used toencrypt data is stored in the ciphertext of the data. Only one version of akey can be primary at any given point in time.

If the primary key version is disabled, that key version cannot be used toencrypt data. Note that an enabled primary key version can be disabled,scheduled for destruction or destroyed, and a version which is not enabled canbe 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 keyversion must be specified.In order for the key version to be available forasymmetric encryption or digital signing, the key version must be enabled. Youcan retrieve a key version's public key only if the key version is enabled.

Variable duration of thescheduled for destruction state

By default, keys in Cloud KMS spend 30 days in theScheduled fordestruction (soft deleted) statebefore the key material islogically deletedfrom 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 keyswhich have a minimum duration of 0.
  • The maximum duration is 120 days.

The value is configured using thedestroy_scheduled_duration field of theCryptoKeyin theCreateCryptoKeyRequest.

We recommend that you use the default duration of 30 days for all keys unlessyou have specific application or regulatory requirements that require adifferent value.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-18 UTC.