KMS Rotation Is Not Ciphertext Migration: Choose the Change and Keep Old Reads Accounted For

Separate KMS material rotation, a new logical key, encrypted-data-key rewrap and payload rewrite. Use a retained-copy register to keep old-key dependencies visible...

Primary sources checked 2026-10-09

Choose the layer that must change

Rotating the material inside a KMS key, sending future writes to another key and migrating stored ciphertext are different changes. Start with the required outcome, identify which encrypted layer must change, then account for every retained representation that still needs the old key. Do not disable the old key merely because the current writer uses a new one.

This guide helps an application and security owner produce that decision for one application-defined archive. Its KMS keys are symmetric customer-managed encryption keys with AWS-generated material, in one account and Region. Its conceptual envelope stores an application ciphertext payload beside a separately identifiable KMS-encrypted data key. That envelope is a teaching contract, not an implemented format or a recommendation to build custom cryptography. An actual implementation needs a qualified format and library review.

Imported material, asymmetric and HMAC keys, custom key stores, multi-Region arrangements and managed-service encryption formats are outside this procedure. These exclusions do not assert that those mechanisms lack rotation features. A database snapshot, an S3 server-side encrypted object and an application envelope can have different migration operations. Do not apply this example's wrapper replacement to a service's internal representation.

All identifiers, copies and evidence references below are fictional. The supplied local exercise compares declared identities; it encrypts nothing, calls no AWS API and verifies no permissions or cryptographic properties. Every output remains non-authorizing.

Name six identities before discussing rotation

Record the logical KMS key separately from its cryptographic material. K-old remains the same KMS resource when its material changes from generation G1 to G2. Generation labels here are explanatory aliases, not instructions to select a material generation in a decrypt request. KMS chooses the appropriate retained material for existing ciphertext. KMS rotation.

Next identify the plaintext data, the application data key, its encrypted representation and the encrypted payload. In the fictional archive, report R17 is the plaintext identity, D17 is a data-key identity, W17 is its encrypted data-key blob and C17 is the payload representation. None of these aliases contains actual key bytes, plaintext or valid ciphertext. A copy identifier names the stored instance containing the envelope, not another KMS key.

KMS can return plaintext and encrypted versions of a generated data key. Application-side cryptography uses the plaintext key for the payload; the encrypted version can be retained with that payload. The application is responsible for its data-key use and handling. Data-key mechanism.

These identities answer different evidence questions. Matching plaintext establishes the intended semantic content only if a real, approved comparison was performed. Matching encrypted payload bytes says the payload representation did not change. A changed wrapper does not establish a changed data key. A changed data-key alias in a spreadsheet proves neither randomness nor secure generation. Keep those limitations in the record rather than allowing a renamed column to stand in for cryptographic evidence.

Match the objective to four different mechanisms

For routine wrapping-material renewal within K-old, consider the supported rotation mechanism. Existing W17 and C17 are not rewritten by that change. New KMS encryption operations use current material, while older ciphertext remains readable through the same logical resource and retained material. Rotation does not rotate application data keys, re-encrypt application data or repair exposure of a data key. Rotation boundaries.

For a new administrative boundary or a policy requiring another logical key, direct approved future writes to K-new. New records can use newly generated data keys and wrappers under K-new. Existing records remain on their recorded path until separately migrated. An alias can be reassociated with another KMS key; that changes the name's target, not the contents of old envelopes. Record the resolved key identity and writer revision, not only the friendly alias. Alias behavior.

For moving an existing data key's wrapping dependency, investigate an encrypted-data-key rewrap. Under this guide's assumed separable envelope, a compatible W17 may become W17-new under K-new while D17 and C17 stay unchanged. This is useful when the objective concerns wrapping ownership and the format permits a safe replacement. It does not renew the payload's encryption key. The format owner must establish whether envelope authentication, signatures, commitments or embedded metadata require another supported transformation.

For renewing the data key or changing the payload algorithm or format, design a full payload rewrite with the appropriate library. The intended plaintext identity may remain R17, but the data-key and payload representations change. That path handles plaintext within a separately approved processing boundary and brings integrity, concurrency and failure-recovery responsibilities. It is not a synonym for KMS re-encryption.

