In this blog post I will walk you through Guest Attestation for Confidential Azure Virtual Desktop session hosts. This is the third post in the Confidential AVD series. In part one we built CVM-compatible images with Azure Image Builder and deployed session hosts with AMD SEV-SNP memory encryption. In part two we layered customer-managed keys on top: Key Vault, Disk Encryption Set, Event Grid alerting, and a 9-step offline rotation script.

Both posts ended with the same question from readers: you said Guest Attestation provides cryptographic proof that a session host is running in a genuine Trusted Execution Environment, but how do you actually verify that? What does the proof look like? Where does it come from? And what happens if it breaks?

That is exactly what this post covers. One important thing I discovered while building this out: you do not need to deploy your own Azure Attestation Provider to get that proof. The Microsoft.Attestation/attestationProviders resource type is not available in Belgium Central, which is where this deployment runs. Microsoft provides shared regional endpoints that do the same job with zero infrastructure, and you can verify the result all the way down to the hardware signature using nothing but PowerShell.

All source code is available on GitHub.

⭐ yannickdils/confidentialavd
Bicep modules, PowerShell scripts, Azure DevOps pipelines, KQL queries, and Azure Policy for Confidential AVD

What Guest Attestation proves and how it works

Let me start with what the proof actually is, because the solution makes more sense once you understand what problem it is solving.

When you deploy a Confidential VM with securityType: ConfidentialVM in Bicep, Azure records the security profile and places the VM on hardware that supports AMD SEV-SNP. But that is a declaration in the Azure control plane. The session host has no built-in way to verify from inside the guest that it is actually running in a hardware TEE and not on a standard host with the security profile flags set. Neither does your security team or your auditors.

Guest Attestation fills that gap. Here is the full sequence of what happens when the GuestAttestation extension runs on a session host.

1. The extension calls the AMD SEV-SNP firmware inside the physical CPU and requests a hardware attestation quote. The quote contains cryptographic measurements of the processor firmware version, the boot chain as recorded by the vTPM, the Secure Boot state, and the SEV-SNP features active at the hardware level.
2. The quote is signed by a key that is physically embedded in the AMD CPU. It cannot be forged in software.
3. The extension sends the quote to a Microsoft Azure Attestation (MAA) endpoint over HTTPS.
4. MAA verifies the AMD signature, checks the firmware measurements against Microsoft’s known-good baseline for Azure CVMs, and if everything passes, issues a signed JWT attestation token.
5. The extension writes the result to the Microsoft-Windows-Attestation/Operational Windows event log.

The JWT token is the proof. The three claims in the payload that matter for Confidential AVD are:

• x-ms-attestation-type: sevsnpvm – confirms the platform is AMD SEV-SNP hardware, not emulated and not a standard VM with the security profile set incorrectly
• x-ms-compliance-status: azure-compliant-cvm – confirms Secure Boot is active, vTPM is present, and the platform passed Microsoft’s full CVM compliance baseline
• secureboot: true – explicit Secure Boot confirmation

And critically: the JWT is signed with RS256 using a certificate from the MAA endpoint. Anyone who holds the public key can verify that the token was issued by Microsoft and was not tampered with. That verification step is what makes this a technical guarantee rather than a policy promise.

Why you do not need a custom Attestation Provider

You might expect this post to start with deploying a custom Microsoft.Attestation/attestationProviders resource. It does not – and for a Belgium Central deployment it cannot. The resource type has a fixed list of supported regions that predates the Belgium Central region, which only went GA in November 2025.

If you try to deploy the Attestation Provider resource to belgiumcentral you will get:

LocationNotAvailableForResourceType: The provided location 'belgiumcentral' is not available for resource type 'Microsoft.Attestation/attestationProviders'.

This turns out not to matter, because Microsoft already runs shared Attestation Provider instances in each supported region. These shared endpoints are available to every Azure customer, require no deployment, and apply Microsoft’s default attestation policy which validates exactly what you need for Confidential VMs: AMD SEV-SNP hardware, Secure Boot, and vTPM state.

The three shared endpoints closest to a Belgium-based deployment are:

For a Belgium Central deployment, the region-local authority is https://sharedbec.bec.attest.azure.net, and that is what Belgium Central session hosts should call – and do call, once you set it explicitly. This is the same authority that CreateHSM_CMK.ps1 hardcodes in the Managed HSM Secure Key Release policy, so lining up the runtime GuestAttestation extension with it keeps the attestation authority consistent across both flows. It is not the default yet: if you leave maaEndpoint empty the extension falls back to sharedweu.weu.attest.azure.net. To pin Belgium Central session hosts to the region-local endpoint, set maaEndpoint to https://sharedbec.bec.attest.azure.net in the GuestAttestation extension settings of your hostpool config, mirroring what the SKR script does for the HSM key.

The only practical difference between the shared endpoint and a dedicated one is that with the shared endpoint you cannot write a custom attestation policy. For Confidential AVD, the default Microsoft policy validates everything you need. Custom policies are relevant for more advanced scenarios like Secure Key Release, where you want to restrict key access to CVMs running in a specific region or with a specific firmware version.

Architecture overview

The attestation validation stack built in this post sits on top of the infrastructure from parts one and two. The session hosts were already calling the shared MAA endpoint. What we are adding is the visibility layer: a Data Collection Rule that captures what the extension reports, KQL queries to surface it in Azure Monitor, a PowerShell script that performs six steps of validation, and a pipeline that runs everything in sequence.

Figure 1 – Guest Attestation flow: CVM session host calls the Microsoft shared MAA endpoint, the GuestAttestation extension writes results to the Windows event log, Azure Monitor Agent ships them to Log Analytics via the CVM-specific DCR

The validation flow has six steps, each building on the previous one.

Step 1 – Extension health (control plane): Checks the GuestAttestation extension provisioning state on every CVM via az vm extension show.

Step 2 – Instance view (control plane): Queries the detailed attestation status from each VM’s instance view, retrieving component status and health messages reported by the extension.

Step 3 – MAA certificate chain analysis: Fetches all signing certificates from the shared MAA endpoint and analyses the full X.509 certificate chain: subject, issuer, validity period, and signature algorithm.

Step 4 – In-VM evidence collection (data plane): Uses Run Command to collect Secure Boot state, TPM status, VBS configuration, THIM endpoint data, and IMDS attestation metadata directly from each session host.

Step 5 – JWT decode and signature verification: Retrieves the attestation token from the Windows event log on each session host, decodes the payload to validate the critical claims (x-ms-attestation-type, x-ms-compliance-status, secureboot), then verifies the RS256 signature against the MAA signing certificates. A valid signature proves the token was issued by Microsoft Azure Attestation and was not tampered with.

Step 6 – Log Analytics query: Queries the Log Analytics workspace for attestation error events from the past N days, providing a historical view of attestation health across the host pool.

The new components added in this post:

• CVM-specific Data Collection Rule (dcr-avd-confidential-prd-weu-001) – collects attestation events, vTPM key operations, and boot integrity events that the standard AVD Insights DCR misses
• Azure Policy definition – audits all Confidential VMs for the GuestAttestation extension
• Get-AttestationStatus.ps1 – six-step validation script covering extension health, instance view, MAA certificates, in-VM evidence, JWT signature verification, and Log Analytics queries
• AVD-DeployAttestation.yml – five-stage pipeline that loads JSON config, deploys the DCR and Log Analytics solutions, deploys Policy, and runs the validation script

Understanding the shared MAA endpoint

Because there is no custom provider to deploy, the first thing to verify is that your session hosts can reach the shared endpoint. The GuestAttestation extension makes an outbound HTTPS call to sharedweu.weu.attest.azure.net on TCP 443. If an NSG blocks this call, the extension will provision successfully but attestation will silently fail.

You can test connectivity from a session host using Run Command in the portal, or from your pipeline:

# Run this via az vm run-command or in the portal Run Command blade
$endpoint = "https://sharedweu.weu.attest.azure.net"
try {
    $response = Invoke-WebRequest -Uri "$endpoint/certs" -Method Get -TimeoutSec 10 -UseBasicParsing
    Write-Host "Reachable: $($response.StatusCode) - $($response.Headers['Content-Type'])"
} catch {
    Write-Host "UNREACHABLE: $_"
    Write-Host "Check NSG outbound rules for TCP 443 to sharedweu.weu.attest.azure.net"
}

