The key is the material; the lifecycle belongs to the ARN

Business Challenge

Payment Cryptography is the service for PIN blocks, card verification values and the key hierarchies that payment networks mandate. Its keys are governed by standards rather than by preference: “AWS Payment Cryptography keys have key types, principally defined by ANSI X9 TR 31, that restrict their use to their intended purpose as specified in PCI PIN v3.1 Requirement 19.”

Which makes one sentence in the concepts page worth reading slowly, because it decides what every lifecycle operation actually touches:

“The ARN is not related or derived from the key material. As they are automatically assigned during create or import operations, these values are not idempotent.”

1Import the same secret twice and you have two keys, with two lifecycles

AWS states this twice on one page, which is usually a sign somebody got caught by it.

“Importing the same key multiple times will result in multiple key ARNs with their own lifecycle.”

And in a note, in different words: “if adding the same key material multiple times using the import key functionality, the same key material will be located under multiple key ARNS but each with a different key lifecycle.”

So the service does not deduplicate on material, deliberately. Two consequences follow and they point in opposite directions.

The first is a false sense of completion. You schedule deletion of the ARN your application references, the waiting period expires, the key is gone — and the material is still live under another ARN somebody imported during a migration eighteen months ago. Your key inventory says one fewer key; your cryptographic exposure is unchanged.

The second is a false alarm. Two ARNs holding the same material look exactly like two distinct keys in any list, so an audit counting keys over-counts secrets, and a rotation that replaces one ARN leaves the other serving.

Fix

The key check value is what tells you two ARNs hold the same material — the API returns KeyCheckValue and KeyCheckValueAlgorithm on every key. Make a duplicate-KCV sweep part of your key inventory, not a thing you do during an incident, and record KeyOrigin alongside it, since AWS notes “The origin of a key can be determined by reviewing the attribute KeyOrigin” and an imported duplicate is the case that matters.

2Scheduling deletion stops the key working immediately, not in three days

The waiting period reads like a grace period, and for recovery it is one: “Because deleting a key is irreversible, AWS Payment Cryptography requires you to set a waiting period of between 3–180 days”, and “If you find that you do need the key during the waiting period, you can cancel key deletion before the waiting period ends.”

But it is not a grace period for the workload:

“An AWS Payment Cryptography key pending deletion cannot be used in any cryptographic operations.”

So the moment you schedule deletion, PIN verification against that key stops. The 3-to-180-day window protects your ability to get the key back; it does nothing to keep it working in the meantime. Anyone reading "waiting period" as "the key keeps working until the date" has it backwards, and in this domain the symptom is declined transactions.

There is also a small honest imprecision worth knowing: “the actual waiting period might be up to 24 hours longer than the one you scheduled”, with “To get the actual date and time when the AWS Payment Cryptography key will be deleted, use the GetKey operations”.

Fix

Treat DeleteKey as the disable switch it effectively is. If you want to stop using a key but keep the option of using it again, that is what the waiting period buys — but verify nothing is still calling it first, because scheduling is the outage, not the deletion date. And read the real date from GetKey rather than computing it from your own schedule.

3What a key is allowed to do is fixed at creation, so "changing a key's usage" means a new ARN

The split is stated plainly: “These keys have both immutable and mutable attributes defined at creation. Attributes, such as algorithm, length, and usage are defined at creation and cannot be changed. Others, such as effective date or expiration date, can be modified.”

And the permitted combinations are not yours to choose freely: “certain keys can only be created with certain key modes of use”, aligned “whenever possible” with TR-31, and “AWS Payment Cryptography will prevent you from creating invalid keys”.

That is correct design for this domain — a PIN verification key that could be quietly widened to allow encryption would defeat the standard it exists to satisfy. The operational consequence is that there is no such thing as adjusting a key. A key whose modes of use are wrong is replaced, which produces a new ARN, which is why the alias exists: “Aliases allow keys to be rotated or otherwise changed without impacting your application code.”

Fix

Reference keys by alias from the start, never by ARN, because every correction to a key's permitted use is a replacement. Aliases are “up to 256 characters” and always begin with alias/; the cost of adopting them later is a code change in the one system you least want to change in a hurry.

Architecture

A handle, a secret, and a set of attributes bound together by a standard — with the lifecycle attached to the handle.

