Understanding attested TLS in OPAQUE¶

OPAQUE uses attested Transport Layer Security (aTLS) to protect service-to-service communication and to ensure that sensitive requests and data are handled only by workloads that can prove their identity and runtime integrity. aTLS pairs standard TLS encryption with remote attestation so peers can verify “who am I talking to, and is it running where it’s intended to run?”—not just “does it hold the right key?”

This document provides an overview of aTLS for security engineers, platform owners, architects, and compliance stakeholders.

Why aTLS matters¶

In many enterprise systems, TLS is treated as sufficient for service-to-service security. TLS is necessary—it encrypts traffic and authenticates endpoints—but a standard TLS certificate does not tell you what software is running at the other end, or whether it’s running in a verified, trusted runtime.

A standard TLS certificate proves control of a key and helps authenticate an endpoint, but it does not prove what software is running on the other end or whether it’s running in an approved environment. In OPAQUE, trust decisions often depend on the identity and integrity of the workload—not just the presence of a valid certificate. In that model:

Encryption in transit is not enough if traffic can be redirected to an untrusted workload that still presents a valid certificate.
Workload identity matters, not just server identity. The receiving endpoint must be the expected workload, not merely “a host with a key.”
Runtime integrity matters, especially for the components responsible for handling sensitive data, enforcing policy, or processing workloads under confidential computing guarantees.

aTLS addresses those gaps by making verification of the peer’s runtime identity part of establishing trust.

How aTLS works¶

At its core, aTLS extends a standard TLS handshake with a verification step that proves what software is running on the other end and whether it is running in an approved environment. The process works as follows:

Two services establish a standard TLS session. They first create an encrypted channel using TLS 1.3. This ensures confidentiality in transit and provides basic endpoint authentication.
Each service presents attestation evidence about itself. Once the TLS tunnel is in place, each side sends cryptographic evidence describing the sending service’s execution environment and workload identity. This evidence includes hardware-rooted measurements and signed claims about what is running (see Attestation reports for details).
Each service verifies the other before proceeding. Depending on policy, the peer is verified against requirements such as runtime environment, approved workload identity, or expected measurement values. If verification fails, the connection is rejected.
Each service binds that verification to the live TLS session. aTLS cryptographically ties the attestation evidence to the specific TLS connection (via the TLS channel binding mechanism). This prevents an attacker from replaying a valid attestation report in another connection to impersonate a trusted component.

In practice, attestation checks fall into two categories:

Environment and identity verification: Ensures the peer is running the expected workload in the expected environment—for example, inside a TEE when required, with measurements that match an approved build.
Authenticity and freshness: Ensures the evidence chains to a trusted attestation authority, has not been tampered with, and is current and specific to the connection being established.

How aTLS is integrated with OPAQUE¶

OPAQUE uses aTLS as a foundational control for internal service communication and authentication, particularly where sensitive inputs, policy decisions, encryption contexts, or workload execution requests are involved.

From a conceptual standpoint, there are three common places aTLS shows up in OPAQUE deployments (including interactions with control-plane key management for sensitive data access):

Within the customer-hosted environment (client and data plane). Core services authenticate and verify each other before exchanging sensitive traffic. This is especially important when components handle sensitive data flows, workflow execution, or policy-enforced interfaces.
Between customer-hosted services and control plane key management. OPAQUE’s key management services (KMS) live in the control plane. When client plane services request keys, they authenticate in the context of the user. When data plane workload services request keys, they authenticate using workload identity verified via aTLS. This helps ensure keys are released only to the intended, verified components.
Between the customer-hosted environment and OPAQUE-hosted control plane services. OPAQUE uses private connectivity and authenticated channels for control plane integrations. Where workload identity must be verified (for example, when sensitive operations depend on verified components), aTLS adds an additional verification layer on top of encrypted transport.

A key accuracy point for reviewers:

aTLS verifies attestable workloads. The verified endpoint must be able to present attestation evidence, which can provide hardware-backed assurance when it runs in a TEE-backed environment. The verifier (that is, the service performing the verification) does not need to run in a TEE.
Not every Azure-native dependency is itself a TEE workload. Some supporting services sit outside TEEs, but can still be accessed over encrypted channels and through policy-controlled interfaces.

In short, aTLS is used to ensure sensitive traffic is exchanged only with verified workloads, especially the components that define the confidential boundary. Supporting managed services, however, are not necessarily hardware-attested workloads.

Certificate management and trust anchors¶

aTLS relies on certificates (to establish TLS) and on trust anchors (to validate attestation and identity), and it’s useful to distinguish these:

TLS certificates establish an encrypted channel and authenticate the peer’s certificate identity (i.e., that the peer controls the private key for a certificate that chains to a trusted CA). On their own, certificates do not prove what software is running.
aTLS adds workload verification by validating attestation evidence against OPAQUE policy and trust anchors, so the peer can prove it is the expected workload (and, when applicable, running in an approved attested environment).
Attestation trust anchors are used to validate runtime identity claims (for example, that a workload is the expected one running in an approved execution environment).

OPAQUE’s model is “verify before trust,” which typically implies:

Services are provisioned to present certificates for TLS and to validate peer certificates.
Services are also provisioned to request and validate attestation evidence according to OPAQUE policy (for example, expected workload identities and allowed execution environments).
Verification can be enforced by components on the request path (for example, service mesh sidecars/proxies and policy enforcement points), so the check is applied consistently and does not depend on each application team implementing it correctly.

In practice, reviewers usually want to confirm three things:

Trust is anchored. There is an explicit set of trusted roots (PKI roots for certificates, and attestation trust anchors for evidence).
Identity is workload-specific. Connections are accepted only when the peer proves it is the expected OPAQUE component in the required execution environment—not merely “some service with a valid certificate.”
Verification is enforceable and observable. Verification succeeds or fails deterministically on sensitive paths, and the result produces observable signals (e.g., connection acceptance/rejection and audit/log events).

What you can verify¶

Security and compliance reviewers usually want two things: what is enforced and where they can see evidence of it. In OPAQUE, the most useful verification checks are:

Sensitive requests are accepted only after verification succeeds. For traffic OPAQUE treats as sensitive, aTLS verification is enforced. If verification cannot be completed or does not succeed, the connection is rejected.
Workloads identify as the expected OPAQUE components. Verified services correspond to known OPAQUE service identities (and, where applicable, expected measurements tied to an attested runtime).
Required execution environments can be confirmed (when applicable). For components that must run inside TEEs (for example, workloads forming part of the confidential boundary), attestation provides evidence about that runtime.
Verification outcomes are visible in OPAQUE. You can review verification status and related signals in the OPAQUE Trust dashboard (and export a report where available). For deeper troubleshooting, audit logs can provide details on verification failures and rejected connections.

For more detail on what OPAQUE reports (and where to find it), see Attestation reports.

Summary¶

aTLS strengthens service-to-service trust in OPAQUE by combining standard TLS encryption with attestation-based verification where required. It helps ensure sensitive requests are accepted only by the intended OPAQUE components—and, when components run in attested environments, it can provide hardware-backed evidence about what is running and where.