Azure Attestation explained: cryptographic proof for confidential computing

Beyond Encryption · Part 4 of 7

Understanding how Azure Attestation turns platform claims into verifiable proof.

TL;DR

Microsoft Azure Attestation validates evidence produced by a Trusted Execution Environment, evaluates that evidence against policy and returns a signed JSON Web Token.

For a confidential VM, the evidence can prove properties of the hardware backed environment, measured launch state and guest security configuration. Application assurance requires a trusted measurement or enforcement mechanism that binds the approved application to the evidence. A public key alone binds secret delivery to the attested environment, not to a particular binary.

The token does not make a workload trustworthy by itself. The relying party must verify its signature, issuer, validity period, freshness data, policy hash, platform claims and any application specific claims required by the use case.

The strongest pattern binds a fresh nonce and an ephemeral public key into hardware backed evidence. A secret can then be encrypted for that key only after every required attestation check succeeds.

In short:

No valid evidence means no trusted token. No trusted token means no secret or key release.

Table of contents

1. What is Azure Attestation?
2. Environment proof versus application proof
3. Identity is not runtime proof
4. Evidence, reports and measurements
5. How remote attestation works
6. Why a nonce matters
7. How endorsement chains prove hardware identity
8. How attestation policy works
9. How to verify an Azure VM guest attestation token
10. Common attacks and implementation mistakes
11. What attestation does not solve
12. From runtime proof to Secure Key Release
13. Key takeaways
14. Continue the series

What is Azure Attestation?

Microsoft Azure Attestation, often shortened to MAA, is a service for validating evidence from trusted computing environments.

It supports evidence from technologies including Trusted Platform Modules, Intel SGX enclaves, Virtualisation Based Security environments and Azure confidential VMs. The service converts evidence into claims, evaluates those claims against policy and produces a signed attestation token when the checks succeed. Microsoft Azure Attestation overview.

A confidential VM can use guest attestation to prove that it is running on genuine hardware backed confidential computing technology. Depending on the protocol and platform, the resulting claims can also describe Secure Boot, virtual TPM availability, debug state, measured launch state and security version information. Microsoft guest attestation documentation.

Figure 1. Official Microsoft guest attestation workflow. Source: MicrosoftDocs Azure documentation, licensed under CC BY 4.0. Downloaded unchanged. This figure is documentation material, not an Interian test result.

Azure Attestation does not decide what your organisation should trust. It validates evidence, applies a configured policy and issues claims. Your relying party still makes the final access decision.

Environment proof versus application proof

This distinction deserves its own section because it is easy to overstate what guest attestation proves.

Platform or guest attestation can show that a VM is running on genuine AMD SEV-SNP or Intel TDX hardware, that expected platform settings are active and that measured boot information meets policy. The exact scope depends on the attestation type and protocol.

It does not automatically identify every user space process inside the VM.

A launch measurement may cover firmware, the initial guest image or another defined launch state. It should not be described as proof of an arbitrary application unless the application and attestation design make that relationship explicit.

Application assurance normally requires an additional binding. Examples include:

1. A trusted loader or measured component verifies the application binary or signed manifest and binds its digest to the attestation evidence.
2. The workload generates an ephemeral key inside the protected environment and binds the public key to the evidence for secure secret delivery.
3. A confidential container policy commits to approved container images, commands, mounts and environment rules.
4. The relying party checks the application digest, signing identity or policy hash against an approved reference value.

Hardware binding proves that runtime data came from the attested environment. It does not independently prove that a self-reported application digest is truthful. The verifier must also trust the code or enforcement mechanism that produced that digest. In a confidential VM, privileged guest software remains inside the trust boundary.

Without that binding and verification, the correct conclusion is:

The environment was attested. The individual application was not independently identified by that evidence.

This is not a weakness in attestation. It is a requirement to define the evidence scope accurately.

Identity is not runtime proof

Most access decisions begin with identity.

A managed identity can identify an Azure resource or workload. Microsoft Entra ID can authenticate that identity. Azure role based access control can determine which operations it may perform.

These controls answer an important question:

Who is requesting access?

They do not fully answer a second question:

What protected environment is using that identity now?

A valid workload identity could be used from an unexpected image, a modified environment or a host without the required confidential computing protection. Attestation adds evidence about the runtime platform and measured state.

Identity and attestation therefore complement each other:

