Open Enclave SDK: writing code that runs inside a trusted execution environment

The host and enclave split, and what an enclave actually is

The Open Enclave SDK is a hardware-agnostic open source library for developing applications that use Hardware-based Trusted Execution Environments, also known as Enclaves.

Open Enclave, usually shortened to OE, is an SDK for building enclave applications in C and C++. The key structural idea is that an enclave application partitions itself into two components. There is an untrusted component, called the host, and a trusted component, called the enclave.

An enclave is defined as a protected memory region that provides confidentiality for data and code execution. It is an instance of a Trusted Execution Environment, which is usually secured by hardware, and the README gives Intel Software Guard Extensions as the example.

That definition is doing a lot of work, so it is worth reading closely. The protection is of memory and of execution, not of the whole process. The host runs outside the enclave and is, by construction, not trusted by the enclave's contents. Any design that puts a secret in the host and expects the enclave to keep it safe has misunderstood the model, and the partition is the design decision that forces you to get it right.

The SDK aims to generalize the development of enclave applications across TEEs from different hardware vendors, and the README says that as an open source project it also strives to provide a transparent solution that is agnostic to specific vendors, service providers and choice of operating systems. The current implementation provides support for Intel SGX, and preview support for OP-TEE OS on ARM TrustZone.

The project is MIT licensed, the default branch is master, and the last push was on 2026-10-13, with releases v0.19.19 from 2026-10-02, v0.19.18 from 2026-09-17 and v0.19.17 from 2026-08-07.

Simulation mode, and why it changes how you develop

The single most useful practical line in the README is in the contributing section: you do not necessarily need a hardware enclave to develop the OE SDK, because some tests and code paths can be executed in simulation mode for the purposes of testing on non-TEE-enabled hardware.

That is a significant property for an SDK in this space. The usual objection to confidential computing is that the development loop is slow and hardware-bound, because the machine you develop on does not have the silicon and the machine that runs the enclave is somewhere else. Simulation mode means the same code path, the same build and most of the same tests can run on a laptop.

What simulation mode does not give you is the hardware guarantee. An enclave in simulation is not protected, because there is no protected region. So it is a development and testing convenience, not a substitute, and the distinction matters when you write the threat model: the adversary model in simulation is not the adversary model in production.

The rest of the getting-started material points at a Getting Started Guide in the `docs/GettingStartedDocs` directory, and there is a separate community documentation set in `docs/Community` that the README describes as hosting information on where to get engaged with the project, whether you want to contribute code, add test cases, help improve the documentation or something else, including how to join meetings and who to contact.

That separation between technical documentation and community documentation is a small sign of a project that has been running for a while and has a community practice, not just a codebase.

The samples are the fastest way to read the API

The `samples/` directory is the most instructive part of the repository, and it is organised around the problems an enclave application actually has.

`helloworld/` is the starting point. `file-encryptor/` is the canonical example of a workload worth moving into an enclave, because the key never leaves the protected region. `data-sealing/` is the other canonical one, covering the pattern where the enclave encrypts data for storage and the ciphertext can only be unsealed on the same machine. `attested_tls/` and `attestation/` cover the remote attestation flow, and `host_verify/` is the counterpoint, the side that verifies what the enclave says about itself.

`apkman/` is an application-level example, and `switchless/` is the mechanism for switching the execution of ordinary code into an enclave without a separate process or a modified binary.

Then there are the ones about the mechanics of writing enclaves rather than about the application domain. `debugmalloc/` is a pluggable allocator for the enclave's memory, and `pluggable_allocator/` is the general version of the same idea. `log_callback/` shows how to get output out of an enclave, which is a real problem because the enclave has no console. `check_quote_provider.cmake` and `config.mk` are the build plumbing, and `test-samples.cmake` runs them.

The build instructions are split by platform too, with `BuildSamplesLinux.md` and `BuildSamplesWindows.md` and a `samples/CMakeLists.txt` at the top of the directory. That platform split is not incidental, because the host and the enclave are built as separate artefacts and the host is the part that differs most between operating systems.

Reading `file-encryptor` first gives you the shape of the SDK, and `host_verify` gives you the other half of it.

What the repository contains besides the SDK

The top level of the repository shows that this is a large, self-contained project rather than a small library.

The core directories are `enclave/` and `host/`, which are the two halves of the partition, plus `common/` for what both sides share, `include/` for the public headers, and `syscall/` for the system call interface between them. Then there is `libc/` and `libcxx/`, a C and a C++ standard library for the enclave side, because the enclave cannot call the host's libc directly, and `tools/` and `debugger/` for the development and debugging tooling.

