A PAW architecture is only true if something makes it true. This is the build that makes it true: one deliberately named provisioning policy, one property that flows from it, and a Conditional Access policy that closes the loop.
The privileged access article argued the design; this companion builds the Cloud PC PAW pattern end to end. The whole construction hangs on a single mechanism worth stating up front: every Cloud PC carries its provisioning policy’s name as the enrollmentProfileName property in Entra ID and Intune, stamped at enrollment. That one property lets the provisioning policy name become the membership rule for the Intune hardening scope and the device filter for the Conditional Access enforcement, which means the entire PAW fleet is defined in exactly one place. Name the policy correctly and everything downstream inherits it.
Step one and two: the policy and the group it feeds
Build a dedicated provisioning policy exactly as in the provisioning build article, with three differences. Name it for its purpose and permanence, something like CPC-PAW-Prod, because that string is about to become infrastructure. Target it at a small, tightly controlled Entra group containing only the administrators approved for a privileged workstation, with membership governed by an access review. And size it modestly; a PAW runs an admin session and a browser pointed at portals, not a workload. The machines join as Entra joined, on the Microsoft-hosted network unless your privileged plane genuinely lives behind an ANC, with SSO enabled.
Then create the dynamic device group that the property feeds. In Entra, create a security group with a dynamic device membership rule of device.enrollmentProfileName -eq “CPC-PAW-Prod”. Every Cloud PC the policy ever provisions lands in this group automatically, and nothing else does. This group is your Intune assignment scope for the PAW fleet: assign the hardened configuration profile set to it, your strictest baseline variant with no exceptions, since nobody does general work here, along with the compliance policy the CA layer will evaluate. The practical beauty of the pattern is operational: reprovision a compromised PAW and the replacement machine is born into the same group, inherits the same hardening, and satisfies the same filter, with no human in the loop to forget a step.
Step three: the Conditional Access policy that enforces the claim
If you run the VCIO CA Framework from the Phase 8 series, the privileged plane is already protected: CA100 requires phishing-resistant authentication for admin roles, CA101 requires a compliant device, and CA103 holds the Tier 0 control plane to both for all identities. The PAW policy narrows one of those grants: compliant is no longer enough; it must be compliant and be one of these machines. Build it as a customer extension that sits alongside the framework under a descriptive name of its own, outside the framework’s numbering, and note clearly in your documentation that it is an extension, not part of the shipped framework release.
In the Entra admin center, create a new Conditional Access policy named PAW Only - Privileged Admins. The name deliberately sits outside the framework’s CA numbering: that number space belongs to the policies the framework ships as code, and an adjacent policy should not claim a slot in it. Target the same admin role list CA100 uses, against all resources or, for a staged rollout, the Microsoft Admin Portals and Azure management apps first. Under Conditions, add a filter for devices in include mode with the rule device.enrollmentProfileName -ne “CPC-PAW-Prod”, and set the grant to Block; the policy reads as: block privileged access from any device that is not a PAW Cloud PC. Exclude the break-glass accounts and the policy’s own exclusion group, SG-CA-Excl-PAWOnly, following the framework’s one-group-per-policy pattern, and keep that group empty and access-reviewed. Ship it in report-only, exactly as the framework rings do, and read the sign-in logs for a week: every privileged sign-in the policy would have blocked is either an admin not yet moved onto their PAW, which is adoption work, or a workflow you forgot, which is design work. Enable only when report-only goes quiet.
The filter matches on a string you control in exactly one place. Rename the provisioning policy and the enforcement silently breaks, so the policy name goes in the change-control list next to the break-glass credentials.
Step four: getting the admin inside
The bootstrap sequence matters because the credential for the privileged identity should live inside the PAW, not on the daily driver. The privileged account is a separate, cloud-only identity per the framework’s admin account model. Issue it a Temporary Access Pass, have the administrator connect to their PAW Cloud PC with their everyday identity’s client, sign in to the privileged account inside the session using the TAP, and enroll the phishing-resistant credential, a passkey, from within that session. From that point the privileged credential exists where privileged work happens, CA100 is satisfiable only there, and the PAW-only block makes any other path a dead end. Pair the whole construction with the connecting-device rule from the design article, privileged path never from an unmanaged machine, and the claim the architecture makes, that privileged keystrokes happen only on machines you built for them, is now enforced rather than hoped.
Windows 365
‹ Previous: [W365 5] The Cloud PC as a Privileged Access Workstation
Next: [W365 6] Cloud PCs at the Enclave Boundary: Windows 365 Government and CUI Access ›