Retaining K-old is also a legitimate decision. If locked copies must remain readable and cannot be transformed now, preserve their dependency under reviewed access controls. State the retention owner and reconsideration trigger. A second key and a partially migrated archive can be the honest operating state; hiding that state to declare a completed migration makes retirement dangerous.

Arrows mean proposed representation changes, not network calls. G1 and G2 are explanatory material aliases, not selectable decrypt generations. R18 is a separate new record. Rewrap preserves D17/C17; rewrite only intends equivalent R17 meaning and requires a separately approved read. These are alternative mechanisms, not four completed sequential steps.

Mechanisms 1 and 2 are separate alternatives. Existing W17 retains its creation-material relationship; callers do not select G1. Future-write cutover does not migrate existing R17 copies. All aliases and transitions are fictional and unexecuted.

Mechanisms 3 and 4 are separate alternatives under the reviewed conceptual-envelope prerequisite. Only a supported separable KMS blob is a rewrap candidate. Equivalent plaintext requires a separately approved read; neither mechanism erases earlier exposed copies. No transformation or read was executed.

Check whether ReEncrypt applies to the blob you actually have

KMS ReEncrypt decrypts and encrypts compatible ciphertext inside KMS. It can process a blob produced by KMS operations such as GenerateDataKey. It cannot consume the complete ciphertext format returned by libraries such as the AWS Encryption SDK or S3 client-side encryption. Passing a whole application archive to it is not a payload migration strategy. ReEncrypt API.

In this conceptual envelope, only a reviewed, extracted KMS data-key blob is a candidate. Do not infer extractability from a filename or the presence of a key ARN. Document the format version, parser/library owner, wrapper location, authenticated metadata and supported update method. Unknown format means HOLD. A format that binds the wrapper into authenticated content needs its documented format-specific procedure, not a blind byte substitution.

Source decryption context and destination context are separate request inputs. The source context must match the original where one was used. An approved context change also requires updating the application's lookup and authorization assumptions. Keep context values non-sensitive because they are not secret and can appear in logs. Case changes and missing pairs are not cosmetic. Encryption context.

Review source ReEncryptFrom and destination ReEncryptTo authority and compatible key states. A source read does not establish destination write authority. A permission-only dry run that ignores ciphertext cannot validate the actual blob or prove an application read. Keep permissions, format compatibility and end-to-end read results separate, even when one operator collects all three. The guide deliberately supplies no broad access policy or executable cryptographic command.

Inventory retained copies before changing the writer

The application owner inventories current records, object versions, snapshots of application files, exports, disaster-recovery archives and delayed-job inputs within the declared archive scope. The data owner confirms which must remain readable. An omitted copy is not an expired copy. Attach the inventory acquisition method, scope and revision so another person can distinguish complete enumeration from a sample.

Copy identity must survive retries and transformations. Give each original a stable identifier, then record any replacement representation and its lineage. A backup containing W17 is still dependent on K-old after the active record receives W17-new. Creating a new backup of the transformed active record does not rewrite the earlier retained backup. Keep both rows until the relevant retention owner establishes their disposition.

Do not turn discovery limits into universal claims. Logs can identify some observed key uses, but an infrequently restored archive may have no recent use. KMS does not maintain an inventory of your ciphertext. The archive's own register and recovery requirements remain necessary. Deletion and past-use limits.

The fictional register contains four copies of R17. They share a conceptual source payload but have independent retention and read obligations. Its labels describe expected relationships, not observed AWS behavior. Use records rather than a wide table so every field remains available on a narrow screen.

active-R17

Representation and dependency

R17 / D17 / C17 / W17 under K-old, G1 at creation.

Reader and retention

Archive reader; current record retained for normal retrieval.

Proposed disposition

Reviewed wrapper replacement to W17-new under K-new; payload C17 and data key D17 unchanged.

Required proof and owner

Exact replacement-version identity, supported-format review and independent read evidence; application owner.

version-R17-v1

Representation and dependency

R17 / D17 / C17 / W17 under K-old, G1 at creation.