You can also query the signing certificates directly from the pipeline agent to verify the endpoint is reachable from your network:

$certs = Invoke-RestMethod "https://sharedweu.weu.attest.azure.net/certs"
Write-Host "Signing certificates available: $($certs.keys.Count)"
$certs.keys | ForEach-Object {
    Write-Host "  kid: $($_.kid)"
    Write-Host "  alg: $($_.alg)"
    # The x5c array contains the signing certificate chain (base64 DER encoded)
}

Decoding and validating the JWT attestation token

The GuestAttestation extension writes the attestation token to the Microsoft-Windows-Attestation/Operational Windows event log on each session host after each attestation cycle. The token is a standard base64url-encoded JWT with three dot-separated sections: header, payload, and signature.

Here is how to decode and validate it manually from inside a session host:

# Read the latest token from the GuestAttestation extension log
$logPath = "C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Security.WindowsAttestation"
$token = Get-ChildItem $logPath -Recurse -Filter "*.log" |
    Get-Content | Where-Object { $_ -match "eyJ" } |
    Select-Object -Last 1

# Decode the payload (second section)
$b64 = $token.Split('.')[1].Replace('-','+').Replace('_','/')
$b64 += '=' * ((4 - $b64.Length % 4) % 4)
$claims = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($b64)) |
    ConvertFrom-Json

# The three claims that matter for Confidential AVD validation
Write-Host "x-ms-attestation-type  : $($claims.'x-ms-attestation-type')"
Write-Host "x-ms-compliance-status : $($claims.'x-ms-compliance-status')"
Write-Host "secureboot             : $($claims.secureboot)"
Write-Host "issuer (iss)           : $($claims.iss)"
Write-Host "issued at              : $([DateTimeOffset]::FromUnixTimeSeconds($claims.iat).ToString('u'))"
Write-Host "expires                : $([DateTimeOffset]::FromUnixTimeSeconds($claims.exp).ToString('u'))"
Write-Host "SEV-SNP microcode SVN  : $($claims.'x-ms-isolation-tee'.'x-ms-sevsnpvm-microcode-svn')"

# Validation
if ($claims.'x-ms-attestation-type' -ne 'sevsnpvm') {
    Write-Host "FAIL: not AMD SEV-SNP hardware" -ForegroundColor Red
} elseif ($claims.'x-ms-compliance-status' -ne 'azure-compliant-cvm') {
    Write-Host "FAIL: platform is not azure-compliant-cvm" -ForegroundColor Red
} elseif ($claims.secureboot -ne $true) {
    Write-Host "FAIL: Secure Boot is not active" -ForegroundColor Red
} else {
    Write-Host "PASS: all critical claims valid" -ForegroundColor Green
}

Cryptographic signature verification

Decoding the claims tells you what the token says. Verifying the signature tells you that the token was issued by Microsoft Azure Attestation and has not been tampered with since. This is the step that Thomas Van Laere covers in depth in his post on verifying MAA JWT tokens.

The JWT header contains a jku field pointing to the MAA signing certificate set URL, and a kid identifying which specific certificate was used to sign this token. The process is:

1. Fetch the signing certificates from <MAA_ENDPOINT>/certs
2. Find the certificate whose kid matches the token header
3. Build an RSA public key from the certificate’s x5c value
4. Reconstruct the signed input as base64url(header).base64url(payload)
5. Verify the RS256 signature (RSASSA-PKCS1-v1_5 with SHA-256)

$maaEndpoint = "https://sharedweu.weu.attest.azure.net"

# Fetch signing certs from the shared MAA endpoint
$certs = Invoke-RestMethod "$maaEndpoint/certs"

# Decode the token header to find the kid
$headerB64 = $token.Split('.')[0].Replace('-','+').Replace('_','/')
$headerB64 += '=' * ((4 - $headerB64.Length % 4) % 4)
$header = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($headerB64)) |
    ConvertFrom-Json

