How to offer BYOK to your enterprise customers

At some point in an enterprise sales cycle, a security questionnaire will ask whether your application supports bring your own key (BYOK). If your answer is no, that questionnaire goes back to the buyer's security team with a gap, and the deal slows down while someone decides how much they care.

BYOK is no longer an enterprise differentiator. It is a procurement checkbox. And increasingly, it is a checkbox that appears earlier in the sales process than it used to.

This post covers what BYOK actually is, why enterprise buyers ask for it, what they are really trying to accomplish when they do, and how to implement it in your application without rebuilding your encryption infrastructure.

What BYOK means

Bring your own key allows a customer to supply their own encryption key, stored in their own key management system, to be used when encrypting their data in your application. Instead of your application managing all encryption keys, the customer's key becomes the key-encrypting key (KEK) for their data.

In practical terms: the customer creates a key in AWS KMS, Azure Key Vault, or Google Cloud KMS. They grant your application permission to use it for cryptographic operations, but not to export or read the key material itself. From that point on, whenever you encrypt or decrypt their data, you are doing so using their key. If they revoke access to the key, you can no longer read their data. They are in control.

The underlying encryption mechanism (envelope encryption, where a data encryption key encrypts the data and the customer's KEK encrypts the DEK) is the same whether you use a managed key or a customer-supplied one. The only thing that changes is which key sits at the top of the hierarchy.

Why enterprise buyers ask for it

Security questionnaires ask about BYOK for several distinct reasons, and understanding them helps you have a more useful conversation with the buyer's security team.

Key revocation as an exit right

The most common real reason: BYOK gives a customer a guaranteed, immediate way to make their data unreadable if they ever leave your platform, have a dispute, or need to shut down access in an emergency. If they hold the KEK, they can revoke your application's access to it at any time. Every DEK that was wrapped with their KEK becomes permanently unreadable.

This is particularly important for customers in regulated industries. When they offboard from a platform and need to demonstrate to an auditor that their data is no longer accessible, "we asked the vendor to delete it" is a weaker answer than "we revoked the key and the data is mathematically unreadable."

Compliance mandates

Several compliance frameworks either require or strongly encourage customer-controlled encryption keys. Some HIPAA interpretations require covered entities to control their own PHI encryption keys. FIPS 140-2 and Common Criteria certifications sometimes require use of specific HSMs or key management systems the customer already operates. Internal security policies at financial services companies and government contractors frequently mandate that encryption keys must not be held by third parties.

In these cases, BYOK is not a preference. It is a requirement that blocks a deal if unmet.

Data sovereignty

For customers subject to data residency requirements, BYOK can be part of the answer. If their encryption key is provisioned in a specific geographic region (an AWS KMS key in eu-west-1, for example), they have additional assurance that the key material itself is subject to the legal jurisdiction of that region. This matters for customers operating under GDPR or other regional data protection laws with strict data localisation requirements.

A proxy for security maturity

Security teams at enterprise companies evaluate vendors partly by asking hard questions and watching how the vendor responds. BYOK is a question that separates vendors who have thought carefully about their encryption architecture from those who have not. A confident, accurate answer signals that your application was built with data security as a first-class concern, not bolted on after the fact.

What buyers are not asking for

It is worth being explicit about what BYOK does and does not guarantee, because some buyers have an inflated sense of what it provides.

BYOK does not prevent your application from reading the customer's data during normal operations. Your application still decrypts data to serve it to the customer's users. What BYOK prevents is your application being able to read the data without the customer's key, which is useful in an emergency (revocation) or after an offboarding (key deletion), but not during normal operation.

BYOK also does not protect against vulnerabilities in your application layer. If an attacker compromises your application and can issue valid API calls on behalf of a customer, those calls will use the customer's key to decrypt their data. Cryptographic isolation and application-layer authorization are separate concerns.

When you explain this clearly in a sales conversation, two things happen. First, the security-literate buyers respect it, because they know you understand what you are offering. Second, it often unlocks a better conversation about what the buyer actually needs, which is sometimes just the right answer to a questionnaire question and sometimes a more substantive security discussion.

How BYOK works with Vault

If your application uses WorkOS Vault for encrypted storage, BYOK is not an engineering project. It is a configuration step that you initiate and your customer's IT team completes.

The architecture works as follows. When your application stores data with a key context tied to a customer's organization, Vault normally uses a WorkOS-managed KEK for that context. With BYOK enabled, Vault uses the customer's CMK as the KEK instead. The key context matching is automatic: if a customer has configured a CMK for their organizationId, Vault uses it for any operation that includes that organization's ID in the context. Customers who have not configured BYOK continue using WorkOS-managed keys without any change.

Your application code does not change. The createObject and readObject calls look identical. The difference is entirely in which key Vault uses to wrap the DEK.

  
// This call looks the same whether or not BYOK is configured for org_acmecorp.
// Vault resolves the correct key automatically based on the context.
const object = await workos.vault.createObject({
  name: 'acme-payment-token',
  value: 'tok_live_...',
  context: { organizationId: 'org_acmecorp' },
});
  

If Acme has configured their AWS KMS key for their organizationId, Vault uses it. If they have not, Vault uses a WorkOS-managed key. Either way, your code is identical.

Enabling BYOK for a customer

The setup flow is managed through the WorkOS Admin Portal. When a customer is ready to configure BYOK, here is what the process looks like.

1. ‍Contact WorkOS to enable BYOK for your application. BYOK is enabled at the application level. Once it is on, you can initiate the setup flow for individual customers.‍
2. Generate an Admin Portal link. In your WorkOS dashboard, navigate to the customer's organization. Click "Invite admin" and select "Bring Your Own Key" from the feature options. This generates a unique, scoped link for that customer.‍
3. Send the link to the customer's IT team. The customer's IT administrator opens the link and follows the guided setup. The Admin Portal walks them through creating a key in their cloud provider of choice (AWS KMS, Azure Key Vault, or Google Cloud KMS) and configuring the IAM permissions that allow Vault to use the key for cryptographic operations. WorkOS-provided screenshots guide them through each step in their specific cloud provider's console.‍
4. Vault validates the configuration. At the end of the Admin Portal flow, Vault tests that it can use the CMK the IT admin configured. If validation succeeds, the customer sees a "Setup is complete" confirmation. From that point forward, all Vault operations for their organization use their key.‍
5. Confirm the configuration in your dashboard. A key details card appears under the organization in your WorkOS dashboard, showing the CMK configuration, active state, and the key context it is associated with. You can monitor it from there.

The customer's IT team never needs to talk to your engineering team. The Admin Portal handles the entire setup on their side, and Vault handles the key context matching on yours.

What happens when a customer revokes their key

If a customer revokes Vault's access to their CMK in their cloud provider, Vault can no longer unwrap the DEKs for their data. Read and write operations for that customer will fail. This is the intended behavior from the customer's perspective. From yours, you need to handle these errors gracefully and have a process for communicating to the customer that their key access needs to be restored before their data is accessible again.

If a customer is offboarding and revokes deliberately, this is the mechanism that gives them confidence their data is gone. Their key is revoked, the DEKs are unreadable, and the ciphertext in your database is permanently inaccessible.

How to position BYOK in the sales process

Once you have BYOK working, the question is how to talk about it. A few approaches that work well.

Lead with the outcome, not the acronym. "Your IT team can bring their own AWS KMS key, and if you ever revoke it, your data is immediately and permanently unreadable to us" is a more useful sentence than "we support BYOK." The outcome (irrevocable data control) is what the buyer's security team is evaluating, and naming it directly moves the conversation forward.

Use it proactively in security questionnaires. Do not wait for a prospect to ask. Add BYOK to the encryption section of your security documentation, your trust center, and your standard questionnaire responses. Buyers who are evaluating your encryption posture will find it there, and it becomes a positive signal rather than a gap.

Be honest about what it is and is not. As covered earlier, BYOK prevents access to data after key revocation. It does not prevent access during normal operations. Security-literate buyers know this, and stating it plainly signals that you understand the feature you are offering. The buyers who do not know this will appreciate the clarity.

Tier it as an enterprise feature. BYOK is legitimately an enterprise-grade security capability. It is reasonable to make it available on enterprise plans and use it as an upgrade lever. Customers who need it typically already know they need it and are willing to pay for the tier that includes it.

Putting it together

BYOK used to be a feature that set enterprise software apart. It is now a baseline expectation for any application handling sensitive data in regulated industries or enterprise accounts.

The good news is that implementing it well does not require rebuilding your encryption infrastructure. If you are already using Vault with key context, the architecture is already correct. Adding BYOK for a specific customer is a configuration step that takes your customer's IT admin through a guided flow, not an engineering project for your team.

The prerequisite is having the right encryption architecture underneath: per-tenant key isolation via key context, envelope encryption so the customer's key sits at the KEK layer without ever touching the data directly, and an application-layer encryption layer that operates independently of your application database.

If those are in place, BYOK is the last step, not the first one.

Further reading

• BYOK documentation: the full setup guide for enabling BYOK in your WorkOS dashboard
• Cryptographic key isolation in multi-tenant SaaS: the architecture that makes BYOK possible
• Envelope encryption explained: the DEK and KEK model that BYOK sits on top of
• Encrypting PII in a Node.js app with WorkOS Vault: a practical tutorial for the underlying Vault operations