Reader and retention

Historical-version reader; retained until the version owner's approved expiry.

Proposed disposition

Unchanged. A replacement active version is not migration of this version.

Required proof and owner

Historical read path and continuing K-old authority; retention owner.

backup-R17-B1

Representation and dependency

R17 / D17 / C17 / W17 under K-old, G1 at creation.

Reader and retention

Isolated restore reader; immutable retained application-envelope copy.

Proposed disposition

Unchanged through retention. This is not an AWS Backup service-encryption claim.

Required proof and owner

Restore procedure reaches this exact envelope and its context; recovery owner.

queued-R17-Q1

Representation and dependency

R17 / D17 / C17 / W17 under K-old, G1 at creation.

Reader and retention

Delayed export worker; input retained until the reviewed job disposition.

Proposed disposition

Hold transformation pending worker-format evidence; no inferred expiry from queue age.

Required proof and owner

Worker revision, context recovery and consumed/cancelled-input evidence; job owner.

Work through the cutover without claiming the archive migrated

Suppose the objective is to use K-new for future records while keeping R17 readable. The writer owner first identifies every writer configuration, scheduled task and retry path. A single foreground request is not the whole write population. Record when the reviewed revision becomes effective and what happens to queued requests prepared earlier. A cache or long-lived process can make observed behavior differ from a configuration screen.

The expected mapping for material rotation is K-old/G1 to K-old/G2 for future wrapping operations, with existing D17/W17/C17 unchanged. The expected mapping for new-write cutover keeps all four existing copies unchanged while a new record R18 uses D18/W18/C18 under K-new. Those are two separate experiments. A rotation event and a new-write read answer neither the historical-version nor backup question.

For an optional rewrap proposal, select active-R17 only. The expected result is D17/C17 unchanged, W17-new replacing W17 in the supported active envelope, and K-new as that representation's wrapping key. The retained version, backup and queued input still depend on K-old. Record one proposed transformed copy and three continuing dependencies, not a percentage that silently excludes inconvenient copies.

For a full rewrite proposal, the expected active representation becomes R17/D17-new/C17-new/W17-rewrite under K-new. The semantic content must match the agreed plaintext contract, including encoding and schema where relevant. Old retained representations still require their recorded keys unless transformed or separately disposed of. Rewriting the active payload cannot retrieve plaintext an attacker already obtained or erase an earlier exposed copy.

The supplied manifest uses these exact aliases. Its evaluator checks whether a submitted before/after mapping respects the selected layer change. It also rejects contradictory reuse of a wrapper or payload identity across copies: a wrapper cannot name different data keys, wrapping keys, generations or contexts, and one payload cannot name different data-key or plaintext identities. Different wrappers for the same data key remain possible. These are label-coherence checks, not proof about actual encrypted bytes. It cannot verify that two real ciphertext blobs correspond to the same data key or that a real rewrite preserved meaning. Those claims require separately authorized cryptographic and application tests.

Arrows point from retained representations to the wrapping key needed for unwrap, not replication or traffic. This optional active-only rewrap view has three old-key dependencies. The filled future-writes-only worksheet below makes no active transformation and retains all four. The backup and delayed input are application envelopes, not AWS Backup or SQS internals. HOLD is separate from the no-declared-residuals review case; neither authorizes disabling or deleting a key.

Optional active-only rewrap example, not the future-writes-only filled worksheet. Three old copies remain required; the worksheet retains all four. These are declared application-envelope dependencies, not performed reads or named backup/queue services. Continue to the separate retirement panel.

The two cases are separate, not an automatic transition. Completeness, writers, caches and required reads still need evidence. No ciphertext discovery, cryptographic validation, application read, disable or deletion was performed or authorized.

Design independent reads and partial-failure recovery

Before a real transformation, the application owner defines a small non-sensitive fixture with independently retained expected content and access behavior. Bind each test to the exact copy/version, decoder revision, principal, context and key identity. Read the replacement through the intended application path. A successful KMS response alone does not establish that the envelope decoder, authorization checks and payload reader agree.

