A Checklist Tells You the Architecture Is Sound. It Doesn't Tell You It's Still Holding.

SELF-CUSTODY SERIES · PART 2 OF 2

Part 1 covered what makes Self-Custody structurally different from a rebranded managed VDI environment: a genuine control plane and data plane split, tested against a six-question diligence checklist. Here, we address the harder question that checklist can’t answer on its own, whether a boundary that was sound on deployment day is still holding months later, and how to prove it continuously rather than only at audit time.

That checklist is the right way to judge a BYOC or Self-Custody deployment on the day it goes live, but sound architecture at deployment and a boundary that is demonstrably holding six months later are two different claims, and the second is harder to prove. Knowing that CUI never left a customer-controlled boundary is necessary for compliance, but it is not the same as knowing, continuously, how well that boundary is actually holding, or how it would score against the framework’s own controls if an assessor walked in today.

Three Layers, One Incomplete Picture Each

The first is the enclave itself: the operational record of what happened inside the boundary, including access grants and revocations, policy acceptance and denial, firewall and DNS changes, session activity, secret retrieval, and lockouts. This is the evidence layer closest to the workload, and it is genuinely valuable, but it is also incomplete on its own. It tells you what happened inside the enclave; it does not tell you whether the identity layer enforcing access into that enclave has MFA coverage gaps, or whether conditional access policy is actually being honored at the point of authentication.

The second layer lives in the customer’s hyperscaler, whose own identity and control plane generates signals about sign-in risk, multi-factor enforcement, conditional access outcomes, and federation health, a posture context the enclave simply cannot see from the inside. An enclave can faithfully log every access attempt it receives without ever knowing whether the identity behind that access was itself compromised, under-protected, or granted through a policy exception nobody reviewed.

The third layer is endpoint and device posture: hardening baseline compliance, configuration drift, remediation outcomes, and malware or scan results for the devices actually connecting into the enclave. An enclave can be perfectly configured and still inherit risk from an endpoint that never received the latest hardening profile.

Figure: three evidence layers, each visible from a different vantage point, none complete on its own.

Read alone, none of these three layers answers the question a CMMC assessor, a CISO, or a prime contractor’s risk team is actually asking: whether the boundary is holding right now, not whether it held during the last audit cycle.

Is this boundary holding right now? Not whether it held during the last audit cycle.

Why Correlation Is the Missing Piece

The architecturally consistent answer is to treat all three layers as a single, correlated evidence model rather than three scattered logs an assessor has to reconcile by hand, joined on shared identity: the same user, the same device, the same enclave, the same point in time, viewed from three different vantage points at once. Correlated properly, the result is not a static audit artifact assembled once a year before an assessment, but a continuous compliance posture view, covering access control health, audit completeness, configuration drift, and boundary integrity, built by joining enclave-level operational evidence to hyperscaler identity signals and endpoint hardening state.

That is a meaningfully different deliverable than a point-in-time evidence package. It is the difference between proving compliance once a cycle and observing it continuously, the same way a security operations team monitors live telemetry instead of waiting for a quarterly report.

Where This Leaves the Checklist

This is the direction the BYOC parallel points toward naturally. If the enclave is the data plane, the hyperscaler’s identity and control plane is one external layer of posture context, and endpoint hardening telemetry is another, then the next layer of value sits at the correlation point between all three, not in any single source alone. It is also the next item the original diligence checklist will eventually need: not just whether the boundary is sound, but whether you can prove, continuously, that it still is.

For organizations evaluating Self-Custody specifically for CMMC, HIPAA, or similarly evidence-driven frameworks, that correlation layer is where the architecture is heading: enclave evidence, identity posture, and endpoint integrity joined into a single, continuously updated view, rather than three separate logs nobody has reconciled until assessment week.

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. 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 · Part 2: A Checklist Tells You the Architecture Is Sound. It Doesn’t Tell You It’s Still Holding.