Bring Your Own Key (BYOK): What It Is and How It Works

Who holds the key that unlocks your data?

Every secrets manager, database, and backup service encrypts your data. That part is table stakes. A quieter question sits underneath it: once the data is encrypted, who holds the key that can decrypt it?

For most services, and most teams, the answer is the vendor, and that is a sound default. The vendor generates the key, stores it on hardened infrastructure built for exactly that job, and uses it on your behalf. It is simple to run and it is secure.

Bring your own key is a second option layered on top. Instead of the vendor holding the key that unlocks your data, you do, in your own cloud account. Neither model has stronger encryption than the other; the cryptography is the same. What changes is custody: who holds the key, and therefore who can revoke it.

This post explains what bring your own key means, how it works, what it does and does not change, and how SikkerKey offers it alongside SikkerKey-managed keys.

What is bring your own key (BYOK)?

Bring your own key, usually shortened to BYOK, is a model where you supply and control the encryption key a service uses to protect your data, rather than the service generating and holding that key itself.

In practice you create a key inside your own cloud key management service, or KMS: a dedicated, hardened service for storing and using encryption keys that every major cloud offers. The service is then set up to encrypt your data under that key. Your key never leaves your KMS. When the service needs to decrypt something, it asks your KMS to do the unwrapping, and your KMS answers only while you allow it to.

The shift is narrow and specific: it moves the key that gates your data into an account you control, so you can grant or withdraw the service's ability to decrypt at any moment.

Bring your own key puts the outermost lock of the encryption hierarchy in your KMS.

How does BYOK work?

To see why holding one key gives you that leverage, it helps to see how modern encryption is layered. Almost no system encrypts a large amount of data directly with a single master key. Instead it uses envelope encryption, a set of nested locks:

• Each piece of data is encrypted with its own data key.
• Those data keys are themselves encrypted by a higher-level key.
• That higher-level key is encrypted by a key above it, and so on, up to a single root key at the top.

Think of a set of nested boxes. The innermost box holds your secret. Every box is locked, and the key to each one sits inside the next box out. To reach the secret you open the boxes from the outside in, so everything ultimately depends on the key to the outermost box.

Whoever holds that outermost key holds the whole hierarchy. With vendor-managed keys, the vendor holds it. With BYOK, you do: when you connect your own key, the service re-encrypts the top of the hierarchy so the outermost box can only be opened by a key that lives in your KMS. The encryption underneath is unchanged; the only thing that moved is where the outermost key lives.

The kill switch: revoking access

The reason teams reach for BYOK is what that dependency lets them do: hold a direct off switch they operate themselves, rather than one they request from the vendor.

Revoke access and every decryption that depends on your key stops at once, with no cached copy to wait out.

Revoke the service's access to your key, or disable the key in your own console, and the top of the hierarchy can no longer be opened. Every layer beneath it stays locked. The service cannot decrypt your data, and there is nothing for it to wait out: a well-built BYOK system checks with your KMS on every decryption rather than caching a copy of your key.

Restore access and things resume. Nothing was destroyed and nothing has to be re-encrypted; the outermost lock simply becomes openable again.

That self-service control is the whole point of BYOK. It is why the model shows up in data-residency rules, key-custody policies, and compliance frameworks: some teams need to be the ones who can pull the key, on their own and on demand. If that does not describe you, vendor-managed keys remain a completely reasonable choice, and usually a simpler one.

BYOK and zero-knowledge: an honest limit

It is worth being clear about what BYOK does not do, because the term is easy to over-read.

BYOK is not the same as zero-knowledge or end-to-end encryption, and it does not make the encryption itself any stronger. To actually use your data, whether that means running a query, serving an API response, or returning a secret to your application, the service has to decrypt it. So while your key is available, the service holds your plaintext in memory for the moment it needs it. That is true of vendor-managed keys and BYOK alike.

What BYOK changes is custody. Every one of those brief decryptions runs through your key, so you can end them, everywhere, at once. The honest way to describe BYOK is not "the vendor can never see my data." It is "the vendor can only decrypt my data while I allow it, and I can end that whenever I choose, on my own."

