When Your Keys Get Locked In: Navigating AWS KMS Import Limitations

AWS KMS is designed so that key material never leaves its FIPS 140-3 Level 3 HSMs — not even to you. That’s a feature, not a bug. But when an external PKI partner generates keys, imports them into KMS, and then discards their own copy, you end up with cryptographic material that exists in exactly one place with no way to back it up.

The Problem

Here’s a scenario that comes up more often than you’d expect in enterprise environments. A company uses an external PKI partner to generate cryptographic keys via their HSM infrastructure. The workflow looks like this:

External PKI Partner (HSM)
    → Generates key pair (asymmetric or symmetric)
    → Creates associated certificate
    → Imports key material into AWS KMS (BYOK / ImportKeyMaterial)
    → Discards the key material after creation

The problem isn’t visible until you ask the question: what happens if we need to recover this key?

• KMS can’t export it. The HSMs are FIPS 140-3 certified — there is no API, debug interface, or operator command to extract key material in plaintext. This is by design and verified by independent audits.
• The partner doesn’t have it. They discarded the material after import.
• No backup exists anywhere. If the KMS key is deleted or the imported material expires, the data encrypted with it is permanently lost.

The immediate reaction from the security team? “Let’s use Azure Key Vault instead — it supports key export.” And CloudHSM was considered but dismissed (for reasons that weren’t entirely clear).

Moving to a different cloud provider’s key vault to solve a key management gap on AWS is like buying a second house because you lost the key to your front door. There are better options.

The Solution

The right approach depends on what the keys are actually used for — certificates (PKI) or data encryption — and whether the partner can change their process. Four AWS-native options solve this without introducing cross-cloud complexity.

The decision tree boils down to three questions:

1. What are the keys used for? Certificates → Private CA. Data encryption → continue.
2. Can the partner retain the key material? Yes → fix the BYOK process (cheapest, simplest). No → continue.
3. Do you need to export key material? Yes → CloudHSM. No, but need sovereignty → XKS.

How It Works

Why KMS Doesn’t Allow Export

This isn’t a missing feature. KMS uses FIPS 140-3 Level 3 HSMs — the firmware contains no mechanism to export keys in cleartext. Every cryptographic operation happens inside the HSM boundary. The key hierarchy is designed around this constraint:

Layer	Key Type	Storage	Purpose
Top	Domain Key (AES-256-GCM)	HSM volatile memory only	Protects backing keys
Middle	HSM Backing Key (HBK)	Encrypted, never in cleartext outside HSM	The actual KMS key material
Bottom	Data Encryption Key (DEK)	Returned to client via TLS, never stored in KMS	Encrypts your data

For keys generated by AWS (Origin = AWS_KMS), this works well. AWS manages durability — multi-AZ replication, automatic backups, the whole stack. You don’t need to export because AWS guarantees the key won’t be lost.

For imported keys (Origin = EXTERNAL), the responsibility model flips. From the AWS documentation:

“Imported key material cannot be exported, and users must maintain a copy outside of AWS KMS for reimportation if deleted or expired.”

The BYOK model assumes the customer keeps a copy. When the PKI partner doesn’t retain the material, this assumption breaks and you’re left with a single copy in a system designed to never release it.

Option 1: Fix the BYOK Process

The simplest solution is often the right one. The real problem isn’t KMS — it’s that the PKI partner discards the key material. That’s not standard PKI practice.

PKI Partner (HSM)
    → Generates the key
    → RETAINS an encrypted backup in their HSM
    → Imports into KMS via ImportKeyMaterial
    → On recovery: re-imports from their backup

Cost: ~$1/key/month (KMS standard pricing). No additional infrastructure.

When to use this: When the partner can change their workflow. This is a process fix, not a technology fix. Ask the partner why they discard the material — it may be a policy decision that can be revisited.

Option 2: AWS CloudHSM — When You Need Export

CloudHSM gives you a single-tenant HSM cluster that you own and control. Unlike KMS, it supports key export through key wrapping.

How CloudHSM secures key material:

The cluster architecture provides high availability by default. When a key is created on one HSM, it’s automatically synchronized across all HSMs in the cluster in real-time.

CloudHSM Cluster (eu-west-1)
├── HSM 1 (AZ-a) ──┐
├── HSM 2 (AZ-b) ──┼── automatic sync
└── HSM 3 (AZ-c) ──┘

