The contract archive has been copied to a recovery site. Every file is present and the checksums match. Restoration then reveals that the key is accessible only through the unavailable primary cloud account. The company has retained all its data and cannot read a single document.
Key management is about continued access as well as preventing disclosure. Who can use encrypted data today, and who will be able to restore it years later? This article focuses on keys protecting stored data. Signing keys and other cryptographic uses have different requirements; one replacement schedule should not be assumed to suit them all.
Decide which threat the encryption addresses
Disk encryption can protect a removed storage device. It does not necessarily prevent an authorised application from reading a running database. An attacker with that application's permissions may be served by the same decryption mechanism.
Choose the encryption layer against a threat model and design access controls separately. The OWASP Cryptographic Storage guide follows this distinction. “Enable encryption” is incomplete until we know which copy could be stolen and who could still open it.
For contracts, identify the live database, attachments, exports, backups and temporary files. Encrypting the database does not protect an unencrypted nightly export. Copies need not all use the same mechanism, but none should be overlooked.
An encrypted key beside a file can be correct
A common construction encrypts a document with a data key, then protects that data key under a key managed by a KMS. This is envelope encryption. The encrypted data key can be stored alongside the document; reading it requires an authorised operation to recover the usable key. AWS KMS documentation describes the construction.
Asking whether a key is “next to the data” therefore misses the point. A plaintext data key in an accessible folder is not equivalent to an encrypted data key protected by a separately controlled KMS key.
Applications need permission for specific operations and data, not administration of the entire key system. Upload and viewing services may have different duties. Permission to change a key policy matters too: an administrator who can grant themselves decryption is not an independent control just because their role has another name.
Rotation does not rewrite the past
“Replace the key” may mean new key material, a different logical key or re-encryption of stored content. These are distinct changes. For example, AWS KMS rotation neither re-encrypts existing data nor replaces previously generated data keys. Earlier material remains available for required decryption.
If an attacker already holds a document and its usable key, an administrative change cannot take that ability away. A new key can protect subsequent writes. Existing data needs a separate decision, and a stolen copy cannot be forced to follow our migration.
A transition plan should identify what stays under the old key, what is transformed and how both generations are tested. Successfully creating one new document is not permission to delete the earlier key while archives and backups still depend on it.
Deleting a key is not just stronger disabling
Disabling a key can often be reversed. Destroying indispensable key material can make data unrecoverable. AWS warns explicitly about deletion and the need to establish that the key is no longer required.
Maintain an account of which datasets and backup generations depend on each key. No recent use is weak evidence: an archived contract might be opened after years of inactivity. Data retention and the ability to decrypt it must be planned together.
Key destruction can form part of data deletion, but only within a verified design: no other usable key copies, plaintext exports or alternative reading paths. Removing one KMS object is not proof that every copy of a customer's information has disappeared.
Why one instance keeps working without KMS
An application may already hold a usable data key in memory. Some reads can continue when KMS becomes unreachable, while a new instance cannot obtain the same material. This also affects permission revocation. Losing the service and immediately preventing every decryption are different events.
Caching cryptographic material needs limits on age and use. It reduces calls but leaves usable keys in the process for longer. The AWS Encryption SDK treats data-key caching as a mechanism with security thresholds, not an instruction to retain keys indefinitely for speed.
Test startup, old-document reading and new writes while the dependency is unavailable. An application must distinguish failure to decrypt from absence of the document. Creating an empty replacement automatically would make an availability incident much worse.
Recovery ends with a readable document
The recovery site needs an authorised route to the necessary keys, compatible decryption and operator access. Operators do not necessarily need, or have the option, to export the root key itself. Verify the supported recovery or transfer arrangement before relying on it.
Take several generations of the archive and its backups. Restore them in an agreed environment, read them with an authorised identity and confirm that an unauthorised one is refused. Test disabling and re-enabling a disposable test key rather than experimenting with irreversible deletion of production material.
Record the owner, scope, administration permissions and conditions for retirement. A suitable managed service may be simpler than building a private key-management platform. The company still owns the question of whether an old contract remains readable; an “encryption enabled” setting cannot answer it.