The Assumption That Broke First

The foundational assumption in most AVD hybrid join deployments is this: if the session host is domain-joined and the Azure AD Connect sync is healthy, the device object in Entra ID is valid and the hybrid join state is current.

That assumption was reasonable in 2021. It is not reliable in 2024.

Entra ID's device registration service now performs certificate-based validation of the hybrid join state at intervals that are decoupled from the Azure AD Connect sync cycle. The device certificate issued during hybrid join has a defined validity window, and renewal depends on the Microsoft Entra device registration task running successfully on the session host — specifically the scheduled task Automatic-Device-Join under Microsoft\Windows\Workplace Join.

In pooled AVD host pools, this task frequently fails silently. The reasons vary: the session host is deallocated when the task fires, the task runs in a context that cannot reach the Entra ID registration endpoint due to a network policy change, or the session host was redeployed from a golden image that carried a stale or missing device certificate without triggering a clean re-registration.

When the device certificate expires or the registration state becomes inconsistent, Entra ID does not immediately mark the device as non-compliant. There is a grace period and a reconciliation window. During that window, conditional access policies that require a hybrid Azure AD joined device will still pass — because the evaluation is based on the device object's join type attribute, not a live certificate check at every authentication event.

This is the gap. The device is functionally unregistered. The policy says it is joined. The audit log says access was granted.

---

What Changed in the AVD Session Host Registration Flow

AVD session host registration — the process by which a VM enrolls in a host pool — has always been separate from Entra ID device registration. But recent changes to the AVD agent (specifically agent versions in the 1.0.8xxx and later series) introduced tighter coupling between the two.

The AVD agent now performs a registration health check at startup that queries the local device registration state. If the check detects that the device certificate is missing, expired, or that the dsregcmd /status output shows AzureAdJoined: NO or DomainJoined: YES with WorkplaceJoined: NO, the agent logs a warning but does not block session host availability. The host pool shows the session host as available. Users can connect.

What changes is the token claims profile for sessions initiated from that host. The device claim in the access token — specifically the deviceid claim and the associated compliant and managedby claims — may be absent or stale, depending on how far the registration state has drifted.

Conditional access policies that evaluate device.isCompliant or device.trustType are now operating on token claims that do not reflect the actual device state. In environments using Intune compliance policies tied to hybrid-joined AVD session hosts, this creates a second-order problem: Intune's compliance evaluation depends on a valid device object with a current check-in. A session host that has drifted from valid hybrid join state will eventually stop checking in to Intune, causing the compliance state to go stale and then flip to non-compliant — but only after the grace period expires.

The timeline from "registration drifted" to "compliance flipped to non-compliant" can be weeks. During that window, access continues.

---

Detecting the Drift Before It Becomes an Incident

The first operational step is establishing a detection baseline. You cannot remediate what you have not measured.

Run the following KQL query against your Entra ID sign-in logs in Log Analytics to identify AVD session authentications where the device compliance claim is absent or the device is not recognized:

SigninLogs
| where AppDisplayName has "Windows Virtual Desktop"
    or AppDisplayName has "Azure Virtual Desktop"
| where TimeGenerated > ago(30d)
| extend DeviceDetail = parse_json(DeviceDetail)
| extend IsCompliant = tostring(DeviceDetail.isCompliant)
| extend TrustType = tostring(DeviceDetail.trustType)
| extend DeviceId = tostring(DeviceDetail.deviceId)
| where IsCompliant != "true" or TrustType == "" or DeviceId == ""
| project TimeGenerated, UserPrincipalName, IPAddress, IsCompliant, TrustType, DeviceId, ResultType, ConditionalAccessStatus
| order by TimeGenerated desc

This query surfaces sign-ins where the device claim is missing or the compliance state is not confirmed. A healthy hybrid-joined AVD environment should show TrustType == "ServerAD" and IsCompliant == "true" for every session host-initiated authentication.

Next, validate the registration state directly on the session hosts. The following PowerShell script runs against a list of session host names and reports the dsregcmd output for the fields that matter:

$sessionHosts = @("avd-host-01", "avd-host-02", "avd-host-03")

