A KMS Is Not Key Management

“The keys are in KMS, so key management is solved.”

Right.

Let us take that apart before it gets promoted from a deployment detail to an architecture conclusion.

A KMS is not key management.

A KMS can generate key material.

Keep it on provider infrastructure.

Expose cryptographic operations through an API.

And, in many service tiers, put the material behind an HSM boundary.

Good.

That eliminates some genuinely difficult custody work.

It doesn’t decide which workload identity may ask to decrypt a customer record.

It does not decide whether a signing key has a recovery path it should not have.

It doesn’t tell every dependent service that a certificate was replaced.

It does not make a disabled key harmless if production has spent years quietly depending on it.

Those are key-management decisions.

Your service is one control in that system.

It isn’t your system.

NIST SP 800-175B Rev.

1 divides the relevant cryptographic services into encryption, digital signatures, message authentication and key establishment.

Those primitives supply distinct properties.

Key management supplies the conditions under which a key keeps supplying them.

Pretending the API endpoint solves the latter because it performs the former is like calling a lockbox a building-access programme because it contains your keys.

1. “But the Provider’s HSM Holds the Key Material.”

Yes.

That is a real property, and it matters.

An HSM performs signing or decryption inside its own secure processor.

The caller submits data and gets back a signature or plaintext.

Usable key material never crosses your boundary in plaintext.

FIPS 140-3 defines four increasing qualitative security levels for cryptographic modules.

A validated module is evidence about that hardware boundary, not a decorative word in your cloud diagram.

That property is non-extraction.

It answers one question.

Can a caller, or a compromised host, recover your key material itself?

For a software key protected only by filesystem permissions, your host operating system may eventually hold your key in memory.

An HSM is designed so the OS never holds it in usable form.

Authorization answers a different question.

Who may request the operation?

A workload with permission to call Decrypt against a key does not need to export it.

It can ask the service to produce plaintext.

An identity permitted to call a signing operation can obtain valid signatures without ever holding the private signing key.

Your key remains beautifully non-exportable while the wrong principal uses it exactly as designed.

Non-extraction constrains possession. Authorization constrains use.

Nobody says “the safe has no removable hinge, so anybody with the combination may open every drawer.”

Put the safe in a managed cloud service and suddenly the combination is called a role policy and nobody wants to discuss it.

2. “But Automatic Rotation Is Enabled.”

Good.

Now establish what it rotates, what it leaves behind, and whether any consumer completed the cutover.

AWS KMS automatic rotation, enabled on a symmetric customer-managed key, defaults to 365 days and can be set to a custom period.

AWS changed its own AWS-managed-key schedule from roughly 1,095 days to 365 in May 2022.

That change is useful evidence that a provider default is dated operational policy.

Not a natural constant discovered on a stone tablet.

More importantly, the operation doesn’t re-encrypt existing data.

New material is generated for future operations.

Old material remains available to decrypt data encrypted before the rotation date.

Dependent data keys are rewrapped.

The underlying data isn’t retroactively re-protected.

That is not a criticism of the feature.

It is the mechanism.

It bounds the exposure of new use going forward.

It doesn’t erase the history of material already encrypted under the older key.

Rotation is also not renewal wearing a fresh certificate.

Renewal extends a certificate validity period.

Rotation replaces key material.

A renewal that reuses the old key has renewed your certificate and achieved precisely none of rotation’s exposure-bounding benefit.

The working procedure: generate new material in the designated boundary, issue or rewrap against it, distribute it, verify consumers are using it, run an overlap window, then retire the old material according to its role.

Distribution isn’t cutover.

A new certificate sitting in a secret store while your load balancer presents the old one is a very successful spreadsheet event.

3. “But No Engineer Can Export the Key.”

Then your service has solved a narrow and valuable custody problem.

Keep it.

It has not settled whether your key should exist.

How it was generated.

What it is for.

Which data class it protects.

How long it stays authorized.

Whether it is escrowed.

What happens when compromise is suspected.

A key is a liability from generation onward.

Its secrecy degrades in memory, in backups, in operational paths, and through the identities allowed to invoke it.

The primitive has no opinion about any of that.

The distinction begins with the primitive itself.

FIPS 197 says AES provides confidentiality.

It does not make ciphertext tamper-proof.

NIST SP 800-38D specifies AES-GCM as authenticated encryption with associated data.

Confidentiality plus integrity and authenticity verification.

HMAC under FIPS 198-1 uses a shared secret, so holders can authenticate a message.

A bare hash can be recomputed by anyone who can alter the message.

