Azure Attestation

About Azure Attestation

Azure Attestation is a managed Microsoft Azure service for remotely verifying evidence from trusted platforms and trusted execution environments before another application decides whether to trust them. The service receives evidence from a compute environment, converts and validates that evidence as claims, evaluates the claims against an attestation policy, and returns a signed attestation token. It is aimed at confidential computing, TPM-backed platform validation, Trusted Launch, enclave scenarios, and other designs where access to data, keys, or sensitive operations depends on cryptographic proof of platform or workload state rather than identity alone.

What does Azure Attestation verify?

Microsoft currently documents Azure Attestation for TPM-based platform attestation and trusted execution environment scenarios including Intel SGX and virtualization-based security enclaves. The current overview also documents platform and guest attestation for AMD SEV-SNP based confidential virtual machines. The evidence and resulting claims differ by attestation type, but the service pattern is consistent: evidence is validated, policy is evaluated, and cryptographic claims are issued to a relying party.

For confidential computing designs, those claims can become part of a decision to release secrets, encryption material, or protected data only to an expected environment. Attestation should therefore be treated as one trust input in a wider architecture rather than as a replacement for identity, authorization, key management, monitoring, or vulnerability management.

What is the current SGX and DCAP requirement?

Microsoft's Azure Attestation overview was updated on June 29, 2026 and states that Intel Xeon Scalable processors use ECDSA-based attestation for SGX enclaves. For Intel Xeon Scalable processor-based server platforms, Microsoft says users are expected to install Azure DCAP version 1.10.0 or later when performing attestation through Azure Attestation.

This is an important deployment requirement for teams using SGX because an otherwise correct attestation design can fail if the supporting DCAP components are below the documented requirement. Buyers should verify the processor platform, SGX attestation model, DCAP version, and application integration during planning instead of assuming all enclave hosts use the same attestation path.

How do attestation providers and policies work?

An attestation provider is an Azure resource that exposes an attestation endpoint and policy configuration. Microsoft documents provider creation and management through Azure resource management tooling. Applications submit evidence to the appropriate attestation flow and receive a token when the evidence and policy requirements are satisfied.

Custom policy is useful when a security team needs to restrict token issuance according to measured or derived claims. Microsoft supports policy workflows that can be unsigned or, where configured, signed. Signed-policy scenarios let the provider validate policy updates against configured signer certificates. This separates the rules defining a trusted environment from the relying application's business logic and gives teams a controlled place to govern trust criteria.

How should relying parties validate Azure Attestation tokens?

A relying party should validate the token rather than trusting it only because it came from an Azure endpoint. Microsoft states that Azure Attestation signs the attestation token and exposes the signing certificates through an OpenID metadata endpoint. The relying party can retrieve those certificates and use them to verify the token signature before using its claims.

For higher-assurance confidential computing designs, teams should also understand which measurements and trust anchors their workflow depends on and how those values are rotated. Attestation proves properties represented by the submitted evidence and evaluated policy. It does not prove that the application has no vulnerabilities or that every service around the attested environment is trustworthy.

How can a relying party verify the Azure Attestation service itself?

Microsoft's June 2026 trust guidance goes beyond checking the workload token. Azure Attestation performs critical operations such as quote validation, policy evaluation, token generation, and token signing inside AMD SEV-SNP based confidential containers so Microsoft operations are kept outside that trusted computing base.

A relying party can validate the SEV-SNP report carried with Azure Attestation's token-signing certificate, verify that the public key used to sign the token is bound to that report, and compare Azure Attestation code measurements with values supplied by Microsoft. For SEV-SNP, Microsoft specifically says HOST_DATA should be validated. Microsoft also integrates Azure Attestation with Microsoft Signing Transparency, which records code signatures in a tamper-resistant ledger and provides cryptographically verifiable SCITT-compliant receipts for build provenance.

What should teams know about attestation measurement rotation?

Trust measurements are not permanent constants. Microsoft states that values identifying valid Azure Attestation instances can change when code-signing certificates rotate or security updates require new policy versions. For a planned rotation, Microsoft gives consumers a two-month grace period, begins using the new values after that period, and stops using the old values three months after the notification date.