Design meaningful negative cases: wrong context, wrong expected source key, denied reader, unsupported format and missing retained-copy row. A failed transport request is not an authorization denial. A wrong-context error does not prove a wrong-principal request was denied. Keep these observations separate and never broaden production permissions to make a fixture pass.

Treat storage mutation as its own transaction. A reviewed implementation needs a conditional write or equivalent concurrency control binding the source version to its replacement. Preserve the supported original until acceptance and its agreed retention decision. Do not overwrite a record changed by another writer using a stale migration snapshot. Record requests with uncertain outcomes for readback before retrying, so an ambiguous response does not create untracked versions.

A reversible write-routing decision can return future writes to the prior reviewed configuration only if its format, permissions and operating state remain valid. It does not reverse records already rewritten or recover destroyed data keys. A failed migration should pause further transformations, preserve lineage and investigate the affected copy. Do not call deleting a key a rollback test. No actual reversal is demonstrated by this article.

Cached plaintext data keys require a separate handling review. The AWS Encryption SDK supports optional data-key caching, and cached material can service operations without another KMS request. That documentation does not establish that this fictional archive uses that SDK or cache. Inventory the actual library and process behavior before inferring that a key-policy change or stopped KMS traffic ended all plaintext-key use. Caching boundaries.

Keep exposure response separate from routine renewal

If a plaintext data key may have been exposed, preserve an incident boundary and involve the security owner. Changing the wrapping key around that same data key does not remove the attacker's knowledge of it. Do not label a rewrap or KMS material rotation as remediation of known data-key exposure. Identify which payloads used the affected data key, where their ciphertext or plaintext may exist, and which accesses remain possible.

A full rewrite under a newly generated data key can establish a different future representation when correctly implemented, but cannot revoke copied plaintext or make an attacker's retained old ciphertext unknowable. The incident decision also covers containment, credentials, cached material, affected copies, disclosure obligations and evidence retention under the appropriate owners. This guide provides no legal assessment and no guarantee of incident closure.

Unknown exposure is not the same as established absence of exposure. Record the security owner's actual scope and uncertainty. The offline model returns HOLD for an exposure-response objective because it cannot evaluate incident sufficiency. Even a structurally correct rewrite packet receives no security authorization. That deliberate boundary prevents a bookkeeping tool from issuing a reassuring but unsupported result.

Complete an objective-to-mechanism record

The following blank record is designed for a review meeting. Fill it with evidence references, not key bytes or customer plaintext. Keep unknown fields visible, assign an owner and stop the affected decision. The filled example has the same fields and remains fictional, including references labelled proposed or stipulated.

Blank record

Decision identity and revision

Unrecorded.

Objective and excluded claims

Unrecorded.

Application, account and Region scope

Unrecorded.

Key type, origin and logical identities

Unrecorded.

Envelope format and supported transformation

Unrecorded.

Data-key identity and exposure assessment

Unrecorded.

Source and destination context

Unrecorded.

Allowed future writes and writer revision

Unrecorded.

Required old reads and consumers

Unrecorded.

Retained-copy register and completeness evidence

Unrecorded.

Source and destination authority evidence

Unrecorded.

Expected layer changes and selected copies

Unrecorded.

Independent read and negative-test evidence

Unrecorded.

Concurrency, partial failure and recovery plan

Unrecorded.

Exceptions, next observation and owner

Unrecorded.

Retirement decision owner and separate authority

Unrecorded.

Filled example: future writes first, no retirement

Decision identity and revision

Fictional ENC-17 revision 1; unexecuted.

Objective and excluded claims

Future records use K-new; no complete archive migration or exposure-remediation claim.

Application, account and Region scope

One fictional archive, account A, Region R; application-owned envelopes only.

Key type, origin and logical identities

Symmetric customer-managed ENCRYPT_DECRYPT, AWS_KMS origin; K-old and K-new, not real ARNs.

Envelope format and supported transformation

Conceptual envelope-v1 with separable KMS data-key blob; real parser and authenticated-wrapper update remain unreviewed.

Data-key identity and exposure assessment

D17 for existing R17; D18 for new R18. No exposure asserted in the synthetic packet; real incident assessment not performed.

