Tying attestation to a TLS connection, so the client knows that the machine it verified is the machine on the other end.
Attestation alone proves that some machine is in a good state. It does not prove that your connection ends at that machine. Attested TLS is the name for designs that try to close this gap.
Where the evidence travels decides whether it works. Evidence can be placed in the certificate, before the handshake. It can be exchanged inside the handshake. Or it can be exchanged after the handshake, over the finished connection.
Formal analysis has found diversion attacks on a certificate-based design, and relay attacks on the handshake-based designs it examined. In both cases a client can accept genuine evidence from a machine it is not talking to.
If your product carries attestation in the certificate or inside the handshake, treat its proof of identity as open to these attacks until it has been reviewed. The findings are in the vulnerability tracker.
Example. A client checks a quote during the TLS handshake and sends its data. An attacker in the middle passed on evidence from a genuine machine. The quote was real, and the client is talking to something else.
Attested AIAttested cloud workloads
Working on re-attestation for your product? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.