FIPS 186-5 signatures add non-repudiation, because only one party holds the private signing key.

All of those claims are conditional.

If the wrong workload may invoke a symmetric key, confidentiality has moved its boundary to that workload.

If both parties share a MAC key, neither can prove to a third party which one made a tag.

If a signing identity has broad access to the signing operation, your HSM will faithfully produce signatures you did not intend to authorize.

The box prevents key export.

It can’t supply key purpose, key ownership or a sensible permission model by osmosis.

Hardware isn’t a governance seance.

4. “But Every Service Has Permission to Decrypt What It Needs.”

The phrase “what it needs” is where your missing key management is hiding.

Does your service need to decrypt one data class for one named purpose?

Or has it accumulated permission to decrypt every secret sharing a convenient key?

Does an administrator who changes key policy also have permission to invoke your key?

Does the person reviewing use logs have the ability to change them?

Is a developer’s human role standing in for a workload identity, because setting up your workload identity was tedious?

Those aren’t rhetorical flourishes.

They determine what an attacker can do after a service identity, a deployment credential or an administrator session is compromised.

A KMS policy limits who is permitted to call an operation.

It does not show who actually called it.

AWS KMS integrates with CloudTrail to log read-only calls, management calls such as policy changes or key creation, and cryptographic calls including Decrypt and GenerateDataKey, with the key ARN attached.

It deliberately excludes plaintext parameters.

That gives you a record of what happened, by which principal, against which key.

Without making your audit trail another plaintext store.

Policy is a prediction. Audit is a record.

Separate key administrators, key users and auditors, because those are separate duties.

Give a workload identity, not a broad human role, the named cryptographic operation it needs for the named key purpose.

Then query the use record afterwards.

A policy saying only Service A may decrypt is useful.

A log showing an unexpected principal did decrypt is how the assumption stops being a bedtime story.

5. “But Revoking the Key Would Break Production.”

Then production has just explained why key management was not solved.

Breaking production may be the correct short-term consequence of disabling a compromised key.

It is not a reason to avoid planning for the event.

It is evidence that you have not mapped the dependency.

Which services need historical ciphertext decrypted.

Which certificates remain deployed.

Which clients trust the old chain.

Which replacement path exists.

Who decides whether availability or immediate containment wins.

Certificate revocation shows why an API action is not the same thing as effective distrust.

OCSP soft-fail treats an unreachable revocation check as “not revoked.” Browsers adopted it because hard-failing on every timeout breaks legitimate connections on unreliable networks, and makes the OCSP responder an attractive denial-of-service target.

An active network-positioned attacker able to present a stolen certificate can also block the revocation lookup.

Turning your unavailable check into a silent pass.

That is a real availability tradeoff.

It is not an argument for leaving compromised certificates alone.

It means your runbook needs replacement, deployment, verification and incident communication alongside revocation.

The root and intermediate hierarchy makes the scale problem visible.

A root is a trust anchor embedded in browsers and operating systems.

Replacing it requires updates across relying parties.

Let’s Encrypt’s DST Root X3 cross-sign expired on 30 September 2021, and clients without trust for ISRG Root X1 lost trust until their operating systems were updated.

A leaf-key replacement is a service operation.

A root transition is a multi-year trust-propagation programme.

Calling both “rotation” does not make them comparable.

6. “But a Separate Key Process Is Bureaucracy.”

Of course it is a process.

The alternative is a collection of irreversible assumptions distributed across teams and represented by nobody.

Publicly trusted certificate lifetimes make this less optional with every schedule change.

The CA/Browser Forum maximum for a subscriber certificate is 200 days effective 15 March 2026.

It falls to 100 days on 15 March 2027, and 47 days on 15 March 2029.

Domain or IP validation reuse falls in step, to 100 days and then 10.

That doesn’t mean assigning a person to renew certificates in a calendar invite.

It means using ACME, standardized by RFC 8555, to automate validation, issuance and renewal, then monitoring whether the right certificate and full chain are actually installed.

A certificate signing request proves possession of the private key.

Validation determines what the CA is willing to bind to the public key.

Installation has to include the leaf and the intermediate chain.

Those are separate moves, because they can fail separately.

Some storage decisions are already rules rather than style preferences.

Since 1 June 2023, the CA/Browser Forum Code Signing Baseline Requirements have required code-signing private keys to be generated and held in a hardware crypto module meeting at least FIPS 140-2 Level 2 or Common Criteria EAL 4+.

A plain file with a reassuring permission bit does not become compliant because it has an owner listed in a ticket.