Source and destination context

Non-secret conceptual map application=archive-example, schema=1; preserved in the packet, not an observed KMS request.

Allowed future writes and writer revision

Proposed writer W2 uses K-new for R18; queued old inputs are separately held.

Required old reads and consumers

R17 active reader, historical reader, restore reader and delayed worker remain required.

Retained-copy register and completeness evidence

Exactly four stipulated R17 copies above; real estate enumeration is absent.

Source and destination authority evidence

Proposed separate source-read and destination-write review; no live policy or grant validation.

Expected layer changes and selected copies

No existing R17 representation changes. New R18 has D18/W18/C18 under K-new.

Independent read and negative-test evidence

Offline identity expectations only; actual new-write, old-version and backup reads pending separate authorization.

Concurrency, partial failure and recovery plan

No storage mutation in this example; proposed writer reversal requires reviewed configuration and format compatibility.

Exceptions, next observation and owner

Delayed worker format unknown; job owner must supply its decoder and context record before any transformation.

Retirement decision owner and separate authority

Security and retention owners; K-old retirement held because all four old representations still depend on it.

Propose retirement only after the dependency review

Retirement is a separate decision from the last migration batch. Reconcile the full register against required reads, remaining writers, delayed work, retained versions and caches. A copy can be migrated, intentionally retained under K-old, or unknown. Only the first disposition removes its declared old-key dependency; intentional retention means the key remains required. Expiry requires the retention owner's evidence, not a migration script's assumption.

Review key policy, IAM paths, grants and the actual key state without changing them in this exercise. Grants participate in authorization and have eventual-consistency behavior; revoking one grant is not proof that every other authorization path disappeared. KMS grants. The existing recovery-authority paper owns the broader prepared recovery permission chain.

Pending deletion already prevents KMS cryptographic use, and completed deletion of the scoped AWS-generated key destroys its material irreversibly. Do not schedule deletion as a convenient experiment to discover overlooked readers. Preserve availability while resolving the register and ask the authorized key and data owners for a separately reviewed lifecycle decision. Deletion consequences.

The EFS cross-account rehearsal separates service backup encryption from restored-file-system encryption. It remains the owner for that EFS operating task. This guide's retained copies contain application envelopes; their register must not replace a service-specific backup-encryption analysis.

Use the offline packet to challenge the decision, not authorize it

The companion fixture supplies an evaluator, independently stipulated expected mappings and a standalone Node test suite. Its only inputs are synthetic JSON-like records. MATERIAL_ROTATION, NEW_WRITES, REWRAP and PAYLOAD_REWRITE check different representation invariants. RETIREMENT_REVIEW additionally rejects a declared surviving K-old dependency. Even an internally consistent packet returns MODEL_REVIEW_ONLY with authorized=false; it never returns a command or a claim that a key may be deleted.

Download the synthetic KMS envelope decision fixture. The anonymous ZIP contains only README.md, decision.mjs, packets.mjs and decision.test.mjs. With Node 20 or later, run node --test decision.test.mjs in the extracted folder. No AWS account, credentials, packages or network acquisition are required.

Required counterexamples include declaring migration complete after an alias-only cutover, omitting the unchanged backup, unknown wrapper format, absent source context, exposed data key, and treating an unknown row as safe. Additional tests cover duplicate copy identities, contradictory shared representations, missing replacement records, inconsistent layers, sparse arrays and unchanged payloads in a declared rewrite. The fixture reserves UNKNOWN in any letter case, including surrounding whitespace, rather than accepting it as an identity. Other identifiers remain exact and case-sensitive, with surrounding whitespace rejected. Context strings are compared exactly without trimming or case folding. Expected outcomes are written independently of the evaluator, not generated from its result.

Before operational adoption, have an independent cryptographic reviewer verify the selected real format and transformation, and an application reviewer verify copy enumeration, consumer identity and concurrency behavior. Then design separately authorized harmless new-write and old-copy read tests. Record actual results only after execution. The useful next output is a completed layer-change record with owned residual dependencies, not a screenshot saying the key rotated.