Documentation

Escrow and Keyout.

This page describes the same arrangement as the Keyout terms. Where the wording differs, the legal page controls. Nothing here softens it, and if you find a place where it reads more generously than the terms do, tell us, because that is a defect rather than a bonus.

The problem this solves

If you put your firmware signing key inside somebody else's service, the honest question is what happens to your product line when that somebody stops answering the phone. Most answers to that question are a promise. This one is a mechanism: the keys are already in an AWS account dedicated to you, and Keyout is the arrangement under which that account and the key material in it become yours to run.

It is worth being blunt about the shape of it, because trust is the product here. This is not a copy of your keys handed over on request. Key material is non-extractable by design and stays that way. What conveys is control of the account and the keys in place, and you reach those keys directly through a role in your own account from the first day of the process rather than at the end of it.

The conditions

Two conditions have to hold, and they are the whole of it:

• Your account is paid up. A subscription in good standing, not a lapsed one.
• The exit fee is paid in full. Not partially, not on terms. The orchestration verifies a confirmed payment before it executes any phase, so payment is the thing that starts the process rather than a step inside it.

Both, not either. A lapsed subscription is not a Keyout event, and neither is an intention to pay.

There is a third thing you provide rather than a condition you meet. At initiation you designate an Escrow Access Role: an IAM role in an AWS account you already own, which must be a different account from your tenant account. That role is what carries your access through the transition, so have the account it lives in before you start.

What actually happens, and when

Three phases follow confirmed payment. The distinction that matters throughout is between access, which you have from day one, and ownership, which arrives at the end.

• Day 1, certificate export then compute demolition. If you hold certificate material, it is exported first into an archive bucket created inside your own tenant account, before anything is torn down, because the storage it is copied out of goes away with the managed layer. Then that managed layer is removed from your account: the Lambda functions, the API Gateway configuration, the orchestration. Your KMS keys and key material are untouched and remain operational. The Escrow Access Role is granted use of your keys before the demolition begins, so cryptographic access never has a gap. What changes is that you now call AWS KMS directly rather than our API.
• Days 2 to 90, transition quarantine. Your account stays inside our AWS Organization while CloudTrail management event history ages out. That history contains our deployment parameters and IAM choreography, which is our intellectual property rather than your data, and the wait is what lets the account transfer without carrying it. Throughout this period you keep full cryptographic access through the Escrow Access Role. You do not yet own the account.
• Day 91, account ejection. The account is formally ejected from our Organization and transferred to you. This is the point at which ownership changes hands and we are no longer in the picture at all.

Plan the ninety days rather than being surprised by them. They are not a delay in getting your keys, because you have direct access to those on day one. They are a delay in owning the container, and the useful thing to do in that window is migrate any production integration off our API endpoints, and line up whoever will administer the account once it lands.

What conveys

The enumeration is closed, which is the point of writing it down:

• The keys. The key material in your account, in place, under your control.
• The audit trail. The record of what was done with those keys, by whom, and when. Evidence you may have a retention duty for long after you stop being a customer.
• The key inventory. What exists, so the conveyed material is identifiable rather than an opaque set.
• The certificate estate. If you run a certificate authority, it conveys as an archive: the CA certificates, the chains, the certificates you issued, the revocation lists, a standard OpenSSL CA database for each authority, and an inventory file describing all of it. The archive sits in a bucket inside the account you receive, so it arrives with the account rather than being sent to you. It is your certificate truth in a format ordinary CA tooling reads; it is not a copy of the tables we ran it from.

What does not convey

Our software does not convey. You receive keys and their audit history, not a copy of the service that was operating them. Running them afterwards is your own tooling calling AWS directly, which is possible precisely because the keys were never in a proprietary format to begin with.

Operational infrastructure does not convey either, and neither do our own service logs as distinct from your audit trail.

How the fee works

The Keyout fee is the greater of $1,000 or twenty four times your trailing twelve month average monthly bill. It is published, it is formulaic, and it is the same formula for everyone, which is the only way a continuity arrangement is worth anything: a price that gets negotiated at the moment you need it is not a continuity arrangement.

The estimator on the pricing page computes it from the same constants the billing system uses.

What happens if you do nothing

The default state of a key is deletable. If you cancel and walk away without executing a Keyout, your keys are eventually destroyed along with the account that held them. That is the honest default and we would rather you read it here than discover it.

So: if the key material matters beyond the life of your subscription, either execute the arrangement while you are paid up, or export what you need before you go. Anything encrypted under a key that is destroyed is unreadable afterwards, permanently, by anyone. See the deletion section of Keys.