What’s changing
Microsoft is hardening the PowerShell execution policy applied during Cloud PC provisioning. Under the stricter policy, scripts that are downloaded from a remote source must carry a valid digital signature before they will run. Locally authored scripts and signed, trusted code continue to work; unsigned downloaded scripts are blocked.
The goal is straightforward: reduce the chance that untrusted code executes on a Cloud PC during the provisioning window, when the device is being configured and is most sensitive to tampering.
Why it matters
Provisioning is a high-trust phase. Anything that runs at that point typically executes with elevated privileges and shapes the final state of the Cloud PC. Requiring signatures gives administrators a practical integrity check that a script is genuinely from the expected publisher and has not been altered in transit or at rest.
- Blocks unsigned scripts pulled from remote locations during provisioning
- Provides verifiable proof of origin and integrity for automation code
- Reduces the impact of a compromised script host or download path
- Aligns Cloud PC provisioning with signing practices already common in managed environments
What to check in your environment
If you rely on PowerShell as part of Cloud PC setup, review that automation now rather than after a provisioning failure.
- Inventory any scripts that run during or immediately after Cloud PC provisioning
- Identify scripts that are downloaded at runtime rather than packaged locally
- Sign those scripts with a code-signing certificate your Cloud PCs trust
- Confirm the signing certificate chain is present and trusted on the target image
- Test provisioning end to end and watch for script execution failures in your logs
Practical guidance
Where possible, avoid runtime downloads altogether. Packaging scripts into a signed deployment, an app package, or a configuration policy is more predictable than fetching code during provisioning. If a download is unavoidable, treat signing as a standard part of your release process so every published version is signed automatically rather than by hand.
It is also worth documenting which certificate signs your automation and who controls it. When a signature check fails, the fastest path to resolution is knowing exactly which certificate should have been used and whether it is still valid and trusted.
Bottom line
This is a sensible tightening of defaults rather than a disruptive redesign. Admins who already sign their PowerShell code will notice little difference. Those who fetch unsigned scripts during Cloud PC provisioning should plan signing work now to avoid broken deployments later.
Source: Microsoft Learn. Summarised independently — check the source for the latest detail.