{
	"id": "9fd10a0e-b576-4f6b-a2ec-6779a3b25d95",
	"created_at": "2026-04-06T02:12:57.443783Z",
	"updated_at": "2026-04-10T13:11:42.731083Z",
	"deleted_at": null,
	"sha1_hash": "d962662b1ea65e977c1013e220aff7e9561f5a36",
	"title": "Key rotation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 46032,
	"plain_text": "Key rotation\r\nArchived: 2026-04-06 01:49:55 UTC\r\nThis page discusses key rotation in Cloud Key Management Service. Key rotation is the process of creating new\r\nencryption keys to replace existing keys. By rotating your encryption keys on a regular schedule or after specific\r\nevents, you can reduce the potential consequences of your key being compromised. For specific instructions to\r\nrotate a key, see Rotating keys.\r\nWhy rotate keys?\r\nFor symmetric encryption, periodically and automatically rotating keys is a recommended security practice. Some\r\nindustry standards, such as Payment Card Industry Data Security Standard (PCI DSS), require the regular rotation\r\nof keys.\r\nCloud Key Management Service does not support automatic rotation of asymmetric keys. See Considerations for\r\nasymmetric keys in this document.\r\nRotating keys provides several benefits:\r\nLimiting the number of messages encrypted with the same key version helps prevent attacks enabled by\r\ncryptanalysis. Key lifetime recommendations depend on the key's algorithm, as well as either the number\r\nof messages produced or the total number of bytes encrypted with the same key version. For example, the\r\nrecommended key lifetime for symmetric encryption keys in Galois/Counter Mode (GCM) is based on the\r\nnumber of messages encrypted, as noted at\r\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf.\r\nIn the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to\r\ncompromise.\r\nIf you suspect that a key version is compromised, disable it and revoke access to it as soon as\r\npossible.\r\nRegular key rotation ensures that your system is resilient to manual rotation, whether due to a security\r\nbreach or the need to migrate your application to a stronger cryptographic algorithm. Validate your key\r\nrotation procedures before a real-life security incident occurs.\r\nYou can also manually rotate a key, either because it is compromised, or to modify your application to use a\r\ndifferent algorithm.\r\nHow often to rotate keys\r\nWe recommend that you rotate keys automatically on a regular schedule. A rotation schedule defines the\r\nfrequency of rotation, and optionally the date and time when the first rotation occurs. The rotation schedule can be\r\nhttps://cloud.google.com/kms/docs/key-rotation\r\nPage 1 of 2\n\nbased on either the key's age or the number or volume of messages encrypted with a key version.\r\nSome security regulations require periodic, automatic key rotation. Automatic key rotation at a defined period,\r\nsuch as every 90 days, increases security with minimal administrative complexity.\r\nYou should also manually rotate a key if you suspect that it has been compromised, or when security guidelines\r\nrequire you to migrate an application to a stronger key algorithm. You can schedule a manual rotation for a date\r\nand time in the future. Manually rotating a key does not pause, modify, or otherwise impact an existing automatic\r\nrotation schedule for the key.\r\nDon't rely on irregular or manual rotation as a primary component of your application's security.\r\nAfter you rotate keys\r\nRotating keys creates new active key versions, but doesn't re-encrypt your data and doesn't disable or delete\r\nprevious key versions. Previous key versions remain active and incur costs until they are destroyed. Re-encrypting\r\ndata removes your reliance on old key versions, allowing you to destroy them to avoid incurring additional costs.\r\nTo learn how to re-encrypt your data, see Re-encrypting data.\r\nYou must make sure that a key version is no longer in use before destroying the key version.\r\nConsiderations for asymmetric keys\r\nCloud KMS does not support automatic rotation for asymmetric keys, because additional steps are required before\r\nyou can use the new asymmetric key version.\r\nFor asymmetric keys used for signing, you must distribute the public key portion of the new key version.\r\nAfterward, you can specify the new key version in calls to the CryptoKeyVersions.asymmetricSign\r\nmethod to create a signature, and update applications to use the new key version.\r\nFor asymmetric keys used for encryption, you must distribute and incorporate the public portion of the\r\nnew key version into applications that encrypt data, and grant access to the private portion of the new key\r\nversion, for applications that decrypt data.\r\nWhat's next\r\nRotate a key.\r\nEnable or disable a key.\r\nLearn more about re-encrypting data.\r\nSource: https://cloud.google.com/kms/docs/key-rotation\r\nhttps://cloud.google.com/kms/docs/key-rotation\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cloud.google.com/kms/docs/key-rotation"
	],
	"report_names": [
		"key-rotation"
	],
	"threat_actors": [],
	"ts_created_at": 1775441577,
	"ts_updated_at": 1775826702,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d962662b1ea65e977c1013e220aff7e9561f5a36.pdf",
		"text": "https://archive.orkl.eu/d962662b1ea65e977c1013e220aff7e9561f5a36.txt",
		"img": "https://archive.orkl.eu/d962662b1ea65e977c1013e220aff7e9561f5a36.jpg"
	}
}