Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Is Quietly Mandating Enterprise PowerShell Script Signing
Transcript
- Lucas: If today's tech conversation gave you something usable, I want to start with a number that keeps coming up in enterprise IT forums: roughly 70 percent of PowerShell scripts in large organizations are still unsigned. That's according to a survey from the PowerShell team's own community calls last year. Luna: And that is about to become a real problem, isn't it? Because Windows 11 is quietly changing the rules around unsigned script execution. Lucas: Exactly right. Starting with the 2025 feature update — which most enterprise devices are now on — Microsoft has tightened the default PowerShell execution policy for devices managed through Intune or subject to a Windows security baseline. The policy is now 'RemoteSigned' by default, which means any script downloaded from the internet or a network share must be signed by a trusted publisher. But the real shift is coming next year: Microsoft has announced that in the 2027 feature update, the execution policy for devices enrolled in Intune will move to 'AllSigned' — meaning every single script, including locally written ones, will require a valid digital signature. Luna: So that is a massive change for IT teams that rely on hundreds of ad-hoc scripts for provisioning, reporting, and maintenance. And I bet a lot of them don't even know this is coming. Lucas: That's the quiet part. Microsoft hasn't exactly shouted this from the rooftops. It's buried in the Windows 11 release health dashboard and in some Intune documentation updates from late 2025. But the signal is clear: they want all enterprise script execution to be signed and auditable. This ties directly into their broader Device Guard and Windows Defender Application Control push — the vision is that every executable, whether it's an EXE, a DLL, or a PowerShell script, should have a cryptographic chain of trust. Luna: And this also aligns with the hardware root of trust mandate we talked about in episode 71. It's all part of the same zero-trust architecture. Lucas: Exactly. And here's the thing — for many IT departments, the practical impact is going to be painful. Think about all those scripts that automate user onboarding, software installations, log file parsing, or connecting to various APIs. If those scripts aren't signed with a code signing certificate that chains to a trusted root, they will simply stop running. PowerShell will throw a security error and refuse to execute them. Luna: And managing code signing certificates at scale is not trivial. You need a certificate authority, a process to sign scripts as part of your CI/CD pipeline, and a way to deploy the root certificate to every device. Plus, if you're using self-signed certificates, you have to ensure they're trusted on every machine. Lucas: Right. And that's where many organizations will run into trouble. The typical approach is to use an internal public key infrastructure — PKI — to issue code signing certificates. But setting up a PKI properly is complex. Alternatively, you can purchase a code signing certificate from a public CA, but those are expensive and often require hardware tokens for security. Microsoft is also pushing for 'time-stamping' of signatures, so that scripts remain valid even after the signing certificate expires — that adds another layer of process. Luna: And we should also mention that this isn't just about PowerShell. It's about any scripting language that can be controlled via Windows Defender Application Control — like VBScript, JScript, and even Python scripts if they're executed through a host that integrates with WDAC. Lucas: Good point. But PowerShell is the big one because it's so deeply embedded in Windows management. Let me give a concrete example. A mid-sized company I spoke with has about 400 PowerShell scripts that they use for daily operations. They estimate that fewer than 50 are currently signed. They have eighteen months to fix that. If they don't, their entire automated onboarding process breaks, their log rotation fails, and their compliance reporting goes dark. Luna: So what should IT teams be doing right now, in mid-2026, to prepare? Lucas: First, audit every script. Use a tool like the PowerShell Script Analyzer to inventory all scripts in your environment. Categorize them by criticality. Second, set up a code signing infrastructure — even if you start with a simple internal CA, it's better than nothing. Third, integrate signing into your development pipeline. For example, you can use Azure DevOps or GitHub Actions to automatically sign scripts after they pass code review. Fourth, test the 'AllSigned' policy in a lab environment well before the 2027 update hits. Luna: And there's also a cultural shift. Developers and IT pros are used to writing scripts quickly and running them without ceremony. This forces a more formal development lifecycle. Lucas: Yeah, that's a real change. Microsoft is essentially saying that any code running on a managed device should be treated like a production application. And honestly, from a security perspective, that makes sense. Unsigned scripts are a common vector for lateral movement and malware. But it does add friction. Luna: And we should note that this is not just a Windows 11 thing. It's also coming to Windows 10 LTSC and Windows Server 2025. So even if you're not on Windows 11, you'll feel it. Lucas: Absolutely. Microsoft has made it clear that the security baseline for all supported Windows versions will converge on 'AllSigned' for PowerShell over the next couple of years. So there's no hiding from it. Luna: Let me ask a practical question: what about scripts that are signed but use a certificate that expires? Do they stop working? Lucas: That's where time-stamping comes in. If you include a time-stamp from a trusted authority when you sign the script, the signature remains valid even after the certificate expires — because the time-stamp proves the script was signed when the certificate was still valid. Without time-stamping, you'd have to re-sign every script every time the certificate is renewed. So definitely use a time-stamp server. Luna: Good advice. Let's also talk about exceptions. Are there any legitimate cases where unsigned scripts might still be allowed? Lucas: Microsoft does provide some escape hatches. For example, in Intune, you can create a policy that allows scripts from specific trusted locations — like a internal file share that's controlled by your security team. But that's a temporary measure. The long-term direction is to close those loopholes. Also, for scripts that are part of a signed application — like an MSI that includes a PowerShell script — the script may be considered trusted if the application itself is signed. But that's not guaranteed. Luna: And there's a nuance with PowerShell 7, the cross-platform version. It has its own execution policy settings that can be configured independently. But on Windows, it still respects the system-wide policy by default. Lucas: Right. And let's not forget about constrained language mode. When PowerShell runs in constrained language mode — which is often enforced by WDAC — it limits what commands are available. That's another layer of security, but it can also break scripts that use advanced.NET types or COM objects. So teams need to test their scripts under constrained language mode as well. Luna: Okay, so to wrap up: the message is clear. If you're in enterprise IT and you haven't started signing your PowerShell scripts, now is the time. Don't wait until the 2027 update forces your hand. Lucas: Absolutely. And on that note, I think we've given our listeners a solid action plan. For those of you who want to dig deeper, I'd suggest looking at the Microsoft documentation on 'Plan for PowerShell Script Signing in Windows 11' — it's a detailed guide. Also, check out the PowerShell team's GitHub repo for sample signing scripts and a lab setup. Luna: Good resources. And we'll link to those in the show notes. Thanks for listening, and we'll catch you next time. Lucas: Take care.