That distinction matters when you evaluate vendors. A provider that claims BYOK makes it zero-knowledge is either misusing the term or hiding a design where your key is not really on the critical path.

How SikkerKey implements bring your own key

SikkerKey is a secrets manager: the encrypted store for the API keys, database passwords, and tokens your applications and machines read at runtime. By default, SikkerKey manages the root key that protects your vault, on isolated infrastructure kept separate from where secrets are stored and served. That is secure, and it is the right choice for most teams. On eligible plans, you can hold that root key yourself instead.

Every read makes a live call to your KMS. Your key is on the critical path, not cached.

Here is how it works when you bring your own key:

• You connect a key from your own cloud KMS. SikkerKey supports Google Cloud KMS and OVHcloud KMS today. You create a key there, authorize SikkerKey to use it for encrypt and decrypt, and point us at it. SikkerKey then re-encrypts every project's key in the vault so that unwrapping it requires your key.
• Every read runs through your key. To return any secret, SikkerKey first asks your KMS to unwrap that project's key, on every request, with no cached copy kept between reads. Your key is on the critical path for real, not only at setup.
• We never hold your cloud credentials. You authorize SikkerKey's access from your own console and can withdraw it there at any time. The permission is scoped to using the key for encrypt and decrypt, and reaches nothing else in your cloud account.
• Your key stays in your region. The call runs against your KMS in the region you chose, so you also decide where the key that gates your secrets resides.
• Connecting and disconnecting are audited. Both are recorded as critical events in your audit log, so a change of custody is never silent.

Connecting your own key controls what gates every decryption; it does not make SikkerKey zero-knowledge, and it does not change the underlying encryption. To serve a read we still decrypt the value in memory for the lifetime of that one request and clear it immediately afterward, exactly as we do with SikkerKey-managed keys. What moves into your hands is custody of the key all of that depends on, and the power to withdraw it.

Whether to bring your own key comes down to whether you need that custody. If a policy, a regulator, or your own risk model calls for holding the key yourself, BYOK gives you that cleanly. If not, SikkerKey-managed keys protect your secrets to the same standard with less for you to run.

The full treatment, including where our responsibility ends and yours begins, is in our security overview.

FAQ

What does BYOK stand for? BYOK stands for bring your own key. It is a model where you supply and control the encryption key a service uses to protect your data, instead of the service generating and holding that key itself.

Is BYOK more secure than vendor-managed keys? Not in the sense of stronger encryption; both protect your data with the same cryptography. What BYOK changes is custody: you hold the key and can revoke the service's access yourself, at any time. It is the right choice when you need that control or a policy requires it, and vendor-managed keys are a sound default when you do not.

Is BYOK the same as zero-knowledge encryption? No. With BYOK the service still decrypts your data to use it, so it can read your plaintext while your key is available. What BYOK gives you is control over the key every decryption depends on, and the ability to revoke it at any time. Zero-knowledge and end-to-end encryption mean the service can never decrypt at all, which is a different guarantee.

What happens if I revoke access to my key? The service can no longer decrypt any data that depends on your key. In a well-built BYOK system there is no cached copy of your key, so revocation takes effect immediately. Restore access and normal operation resumes, with nothing lost.

What happens if I delete or lose my key? Because you hold the key, its safekeeping is yours too. If you permanently delete or lose it, the data it protects can no longer be decrypted by anyone, including the vendor. That trade-off is the flip side of holding the key yourself, and it is why BYOK keys live in a dedicated KMS with its own protections and access controls.

Which cloud KMS providers does SikkerKey support for BYOK? Google Cloud KMS and OVHcloud KMS today, with more planned. You create the key in your own cloud account, so it stays under your control and in the region you choose.

Does BYOK slow things down? There is a small cost, because each read makes a live call to your KMS instead of using a locally held key. In exchange you get a self-service off switch. When your KMS and the service sit in the same region, that cost is typically a fraction of a second.