Write-Host "Token kid  : $($header.kid)"
Write-Host "Token jku  : $($header.jku)"
Write-Host "Algorithm  : $($header.alg)"

# Find the matching signing certificate by kid
$signingKey = $certs.keys | Where-Object { $_.kid -eq $header.kid }
if (-not $signingKey) {
    Write-Host "WARN: no cert found matching kid - token may be from a different endpoint" -ForegroundColor Yellow
    exit 1
}

# Build the X509 certificate and RSA public key
$certBytes = [Convert]::FromBase64String($signingKey.x5c[0])
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($certBytes)
$rsa  = $cert.GetRSAPublicKey()

Write-Host "Signing cert subject : $($cert.Subject)"
Write-Host "Signing cert expiry  : $($cert.GetExpirationDateString())"

# Reconstruct the signed input (header.payload as UTF-8 bytes)
$signedInput = "$($token.Split('.')[0]).$($token.Split('.')[1])"
$dataBytes   = [System.Text.Encoding]::UTF8.GetBytes($signedInput)

# Decode the RS256 signature
$sigB64  = $token.Split('.')[2].Replace('-','+').Replace('_','/')
$sigB64 += '=' * ((4 - $sigB64.Length % 4) % 4)
$sigBytes = [Convert]::FromBase64String($sigB64)

# Verify using RSASSA-PKCS1-v1_5 with SHA-256 (RS256)
$valid = $rsa.VerifyData(
    $dataBytes,
    $sigBytes,
    [System.Security.Cryptography.HashAlgorithmName]::SHA256,
    [System.Security.Cryptography.RSASignaturePadding]::Pkcs1
)

if ($valid) {
    Write-Host "SIGNATURE VALID - token was issued by Microsoft Azure Attestation" -ForegroundColor Green
} else {
    Write-Host "SIGNATURE INVALID - token may have been tampered with" -ForegroundColor Red
}

The CVM-specific Data Collection Rule

The standard AVD Insights Data Collection Rule collects performance counters and Windows event logs useful for general desktop virtualisation monitoring. It does not collect anything from the attestation or TPM event channels. The module at ComponentLibrary/GuestAttestation/main.bicep adds three event sources that are completely absent from the standard DCR.

You can review the key parts here, or view the full module on GitHub:

📄 ComponentLibrary/GuestAttestation/main.bicep
CVM-specific DCR collecting attestation events, vTPM key operations, boot integrity events, and AVD performance counters

dataSources: {
  windowsEventLogs: [
    {
      name: 'AttestationEvents'
      streams: ['Microsoft-WindowsEvent']
      xPathQueries: [
        // GuestAttestation extension operational log - primary attestation health signal
        'Microsoft-Windows-Attestation/Operational!*'
        // TPM driver events - errors indicate degraded vTPM state
        'Microsoft-Windows-TPM-WMI/Operational!*[System[(Level=1 or Level=2 or Level=3)]]'
        // Boot chain integrity events - deviations from measured baseline appear here
        'Microsoft-Windows-Kernel-Boot/Operational!*[System[(Level=1 or Level=2)]]'
      ]
    }
    {
      name: 'SecurityEvents'
      streams: ['Microsoft-SecurityEvent']
      xPathQueries: [
        // vTPM key operations - should only appear during deployment or CMK rotation
        'Security!*[System[(EventID=5059 or EventID=5061)]]'
        // Logon and logoff events for session host activity correlation
        'Security!*[System[(EventID=4624 or EventID=4634 or EventID=4647)]]'
      ]
    }
  ]
}

Microsoft-Windows-Attestation/Operational is where the GuestAttestation extension writes the result of each attestation cycle. Errors here mean the extension failed to verify with the MAA endpoint. This is the primary monitoring signal.

Microsoft-Windows-TPM-WMI/Operational contains events from the vTPM driver. Errors here indicate the virtual TPM is in a degraded state, which means attestation measurements cannot be trusted even if the extension reports success.

Microsoft-Windows-Kernel-Boot/Operational records boot chain events. If Secure Boot blocks a driver or the boot sequence deviates from the measured baseline, errors appear here and help you distinguish hardware-level from software-level problems.

