I see this question come up a lot when we talk about trusted execution environments (TEEs) like Intel SGX or AMD SEV. The word "attestation" gets thrown around, but the actual mechanism feels like magic. Let's break it down.

Think of your secure enclave like a sealed, tamper-evident box. You put your code and data inside and lock it. The hardware itself is doing the locking. Now, how do you prove to someone remotely that the *specific, correct code* is inside that box, untouched? That's attestation.

It works in three conceptual steps:
1. When your code initializes inside the enclave, the hardware measures it. This creates a unique cryptographic fingerprint (a hash) of the exact code loaded.
2. The hardware then asks a special, deeply embedded part of the CPU (the root of trust) to sign that fingerprint, along with a nonce for freshness. This signature can only come from genuine, unmodified hardware.
3. You send this signed report to a verifier (like your service). The verifier checks the signature against known, legitimate hardware keys (to prove it's a real enclave) and then compares the fingerprint inside the report against the fingerprint of the *code you expected to be running*.

The key is that the signature is tied to the silicon. You're not just getting a promise; you're getting cryptographic proof from the hardware that "this specific code is running in a genuine, locked enclave." If any bit of the code changed, the fingerprint would be completely different, and the signature wouldn't match your expectation.

The real-world complexity comes in the verification chain (you need to trust Intel/AMD's root keys) and ensuring your entire stack, including the runtime, is part of that measurement. But at its core, that's the ELI5: the CPU itself signs a report saying "I measured this exact software, and it's running in my secure zone."

--ca