Your Enclave, Your Keys: The Self-Custody Model That Removes Vendor Trust from the Equation

CMMC SERIES · PART 2 OF 3

When the compliance boundary lives inside your own cloud tenancy, and you hold every encryption key, every audit log, and every identity credential, the relationship with your security vendor changes entirely, and so does your audit posture.

In Part 1 of this series, we described why traditional network architectures create the Scope Trap: the compounding dynamic where CUI flows across shared systems, VPNs extend the enterprise perimeter to unmanaged endpoints, and a C3PAO assessor ends up evaluating a sprawling, fragmented environment that no organization can realistically harden to the standard CMMC Level 2 demands. The answer to that problem isn’t a better VPN or a more capable DaaS platform. It’s a fundamentally different architectural model, one where the compliance boundary is defined before the environment is built rather than retrofitted afterward.

Tehama’s approach starts with a precisely defined, technically enforced digital boundary around Controlled Unclassified Information, deployed inside the customer’s own cloud tenancy on Azure or AWS. The enclave becomes the only environment where CUI exists in clear text. Everything outside it (HR systems, email infrastructure, shared collaboration tools, unmanaged endpoints) stays entirely out of scope for the C3PAO assessment. The scope of the evaluation shrinks dramatically, the audit evidence becomes cleaner, and the path to certification becomes far more achievable than it would be under a “harden everything” approach.

The technical mechanism is straightforward in concept. Users access the CUI environment through an encrypted presentation-layer protocol (PCoIP or RDP), meaning the operating system that processes sensitive data never leaves the secure perimeter. The user’s physical device, whether a corporate laptop or a personal machine, functions as a dumb terminal receiving an encrypted pixel stream. No CUI is ever cached on the endpoint, no data traverses the local network, and no file can be downloaded to a device that sits outside the compliant boundary. The endpoint is effectively removed from CUI asset scope because, by design, it never touches CUI directly. For most DIB organizations, that single architectural shift eliminates a substantial portion of the assessment complexity that makes CMMC so difficult to achieve.

The Self-Custody Model: Zero Vendor Access, Full Customer Control

For defense primes and organizations handling sensitive defense information, the question of vendor trust is not a minor consideration. Traditional SaaS security models require customers to surrender meaningful control over encryption keys, audit logs, and identity management to the platform provider, an arrangement that creates opacity that is both unacceptable under CMMC and incompatible with the security posture expected of organizations within the Defense Industrial Base. If your security vendor can access your CUI environment, you have a problem that no contractual assurance can fully resolve.

Tehama addresses this through what we call the Self-Custody deployment model. When a Self-Custody Data Enclave is deployed, the entire environment runs inside the customer’s own Azure or AWS cloud tenancy. The customer retains exclusive ownership of their encryption keys, exclusive control over identity management, and exclusive custody of their audit logs. Tehama operates the control plane and policy engine, configuring the environment, maintaining the software, and ensuring controls remain current, but is architecturally prevented from accessing the CUI or sensitive workloads inside the enclave. This isn’t a policy commitment or a contractual promise. It’s a technical guarantee built into the design: the architecture makes it structurally impossible for Tehama to see what’s inside.

The practical compliance implication of this is significant. Because the customer holds all the keys and all the logs, there is no ambiguity about chain of custody for audit evidence. The C3PAO assessor is examining an environment that belongs entirely to the organization under assessment, with a clear and unbroken record of every access event, configuration change, and data movement. That’s the kind of defensible audit posture that makes assessments faster, cleaner, and substantially less likely to produce findings.

Your Enclave. Your Keys. Our Platform. In a Self-Custody deployment, Tehama provides the software and operates the control plane. The customer owns everything inside: the encryption keys, the audit logs, the identity infrastructure, and the data itself. Zero vendor access isn’t a contractual promise. It’s engineered into the architecture.

Inheriting Compliance Rather Than Building It From Scratch

One of the more significant advantages of deploying a Self-Custody Enclave within an Azure or AWS tenancy is the compliance inheritance it provides. When the CUI environment runs inside a hyperscaler’s infrastructure, the organization doesn’t start from zero. It inherits the multi-billion-dollar compliance investments those platforms have made in physical security, cryptographic infrastructure, and regulatory certification. That inheritance is not incidental. It’s a deliberate part of the architecture’s value.

Physical protection requirements under NIST SP 800-171, for instance, are satisfied by Azure and AWS data center controls: guards, biometric access, redundant power, and secure media destruction. FIPS 140-2 validated cryptography for data at rest and in transit is inherited from the cloud fabric itself, meaning the customer doesn’t need to procure, deploy, or manage encryption appliances. Hardware maintenance and media sanitization are handled by the hyperscaler. For most DIB contractors, building equivalent infrastructure independently would be prohibitively expensive and operationally complex. By deploying inside Azure or AWS, those controls are simply present, documented, certified, and inheritable through the Shared Responsibility Matrix that CMMC assessors are already familiar with.

What remains as the customer’s responsibility under this model is primarily governance: approving and denying access requests, defining RBAC policies, managing the user lifecycle, conducting personnel screening, and facilitating change management through appropriate advisory structures. Tehama automates the technical enforcement layer, blocking unauthorized egress, event recordings, and generating the immutable audit evidence that assessors require, so the organization can direct its compliance effort toward the governance tasks that genuinely require human judgment, rather than the infrastructure hardening that the platform and the hyperscaler handle by default.

Compliance is a team sport, and the Shared Responsibility Matrix makes explicit who does what. The hyperscaler handles physical infrastructure and core cryptography. Tehama enforces the CUI boundary and generates audit evidence automatically. The customer defines policy: who gets access, under what conditions, and for how long. Each party does what it does best, and the assessor gets a clean, navigable compliance story.

What the Assessor Actually Sees

It’s worth being concrete about what this architecture looks like from a C3PAO assessor’s perspective, because that’s ultimately what matters for certification. An assessor evaluating a Tehama Self-Custody Enclave deployment encounters an environment with a clearly defined CUI boundary, a documented Shared Responsibility Matrix that accounts for all 110 NIST 800-171 controls, and an automated evidence pipeline that produces immutable logs, and access records without requiring manual collection or reconstruction. The Assessment Scope is small because the boundary is tight. The evidence is clean because it was generated continuously, not assembled in advance of the audit.

Compare that to the typical experience of assessing a patchwork environment: VPN plus legacy VDI plus bolt-on events recording plus a separate SIEM that may or may not be receiving logs from every relevant system plus IAM for role-based identity access. The difference is not subtle. One environment tells a coherent story. The other requires the assessor to reconstruct a story from fragments, and fragments leave room for findings. The enclave architecture doesn’t make compliance easier by lowering the bar. It makes it achievable by making the environment genuinely auditable, which is what the bar actually requires.

Tehama Technologies helps defense contractors and DIB organizations protect Controlled Unclassified Information and build a compliance posture that holds up under any assessment regime, through Self-Custody Data Enclaves. To learn more, visit tehama.io.

Up next: Part 3 · Beyond Certification: How the Enclave Model Transforms Subcontractor Risk, AI Adoption, and Competitive Positioning.