Anyone building a Privileged Access Workstation eventually hits the point where “basically clean” no longer cuts it. That is exactly where this comes in. I am currently building my Ephemeral PAW on top of Windows 365 Flex in Shared mode, and one piece turned out to be more important than expected: the guarantee that every new session starts on a freshly provisioned machine. No leftovers, no traces, no doubt.

In this post I walk through the full picture: how I harden the Cloud PC underneath (security baselines, session lockdown like clipboard and redirection controls and watermarking, Defender for Endpoint, Conditional Access with phishing-resistant MFA, and access for B2B guests), what Flex shared mode already solves on its own and what it does not, and how I close that gap with an event-driven reprovisioning trigger.

The full solution is on GitHub under the MIT license: github.com/daniel-fraubaum/w365-reprovisioningtrigger. Bicep templates, deployment scripts, the Azure Function backend and the client-side logoff trigger, all in one repo.

Cloud PAW or hardware PAW?

Let me be upfront about one thing: a Cloud PC is not the strongest possible PAW. The gold standard for privileged access is still a dedicated hardware device, physically separate, locked down, used for nothing but administrative work. If you can run that for your Tier 0 admins, do it.

The catch is that a hardware PAW is not always realistic. It means procuring, shipping, patching and physically managing a second device per admin. That falls apart fast with distributed teams, external consultants, on-call staff who need access from anywhere, or simply a budget and logistics reality that does not allow a separate managed laptop for everyone who occasionally touches a privileged role.

A cloud-based ephemeral PAW sits in the pragmatic middle. You do not get the full physical isolation of separate hardware, but you do get a clean, centrally managed, policy-enforced environment that is reachable from anywhere and, with the trigger described below, fully reset after every session. For a lot of organizations that is the difference between having a real PAW concept and having none at all, because the hardware route was never going to happen in the first place.

So treat this for what it is: not a replacement for a hardware PAW where the threat model genuinely demands one, but a viable and often far more achievable option for everyone else.

The foundation: a locked-down, monitored Cloud PC

Before we get to the reprovisioning, one thing has to be crystal clear: an ephemeral PAW is only as strong as the Cloud PC underneath it. Wiping the machine after every session is the last layer, not the first. The Cloud PC itself has to be one of the most tightly controlled devices in the whole tenant. A few things that, for me, are non-negotiable.

Security baselines and attack surface reduction

The Cloud PC runs against Intune security baselines (the Windows and Edge baselines as the starting point), tightened for the privileged use case. Attack surface reduction rules, controlled folder access, no local admin for the signed-in user, a minimal and explicitly approved app set. The logic is the same as for a hardware PAW: this device exists to do administrative work and nothing else, so everything that is not strictly needed gets switched off.

Locking down the session itself

Hardening the operating system is only half the job. The remote session is also a data path, and on a PAW you want tight control over what can leave it. Windows 365 and the underlying RDP stack expose a set of session controls that I treat as standard for the privileged use case, most of them configurable centrally through the Intune settings catalog (Azure Virtual Desktop category) or the provisioning policy:

• Clipboard and copy-paste. Clipboard redirection is restricted. Depending on the requirement that means fully disabled, or one-directional (for example allow paste into the session but block copy out), and limited to plain text where the platform supports it. The goal is simple: an admin cannot quietly copy secrets out of the privileged session onto their personal machine.
• Drive and storage redirection. Disabled. No mapping of local drives into the session, which removes an obvious file exfiltration channel.
• Device redirection. USB, printers, cameras, microphones and COM or serial redirection are switched off unless a specific workflow genuinely needs them. Every open redirection is an attack and exfiltration surface.
• Screen capture protection. Enabled, so session content is blocked from screen-capturing and screen-recording software on the client. A capture tool pointed at the privileged session gets a blacked-out window instead of content.
• Watermarking (optional, recommended for high-security). When enabled, the session shows QR-code watermarks that encode the connection and session identifiers. It will not stop someone from photographing the screen with a phone, but it makes any such capture traceable back to a specific session and user, which is both a deterrent and a useful audit aid.