Diagram: how AWS Payment Cryptography separates a key's identity from its key material, and what each lifecycle operation therefore acts on. Payment Cryptography keys are used for all cryptographic functions and are either generated directly using the create key command or added to the system by calling key import, with the origin recorded in the KeyOrigin attribute. The keys have key types principally defined by ANSI X9 TR 31 that restrict their use to their intended purpose as specified in PCI PIN v3.1 Requirement 19, and attributes are bound to keys using key blocks when stored, shared with other accounts, or exported, as specified in PCI PIN v3.1 Requirement 18-3. The central structural fact is that a key is identified by an ARN which, in AWS's words, is not related or derived from the key material, and because ARNs are automatically assigned during create or import operations these values are not idempotent. AWS states the consequence twice on one page: importing the same key multiple times will result in multiple key ARNs with their own lifecycle, and the same key material will be located under multiple key ARNs but each with a different key lifecycle. The service therefore does not deduplicate on material, deliberately, and two opposite consequences follow. The first is a false sense of completion, because scheduling deletion of the ARN an application references and letting the waiting period expire removes that key while the same material may remain live under another ARN imported during an earlier migration, so the key inventory shrinks while cryptographic exposure does not change. The second is a false alarm, because two ARNs holding identical material are indistinguishable from two distinct keys in any listing, so an audit that counts keys over-counts secrets and a rotation that replaces one ARN leaves the other serving. The remedy is the key check value, since the API returns KeyCheckValue and KeyCheckValueAlgorithm on every key, so a duplicate-KCV sweep belongs in routine key inventory rather than in incident response, recorded alongside KeyOrigin because an imported duplicate is the case that matters. On deletion, Payment Cryptography never deletes keys belonging to active AWS accounts unless deletion is explicitly scheduled and the mandatory waiting period expires. Because deleting a key is irreversible the service requires a waiting period of between 3 and 180 days, with a default of seven days, and the actual waiting period might be up to 24 hours longer than the one scheduled, so the real date should be read from the GetKey operations rather than computed. Deletion can be cancelled before the waiting period ends but not after. The point that matters operationally is that the waiting period is not a grace period for the workload: a key pending deletion cannot be used in any cryptographic operations, so scheduling deletion stops PIN verification against that key immediately. The window protects the ability to recover the key, not its continued operation, and reading waiting period as meaning the key keeps working until the date is backwards, with declined transactions as the symptom. After the waiting period ends the service deletes the key, its aliases, and all related metadata, and CloudTrail records an entry both when deletion is scheduled and when the key is actually deleted. On attributes, keys have both immutable and mutable attributes defined at creation: algorithm, length and usage are defined at creation and cannot be changed, while effective date and expiration date can be modified. Certain keys can only be created with certain key modes of use, aligned whenever possible with TR-31, and the service prevents creation of invalid keys. The operational consequence is that there is no such thing as adjusting a key, since a key whose modes of use are wrong must be replaced, producing a new ARN, which is why aliases exist: an alias is a user-friendly name associated with a key, up to 256 characters, always beginning with alias slash, that allows keys to be rotated or otherwise changed without impacting application code. On multi-Region replication, deleting a key that is a Primary Region key means the Replica Region keys are also automatically deleted, and a Replica Region key cannot be deleted like a Primary Region key; to remove one, the replication regions of the primary must be modified instead. Finally, closing or deleting the AWS account makes the keys inaccessible, and deletion does not need to be scheduled separately from closing the account. The recommended actions are to reference keys by alias rather than ARN from the outset because every correction to permitted use is a replacement, to run a duplicate key check value sweep as part of inventory, to treat scheduling deletion as the disable switch it effectively is and verify nothing still calls the key first, and to read the deletion timestamp from GetKey. — The ARN is the thing with a lifecycle. The material is the thing you care about.

What is fixed and what moves

	Attributes	Changing them means
Immutable	“algorithm, length, and usage” — “defined at creation and cannot be changed”	Creating a replacement key, and a new ARN
Mutable	“effective date or expiration date”	An update on the existing key
Identity	The key ARN	Nothing — it is assigned, and “not related or derived from the key material”

Read down that table and the design intent is clear. The standard requires that a key's purpose be unalterable, so the attributes expressing purpose are immutable; the operational need for dates to move is real, so dates are mutable; and identity is deliberately decoupled from both, which is what allows an alias to be re-pointed.

The deletion sequence, and the two different clocks in it

Moment	State	What is true
Before	`CREATE_COMPLETE`	Usable in cryptographic operations
You schedule deletion	`DELETE_PENDING`	Immediately unusable — “cannot be used in any cryptographic operations”. Recoverable.
During the window	`DELETE_PENDING`	Between 3 and 180 days, default seven, “up to 24 hours longer” in practice
You cancel	`CREATE_COMPLETE`	`DeletePendingTimestamp` is removed; the key is usable again
Window ends	Gone	The key, “its aliases, and all related AWS Payment Cryptography metadata”. “you cannot cancel”

The two clocks are doing different jobs, and only one of them is a grace period

The recovery clock runs 3 to 180 days and is genuinely generous. The availability clock runs out the instant you call DeleteKey.

This is defensible — a key you have declared you intend to destroy should not keep authorising transactions — but it is the opposite of how a "waiting period" reads, and it is the single most expensive thing to misunderstand here.

Replication deletes downward and only downward

“When using Multi-Region key replication, deleting an Payment Cryptography key that is an Primary Region key (PRK), the Replica Region keys (RRK) will also be automatically deleted. A RRK cannot be deleted like a PRK. If you want to delete a RRK, you'll need to modify the replication regions for your PRK.”