foreach ($host in $sessionHosts) {
    $result = Invoke-Command -ComputerName $host -ScriptBlock {
        $dsreg = dsregcmd /status
        $output = @{}

        $output["AzureAdJoined"]     = ($dsreg | Select-String "AzureAdJoined\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
        $output["DomainJoined"]      = ($dsreg | Select-String "DomainJoined\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
        $output["WorkplaceJoined"]   = ($dsreg | Select-String "WorkplaceJoined\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
        $output["DeviceCertValid"]   = ($dsreg | Select-String "KeySignTest\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
        $output["TenantName"]        = ($dsreg | Select-String "TenantName\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
        $output["DeviceId"]          = ($dsreg | Select-String "DeviceId\s+:\s+(.+)").Matches.Groups[1].Value.Trim()

        return $output
    } -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        HostName        = $host
        AzureAdJoined   = $result["AzureAdJoined"]
        DomainJoined    = $result["DomainJoined"]
        WorkplaceJoined = $result["WorkplaceJoined"]
        DeviceCertValid = $result["DeviceCertValid"]
        TenantName      = $result["TenantName"]
        DeviceId        = $result["DeviceId"]
    }
}

Any host returning AzureAdJoined: NO or KeySignTest: FAILED is operating outside valid hybrid join state. These hosts need immediate remediation before the next compliance review cycle.

---

The Conditional Access Evaluation Gap

Conditional access in Entra ID evaluates device state at token issuance, not at session runtime. This is a well-understood architectural characteristic, but it interacts badly with the drift scenario described above.

When a user authenticates to an AVD session, the access token is issued based on the device claims available at that moment. If the session host's device certificate is expired but the device object still exists in Entra ID with trustType: ServerAD, the token issuance may succeed — because the policy engine is evaluating the object's attributes, not performing a live certificate validation.

The practical consequence: a conditional access policy requiring Hybrid Azure AD Joined does not guarantee that the device is currently in a valid hybrid join state. It guarantees that the device object in Entra ID has the trustType attribute set to ServerAD. Those are not the same thing after a registration drift event.

For environments under SOC 2 Type II or FedRAMP Moderate controls, this distinction is material. The control objective typically requires that access to sensitive resources is restricted to managed, compliant devices. If the compliance signal is stale and the device certificate is expired, the device is not managed in any meaningful operational sense — but the access control log will show the policy as satisfied.

This is the audit exposure. The log says compliant. The device is not.

---

Remediation Architecture for Pooled Host Pools

For pooled host pools using ephemeral or regularly reimaged session hosts, the remediation approach must be baked into the image lifecycle, not applied reactively.

The core requirement is ensuring that every session host that comes online from a golden image completes a clean hybrid join registration before it is marked available in the host pool. This requires three changes to the standard deployment pipeline:

First, the golden image must not carry a device certificate or a stale dsregcmd state. Before capturing the image, run dsregcmd /leave to clean the registration state. This ensures that every VM deployed from the image starts from a clean registration baseline.

Second, the session host deployment pipeline — whether ARM template, Bicep, or Terraform — must include a post-deployment script that triggers the Automatic-Device-Join scheduled task and validates the result before the host is added to the host pool drain mode release:

Start-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join"

$timeout = 120
$elapsed = 0
do {
    Start-Sleep -Seconds 5
    $elapsed += 5
    $taskState = (Get-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join").State
} while ($taskState -eq "Running" -and $elapsed -lt $timeout)

$dsreg = dsregcmd /status
$azureAdJoined = ($dsreg | Select-String "AzureAdJoined\s+:\s+(.+)").Matches.Groups[1].Value.Trim()
$keySignTest   = ($dsreg | Select-String "KeySignTest\s+:\s+(.+)").Matches.Groups[1].Value.Trim()

if ($azureAdJoined -ne "YES" -or $keySignTest -ne "PASSED") {
    Write-Error "Hybrid join validation failed. Host should not be released from drain mode."
    exit 1
} else {
    Write-Output "Hybrid join validated. AzureAdJoined: $azureAdJoined | KeySignTest: $keySignTest"
}

Third, implement a scheduled compliance check that runs nightly against all active session hosts in each host pool, using the KQL query above combined with an Azure Monitor alert rule. Any host that fails the compliance check should be automatically placed in drain mode pending investigation.

---

Governance Considerations for Audit Readiness

The governance problem here is not technical — it is evidentiary. Under SOC 2 and FedRAMP, auditors will request evidence that device-based access controls were enforced continuously during the audit period. The Entra ID sign-in logs are the primary evidence source.

If those logs show ConditionalAccessStatus: success for sessions originating from hosts with expired device certificates, you have a control gap that the logs cannot self-correct. The access was granted. The log says it was compliant. The device was not.

The remediation for the governance layer requires three things beyond the technical fixes:

Document the detection gap explicitly in your risk register. The gap between device certificate expiry and conditional access enforcement failure is a known architectural characteristic, not an anomaly. Treat it as a residual risk with defined mitigating controls.

Establish a device object audit cadence in Entra ID. Monthly review of all device objects with trustType: ServerAD that have not checked in within 30 days is a minimum baseline. Stale device objects that remain enabled are a persistent source of false compliance signals.

Align your host pool drain mode policy with your compliance review cycle. If your SOC 2 audit period is quarterly, your session host compliance validation should run at least monthly, with documented evidence of each run stored in your GRC platform.

---

Recommendations for Architects Rebuilding This Right

If you are redesigning an AVD deployment that currently relies on hybrid join, evaluate whether Entra ID-joined session hosts are viable for your environment. Microsoft's current architectural guidance — reflected in the AVD landing zone accelerator — favors Entra-joined session hosts for new deployments, with FSLogix profile containers and Kerberos cloud trust handling the identity scenarios that previously required domain join.

Hybrid join remains necessary in specific scenarios: environments with line-of-business applications that require Kerberos tickets to on-premises resources, environments where GPO-based configuration management cannot be replaced by Intune policies within the project timeline, and environments with legacy authentication dependencies that cannot be modernized.

For those environments, the remediation architecture described above is not optional — it is the minimum viable configuration for maintaining a defensible compliance posture. The alternative is operating with a device trust chain that looks intact from every dashboard while being structurally unsound at the certificate layer.

The change that matters most is cultural: hybrid join validation must move from a one-time deployment check to a continuous operational control. The session host lifecycle — image build, deployment, operation, decommission — must include explicit registration validation at each stage.

---