The build system is CMake, with a `CMakeLists.txt` at the root, a `cmake/` directory, `CMakeSettings.json` for Visual Studio, `CMakeGraphVizOptions.cmake` for visualising the build graph, and a `.cmake-format.json` and `.clang-format` for the two formatting tools the project uses. There is a `pkgconfig/` directory, so the SDK installs a pkg-config file, and `prereqs/` and `3rdparty/` for the dependencies.

The `devex/` directory is a recent addition that the README does not explain, and it is a name that suggests developer experience tooling. `DOCKER_IMAGES.md` documents the container images, and there is a `.jenkins/` directory alongside `.github/` for the continuous integration, a `VERSION` file, a `TECHNICAL_CHARTER.md` and an `OWNERS` file.

A `THIRD_PARTY_NOTICES` file and a `SECURITY.md` complete the picture of a project that takes the governance side seriously, which for a security SDK is not optional.

How the project is tested, and on which hardware

The integration partners section at the top of the README lists the platforms the continuous integration runs on, and the split is informative.

There is a provider agnostic Linux regression job, which is the job that checks the SDK does not depend on one cloud provider's instance types. There are Azure Linux and Azure Windows jobs, which is the evidence that the host side works on both operating systems, since the host is the part that differs. And there is a nightly libcxx job, which runs the C++ standard library tests.

The presence of an OpenSSF Best Practices badge and a bors badge says something about the process. bors is a merge bot, and its badge here means merges go through a continuous integration run rather than a reviewer's laptop. The OpenSSF badge is a third-party assessment of the project's practices, and for an SDK whose entire purpose is to run untrusted-adjacent code, that assessment is the kind of thing a security reviewer will look for.

The feedback routes are also spelled out, and the separation between them matters. General questions, announcements and discussion go to a mailing list. To report a problem or suggest a feature, you file a GitHub issue. And to report a security issue you follow the process in `SECURITY.md`, which is the standard way to keep a vulnerability report out of the public issue tracker.

The project is not archived, and the release history shows a steady monthly-ish cadence across the 0.19 series, with three releases in the last two months.

Where the Open Enclave SDK is the wrong choice

The first wrong case is a team that has not decided whether it needs a TEE. The SDK is a way to build an enclave application, and adopting it means partitioning your code into trusted and untrusted halves and reasoning about what happens when the host is compromised. That is a design project before it is an integration project, and the SDK does not make the design for you.

The second wrong case is a team that wants ARM TrustZone support today. The README describes OP-TEE on ARM TrustZone as preview support, and preview means the interface may still change. A product shipping on a phone, where TrustZone is the relevant hardware, is betting on a preview.

The third is a project that assumes the SDK is a library and nothing else. Building an enclave application means a build pipeline that produces two artefacts, an enclave that is signed or measured, and a host that loads it. The `prereqs/`, `3rdparty/`, `DOCKER_IMAGES.md` and `tools/` parts of the tree are the operational surface, and that is more than a dependency.

The fourth is a workload where the protection boundary does not match the data. An enclave protects a memory region on one machine. If the sensitive data has to be processed on a fleet of machines, the enclave does not help, and the SDK's abstractions will not make it help.

The fifth is a team that needs a hosted confidential computing service rather than the primitives. The Open Enclave SDK is the building block; it is not the managed offering.

What the SDK gives you is the part that is genuinely hard to get right twice, which is the interface between a trusted and an untrusted component, with a standard library for the enclave side, a debugger, and a simulation mode so the whole thing can be developed without the hardware in the room.

Editorial conclusion

Open Enclave SDK suits a team that has decided to put part of its workload inside a trusted execution environment and wants one API across Intel SGX and, eventually, ARM TrustZone, rather than a vendor SDK per silicon. It does not suit a team looking for a managed confidential computing service, since the SDK is a set of libraries and build tooling, and it does not suit a project that cannot make its threat model explicit, because the host and enclave split forces you to decide what you trust. Before adopting it, read the Getting Started Guide and the `samples/` directory, and confirm you can run the build in simulation mode, since the SDK explicitly says you do not need hardware to develop and that some tests and code paths execute in simulation mode.

Frequently asked questions

Official sources

1. License: MIT
2. openenclave/openenclave on GitHub
3. Project website
4. README
5. Releases