Self-Custody Is What BYOC Looks Like When the Workload Is a Compliance Boundary

SELF-CUSTODY SERIES · PART 1 OF 2

“Bring Your Own Cloud” has become one of the more useful pieces of vocabulary to emerge in enterprise software over the past two years, mostly because it forces a question vendors used to be able to dodge: where does the data actually live, and who can actually see it?

For platform teams shipping containers and APIs, BYOC means the control plane stays with the vendor while compute, storage, and traffic remain inside the customer’s own cloud account, a deployment model built for a specific kind of buyer: one with committed cloud spend to consume, a data residency requirement to satisfy, or a compliance ceiling above what shared SaaS responsibility can clear. That same logic, it turns out, describes almost exactly what Tehama customers have been asking for under a different name: Self-Custody.

The parallel isn’t a coincidence; both models exist because of the same unresolved tension in SaaS security. A vendor’s platform is valuable precisely because it’s managed, but managed has historically meant the vendor also holds the keys, the logs, and a line of sight into the customer’s most sensitive workloads, a tradeoff that’s usually fine for a stateless web app and the whole problem for an organization handling Controlled Unclassified Information, protected health information, or regulated financial data.

The Same Boundary, Drawn for a Different Workload

The cleanest way to think about BYOC is as a separation between two layers: a control plane, which is the vendor’s product (the UI, the API, the policy engine, the orchestration logic), and a data plane, where the actual workload runs (your private cloud resources and containers, your compute, your data, your secrets).

Figure: the control plane/data plane split that defines genuine BYOC, and the same split Self-Custody draws around a Tehama enclave.

In genuine BYOC, the vendor operates the former and never has a path into the latter. The test comes down to a single question: can the vendor see the payload?

Can the vendor see the payload?

If the answer is no, the model holds; if the vendor’s infrastructure sits anywhere in the request path, what’s being sold as BYOC is really just single-tenant SaaS with better branding. Self-Custody draws the identical line around a different kind of workload. Instead of a containerized application, the asset inside the boundary is a secure data enclave, a governed virtual desktop environment built to isolate CUI, regulated data, or supply-chain contractor access from everything else in the enterprise.

Tehama operates the control plane, the policy engine, and the secure gateway services, while the customer’s own Azure or AWS tenancy hosts the enclave itself, along with the encryption keys, the identity infrastructure, and the audit logs. Tehama configures the environment, keeps the software current, and enforces policy, but the architecture is built so that Tehama has no path to the data inside, and every change is approved by the customer.

That distinction is structural, not contractual.

That same distinction – the vendor manages the platform while the customer owns the data plane – is what separates real BYOC from a rebranded private SaaS connection, and it’s equally what separates Self-Custody from a managed VDI environment with a confidentiality clause attached.

Why the DIB Looks Like the Canonical BYOC Buyer

BYOC vendors generally agree on who actually needs the model: organizations in regulated industries with strict tenant boundaries, anyone with a hard data residency requirement, companies sitting on committed cloud spend they would rather consume than duplicate, and teams with reserved infrastructure they cannot migrate away from. Defense contractors navigating CMMC map cleanly onto the first two categories, and often the third as well.

A C3PAO assessor evaluating a Level 2 environment is, in effect, asking the same question a BYOC buyer asks before signing: can this vendor see the payload? Under a traditional managed SaaS security model, the honest answer is usually yes in some form, even when it’s bounded by contract language and a SOC 2 attestation. That ambiguity is exactly what creates findings during an assessment. It doesn’t matter how well-intentioned the vendor is; if the audit trail cannot demonstrate that CUI never crossed into infrastructure the vendor controls, the assessor has a gap to flag.

Self-Custody removes that ambiguity the same way genuine BYOC removes it elsewhere: by relocating the boundary itself. The enclave lives inside the customer’s own cloud tenancy, already certified to NIST SP 800-171’s physical and cryptographic baseline through Azure or AWS, and the customer’s Shared Responsibility Matrix, the same instrument C3PAO assessors already know how to read, draws a clean line between what the hyperscaler covers, what Tehama automates, and what the organization governs directly.

