Follow a KMS Rotation Through the Wrapping Key, Data Key and Archive

Begin with the archive's two encryption layers

An enterprise has an encrypted AI dataset archive and has been promised replacement of its data key. The supplier returns a KMS rotation report. Before assessing that report, separate the object being managed from the two encryption relationships.

The logical KMS key is a managed resource. Its cryptographic material supplies the secret used in KMS cryptographic operations. In the wrapping arrangement considered here, that material protects a copy of an application data key. The application uses the data key outside KMS to protect the bulk archive; the encrypted data-key copy can accompany that archive. AWS's data-key guide also explains that KMS does not store, manage or track the application's data keys.

This explanation concerns an application directly using a customer-managed symmetric encryption KMS key with AWS_KMS-origin material and automatic material rotation. It assumes no integrated AWS service's data-key reuse behavior and makes no claim about other key origins, custom stores or providers. The three AWS references are mutable latest documentation read on October 20, 2026, rather than fixed software releases or documents with an asserted publication date. The example explains representations, not a field procedure.

References: [K1][K2]

At T0, connect K, M0, DA, WA and CA

Fictional case KR-LAYERS-01 starts with archive A at time T0. K labels the logical KMS key, and M0 labels its current material. DA labels the application data key used to encrypt archive A. CA labels the resulting bulk archive ciphertext. WA labels the encrypted copy of DA, protected under K using M0.

The archive package in this example contains CA and WA. They contain different kinds of protected content: CA is the encrypted dataset archive, while WA is an encrypted representation of its data key. Recovering DA from WA makes that same DA available for the application's decryption of CA.

All labels and relationships are invented premises. They are neither actual key values nor usable resource identifiers, and describe no real operation or test. M0 and M1 are explanatory material labels, not selectable KMS versions. No key-per-object policy follows from giving this one archive one data key.

References: [K2]

At T1, current material changes while archive A stays as it was

At time T1, the fictional report establishes that K's automatic material rotation completed. Its current material is now M1. K remains the same logical resource. The case explicitly leaves DA, WA and CA unchanged: archive A still has the original data key, its original encrypted copy and its original payload ciphertext.

AWS retains the earlier AWS_KMS-origin material. When decrypting an existing ciphertext, KMS uses the material associated with that ciphertext. WA therefore remains associated with M0 despite M1 becoming current.

The report can fully describe the material change without describing any application transformation. AWS expressly separates that rotation from data-key rotation and re-encryption of protected data. In this case, the changed item is current material; the original archive relationship is still DA, WA and CA.

References: [K1]

A new archive B does not describe what happened to A

Now add a separate fictional report: a new archive B was encrypted with a freshly generated data key DB, producing payload ciphertext CB. Its encrypted data-key copy WB was protected under K using current material M1. DB is stipulated to be different from DA.

Both archive descriptions name K, but their data keys and payloads differ. K's stable identity does not make DB the key for CA. Likewise, showing a new write associated with M1 does not establish that the earlier archive was rewritten.

The new report describes B accurately under the premises. It adds no change to A. A buyer promised replacement of existing archive data keys still needs an explanation covering those existing archives; a demonstration concerning only the newly written B has a different subject.

An alternative WA2 can still contain the same DA

Consider instead a separate wrapper-change report for archive A. It identifies a new encrypted copy, WA2, and explicitly says that WA2 protects the same DA while CA remains unchanged. This is an alternative supplied representation, not something the material-rotation report established. The wrapper has changed; the data key protecting the payload has not.

ReEncrypt is relevant to understanding a possible operation at this layer. AWS documents it as decrypting compatible ciphertext and re-encrypting it within KMS. A suitable KMS-generated encrypted data-key copy can be such an input. The API does not accept arbitrary ciphertext formats: AWS specifically excludes incompatible ciphertext produced by the AWS Encryption SDK or Amazon S3 client-side encryption.

Naming ReEncrypt in a report therefore leaves the role of its input to explain. If the object transformed is the encrypted copy of DA, the operation concerns that wrapper. In the stipulated WA2 report, the underlying key remains DA and the archive remains CA. The word re-encryption alone cannot establish replacement of the key used for the bulk payload.

References: [K3]

Ask the application provider to explain the change to archive A

If the promised result is replacement of archive A's data key, none of the three supplied reports substantiates it. Material rotation changes K's current material. The B report concerns a different archive. The WA2 report expressly retains DA. Their conclusions differ, but all leave the promised replacement for A unsupported.

A new data key for A's existing payload would concern a separate application transformation, with a corresponding payload representation protected by that different key. Another encrypted copy of DA does not describe that transformation. This is a distinction between change scopes, without an instruction to perform a payload rewrite.

Ask the appointed application provider to explain exactly which representation the returned result describes for A. Does it concern K's material, the encrypted copy of the data key, or a changed data key and corresponding archive ciphertext? Have the provider connect its before-and-after explanation to the same existing archive and state which retained archive versions the promised result covers. The buyer needs that explanation, not actual key values.

An absent explanation leaves the deliverable unsubstantiated; it does not establish an actual failed operation or a security outcome. The related guides address the separate questions of encryption versus media sanitization, confidential execution and resource-access enforcement. Evidence for those questions cannot fill the missing application transformation.

Scope any surrounding equipment change separately

If the archive project also includes approved storage-server or rack equipment changes, Leviathan's Hardware Refresh & Physical Support service is relevant to the separately agreed physical package: equipment changes, recabling, records and handoff.

Use the related service and physical project inquiry with a nonconfidential outline of the affected equipment, approved changes, site, window and receiving owner. The appointed application and security providers retain archive transformation, key lifecycle and their acceptance. The physical inquiry concerns the surrounding equipment work.

References: [L1]