For unplanned rotations, including security-driven changes, Microsoft documents a one-month grace period. Teams that pin Azure Attestation measurements or related trust values should therefore treat rotation handling as an operational requirement. Hard-coding one measurement forever can turn a normal service update into an outage, so validation logic should support controlled trust-value updates and monitoring.

What security and network controls are available?

Azure Attestation can be used with Microsoft Entra ID and Azure role-based access control for supported management and data-plane scenarios. Managed identities can reduce the need to embed credentials in application code. Microsoft also documents Private Link support for deployments that should keep service traffic on private connectivity, including configurations where public network access is disabled.

Operational logging should be part of the design when attestation affects access to keys, data, or privileged actions. Azure diagnostic settings can send supported logs to Azure monitoring destinations. Security teams should monitor failed attestation requests, policy changes, and related operational events so they can investigate why an environment was trusted or rejected.

How does availability and disaster recovery work?

Microsoft's current overview documents business continuity and disaster recovery across paired Azure Attestation regional clusters. If the primary region has a significant availability problem, Azure Traffic Manager can direct the endpoint to the paired region. Microsoft states that customers do not need to perform an extra recovery step for this failover.

There are still important limitations. Existing connections can fail during the event, control-plane operations are blocked while the primary region is unavailable, and customers cannot create new attestation providers in that primary region during the outage. Data-plane operations, including attestation calls and policy configuration, can be served from the secondary region using the original primary-region URI. Applications that depend on attestation should therefore implement appropriate retry and failure behavior.

How much does Azure Attestation cost?

Pricing was checked on August 31, 2026. Microsoft's current Azure Attestation pricing page states that Azure Attestation is a free service and is available at no additional service charge. Microsoft does not list a per-request, per-provider, or monthly service fee for Azure Attestation itself.

The wider architecture can still create Azure charges. Confidential virtual machines, Key Vault or Managed HSM, Private Link related networking, logging, storage, monitoring, and other Azure resources used around an attestation workflow can each have their own pricing. Buyers should separate the price of the attestation service from the cost of the compute, networking, key management, and observability components that depend on it.

What are the main limitations and operational considerations?

Azure Attestation is a specialized trust service. It is not a general identity provider, authorization engine, secret store, certificate lifecycle platform, vulnerability scanner, or cloud security posture service. A successful attestation indicates that the submitted evidence satisfied the validation and policy path being used. It does not by itself establish that a user is authorized or that an application is free of vulnerabilities.

Policy quality and lifecycle management are also important. A permissive policy can trust environments that a security team did not intend to accept, while an overly restrictive policy can block valid workloads after firmware, code, certificate, or measurement changes. Teams that depend on specific measurements, signer information, or platform components should build a controlled update and rotation process rather than treating those values as permanently static.

Azure Attestation vs Azure Key Vault and Defender for Cloud

Azure Attestation and Azure Key Vault can participate in the same confidential computing workflow but solve different problems. Attestation evaluates evidence and produces signed claims about a trusted platform or execution environment. Key Vault and Managed HSM store and control access to secrets and cryptographic keys. A relying service can use attestation results as part of a key-release decision, but Azure Attestation is not itself a secret store.

Microsoft Defender for Cloud is also different. Defender for Cloud focuses on security posture, recommendations, alerts, and workload protection. Attestation is the evidence-validation and token-issuance service in a trust workflow. Buyers should not choose Azure Attestation when their actual requirement is posture management, threat detection, or secret storage.

Who should choose something else?

Choose another service if the main requirement is user authentication, application authorization, secret storage, certificate lifecycle management, vulnerability scanning, general cloud security posture, or durable application messaging. Microsoft Entra ID, Azure RBAC, Azure Key Vault, Managed HSM, Defender for Cloud, and other Azure services address those needs more directly.

Teams that do not use TPM-backed trust, SGX or VBS enclaves, Trusted Launch, AMD SEV-SNP confidential virtual machines, or another evidence-based verification workflow may gain little from adding attestation complexity. Azure Attestation is most useful when a relying party genuinely needs cryptographic evidence about platform or workload state before releasing sensitive data, keys, privileges, or operations.