Security EventIDs 5059 and 5061 are cryptographic key operations on the vTPM. These should only appear during VM deployment or CMK key rotation from part two. Unexpected occurrences warrant investigation.

Once the DCR is deployed, update the dataCollectionRuleId field in your hostpool.template.json to the DCR’s resource ID. New session hosts deployed via AVD-DeployAdditionalHosts will associate with it automatically.

📄 ComponentLibrary/GuestAttestation/main.parameters.json
Parameters file – update dataCollectionRuleName and logAnalyticsWorkspaceId

The DCR requires the SecurityEvent and WindowsEvent tables to exist in the Log Analytics workspace before data can flow. These are solution-managed tables that cannot be created via the REST API. The module at ComponentLibrary/GuestAttestation/solutions.bicep deploys the Security and SecurityInsights Log Analytics solutions, which auto-provision both tables. The pipeline deploys this module first and waits for the tables to appear before deploying the DCR.

📄 ComponentLibrary/GuestAttestation/solutions.bicep
Deploys Security and SecurityInsights LA solutions to auto-provision SecurityEvent and WindowsEvent tables

Monitoring attestation health with KQL

With data flowing into Log Analytics via the CVM DCR, these queries give you visibility into attestation health across your host pool. All eight are in Queries/attestation-kql-queries.kql.

📄 Queries/attestation-kql-queries.kql
Eight KQL queries: attestation health per host, failure events, vTPM operations, hosts with no telemetry, 30-day trend, session correlation, performance, and Policy compliance

Attestation health per session host

This is the query to run first after any session host deployment or image rollout. A host missing from the results entirely has never sent attestation telemetry, which is just as concerning as one with explicit errors.

WindowsEvent
| where TimeGenerated > ago(24h)
| where Channel contains "Attestation"
| summarize
    LastSeen   = max(TimeGenerated),
    EventCount = count(),
    ErrorCount = countif(Level in (1, 2)),
    WarnCount  = countif(Level == 3)
    by Computer
| extend AttestationHealth = case(
    ErrorCount > 0, "ERROR",
    WarnCount  > 0, "WARNING",
    "HEALTHY"
  )
| project SessionHost = Computer, AttestationHealth, LastSeen, EventCount, ErrorCount, WarnCount
| order by AttestationHealth asc, LastSeen desc

Session hosts with no attestation telemetry

This catches the silent failure case. Hosts that appear in the Windows event log stream but not in the attestation channel are either running an older image from before part one, have a failed extension installation, or have an NSG blocking the shared MAA endpoint.

let AllHosts = WindowsEvent
    | where TimeGenerated > ago(24h)
    | summarize by Computer;
let AttestingHosts = WindowsEvent
    | where TimeGenerated > ago(24h)
    | where Channel contains "Attestation"
    | summarize by Computer;
AllHosts
| join kind=leftanti AttestingHosts on Computer
| project
    SessionHost = Computer,
    Status      = "NO ATTESTATION EVENTS",
    Action      = "Check GuestAttestation extension - may be missing or NSG blocking sharedweu.weu.attest.azure.net" 

Enforcing the extension with Azure Policy

The policy definition at ComponentLibrary/Policy/policy-require-guest-attestation.bicep uses AuditIfNotExists to flag any Confidential VM that does not have a successfully provisioned GuestAttestation extension. The securityProfile.securityType == ConfidentialVM filter means it only evaluates CVMs, so standard session hosts, the AIB build VM, and any other non-CVM infrastructure are invisible to it.

📄 ComponentLibrary/Policy/policy-require-guest-attestation.bicep
AuditIfNotExists policy definition – flags Confidential VMs missing a healthy GuestAttestation extension

The policy definition uses targetScope = 'subscription' and is deployed at subscription scope via az deployment sub create. The pipeline handles both the definition deployment and the policy assignment in AuditIfNotExists mode automatically.

If you prefer to assign it manually in the Azure Portal:

1. Go to Azure Portal > Policy > Assignments > Assign Policy
2. Set the scope to the subscription containing your CVM session hosts
3. Search for require-guest-attestation-confidential-avd
4. Leave the effect as AuditIfNotExists initially
5. Review compliance after 30 minutes, fix any flagged hosts, then consider switching to Deny if your security posture requires it

Figure 2 – Azure Policy compliance dashboard showing all Confidential VMs with a healthy GuestAttestation extension

Validating attestation health with Get-AttestationStatus.ps1

The script at Scripts/Get-AttestationStatus.ps1 performs the six validation steps in sequence: extension health, instance view, MAA certificates, in-VM evidence, JWT decode with signature verification, and Log Analytics queries. It uses the Microsoft shared MAA endpoint for signature verification – no custom provider required.

📄 Scripts/Get-AttestationStatus.ps1
Six-step attestation validation: extension health, instance view, MAA certificates, in-VM evidence, JWT decode + RS256 signature verification, Log Analytics query

To validate with -DryRun first to confirm all resources are reachable:

.\Scripts\Get-AttestationStatus.ps1 `
    -SubscriptionName "sub-avd-prd" `
    -HostsResourceGroup "rg-avd-prd-hosts" `
    -HostPoolName "hp-avd-prd-weu-001" `
    -MaaEndpoint "https://sharedweu.weu.attest.azure.net" `
    -DryRun

To run the full six-step validation:

.\Scripts\Get-AttestationStatus.ps1 `
    -SubscriptionName "sub-avd-prd" `
    -HostsResourceGroup "rg-avd-prd-hosts" `
    -HostPoolName "hp-avd-prd-weu-001" `
    -MaaEndpoint "https://sharedweu.weu.attest.azure.net" `
    -LogAnalyticsWorkspaceId "/subscriptions//resourceGroups//providers/Microsoft.OperationalInsights/workspaces/law-avd-prd-weu-001" `
    -QueryDays 14

Figures 3-6 – Get-AttestationStatus.ps1 output showing all six validation steps passing

To skip JWT validation when session hosts are deallocated (for example, during a maintenance window):

.\Scripts\Get-AttestationStatus.ps1 `
    -SubscriptionName "sub-avd-prd" `
    -HostsResourceGroup "rg-avd-prd-hosts" `
    -HostPoolName "hp-avd-prd-weu-001" `
    -SkipJwtValidation

The script exits with code 0 if all validations pass, code 2 if some were inconclusive (typically because VMs are deallocated), and code 1 if any validation fails. These exit codes make it safe to use directly in the pipeline validate stage.

Common failure modes and their causes:

Deploying everything with AVD-DeployAttestation.yml

The updated pipeline at Pipelines/AVD-DeployAttestation.yml has been restructured to reflect the correct approach: no Attestation Provider deployment, just parameter loading, DCR and Log Analytics solutions deployment, optional Policy deployment and assignment, and six-step validation.

The five stages are:

1. Initialize Parameters – loads the JSON hostpool config, extracts subscription, host pool, resource group, Log Analytics workspace, and MAA endpoint variables. Validates that confidentialCompute is enabled.
2. Approval gate – same pattern as the other pipelines in the repository
3. Deploy DCR – deploys solutions.bicep to provision the Log Analytics tables, waits for table provisioning, deploys the CVM-specific Data Collection Rule (main.bicep), and associates the DCR to all CVMs in the resource group.
4. Deploy Policy (optional) – deploys the Azure Policy definition at subscription scope and assigns it in AuditIfNotExists mode. Controlled by the deployPolicy parameter.
5. Validate – runs Get-AttestationStatus.ps1 with the shared MAA endpoint against all CVM session hosts. Passes -SkipJwtValidation if the pipeline parameter is set.

Figure 6 – Successful AVD-DeployAttestation pipeline run showing all five stages

📄 Pipelines/AVD-DeployAttestation.yml
Five-stage pipeline: initialize parameters, approval gate, deploy DCR + solutions, policy deployment + assignment, validate

What a failed attestation means operationally

A failed attestation does not block user logons by default. The GuestAttestation extension generates the token and writes it to the event log. Nothing acts on the result automatically unless you configure it to do so.

If you want attestation failures to trigger a response, the most practical options for Confidential AVD are:

Microsoft Defender for Cloud integration. If you have Defender for Servers Plan 2 enabled, a failed attestation generates a security alert in Defender for Cloud. You can connect these alerts to a Logic App or Azure Automation runbook that puts the affected host into drain mode and raises an incident ticket.

Log Analytics scheduled query alert. Use Query 1 from the KQL file and create a scheduled query alert rule in Azure Monitor that fires when ErrorCount > 0 for any session host. Route it to the same Action Group used for CMK key expiry alerts in part two.

For most organisations starting with Confidential AVD, alerting and monitoring first is the right approach. Understand what healthy attestation looks like in your environment, establish a baseline, and then layer in automated remediation once you are confident the alert thresholds are correct.

What’s new in the repository

Here is a summary of what is in the repository after this post. Note that attestation-provider.bicep and its parameters file have been removed because they cannot be deployed to Belgium Central.

📄 ComponentLibrary/GuestAttestation/main.bicep
CVM-specific DCR – attestation events, vTPM key operations, boot integrity, AVD perf counters

📄 ComponentLibrary/GuestAttestation/main.parameters.json
Parameters – update dataCollectionRuleName and logAnalyticsWorkspaceId

📄 ComponentLibrary/GuestAttestation/solutions.bicep
Deploys Security and SecurityInsights LA solutions to auto-provision SecurityEvent and WindowsEvent tables

📄 ComponentLibrary/Policy/policy-require-guest-attestation.bicep
AuditIfNotExists policy – flags Confidential VMs missing the GuestAttestation extension

📄 Scripts/Get-AttestationStatus.ps1
Six-step validation: extension health, instance view, MAA certificates, in-VM evidence, JWT decode + RS256 signature verification, Log Analytics query

📄 Pipelines/AVD-DeployAttestation.yml
Five-stage pipeline: initialize parameters, approval gate, deploy DCR + solutions, policy deployment + assignment, validate

📄 Queries/attestation-kql-queries.kql
Eight KQL queries for attestation health, vTPM events, trend charts, and Policy compliance

Operational checklist

Before calling your Confidential AVD deployment production-ready from an attestation standpoint:

1. Confirm the shared MAA endpoint is reachable from your session host subnet. Outbound TCP 443 to sharedweu.weu.attest.azure.net must be allowed by the NSG. This is the single most common cause of silent attestation failure.
2. Set attestationUrl in hostpool.template.json to match your deployment region. For Belgium Central, set it to https://sharedbec.bec.attest.azure.net to use the region-local authority. An empty string defaults to the West Europe endpoint (sharedweu.weu.attest.azure.net), which works but is not the region-local authority for Belgium Central deployments.
3. Update dataCollectionRuleId in hostpool.template.json with the ID from the DCR deployment. New session hosts deployed via AVD-DeployAdditionalHosts will associate with the CVM-specific DCR automatically.
4. Run Get-AttestationStatus.ps1 after every image rollout. Add it to the validate stage of your AVD-DeployAdditionalHosts pipeline run. A new host that fails the claims validation or signature verification should be investigated before users connect to it.
5. Create an Azure Monitor alert on Query 1. Set it to fire when ErrorCount > 0 for any session host and route it to your existing Action Group.
6. The pipeline assigns the Azure Policy in AuditIfNotExists mode automatically. Run for two weeks, review compliance, resolve flagged hosts, and only switch to Deny if required.
7. For Thomas Van Laere’s deeper coverage of attestation theory and JWT verification, see his posts on verifying MAA JWT tokens and Microsoft Azure Attestation architecture.

References

• Azure Attestation overview – Microsoft Learn
• Guest Attestation for Azure Confidential VMs – Microsoft Learn
• About Azure Confidential VMs – Microsoft Learn
• Verifying Microsoft Azure Attestation JWT tokens – Thomas Van Laere
• Microsoft Azure Attestation architecture – Thomas Van Laere
• Part 1: Building Confidential AVD Images with Azure Image Builder – tunecom.be
• Part 2: Customer-Managed Keys for Confidential AVD – tunecom.be
• Thomas Van Laere – Confidential Computing series