A recent op-ed I wrote for CyberScoop argued that many security conversations stall out at the infrastructure layer, whether cloud versus on-prem or perimeter versus “zero trust,” without fully threat modeling what actually needs protection and where compromise is most likely to occur. That piece sparked a predictable follow-up: what about trusted execution environments (TEEs) and “confidential computing”?
This blog is a direct response to that question. TEEs are not bad. They’re useful. But they are not a silver bullet, and they are not a binary checkbox of safe/not-safe. Like MPC and HSMs before them, “TEE” is increasingly being used as a marketing shorthand for security (“We use TEEs, so we’re secure.”), often without clarifying which TEE model is in play, what guarantees it provides, and what new assumptions it introduces. In other words: the word “TEE” can create false confidence if it’s not anchored to a threat model.
Trusted execution environments (TEEs) and confidential computing
A trusted execution environment, or TEE is designed to execute code in a protected environment isolated from external observation or tampering. This means sensitive computation runs in hardware-enforced isolation so that even if the surrounding system is compromised—such as the operating system, hypervisor, or cloud control plane—an attacker cannot read secrets in memory or modify the code while it runs. When properly configured with secure attestation and containing well-written code, TEEs provide strong cryptographic guarantees against software-based attacks, though they operate within defined threat models that may not cover all physical or side-channel attacks.
If I want to sign a transaction, for example, I can do it inside a TEE so memory and compute are protected. That’s the core value proposition in one sentence: TEEs can reduce the risk that privileged infrastructure compromise translates into key compromise or plaintext exposure.
The problem starts when teams treat that sentence as the end of the story.
Why “we use TEEs” became a security buzzword
Security technologies tend to follow a pattern: a real capability emerges, a few disciplined teams implement it correctly, then it becomes a label that gets repeated until it loses meaning. We’ve seen this with HSMs (“keys are safe”), with MPC (“custody is solved”), and now with TEEs (“confidential computing means secure”).
The label “TEE” is not the control. The control is the combination of a specific TEE model, a specific trust boundary, and an operational discipline around how code is built, measured, attested, deployed, and allowed to communicate. Without that, TEEs can become security theater: a hardened room with a compromised occupant, or a fortress that constantly opens its doors.
Threat modeling TEEs beyond cloud infrastructure
A useful way to think about TEEs is to ask what class of attacker they’re meant to constrain.
TEEs are strongest when your risk includes a privileged adversary at the infrastructure layer: a compromised host kernel, a malicious hypervisor, a cloud operator insider, or an attacker who gains administrative control over the machine running your workload. In those scenarios, TEEs can reduce the blast radius of “root” by making secrets harder to extract from memory and by protecting the integrity of the sensitive computation.
But TEEs do not magically convert an unsafe application into a safe one. They do not eliminate data exfiltration paths. They do not remove the need for strong identity, authorization, auditing, and key management. They shift the security conversation from “who controls the host” to “what is inside the trust boundary, and how do we control every boundary crossing?”
That shift is where many implementations go wrong.
TEEs don’t protect against malicious code inside the TEE
This is the first non-negotiable point: a TEE can protect code from external factors, but it doesn’t necessarily protect you from already malicious code inside your TEE.
If an attacker can influence what you load into the TEE—through a dependency compromise, build pipeline compromise, signed-but-malicious updates, or poisoned artifacts—then you’ve built a very secure execution chamber for the attacker’s logic. The secrets are still protected from the outside, but they are not protected from the code you chose to run.
This is why TEEs don’t replace application security or supply chain security. They raise the importance of it. When teams say “we run it in a TEE” as a reason to relax other controls, they often create a more brittle system: one that is harder to observe and harder to debug, while still being vulnerable to the same upstream compromises that affect non-TEE deployments.
The data egress and outbound communication problem in TEEs
The second non-negotiable point is about boundary crossings.
A TEE can be a secure fortress, but if the application inside the fortress is constantly communicating out, you have to threat model that communication as your primary attack surface. The risk doesn’t disappear; it concentrates in the interfaces.
In practice, a large portion of real-world compromise happens through the “normal” mechanisms that applications use to do their work:
- Telemetry and logging that unintentionally leaks sensitive context
- APIs that accept attacker-controlled inputs and produce sensitive outputs
- Tool calls and plugin-like integrations that expand what the workload can reach
- Authorization mistakes that let the wrong caller request privileged actions
- Data pipelines that move sensitive material across trust zones without strong policy enforcement
A TEE that repeatedly opens its doors can still be a high-value exfiltration engine. In some systems, TEEs make this worse by providing a comforting narrative that discourages teams from minimizing outbound channels or enforcing strict egress controls. Confidential compute without strict communication constraints is often just confidential compromise.
TEE standards and models: Intel SGX, Intel TDX, AMD SEV and more
Another reason “TEE” becomes misleading is that there isn’t a single standard called TEE in the way people casually imply. There are multiple implementation families that operate differently and offer different tradeoffs. The details matter because they determine what is actually protected, what is measured, and what is trusted.
You’ll often hear terms like Intel SGX, Intel TDX, AMD SEV, confidential VMs (CVMs), enclaves, and secure enclaves used interchangeably. But they aren’t interchangeable.
The point isn’t that one acronym is always “best.” The point is that you can’t evaluate a security claim without knowing which model is being used and which features are actually enabled. “We use TEEs” is incomplete. It should immediately trigger: which TEE, which guarantees, what trust assumptions, and what operational enforcement?
Remote attestation and trustworthy execution guarantees
Remote attestation is one of the most frequently cited TEE capabilities, and also one of the most frequently under-implemented in practice.
At a high level, attestation is about proof: proof that a specific workload is running inside a genuine TEE environment, with a particular measured identity, under particular conditions. It’s the mechanism that helps you avoid blindly trusting a runtime you don’t control.
But supporting attestation is not the same as operationalizing it. What matters is whether your systems actually enforce decisions based on attestation. If attestation fails, what happens? Is the workload prevented from accessing keys? Is a transaction blocked? Is the request denied? Is the deployment halted? Are alerts actionable?
If attestation exists only as a diagram, it becomes another checkbox. If it becomes an enforcement gate, it can be meaningful.
Confidential virtual machines (CVMs) versus enclave-based TEEs
This is where architecture choices become opinionated, because the security tradeoffs are real.
One broad implementation model is running a whole operating system inside a TEE-like boundary, commonly framed as confidential virtual machines. CVMs can be attractive because they feel operationally familiar. You can “lift and shift” a workload with fewer changes. You get a big protected envelope around the VM.
The downside is also straightforward: protecting more code means you’re trusting more code. If you put an entire OS and a complex application stack inside the boundary, the trusted computing base expands. Complexity rises. The number of ways the workload can be influenced rises. Debugging and monitoring can become harder, not easier. Your “secure enclave” becomes a large, moving target.
The other model is isolating only specific functions—tiny, sensitive tasks—inside a narrower trusted environment. In many cases, specialized solutions that minimize the protected surface are safer because they reduce the attack surface to the smallest necessary unit. Protect the signing operation. Protect the key derivation. Protect the minimal cryptographic function. Avoid turning your entire workload into a “black box” you now have to trust implicitly.
You can see this philosophy reflected in designs like AWS Nitro Enclaves or hardware-backed secure enclave patterns such as Apple’s Secure Enclave: keep the sensitive boundary small and purpose-built. The more narrowly you define the trust boundary, the easier it is to reason about, test, and defend.
How to evaluate TEEs in a security review: the right questions to ask
If you’re assessing a vendor or an internal architecture that claims TEE-based security, the most productive move is to force precision. You’re not trying to be adversarial; you’re trying to make the trust model explicit.
Start by clarifying the threat the TEE is meant to mitigate. Is the goal to reduce the risk of host compromise? To protect keys from privileged admin access? To keep model weights confidential? To prevent cross-tenant leakage? Different goals lead to different designs.
Then clarify what is inside the trust boundary. Is it a narrow signing function, or an entire workload? How much code is now treated as trusted? How is that code produced, reviewed, and updated?
Then look at enforcement. Is remote attestation used as a gate, or as a story? What happens when it fails? What can the workload do without a passing attestation result?
Finally, focus on outbound channels. What does the application inside the TEE communicate with? What data can it send out? Under what policy? How is exfiltration risk constrained? A TEE that can talk freely to the world is often a more efficient attacker tool than a non-TEE workload, because it’s easier to rationalize its behavior as “secure by design.”
The bottom line on TEEs, confidential computing, and security posture
TEEs are not bad. They are useful technology for reducing certain classes of risk, especially when you’re defending against infrastructure-layer compromise and you need to protect sensitive computation or secrets in use. But TEEs are not a binary signal of safety, and treating them as a checkbox is how teams end up with false assurances.
A TEE can protect execution from outside interference, but it can’t vouch for the integrity of the code you choose to run. It can’t wish away data egress and outbound communication risk. And it doesn’t substitute for the fundamentals: application security, supply chain controls, and enforceable policy. What it does is reshape your threat model. If you don’t model that shift explicitly, you’ll end up building the wrong system, supported by a very convincing security narrative.
Stop asking, “Do we have a TEE?” Start asking, “What’s inside the trust boundary, and what can still go wrong?”
overview