Backup mechanism:
  HSM contents
    → Encrypted with Ephemeral Backup Key (EBK) — AES-256
    → EBK encrypted with Persistent Backup Key (PBK) — derived from HSM firmware
    → Stored in S3 (AWS-managed)
    → AWS CANNOT decrypt these backups (no access to PBK)

AWS takes automatic backups every 24 hours and on every change. These backups can be copied cross-region for disaster recovery. But here’s the critical part: AWS stores the backup but cannot read it. The PBK is tied to the HSM firmware (Cavium/Marvell), and AWS has no access to it.

Three methods to export keys:

Method	Command	Output	Use case
Wrap (encrypted)	key wrap / wrapKey	Key encrypted by a wrapping key	Secure transfer to another HSM
Export symmetric	exSymKey	Plaintext file	Local backup (secure carefully!)
Export private key	exportPrivateKey	Wrapped PEM	Asymmetric key backup

Each exported key produces one file. You choose a wrapping key (an AES key already in the HSM), and the export is encrypted with it:

# Export key handle 14, wrapped by key handle 6
wrapKey -k 14 -w 6 -out /tmp/mykey.wrapped -m AES_GCM

The key must have OBJ_ATTR_EXTRACTABLE = 1 set at creation time. This is immutable — if you create a key as non-extractable, you can’t change it later.

Where to store exported keys:

Storage	Security	Cost
On-premises HSM (Thales, Entrust)	Maximum — key stays in hardware	High (hardware investment)
S3 + KMS (AWS-generated key)	Good — wrapped key + S3 encryption	Low
HashiCorp Vault / CyberArk	Good — dedicated secret management	Medium
Air-gapped cold storage (encrypted USB)	Good — physical isolation	Low
Second CloudHSM cluster (another region)	Maximum — full DR	~$2,300/month

A practical backup strategy has three tiers:

Tier 1 — HA (included with the cluster)
    Multi-AZ HSMs with automatic sync

Tier 2 — DR (automatic AWS backups)
    Copy backup to another region
    Restore into a new cluster

Tier 3 — External export (for critical keys only)
    wrapKey → encrypted file
    Store in on-prem HSM or encrypted vault
    Test re-import (unWrapKey) periodically

Tier 2 is sufficient for most use cases. Tier 3 adds a layer for the most critical keys — root keys, signing keys, master encryption keys.

Integration with KMS: CloudHSM can serve as a custom key store for KMS. This means AWS services (S3, EBS, RDS) can use KMS APIs transparently while the actual key operations happen in your CloudHSM cluster. Best of both worlds: KMS convenience + CloudHSM control.

Cost: ~$1.60/hour per HSM. Minimum two HSMs across two AZs for production = ~$2,300/month. This is the main reason teams hesitate.

One critical risk: If you lose all Crypto Officer and Crypto User credentials AND delete all HSMs in the cluster, the backups become unusable. The backup can only be restored in a cluster sharing the same key hierarchy.

Option 3: KMS + External Key Store (XKS) — When the Key Should Never Enter AWS

XKS flips the model entirely. Instead of importing key material into KMS, the key stays in the external HSM and KMS calls out to it for every cryptographic operation.

AWS KMS ──(SigV4)──> XKS Proxy (customer network) ──> External HSM

Double encryption:
  1. KMS encrypts the data key with its internal key (AWS HSMs)
  2. The ciphertext is encrypted again by the external key via XKS Proxy
  → Neither AWS alone nor the external HSM alone can decrypt

This is the ideal architecture when the PKI partner can serve as the external key manager. The key never leaves their HSM — there’s nothing to export, nothing to back up separately. The partner’s HSM is the key store.

Key characteristics:

• No export needed — the key material never enters AWS
• Unilateral disconnect — cut the proxy connection and all associated KMS keys become UNAVAILABLE instantly
• Independent audit — the proxy logs every operation, under the customer’s control, outside AWS’s reach
• Transparent to AWS services — S3, EBS, RDS, Lambda all work through standard KMS APIs

Trade-offs:

• Latency: ~100-250ms per crypto operation (network round-trip through the proxy)
• Only supports symmetric encryption keys (no asymmetric in XKS)
• Customer is responsible for proxy availability and HSM uptime — no AWS SLA covers these
• Requires deploying and maintaining the XKS Proxy (the API spec is open source)

Cost: ~$1/key/month (KMS standard) + proxy infrastructure + external HSM costs.

Option 4: AWS Private CA — When the Need Is Certificates, Not Encryption

Before choosing between CloudHSM and XKS, there’s a fundamental question to ask: what are these keys actually used for?