Trust signal	Question answered
User identity	Which person is requesting access?
Workload identity	Which application or service principal is requesting access?
Device trust	Is the endpoint managed and compliant?
Platform attestation	What hardware and measured environment is running?
Application binding	Was the approved application measured or enforced by trusted code and bound to evidence?
Authorisation policy	Is this combined request allowed?

A high sensitivity architecture may require all of these signals before a key is released.

Figure 2. Original Interian infographic based on the documented Azure Attestation flow. This is not an Azure product screenshot.

Evidence, reports and measurements

Attestation terminology can be confusing. Three concepts are especially important.

Measurement

A measurement is usually a cryptographic hash of code, configuration or platform state.

Even a small change in the measured input should produce a different hash. This makes a measurement useful for comparing a running environment with an approved reference value.

A measurement alone is not proof. Anyone can place a hash in a JSON document. The value becomes useful when trusted hardware includes it in signed evidence and the verifier understands exactly what was measured.

Quote or attestation report

A quote or attestation report is a structure produced and signed by trusted hardware or by a hardware rooted attestation mechanism.

Depending on the platform, it can contain:

1. A measured launch state
2. Hardware and firmware security versions
3. Debug and migration settings
4. Information supplied by the guest or workload
5. A report identifier
6. Processor security state

With AMD SEV-SNP, the AMD Secure Processor signs the attestation report using a hardware endorsement key such as a VCEK or VLEK. The report structure and signing rules are defined in the AMD SEV-SNP Firmware ABI Specification.

Evidence

Evidence is the complete package needed for verification.

It can include the hardware report, certificate chain, endorsements, revocation information, runtime data and initialisation data.

This distinction is important. A launch measurement might match an approved value while the certificate chain is invalid or the firmware version is no longer accepted. Trust must cover the complete evidence package.

How remote attestation works

A strong attestation flow involves four actors:

1. The workload inside the Trusted Execution Environment
2. The hardware that creates the report
3. Microsoft Azure Attestation
4. The relying party that controls access to a secret or dataset

1. Challenge. The relying party sends a fresh nonce and request context to the workload.
2. Bind. The workload creates an ephemeral key and binds the public key, nonce and any trusted application measurement into runtime data.
3. Report. The hardware produces a signed report covering the bound data and platform state.
4. Attest. The workload submits the report, runtime data and endorsements to Azure Attestation.
5. Evaluate. Azure Attestation validates the evidence, applies policy and returns a signed JWT when the checks succeed.
6. Verify. The relying party checks the signature, issuer, freshness, approved policy and required platform and application claims.
7. Release. Only after verification does the relying party encrypt the secret for the public key bound to the accepted evidence.

The final data path is important. Azure Attestation returns the signed token. It does not receive the application secret in this design. After verification, the relying party sends the encrypted secret directly to the workload or uses the verified token with a separate key release service.

The process can create three useful cryptographic bindings.

First, the hardware report binds measurements and security state to the trusted processor.

Second, a nonce can bind the evidence to the current request.

Third, an ephemeral public key can be bound to the evidence. The relying party can use that key to send a secret that only the intended protected workload instance should be able to decrypt.

Figure 3. Official compact success and failure capture from the Azure Samples Visual Attestation Demo v2, licensed under the repository MIT licence. The left side shows successful attestation on a confidential ACI SKU. The right side shows the same sample failing on a standard SKU without the required SEV-SNP interface. This is a Microsoft Azure Samples capture, not an Interian test or benchmark.

The comparison is useful because a success only result is easy to imitate. The failure on a non confidential environment demonstrates that the sample depends on the expected hardware path.

Why a nonce matters

A valid report can still be old.

An attacker might record a successful attestation response and replay it after the workload or platform has changed. This is why the relying party should create a fresh, unpredictable nonce for each sensitive session.

The nonce must be cryptographically bound through the attestation protocol. Merely copying it into an unrelated JSON field is not enough.

The Azure Attestation SEV-SNP API supports runtime data. MAA verifies the supplied runtime data against the hash binding in the hardware report; the documented runtime-data convention uses SHA-256 in the lower 32 bytes of the report data field. Azure Attestation REST API.

Runtime data could represent a canonical structure containing:

nonce + ephemeral public key + application or configuration digest

The workload hashes that structure and requests a hardware report containing the hash. MAA verifies the binding. The relying party then verifies that the returned claims represent its original challenge, expected key and any required application identity.

The REST API also accepts a separate nonce parameter that is copied into the token. That echo alone does not prove that the hardware report was freshly generated. Bind the challenge to the hardware evidence and verify that binding. Microsoft attestation claim sets.

