"Running Scripts Is Disabled on This System": PowerShell Execution Policy, Safely
If PowerShell tells you a file "cannot be loaded because running scripts is disabled on this system," the fix is one command: open PowerShell as administrator and run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser, then type Y to confirm. Here's the part almost nobody tells you: this setting was never designed to stop a determined attacker in the first place. Microsoft's own documentation calls it "defense in depth," not a security boundary — anyone blocked from running a script can just paste its contents into the console line by line and get the exact same result. You're not disabling a lock. You're turning off a doorbell.
Jake had already promised the customer their trade-in phone would be wiped and reset by five o'clock. The vendor's diagnostic tool was a .ps1 script, double-clicked, and instead of running it just flashed a black window and closed. He opened it from PowerShell directly to see what happened, and there it was: "cannot be loaded because running scripts is disabled on this system." No wipe, no five o'clock, and a customer sitting in the shop.
What "Running Scripts Is Disabled" Actually Means
PowerShell is the command-line and scripting tool built into every copy of Windows 11 and Windows 10. A "script" here just means a text file ending in .ps1 — a saved list of PowerShell commands, the same commands you could type one at a time, bundled so you can run them all at once. That bundling is exactly what the error is reacting to.
Every Windows installation has a setting called the execution policy, which controls whether .ps1 files are allowed to run at all, and whether they need a digital signature (a cryptographic stamp proving who wrote them and that they haven't been altered) before they will. Windows PowerShell and PowerShell 7 both maintain this setting on Windows computers specifically — it doesn't exist as a real restriction on macOS or Linux, where PowerShell just runs everything by default.
On a brand-new Windows 11 or Windows 10 machine, if nobody has ever touched this setting, PowerShell treats the policy as Restricted for a regular Windows client. Restricted means individual commands typed at the prompt work fine, but no script file of any kind is allowed to load — not one you wrote yourself, not one from a coworker, not one from a well-known vendor. That's the wall Jake hit.
🙋♂️ Jake's Reality Check
"So Microsoft ships every PC with scripts turned off by default? Why would they do that on purpose?"
Because most people who open PowerShell by accident have no idea what a script does, and a script can do a lot more damage than a wrong click in a normal program. Restricted is the safety-off setting for people who never meant to open PowerShell in the first place. It isn't a sign your PC is broken — it's the factory default doing exactly what it's supposed to do.
Check Which Policy You Actually Have Right Now
Before changing anything, look at what's actually set. Open PowerShell — you don't need administrator rights just to check — and run:
Get-ExecutionPolicy -List
This prints five rows, one for each place a policy can be set, in the exact order PowerShell checks them. The first one with an actual value wins; everything below it is ignored for that session.
| Scope | Who set it | Precedence |
|---|---|---|
| MachinePolicy | IT admin, via Group Policy | Highest — you cannot override this yourself |
| UserPolicy | IT admin, via Group Policy | Same as above, applies per user |
| Process | A flag on the command that opened this session | Highest one you control; gone when the window closes |
| CurrentUser | You, without admin rights | Saved permanently for your account only |
| LocalMachine | Anyone running PowerShell as administrator | Lowest; affects every account on the PC |
If every row says Undefined, the effective policy falls back to Restricted on a Windows client — which is almost certainly what Jake saw. If MachinePolicy or UserPolicy already has a value, skip straight to the Group Policy section further down, because nothing you type into Set-ExecutionPolicy will change your effective policy until that's dealt with.
Fix 1: Run This One Script Right Now, Change Nothing Permanently
If you just need this one file to run today and don't want to touch the machine's settings at all, set the policy for the Process scope only. It lives in memory for the current PowerShell window and disappears the moment you close it — nothing is written to disk.
- Open PowerShell (administrator rights are not required for the Process scope).
- Run
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Processand confirm with Y if prompted. - Run your script normally, for example
.\GenerateRpt.ps1. - Close the window when you're done — the temporary setting is gone with it.
There's a one-line version of the same idea that skips opening PowerShell first: from the Run box (Win + R) or Command Prompt, run:
powershell.exe -ExecutionPolicy Bypass -File "C:\path\to\yourscript.ps1"
This is the version vendors put in their own launcher batch files, because it asks nothing of the person running it and leaves their system exactly as it found it. It's also the version to reach for if a script is something you'll run once and never again — a one-off migration tool, a single diagnostic a vendor emailed you, that kind of thing.
Fix 2: Allow Local Scripts For Your Account, Permanently
If you write or run PowerShell scripts more than once a month, doing the Bypass dance every time gets old fast. The setting almost everyone should land on instead is RemoteSigned at the CurrentUser scope — it's also the built-in default policy Microsoft ships for Windows clients and servers when nothing else is configured, so setting it explicitly for yourself just makes that default permanent and visible.
- Open PowerShell. Administrator rights are not required for the CurrentUser scope, because it only touches your own account's settings.
- Run
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser. - Type Y and press Enter when PowerShell asks you to confirm the change.
- Run
Get-ExecutionPolicy -Listagain to confirm CurrentUser now shows RemoteSigned.
RemoteSigned means scripts you wrote yourself, or that were created directly on your computer, run without a fight. Anything that arrived from the internet — downloaded through a browser, attached to an email, sent over chat — still needs a valid digital signature from a trusted publisher, or it gets blocked with a related but different error about the file "not being digitally signed." That's a deliberate second checkpoint, not a bug, and it's covered on its own further down.
✅ Why this is the one to use
RemoteSigned at CurrentUser gives you everything the Restricted default was protecting you from — running scripts you don't recognize by accident — while removing the actual annoyance, which is that your own scripts got caught in the same net. It also doesn't touch other accounts on a shared PC, so you're not loosening security for anyone but yourself.
Fix 3: Set It For Every Account on the Machine
On a shared computer, a family PC, or a machine where scheduled tasks and services need to run scripts under a different account than the one you're logged in as, CurrentUser won't help. You need the LocalMachine scope instead, which requires an elevated (administrator) PowerShell window because it changes behavior for every account on the device.
Right-click the Start button, choose Terminal (Admin) or Windows PowerShell (Admin), accept the User Account Control prompt, then run:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
⚠️ What this actually breaks
LocalMachine still loses to a CurrentUser or Process setting for any account that has one, because of the precedence order above. If you set LocalMachine to RemoteSigned but a particular account already has CurrentUser set to something stricter, that account is unaffected. Check both scopes before assuming a machine-wide change fixed things for everyone.
When Set-ExecutionPolicy Doesn't Stick: Group Policy Is Overriding You
This is the scenario that makes people write angry forum posts titled "Set-ExecutionPolicy doesn't work." It usually does work — it's just being overruled. If Get-ExecutionPolicy -List shows anything other than Undefined for MachinePolicy or UserPolicy, a Group Policy setting called Turn on Script Execution has been applied, and Group Policy always wins over anything set directly in PowerShell, in every scope, with no exceptions.
Trying to change MachinePolicy or UserPolicy yourself with Set-ExecutionPolicy produces an error explaining that the scope is controlled by Group Policy and cannot be changed that way — which is at least an honest error, unlike the plain "disabled on this system" message.
🙋♂️ Jake's Reality Check
"My work laptop is company-managed. I ran the RemoteSigned command, it said Y, and nothing changed. Am I doing it wrong?"
Probably not — your IT department set it, and only they can change it. Ethan's take is that this is the one situation where you should stop troubleshooting and open a ticket instead of trying registry edits or third-party workarounds, because a Group Policy setting on a company laptop exists on purpose, and getting around it can put you in breach of company policy even if it's technically possible.
Windows 11 and Windows 10: Same Command, One Practical Difference
Everything above — Get-ExecutionPolicy, Set-ExecutionPolicy, the scope names, the precedence order — is identical on Windows 11 and Windows 10. This is a PowerShell setting, not a Windows shell feature, so there's no version split in the commands themselves. If you're following a guide written for Windows 10, it applies to Windows 11 word for word.
Where Windows 11 differs is only in how you get to an elevated PowerShell window. Right-click the Start button on Windows 11 and you'll usually see "Terminal (Admin)" rather than "Windows PowerShell (Admin)" — Windows Terminal is the default host now, but it's still running the same PowerShell engine underneath, and every command in this guide behaves the same inside it. On Windows 10, right-clicking Start shows "Windows PowerShell (Admin)" directly.
One more thing worth saying plainly for anyone still on Windows 10: support for Windows 10 ended on October 14, 2025, and the operating system no longer receives free security updates unless you've enrolled in Extended Security Updates. That has no bearing on execution policy behavior — it still works exactly as described here — but if you're troubleshooting PowerShell issues on an unsupported Windows 10 machine, an ESU enrollment or a Windows 11 upgrade is worth putting on the list, separate from this particular error.
The Sibling Error: "The File Is Not Digitally Signed"
If you've already set RemoteSigned and now see a different message — "the file is not digitally signed, you cannot run this script on the current system" — that's not the same problem, and RemoteSigned did exactly what it was designed to do. This message means PowerShell recognizes the file as having come from outside your machine, and it has no signature to verify.
You have three honest options here, and no fourth option that avoids the tradeoff:
- Get the script from its author signed, if that's realistic for how you obtained it.
- Unblock the specific file, covered in the next section, if you trust the source and just want RemoteSigned to stop flagging this one download.
- Temporarily raise the policy to Unrestricted or Bypass for a single Process-scoped session, run the script, then let the setting expire when you close the window.
Unblocking Scripts You Downloaded From the Internet
When Internet Explorer, Microsoft Edge, or a similar program downloads a file, Windows tags it with something called an alternate data stream — an extra, invisible piece of metadata attached to the file marking it as having come from the internet. RemoteSigned checks for that tag specifically. Notably, tools like curl.exe, Invoke-WebRequest, and Invoke-RestMethod don't always apply that same tag, which is why a script downloaded one way triggers the signature check and the same file downloaded another way sometimes doesn't.
To remove the tag from a script you've decided you trust, run:
Unblock-File -Path "C:\path\to\yourscript.ps1"
This doesn't touch your execution policy at all — it changes the file itself. Once unblocked, RemoteSigned treats it as a local, trusted file and stops asking for a signature. If you have a whole folder of scripts from the same vendor, you can unblock them all at once with Get-ChildItem -Path "C:\Scripts" -Recurse | Unblock-File.
Bypass vs RemoteSigned vs AllSigned vs Unrestricted: Which One Should You Actually Use
There are six policy names in total, but only four come up in normal troubleshooting. Here's what each one actually does, not what its name implies:
| Policy | What it allows | Use it when |
|---|---|---|
| Restricted | No scripts at all, individual commands only | This is the factory default; leave it alone if you never run scripts |
| RemoteSigned | Local scripts run freely; downloaded scripts need a signature or an unblock | Everyday use — this is the built-in Windows default when nothing else is set |
| AllSigned | Every script, including ones you write yourself, must be signed | Managed environments where every script must be traceable to a publisher |
| Bypass | Nothing blocked, no prompts, no warnings | A single trusted session or a script embedded in a larger application with its own security model |
| Unrestricted | Unsigned scripts run, but you get a warning first for anything outside the local zone | Rarely, on a Windows client — RemoteSigned covers the same need with less exposure |
For most home users and small-shop setups like Jake's, RemoteSigned at CurrentUser is the answer nine times out of ten. AllSigned is what a workplace with strict compliance requirements sets through Group Policy, not something to choose for yourself unless you have a reason to. Unrestricted looks tempting because the name sounds like "just make the error go away," but it warns you every single time you run something unsigned from outside the local zone, which gets old fast and gives you the annoyance without the protection RemoteSigned already provides.
Jake's Case: Running a Vendor Script Without Opening the Door Wide
Back to the trade-in phone. The vendor's diagnostic tool was a single .ps1 file, emailed as an attachment, that Jake needed to run maybe once a week when a trade-in came through the shop's counter. Ethan's advice wasn't RemoteSigned and it wasn't Bypass — it was a specific case for Unblock-File.
"You didn't write that script, and you're going to keep getting new copies of it by email," Ethan told him. "If you set your whole account to RemoteSigned, every future email attachment gets the same free pass the moment you save it locally and run it — you've traded one problem for a bigger, permanent one. Unblock the specific file each time instead. It's one extra command, and it means nothing gets a free pass except the thing you actually looked at first."
Jake's actual fix ended up being Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser once, because he also had a handful of scripts he'd written himself for backing up customer intake forms, plus Unblock-File run once against the vendor's attachment each time a new version arrived. Two commands, five minutes, customer out the door with a wiped phone by 4:50.
VS Code, Scheduled Tasks, and Other Places This Error Hides
The error shows up outside a plain PowerShell window more often than people expect, and the fix is always the same underlying setting, just triggered from a different launcher.
A code editor's built-in terminal that runs PowerShell as its default shell is still just running PowerShell — the CurrentUser or LocalMachine fix above applies exactly as written, with no extra steps for the editor itself.
Scheduled Tasks that call a .ps1 file directly will hit the same wall if the account running the task has a Restricted policy. Rather than changing that account's permanent policy, point the task's action at powershell.exe with arguments -ExecutionPolicy Bypass -File "C:\path\to\script.ps1" — the same Process-scope trick from Fix 1, applied per task instead of per session.
Double-clicking a .ps1 file in File Explorer won't run it at all by default, execution policy aside — Windows opens PowerShell script files in a text editor rather than executing them, as a separate safety measure from the one covered in this guide. That's normal, not a sign anything is broken.
If PowerShell is also throwing an unrelated 'wmic' is not recognized error on the same machine while you're troubleshooting scripts, that's a separate, Windows-11-specific removal issue rather than an execution-policy problem — covered in detail here, including which replacement commands to use instead.
Why This Setting Is Not a Security Boundary (and Why That's Fine)
This is worth spelling out clearly because it changes how you should think about every decision above: Microsoft's own documentation states plainly that the execution policy isn't a security boundary at all. It's there to stop accidents, not attacks. A malicious actor who already has the ability to run commands on your machine can bypass any policy in seconds by typing the script's contents at the prompt one line at a time, since that was never blocked in the first place.
That doesn't mean the setting is pointless — it means its job is narrower than the scary-looking error message suggests. It stops a curious double-click, an accidental drag-and-drop, or a script that someone else's malware tries to run silently through a shortcut. It was never meant to stop someone who is deliberately trying to compromise your system through PowerShell, and treating it as if it does is the actual security mistake here.
⚠️ What this actually breaks
Because it isn't a security boundary, don't rely on execution policy as your only defense against malicious scripts. Antivirus/EDR software, not knowing where a file came from, and not running unfamiliar scripts as administrator do the actual protecting. Setting the policy to RemoteSigned or even Bypass on a well-managed home PC is a convenience decision, not a security one.
Still Blocked After Changing the Policy? Here's Why
- You changed the wrong scope. Run
Get-ExecutionPolicy -Listagain — if a higher-precedence scope (Process, or MachinePolicy/UserPolicy from Group Policy) still has a stricter value, your CurrentUser or LocalMachine change is technically active but has no effect. - You're using Windows PowerShell 5.1 and PowerShell 7 as if they were one program. They maintain independent execution policy settings. Setting the policy inside a "PowerShell 7" window doesn't change what "Windows PowerShell" (the older, built-in version) reports, and vice versa — check which one your shortcut or script actually launches.
- You skipped elevation for LocalMachine. Attempting to set the LocalMachine scope from a non-administrator window fails silently or with an access-denied error, depending on the PowerShell version — always right-click and "Run as administrator" first for that specific scope.
- You're seeing the digital-signature error, not the execution-policy error. These look similar but need different fixes — see the signed-scripts section above rather than raising the policy further.
- The Windows Desktop Shell wasn't ready to verify the file's zone. On Windows Server Core, Nano Server, or occasionally during very early sign-on scripts, PowerShell can't check whether a file came from the internet because the component it relies on (explorer.exe) isn't running yet, producing an "AuthorizationManager check failed" error instead. Bypass or AllSigned avoid this specific check and sidestep the problem.
Frequently Asked Questions
What does "running scripts is disabled on this system" actually mean?
It means the effective PowerShell execution policy on your account, for that session, is Restricted or another value that blocks the specific script you tried to run. It's a setting, not a malfunction.
Is my computer at risk if I see this error?
No — the opposite. Seeing this error means the setting is doing its job and stopping a script from running before you decided whether you trust it. It's a safety prompt, not a symptom of infection.
What is the default PowerShell execution policy on Windows 11?
If nothing has ever been configured, the effective policy is Restricted on a Windows client machine (Windows 11 or Windows 10). PowerShell's own built-in default, if you explicitly select "Default" as a policy value, resolves to RemoteSigned for Windows clients and servers.
How do I check my current execution policy?
Open PowerShell and run Get-ExecutionPolicy for the effective policy, or Get-ExecutionPolicy -List to see every scope in precedence order.
Which execution policy should I use for everyday use?
RemoteSigned at the CurrentUser scope, for almost everyone. It lets your own scripts run and still checks anything that arrived from the internet.
Can I run a script without changing my PowerShell settings permanently?
Yes. Set the policy to Bypass for the Process scope only, or launch the script directly with powershell.exe -ExecutionPolicy Bypass -File "script.ps1". Both leave your permanent settings untouched.
Why does Set-ExecutionPolicy say the operation isn't permitted?
That message means the scope you're trying to change (usually MachinePolicy or UserPolicy) is set by Group Policy and can only be changed by whoever administers that policy — typically an IT department on a managed machine.
Why does the policy keep reverting after I change it?
A higher-precedence scope is overriding your change. Check MachinePolicy and UserPolicy first with Get-ExecutionPolicy -List, and check whether your PowerShell session itself was launched with a Process-scope flag set to something stricter.
What's the difference between CurrentUser and LocalMachine scope?
CurrentUser only changes behavior for your own account and doesn't need administrator rights. LocalMachine changes behavior for every account on the device and requires an elevated PowerShell window to set.
Why do I still get an error about the file "not being digitally signed"?
Your RemoteSigned policy is correctly blocking a downloaded, unsigned script. Either get a signed copy, unblock the specific file with Unblock-File if you trust the source, or temporarily raise the policy for one session.
Do I need to run PowerShell as administrator to change this?
Only for the LocalMachine, MachinePolicy, or UserPolicy scopes. Setting your own CurrentUser or Process scope does not require elevation.
Does this setting affect PowerShell 7 the same as Windows PowerShell 5.1?
No. The two engines keep independent execution policy settings, even on the same machine and the same account. Check which shell your script or shortcut is actually launching, and set the policy in that one.
Is Unrestricted the same as Bypass?
No. Bypass runs everything with zero prompts or warnings. Unrestricted runs unsigned scripts too, but still warns you before running anything from outside the local intranet zone — you'll see more prompts with Unrestricted than with Bypass, not fewer.
Will changing the execution policy let me run any .exe or .bat file too?
No. Execution policy only governs PowerShell script files and configuration files — .ps1, .ps1xml, and .psm1. It has no effect on .exe, .bat, or .cmd files, which are controlled by entirely different Windows security settings.
Does this apply the same way on Windows 10?
Yes. Every command and scope in this guide behaves identically on Windows 10 and Windows 11. The only difference is how you open an elevated PowerShell window, since the right-click Start menu options changed between the two versions.
How do I undo my change and go back to the default?
Run Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser (or whichever scope you changed). With every scope back to Undefined, the effective policy returns to Restricted on a Windows client, which is the original factory state.
Revision note. Written September 2026, covering Windows 11 and Windows 10, Windows PowerShell 5.1, and PowerShell 7, using the execution policy behavior documented by Microsoft. This will need a fresh look if a future PowerShell release changes the scope precedence order or the default policyso refer latest details on MS website if not worked or let me know through contact us page, i will check and update. If this error caught you mid-task the way it caught Jake, hang in there — one command and you're back to whatever you were actually trying to do.