The bureaucracy accusation is usually a complaint that your system now has to remember what it was doing.

Correct.

That is the job.

7. No, This Does Not Mean Managed KMS and HSM Services Are Weak.

They aren’t.

Managed KMS and HSM services remove genuinely hard custody work.

An on-premises HSM requires you to own, patch, cluster for availability, and eventually replace physical hardware.

A cloud KMS gives you non-extraction through an API without that hardware operation.

That is an enormous improvement over private keys in arbitrary files, backups and developer laptops.

Nor does this mean every key needs the same recovery decision.

Escrow is a recoverability-versus-exposure decision, by key category.

A lost data-encryption key can make data unrecoverable, so you may escrow a recovery key in a controlled internal system.

A signing or authentication key has no comparable recovery need.

The correct response to loss is a new key and revocation of the old identity.

Escrowing it only creates another target.

The Clipper chip is not proof that escrow is always bad.

It is proof that an escrow mechanism can become both a recovery failure and an additional attack surface.

Its Law Enforcement Access Field was protected by a 16-bit hash short enough to brute-force, shown forgeable in 1994, and the scheme was defunct by 1996.

The durable correction is narrower and more useful.

Escrow only your keys that require recovery.

Then protect the escrow path as seriously as the primary key.

Managed custody is a necessary control for many keys. It is not an authorization model, a lifecycle, or a revocation rehearsal.

8. What You Should Actually Do.

Create keys by purpose and data class. Do not let “production encryption key” be your answer to what a key does.

Record owner, authorized workload identities, storage boundary, algorithm family, cryptoperiod, rotation state, consumers, recovery decision and revocation procedure.

Include symmetric keys, certificates and signing keys.

Certificate lifecycle is a second inventory, not a footnote to the first.

Separate administration, use and audit. Key administrators may create keys and alter policy, and should not casually perform the protected business operation.

Key users are workloads with narrowly scoped Decrypt, signing or data-key rights.

Auditors review the management and cryptographic call record.

Role names can vary.

The separation cannot.

Use the primitive that supplies the property you need, then manage its key accordingly. AES gives confidentiality; AES-GCM adds integrity and authenticity.

HMAC authenticates between parties sharing a secret, and cannot supply the third-party proof a signature can.

RSA, ECDSA and Ed25519 have different key shapes and operational risks, an ECDSA nonce reused or biased across signatures leaks the private key, while EdDSA derives its nonce deterministically.

“KMS key” is not a cryptographic purpose, any more than “database” is a data classification.

Define rotation and revocation runbooks separately. Rotation generates replacement material, prepares consumers, verifies cutover, overlaps where necessary, retires old material.

Revocation responds to suspected or confirmed loss of trust: identify dependencies, decide containment versus availability, deploy replacements, observe failures, document recovery.

Test both.

Against a non-production dependency first, then a controlled production scenario.

An untested emergency disablement is an outage plan written by optimism.

Monitor certificate expiry and automate renewal. ACME made this operationally feasible, and automation only completes the work if the certificate, the full chain and the consumer configuration all arrive where they must.

Equifax’s internal traffic-monitoring certificate had been expired for nine months in 2017.

The monitoring system could not inspect encrypted traffic, and renewal on 29 July 2017 began flagging activity that had already run undetected for 76 days.

That was not an AES failure.

It was a lifecycle failure.

Use the inventory and audit trail during design review. For each key: what property does this primitive supply, where can the material exist, who may request each operation, what records actual use, how is it rotated, how is it revoked, and what fails when it is gone?

If your last answer is “we do not know,” the KMS has not solved key management.

It has made the unknown harder to export.

9. The Model Is Not Complicated.

Cryptographic primitives make bounded promises.

Encryption supplies confidentiality.

MACs supply keyed integrity and authenticity.

Signatures add third-party-verifiable authorship and non-repudiation.

Key establishment derives a shared secret and does not, by itself, authenticate an endpoint.

Key management supplies the lifecycle that makes those promises operational: generation, purpose, custody, authorization, use logging, rotation, recovery, expiry, revocation.

A KMS is excellent at being a KMS.

Use managed HSM-backed custody where it fits.

Use provider rotation where it fits.

Use your audit logs.

Then do the work your service cannot do for anybody.

Decide who may invoke which key for which purpose.

Make those grants narrow.

Prove actual use.

Rehearse what happens when trust has to change now.

Otherwise you have stored keys in KMS and called the resulting absence of a spreadsheet “key management.”

That is not a control.

That is a storage location with a better logo.