So the replica is not an independent object with its own lifecycle, unlike the duplicate-import case where two ARNs are independent. Two superficially similar situations — the same material in two places — with opposite lifecycle semantics depending on how it got there.

Closing the account is its own path

“If you close or delete your AWS account, your AWS Payment Cryptography key become inaccessible. You do not need to schedule deletion of your AWS Payment Cryptography key separate from closing the account.”

Worth noting the word: inaccessible, not deleted. For a compliance question about key destruction, that distinction is the answer, and it is not the same answer as the deletion path gives.

Why This Architecture Holds Up

Not deduplicating on material is the right call, even though it surprises people

The alternative is a service that recognises your key material and returns an existing ARN. That would mean the service comparing imported secrets against stored ones, and it would silently merge two lifecycles that two teams created for two reasons — including their attributes, which are immutable and might differ. “These values are not idempotent” is AWS declining to make that inference.

It also respects the key block model: “Attributes are bound to keys using key blocks when stored, shared with other accounts, or exported”. Material plus attributes is the unit, so the same material with different attributes is legitimately a different key.

Immutable usage is the whole point of the service

“A tenet of proper key management is that keys are appropriately scoped and can only be used for permitted operations”, with the permitted set drawn from TR-31 and enforced at creation rather than at use. A service that let you widen a key's modes of use after the fact would be offering a PCI-shaped API without the property PCI is asking for.

And it fails closed on the way in: “AWS Payment Cryptography will prevent you from creating invalid keys”. The valid combinations table is documentation for convenience, not the enforcement point — which is the right order, because a table can go stale and an API check cannot.

The gap is that nothing in a key's identity reveals a duplicate

The rest of this design is explicit. Attributes are immutable and stated. Deletion is logged to CloudTrail at both ends. The waiting period is documented including its 24-hour imprecision. Replication's delete semantics are spelled out in both directions.

But two ARNs holding the same secret are indistinguishable in a key listing, and the only thing that reveals the relationship is comparing key check values — which no part of the service prompts you to do. The information is available; the question is one you have to think to ask.

Logging both ends of deletion is a small thing done properly

“AWS Payment Cryptography records an entry in your AWS CloudTrail log when you schedule deletion of the AWS Payment Cryptography key and when the AWS Payment Cryptography key is actually deleted.”

Two events rather than one, which matters precisely because the two moments are days apart and have different meanings — one is the outage, the other is the point of no return. A service logging only the second would leave the actual operational event unrecorded.

Key Architecture Decisions

Decision	Choice	Reasoning
How application code references keys	Always by alias	Aliases exist so keys can be “rotated or otherwise changed without impacting your application code”.
Duplicate detection	Sweep for duplicate key check values	Nothing in the ARN reveals shared material.
Before scheduling deletion	Confirm nothing still calls the key	Pending deletion “cannot be used in any cryptographic operations”.
Reading the deletion date	From `GetKey`, not from your schedule	It may be “up to 24 hours longer”.
Changing a key's usage or algorithm	Create a replacement; re-point the alias	Those attributes “cannot be changed”.
Removing a replica key	Modify the primary's replication Regions	“A RRK cannot be deleted like a PRK.”
Deleting a primary	Expect the replicas to go with it	They “will also be automatically deleted”.
Waiting period length	Choose from recovery need, not from caution	Longer does not keep the key working; it only extends the cancel window.
Key destruction for compliance	Distinguish deleted from inaccessible	Account closure makes keys “inaccessible”, which is a different claim.
Audit of key counts	Count distinct material, not ARNs	Imported duplicates inflate the ARN count.

The audit worth running

List every key with its KeyCheckValue and KeyOrigin, and group by KCV. Any group with more than one member is the same secret under several ARNs, each with its own lifecycle, each independently deletable and independently survivable. That set is where "we removed that key" can be true and wrong at the same time.

Then check what your code holds. If any system references a key ARN rather than an alias, the next immutable-attribute correction is a deployment rather than a configuration change — in the system where deployments are hardest to schedule.

Closing Thought

The sentence that explains this whole service is five words long: “not related or derived from the key material”. Once identity is independent of the secret, everything else follows. Lifecycle operations act on handles, so the same secret can exist under several of them. Immutable attributes mean corrections produce new handles, so aliases are necessary rather than convenient. And a replica is a handle AWS manages for you, which is why it deletes with its primary while a duplicate import does not.

Everything here is documented, most of it twice. The one thing the service does not do is tell you when two handles point at one secret — the key check value will tell you, and nothing asks you to look.

#87 had a backup whose lifecycle policy attached to a cluster the backup could leave. This has a lifecycle that attaches to a handle the material can outlive. Both are the same question in different services: when you delete the thing, what exactly did you delete.

Next in this series

Security & Identity — Amazon Cognito identity pools: why an unauthenticated identity is still an identity with a role attached, what the token-to-credential exchange actually asserts, and how pool-level role mapping interacts with the trust policy on the role it chooses.

AWS Architecture Series #88 — The key is the material; the lifecycle belongs to the ARN