Not every control fits every environment, and some of them (clipboard and redirection especially) have a direct impact on day-to-day usability. So this is a conscious decision per scenario, not a blanket “switch everything off.” For a true Tier 0 PAW I lean to the strict end. For a broader privileged-access scenario you might deliberately allow one-way clipboard or printing. The mechanisms are all there, the real work is choosing the right level.

Defender for Endpoint onboarding

Every Cloud PC is onboarded to Microsoft Defender for Endpoint, and that matters more here than on a normal endpoint, precisely because the machine is ephemeral. Once it is reprovisioned, the local state is gone. The device timeline, alerts and advanced hunting data in Defender are what give me a durable record of what actually happened during a privileged session: which processes ran, which connections were made, whether anything looked off. Without EDR telemetry flowing into the cloud, a wiped machine would also wipe its own forensic trail. With it, the reset stays clean and the history is preserved where it belongs, off the box and in the security stack.

Conditional Access with phishing-resistant MFA

Access to the Windows 365 Cloud PC is gated by Conditional Access, and for a PAW that means the strongest authentication you have. A phishing-resistant authentication strength is mandatory (FIDO2 security keys, passkeys, or certificate-based authentication with a smart card), not just “any MFA.” Password plus push approval is not good enough for a machine that effectively holds the keys to the kingdom. On top of that come a compliant-device requirement, sign-in risk and session controls, and network or location scoping where it fits. The Cloud PC is the privileged target, so the front door is locked to match.

External identities: B2B guests get a PAW too

One of the underrated strengths of putting the PAW in the cloud is that external identities work natively. External administrators, managed service providers or project consultants can be onboarded as B2B guest users and handed access to the same hardened, ephemeral Cloud PC, under the same Conditional Access policies and the same phishing-resistant MFA requirement (enforced through cross-tenant access settings and authentication strength for guests). No shipping a hardware device to an external party, no separate trust setup, no exceptions to the access model. They get a clean, policy-controlled admin workstation that resets after every session, exactly like internal staff do. Anyone who has tried to give a contractor secure privileged access the traditional way knows how much that is worth on its own.

What the platform already solves, and what it does not?

With that foundation in place, let me be precise about what is actually a gap, because Flex shared mode already does more here than people often assume.

Shared mode is non-persistent by design. When a user signs out, their profile and data are removed, and with snapshot-based reset the Cloud PC reverts to a clean state before the next user connects. Plain user-data carryover between sessions is therefore handled natively. You do not need to build anything for that, and any post that claims otherwise is overselling the problem.

The distinction that still matters for a high-assurance PAW is snapshot revert versus image rebuild. A snapshot reset restores a captured point-in-time state. It does not rebuild the machine from source. For a privileged workstation I want every session to start from a known-good, freshly provisioned image, not from a snapshot baseline whose integrity I have to keep trusting session after session. A full reprovision rebuilds the Cloud PC from the image and pulls in the latest patched build each cycle, which is a stronger guarantee than reverting to a fixed baseline.

Native reprovisioning does exist, manually and as a scheduled or bulk action, but it does not fire automatically after every single sign-out. That last piece, an automatic full image rebuild triggered on every logoff, is the narrow but real gap I close. So this is not a fix for “leftover data,” that is solved. It is a clean-source guarantee for the scenarios where reverting to a snapshot is not good enough.

When one user signs out and the next is handed the same Cloud PC, a privileged session still has to be provably isolated. Native reset gets you a clean state. A rebuild from image gets you a clean origin. For a PAW I want both.

The solution in one sentence

The W365 Reprovisioning Trigger kicks off a full reprovisioning of the Cloud PC on every sign-out, guaranteeing the next user a freshly provisioned, clean desktop.

How it works

The flow is deliberately simple and event-driven:

1. A user signs out of the Windows 365 Cloud PC.
2. A scheduled task on the Cloud PC detects the logoff event (Event ID 23).
3. A configurable grace period (default: 30 seconds) elapses. During this window it checks whether someone signs back in, which prevents pointless reprovisioning on short reconnects.
4. If the machine stays idle, a client script calls a webhook, specifically an Azure Function, passing along the device name.
5. The Azure Function queries the matching Cloud PC through the Microsoft Graph API.
6. It calls the Graph endpoint for reprovisioning.
7. The Windows 365 service resets the Cloud PC (takes roughly 5 minutes).
8. A clean desktop is ready for the next user.