The exact freshness field and binding differ between attestation protocols. For example, TPM based flows may expose relying party data separately. A verifier must follow the semantics of the actual attestation profile rather than assume that any field called nonce is automatically protected by hardware.

Token time claims also matter. The relying party should validate iat, nbf and exp, maintain reliable time and enforce a short local acceptance window. Microsoft currently documents an eight-hour service token lifetime, which is longer than many sensitive sessions should accept. The verifier can reject tokens older than its own maximum age without changing their signed expiry. Microsoft Azure Attestation FAQ.

Attestation is a point in time decision. Long lived token caching weakens the value of the evidence.

How endorsement chains prove hardware identity

A digital signature is only useful when the verifier trusts the signing key.

Attestation therefore relies on endorsement material. This can include manufacturer certificates, certificate chains, revocation information and Trusted Computing Base metadata.

For AMD SEV-SNP, a VCEK can be associated with a particular processor and security version. A valid signature alone does not prove that the firmware is sufficiently current. The verifier must also assess security version information and applicable revocation status.

Azure Attestation performs much of this work. It validates the submitted evidence against the relevant platform baseline and converts verified information into claims.

This reduces the amount of hardware specific logic required in the relying party. It does not remove the need to trust and correctly configure the Azure Attestation provider.

The relying party must know:

1. Which provider is trusted
2. Which signing keys belong to that provider
3. Which policy is expected
4. Which claims must be present
5. Which claim values are acceptable
6. Which evidence scope is sufficient for the requested action

How attestation policy works

Evidence describes a measured environment. Policy determines whether that environment should be accepted.

Depending on the attestation profile, Azure Attestation policy and the relying party’s acceptance policy can require conditions such as:

1. The expected TEE type
2. An approved launch measurement
3. Debug mode disabled
4. Acceptable firmware and TCB versions
5. Secure Boot enabled
6. An approved application, container policy or configuration digest when application assurance is required

Azure Attestation separates policy into authorisation rules and issuance rules.

Authorisation rules decide whether the evidence is accepted. Issuance rules determine which claims appear in the final token. If the authorisation checks fail, Azure Attestation should not issue a usable token. Microsoft guide to authoring an attestation policy.

Policy management is therefore a critical security function.

A perfectly protected TEE provides little assurance if the policy accepts every measurement. Sensitive environments should protect policy changes with limited administrative access, approval workflows, logging and policy signing.

The relying party can also compare the x-ms-policy-hash claim with a known approved value. This confirms which policy was used to evaluate the evidence.

How to verify an Azure VM guest attestation token

Azure Attestation returns a signed JSON Web Token after successful validation.

The following shortened example reflects the nested structure documented for Azure confidential VM guest attestation. It is a reading aid only. Values are fictional, fields are omitted and it is not copy and paste production code. Other attestation profiles, including direct SEV-SNP container attestation, can have a different token shape.

{
  "iss": "https://<provider>.<region>.attest.azure.net",
  "iat": 1787000000,
  "nbf": 1787000000,
  "exp": 1787028800,
  "jti": "<unique-token-id>",
  "x-ms-attestation-type": "azurevm",
  "x-ms-azurevm-vmid": "<vm-id>",
  "x-ms-policy-hash": "<approved-policy-hash>",
  "x-ms-isolation-tee": {
    "x-ms-attestation-type": "sevsnpvm",
    "x-ms-compliance-status": "azure-compliant-cvm",
    "x-ms-sevsnpvm-is-debuggable": false,
    "x-ms-sevsnpvm-launchmeasurement": "<launch-measurement>",
    "x-ms-sevsnpvm-reportdata": "<hash-bound-runtime-data>",
    "x-ms-runtime": {
      "keys": [
        {
          "kid": "HCLAkPub",
          "kty": "RSA",
          "key_ops": ["encrypt"],
          "n": "<public-key-material>",
          "e": "AQAB"
        }
      ],
      "vm-configuration": {
        "secure-boot": true,
        "tpm-enabled": true,
        "vmUniqueId": "<value>"
      }
    }
  },
  "x-ms-runtime": {
    "keys": [
      {
        "kid": "TpmEphemeralEncryptionKey",
        "kty": "RSA",
        "key_ops": ["encrypt"],
        "n": "<public-key-material>",
        "e": "AQAB"
      }
    ]
  },
  "x-ms-ver": "1.0"
}

The nested x-ms-isolation-tee object describes the confidential isolation layer and contains the SEV-SNP and guest configuration claims. The outer token describes the Azure VM attestation result and can contain a separate runtime key used by the guest attestation protocol. Microsoft guest attestation token example.