There is no “trust us” layer in the middle, only an architecture that makes the question moot.

What Most Teams Get Wrong About Needing It

The BYOC literature is unusually candid about one thing: most teams don’t actually need it. If a company’s compliance ceiling tops out at SOC 2 Type 2, and that is genuinely what its customers ask about, a well-run managed SaaS platform is faster to deploy and easier to operate, and BYOC earns its operational overhead only when a specific, identifiable requirement is driving it, not a generalized instinct toward more control.

The same discipline applies to Self-Custody, and it’s worth saying rather than burying it in a footnote: an organization that only needs to demonstrate reasonable security hygiene, with no CUI and no regulatory mandate forcing a verifiable chain of custody, does not need a self-custodied deployment. The added setup, however streamlined, is not worth it without a concrete driver attached. Where Self-Custody earns its complexity is precisely where BYOC earns its complexity elsewhere: CMMC Level 2 assessments, HIPAA environments handling PHI under a Business Associate Agreement, financial services workloads under FINRA or PCI-DSS, and any environment where a regulator or a prime contractor needs to see, not just be told, that the vendor has zero path to the data.

That’s also why a Self-Custody deployment should not require months of professional services to stand up. If a customer-controlled cloud security model takes a quarter to operationalize, it has quietly reintroduced the complexity it was supposed to eliminate. The bar Tehama holds itself to is rapid provisioning and policy enforcement even inside the customer’s own tenancy: the enclave deploys at the same speed as a managed environment because the platform layer is still fully managed. Only the data plane has moved.

What to Look for in Either Model

Whether the conversation is about BYOC for a development platform or Self-Custody for a CUI enclave, the diligence checklist is nearly identical, and it’s worth having on hand the next time a vendor uses either term.

Self-Custody answers all six the way a genuine BYOC implementation should. The enclave runs in the customer’s tenancy with Tehama structurally unable to access it, deployment uses the same provisioning speed as a managed enclave, and the customer retains the full Tehama feature set, identity integration, session auditability, DLP, zero-trust access, network segmentation, without giving any of it up to gain sovereignty.

The Same Idea, Wearing the Right Name for Each Audience

BYOC and Self-Custody emerged from different corners of the software industry, one from platform engineering, the other from compliance-driven enterprise security, yet they arrived at the same architectural answer because they were solving the same underlying problem from two directions. A platform team needed to keep workloads within a customer’s committed cloud spend without sacrificing a managed experience; a defense contractor needed to keep CUI within a verifiable boundary without sacrificing the agility of an enclave-as-a-service platform. The vocabulary differs. The control plane and data plane split underneath it does not.

For organizations evaluating Self-Custody for CMMC, HIPAA, PCI-DSS, or any regime built around a hard boundary requirement, that parallel is useful context rather than a coincidence to wave away. It means the model is not a defense-industry curiosity invented to satisfy a single regulation, but rather the same deployment pattern enterprise software is converging on broadly, applied to the workload where the stakes for getting the boundary wrong are highest.

This is where Part 1 leaves off: a structurally sound boundary, verified against a six-question checklist. Part 2 picks up the harder question sound architecture alone can’t answer, the one its title poses directly: A Checklist Tells You the Architecture Is Sound. It Doesn’t Tell You It’s Still Holding.

Tehama Technologies delivers Self-Custody Data Enclaves so that organizations handling CUI, PHI, and other regulated data can operate inside their own Azure or AWS tenancy with full control of their keys, logs, and identity, without sacrificing the speed or unified platform experience of a modern enclave-as-a-service deployment. To learn more, visit tehama.io/product/self-custody.

Read the full series: Part 1: Self-Custody Is What BYOC Looks Like When the Workload Is a Compliance Boundary · Stay tuned for Part 2: A Checklist Tells You the Architecture Is Sound. It Doesn’t Tell You It’s Still Holding.