Schematically:

Cloud PC (Logoff)  ->  Scheduled Task          ->  Azure Function       ->  Graph API
   Event ID 23         (SYSTEM, Grace Period)      (Managed Identity)       reprovision

See it in action

Reading the steps is one thing, watching the reset happen is another. The short demo below walks through the full flow end to end: a user signs out, the grace period elapses, the webhook fires, and a few minutes later the Cloud PC comes back as a clean, freshly provisioned desktop.

Architecture and components

The solution consists of three building blocks.

1. Client side (on the Cloud PC)

A PowerShell-based scheduled task that runs under the SYSTEM account, catches the logoff event and fires the webhook once the grace period expires. Delivery happens either through Intune (as a Win32 app) or directly in the golden image, in both cases including install, uninstall and detection scripts.

2. Backend (Azure Function App)

An Azure Function written in PowerShell 7.4, running on a dedicated B1 plan (always-on), integrated into a virtual network, encapsulating the actual Graph API logic: find the matching Cloud PC by device name and reprovision it.

3. Infrastructure (Infrastructure as Code)

The complete Azure environment is deployed in a single run via Bicep and deployment scripts (PowerShell for Windows, Bash for macOS, Linux and WSL): resource group, storage, VNet, private endpoints, App Service plan, Log Analytics, Application Insights and the Function App itself.

What makes it secure

Security here was not a bolt-on afterthought, it was a design principle:

• Zero stored secrets. Access to the Graph API runs exclusively through a managed identity. There are no passwords, client secrets or certificates lying around.
• Function key authentication. The webhook is protected by an Azure Function key.
• Private endpoints and VNet integration. Communication between the Function and storage stays private, with no public access.
• Complete auditing. Every trigger attempt is logged to the Windows Event Log, and the backend delivers full telemetry through Application Insights.

What it costs

An often underestimated point: the running costs stay modest, roughly 79 USD per month.

Resource	SKU	approx. cost
App Service Plan	B1 Dedicated (Windows, always-on)	~55 USD
Storage Account	Standard LRS	~1 USD
Private Endpoints	3x (Blob, Queue, Table)	~22 USD
Log Analytics and App Insights	Pay-per-use	~1 USD
Total		~79 USD

Prerequisites

• Windows 365 Flex in Shared mode with an active provisioning policy
• An active Cloud PC provisioning policy
• An Azure subscription with the Contributor role, plus the Privileged Role Administrator role in Entra ID to assign the Graph permission CloudPC.ReadWrite.All (a Global Administrator covers both)
• Azure CLI 2.50+ and PowerShell 7.x for the deployment

Conclusion

With relatively few moving parts, the W365 Reprovisioning Trigger solves a concrete, real-world security problem of shared Cloud PCs: no user ever finds the remnants of another. Fully automatic, traceably logged, with no stored secrets and at negligible cost.

For my Ephemeral PAW the trigger is the final layer in a deliberately layered concept. The hardened baseline, the locked-down session (clipboard and redirection controls, screen capture protection, optional watermarking), Defender onboarding for a durable session timeline, and Conditional Access with phishing-resistant MFA (for internal staff and B2B guests alike) build a Cloud PC that is genuinely locked down while it is in use. The reprovisioning trigger then guarantees that this locked-down state is also a fresh state at the start of every single session. Together they turn “a shared Cloud PC” into a real Privileged Access Workstation, and a good reminder that solid privileged access does not always have to be built from large, complex platforms.

The full solution (Bicep, deployment scripts, the Azure Function backend and the client-side logoff trigger, including Intune packaging) is on GitHub under the MIT license: github.com/daniel-fraubaum/w365-reprovisioningtrigger. Deployment is a single script run that handles the resource group, all infrastructure via Bicep, the Graph permission assignment and the backend in one pass.