A relying party should perform the following checks:

1. Confirm that the issuer is the configured Azure Attestation provider.
2. Obtain signing key metadata from the trusted provider endpoint.
3. Select the key matching the JWT header kid.
4. Verify the token signature with a maintained JWT library and an explicit allowlist of accepted signing algorithms.
5. Validate iat, nbf and exp with an appropriate clock skew policy.
6. Verify freshness according to the actual attestation profile and challenge binding.
7. Check both the outer attestation type and the nested confidential TEE claims.
8. Compare the policy hash with the approved policy.
9. Validate the required platform measurements and security settings.
10. If application assurance is required, validate the application identity, digest or container policy and the trusted mechanism that bound it to the evidence.
11. Confirm that the public key used for secret delivery is bound to the accepted evidence.

Microsoft exposes signing certificate information through the OpenID metadata endpoint of the attestation provider. Microsoft Azure Attestation FAQ.

Do not blindly trust a jku address supplied in an incoming token. Configure the expected issuer and metadata endpoint locally. Otherwise, an attacker could try to direct the verifier towards an untrusted signing key.

Common attacks and implementation mistakes

Risk	Weak implementation	Required control
Token replay	Accept an old valid token	Fresh challenge, short local acceptance window and verified binding
Environment mistaken for application proof	Assume a confidential VM proves every process inside it	Bind and verify application identity or measurement when required
Wrong workload	Check only the TEE type	Validate the required measurement, signing identity or policy digest
Key substitution	Accept a public key outside the evidence	Bind the public key through measured runtime data
Forged JWT	Decode without verifying	Verify signature, issuer and provider key
Policy downgrade	Trust any successful policy	Pin the approved policy hash and protect policy changes
Debug environment	Ignore debug claims	Reject environments with debugging enabled when policy requires it
Old firmware	Check only the hardware signature	Validate TCB status, versions and revocation information
Service outage	Continue without attestation	Fail closed and use controlled retry logic
Excessive caching	Reuse tokens for long periods	Enforce a short maximum token age and risk based reattestation

The most common conceptual mistake is checking only:

x-ms-attestation-type = sevsnpvm

That can show that a SEV-SNP attestation path was involved. It does not prove that the correct application, challenge, policy and public key were validated.

Test paths also require care. The Azure Attestation API can evaluate evidence against a draft policy, but a token created through that test flow must not be treated as a normal production token.

What attestation does not solve

Attestation answers a narrow but important question about a runtime environment. It does not prove that the application is free from vulnerabilities.

It does not automatically prevent:

1. Injection vulnerabilities
2. Broken authorisation inside the application
3. Malicious but approved releases
4. Unsafe output generated by the workload
5. Every processor side channel risk
6. Denial of service
7. Compromise of the relying party
8. Poor policy and key lifecycle management

A measured binary can match an approved release and still contain a critical vulnerability.

Reference values must therefore be revocable. When a release becomes untrusted, its application digest, launch measurement, signing identity or policy digest must be removed from the accepted set as appropriate. Future key release attempts should then fail.

From runtime proof to Secure Key Release

Attestation becomes valuable when it controls a real action.

A data provider can refuse to send personal data. An API can refuse to open a sensitive session. A key service can refuse to release decryption material.

Secure Key Release is one of the strongest applications.

A managed identity can first establish which workload identity is requesting the key. Attestation can then prove the relevant environment properties. When application assurance is required, the design also binds and verifies the application identity, measurement or configuration digest through a trusted measurement or enforcement mechanism. Secret delivery uses a public key bound to the accepted evidence.

A release policy combines those trust signals.

The result is simple:

No valid proof, no key. No key, no decrypted data.

Key takeaways

1. Azure Attestation provides cryptographic evidence about a runtime environment.
2. Platform and guest attestation do not automatically prove a specific application.
3. Application assurance requires a deliberate application identity or measurement binding and policy verification.
4. Identity and attestation answer different trust questions.
5. Measurements only become useful when their scope is understood and they are bound to signed evidence.
6. A fresh nonce helps prevent replay only when the protocol binds it to the evidence.
7. The relying party must verify the complete token and its trust context, not just one platform claim.
8. Policy quality is as important as hardware protection.
9. Attestation is a point in time decision, not continuous security monitoring.
10. The practical goal is an enforceable decision such as Secure Key Release.

Continue the series

Previous: Building a confidential workload on Azure