Why we built customer-managed keys into every paid plan

If you survey the file-transfer and secure-messaging market, customer-managed keys — BYOK, bring your own key — almost universally lives behind an enterprise paywall. We’ve watched this pattern for years and decided it was wrong. As of this release, every paid plan on SEND-SECURELY.COM includes customer-managed key support. This post explains the technical architecture and the business reasoning behind that decision.

The “BYOK is Premium” anti-pattern

The argument for gating BYOK is usually framed as infrastructure cost: managing key references per-tenant, building the KMS adapter, handling rotation events, testing across AWS KMS, GCP Cloud KMS, and HashiCorp Vault. There’s real engineering work there. We’re not dismissing it.

But the market outcome is that SMBs and mid-market companies — who are increasingly subject to HIPAA, CMMC 2.0, NIST 800-171, and NYDFS Part 500 — are buying tools where the vendor holds the encryption keys. They think they have encryption; they don’t have key separation. When a vendor is compromised, their data is compromised along with it. The organizations that can least afford a breach are the ones that can’t afford the tier that actually protects them.

There’s also a trust argument that matters to us as a vendor. When we hold your keys, you have to trust not just our security controls but our key management practices, our access policies, our insider threat program, and our recovery procedures. Reasonable enterprises scrutinize all of that in vendor assessments. Customer-managed keys collapse that surface: if we can’t decrypt without your KMS, there’s less to audit.

Architecture: wrapped-key envelope

Here’s how it works. When you configure a BYOK key:

1. We generate a per-transfer data encryption key (DEK) using AES-256-GCM. This key never leaves our encryption layer in plaintext.
2. We submit the DEK to your configured KMS endpoint for wrapping (encryption). The KMS returns a wrapped DEK (wDEK).
3. We store the wDEK alongside the ciphertext. The plaintext DEK is discarded after use.
4. On download, we submit the wDEK to your KMS for unwrapping, use the returned plaintext DEK to decrypt the ciphertext, and again discard the DEK.

This is the envelope encryption pattern documented in AWS KMS, GCP Cloud KMS, and the HashiCorp Vault Transit secrets engine. The KMS never sees your data. We never see your plaintext key. The only long-lived secret in our infrastructure is the wDEK — and that’s useless without your KMS.

We support three KMS adapters at launch: AWS KMS (including AWS CloudHSM-backed CMKs), GCP Cloud KMS, and HashiCorp Vault Transit. We abstract over these with a thin adapter interface, which means adding additional KMS backends — Azure Key Vault is next — is a matter of implementing a four-method interface rather than rearchitecting the encryption layer.

Key material never crosses our trust boundary. We validate this claim with a quarterly penetration test specifically scoped to the key-unwrap pathway.

FIPS 140-3 and key derivation

For customers operating under FIPS 140-3 requirements — federal contractors under CMMC 2.0 and FedRAMP-adjacent workloads — we support FIPS 140-3 cryptographic modules for all key operations on both our side and in the AWS KMS and GCP KMS adapters. The HashiCorp Vault adapter operates in FIPS-mode Vault when the customer’s Vault instance is configured accordingly. We document the full FIPS module chain in our trust documentation, available on request.

Key rotation events from your KMS are handled without transfer interruption: we re-wrap outstanding wDEKs against the new key version during a scheduled background job, and we log every rotation event in the audit log with the old and new key version identifiers.

Operational cost reality

We want to be honest about the engineering investment we made here, because part of our argument is that the “BYOK is expensive” framing doesn’t hold up once you’ve made the architectural decision correctly.

The majority of the implementation cost was in the adapter abstraction and the rotation event pipeline. Those were one-time investments. The per-tenant operational overhead is a KMS API call on every file encryption and decryption. At current KMS pricing — approximately $0.03 per 10,000 API calls on AWS — the marginal cost for a typical customer doing several hundred transfers per day is under $0.10/month. That cost does not justify a tier gate.

What does add operational complexity is support: customers misconfigure KMS policies, IAM roles expire, VPC endpoints are removed. We’ve invested in better error messaging and a KMS connectivity diagnostic tool that customers can run before they go live. The first 90 days after launch were heavier on support tickets than we expected; we’ve addressed most root causes in the diagnostic tooling.

What this means for buyers

If you’re evaluating file-transfer platforms under HIPAA, CMMC 2.0, or NIST 800-171, the encryption key question should be one of your first due-diligence items. Ask: “Who holds the encryption keys, and at what plan tier can I manage my own?” If the answer is “Enterprise only,” factor that into your total cost of ownership and your residual risk calculation.

We made the opposite choice. Customer-managed keys are available on every paid plan, documented in our security overview, and covered under our standard BAA for HIPAA customers. If you want to run a proof-of-concept with your AWS KMS or GCP KMS, the setup takes about 20 minutes and the configuration guide is in our docs.