BYOK on AWS KMS: Architecture

Customer-managed keys on AWS are protected by two independent, deliberately separate layers of trust. This page explains the model at a level useful for a security review; for the actual setup steps, see the BYOK on AWS KMS setup guide.

Two independent trust layers

Wrapping and unwrapping a file’s encryption key against your AWS KMS key involves two separate authorization decisions, each granted independently and each with its own, deliberately different, blast radius:

  1. BYOVault’s backend, authenticating to a narrow intermediary service BYOVault operates. BYOVault holds a credential scoped ONLY to invoking that one intermediary — nothing more.
  2. That intermediary, authorized against your KMS key. The real cross-account trust that lets anything touch your actual key material lives entirely in a policy statement you add to your own key — never in anything BYOVault’s backend holds.

These two layers are never conflated. The credential BYOVault’s backend holds cannot reach your key material at all; the credential that can reach your key material never leaves BYOVault’s own AWS environment.

Layer 1: a narrow, invoke-only credential

BYOVault authenticates to the intermediary service using a credential dedicated to this one purpose. It is scoped to invoking only that one service and nothing else — no permission to reach KMS, no permission to reach any other AWS resource.

Every request is cryptographically signed and time-bound, and every invocation is independently logged.

Blast radius if this credential leaks
A leaked copy of this credential lets an attacker invoke this one intermediary service — nothing more. It grants no access to any customer’s KMS key, no access to key material at all, and no access to any other AWS service. The credential is structurally incapable of decrypting or wrapping a key on its own; it can only make a request to the intermediary, which in turn can only act on keys whose owners have separately authorized it.

Layer 2: cross-account trust on your own key

The intermediary service is granted permission to encrypt, decrypt, and describe keys through its own execution identity — but this is not, in practice, broad access to every KMS key in existence.

AWS KMS enforces both sides of a grant. The intermediary’s own permissions are necessary but not sufficient: your key’s own policy must separately name that identity before it can do anything at all. Without a matching statement on your key, the intermediary has no path to your key’s contents whatsoever.

That statement is what the setup guide has you add to your key’s policy, granting BYOVault’s intermediary permission to encrypt, decrypt, and describe your key.

This is the only place the real cross-account trust exists, and it is entirely under your control — revocable by editing your own key policy, with no coordination from BYOVault required.

Wrap/unwrap only, never key export
None of the granted permissions extract your key’s raw material. Generating or using a data key returns only a value usable for that one operation, alongside that same value protected under your KMS key; your KMS key’s own key material never leaves AWS KMS in any form.

Why an intermediary exists at all

Unlike Azure, where a managed identity can only be issued to something running on Azure’s own compute, an AWS credential authenticates identically whether the caller runs on AWS compute or anywhere else. Nothing about AWS’s authentication model structurally forces an intermediary to exist the way Azure’s design does.

The intermediary exists to ensure no standing, KMS-capable AWS credential is ever held outside BYOVault’s own isolated AWS environment.

Why this matters
A long-lived credential with direct KMS permission would be a real secret whose leak exposes every BYOK customer’s key access at once. The only credential held elsewhere is the narrow, invoke-only one described above, which is structurally incapable of reaching KMS under any circumstances.

What each side stores

BYOVault stores only your key’s identifier. No customer-specific credential, secret, or key material is held anywhere in BYOVault’s database.

Authorization flows entirely from the key-policy statement described above, which lives in your own AWS account and which you control.

For the actual console steps to create a key and add the required key-policy statement, see BYOK on AWS KMS: Setup Guide. For what happens when a key becomes unreachable, disabled, or deleted, see Key Availability & Failure Behavior. For how AWS BYOK compares to BYOVault’s default key path, see Customer-Managed Keys (BYOK).

PreviousCustomer-Managed Keys (BYOK)NextBYOK on Azure Key Vault: Architecture