If the answer is “certificates” — TLS, code signing, mutual authentication — then KMS was never the right tool. AWS Private CA is purpose-built for this.

The architecture works as a subordinate CA under the partner’s root:

PKI Partner = Root CA (trust anchor, on-premises)
    │
    │  Signs the subordinate CA certificate
    │
    └── AWS Private CA = Subordinate CA
            → Generates its OWN private key (in AWS HSMs)
            → Creates a CSR (Certificate Signing Request)
            → Sends CSR to the partner for signing
            → Imports the signed certificate (NOT the private key)
            → Issues end-entity certificates
            → Manages revocation (CRL/OCSP)
            → Native integration with ACM (ELB, CloudFront, API Gateway)

The partner stays the root of trust. Private CA manages certificate issuance autonomously. The subordinate CA’s private key is generated and stored inside AWS HSMs — there’s no key import, no key export, and no backup responsibility for the customer. AWS handles durability.

Cost: ~$400/month per CA + $0.75 per certificate issued.

Important note: KMS cannot generate a private key and transfer it to Private CA. These are separate services with independent key stores. Private CA always generates its own CA key internally.

Why “Just Use Azure Key Vault” Is the Wrong Answer

The instinct to move to Azure Key Vault because it allows key export deserves a direct challenge:

1. Key export is a security anti-pattern. FIPS 140-3 HSMs don’t allow export for a reason — it eliminates an entire attack vector. An exportable key is an exfiltrable key.

2. Azure Key Vault (standard tier) uses FIPS 140-2 Level 2 HSMs. That’s a certification downgrade from KMS’s FIPS 140-3 Level 3. For regulated industries — pharma, life sciences, finance — this matters.

3. Cross-cloud key management adds complexity. AWS workloads encrypted with Azure keys means two cloud dependencies, cross-cloud network latency, two sets of IAM policies, two billing systems, and two blast radiuses to manage.

4. The real problem is the partner’s process. If the PKI partner retained the key material (standard practice), none of this would be necessary. Switching clouds doesn’t fix a partner workflow issue.

Criteria	KMS BYOK (fixed)	CloudHSM	KMS + XKS	Azure Key Vault
Solves backup	Yes (if partner cooperates)	Yes (native export)	Yes (key never in KMS)	Yes (native export)
Key export	No	Yes	No (not needed)	Yes
Monthly cost	~$1/key	~$2,300+	~$1/key + proxy	~$1/key + Azure
HSM certification	FIPS 140-3 L3	FIPS 140-3 L3	Depends on external HSM	FIPS 140-2 L2/L3
Stays on AWS	Yes	Yes	Yes	No
Complexity	Low	Medium-high	Medium	High (cross-cloud)

What I Learned

• KMS’s no-export design is a feature, not a limitation. The entire security model of FIPS 140-3 Level 3 HSMs depends on key material never being extractable. When someone says “we need to export keys from KMS,” the right response isn’t “how” — it’s “why, and is there a better architecture?”

• The BYOK shared responsibility model has a hidden assumption. AWS documentation clearly states that customers must maintain their own copy of imported key material. But in practice, when a third-party partner handles the key generation, this responsibility can fall through the cracks. The partner discards the material, the customer assumes KMS handles durability, and nobody holds the backup.

• CloudHSM’s backup model is underappreciated. The automatic encrypted backups (with keys AWS can’t access), cross-region copy, and key wrapping export give you four independent copies of your key material — far more resilient than any BYOK setup. The ~$2,300/month price tag scares teams off, but for critical key material, it’s the most complete solution on AWS.

• XKS solves the problem at the root, not the symptom. Instead of trying to export keys from KMS, XKS keeps the key material in the external HSM permanently. No import, no export, no backup gap. If the PKI partner can serve as an XKS-compatible external key manager, this is architecturally the cleanest option.

• Always ask “certificates or encryption?” first. The answer changes the entire solution architecture. PKI certificate management and data encryption key management are fundamentally different problems that require different AWS services. Conflating them leads to over-engineered solutions.

What’s Next

• Verify whether major PKI partners (Entrust, Thales, Evertrust) support the XKS Proxy API natively
• Build a cost comparison calculator: CloudHSM vs XKS vs fix-BYOK for different key volumes
• Test CloudHSM key wrapping end-to-end: import from external HSM, export via wrapKey, re-import in another region
• Document the Private CA subordinate CA setup with an external root CA step by step
• Explore the CloudHSM + KMS custom key store integration for transparent service-side encryption