PowerShell Is a Security Risk – Here’s How to Fix It
If you run a Windows environment, you already know how critical PowerShell is. It’s the backbone of modern administration, used for automation, configuration, and day-to-day operations at scale. And it doesn’t stop at Windows.
Music giant BMG sues Anthropic over AI training
If you run a Windows environment, you already know how critical PowerShell is. It’s the backbone of modern administration, used for automation, configuration, and day-to-day operations at scale. And it doesn’t stop at Windows. If you manage Azure, Microsoft 365, Entra ID, or Exchange Online, PowerShell is likely how you do it. A compromised session isn’t just an endpoint risk. It’s a path to your cloud infrastructure and identity layer. There’s no avoiding it.
And that’s exactly the problem.
PowerShell is also one of the most common entry points for attackers. Once it’s compromised, the blast radius grows quickly. Lateral movement, credential harvesting, persistence, and data exfiltration all become easier.
The uncomfortable truth is that most organizations still haven’t figured out how to securely manage privilege in PowerShell.
Why Privileged Access Is the Weak Link in PowerShell Security
PowerShell itself isn’t the issue. The real problem is how privilege is handled around it.
Unix and Linux solved this years ago with sudo, enabling controlled, command-level privilege elevation. Windows never introduced a true equivalent. Instead, teams rely on workarounds—shared admin credentials, permanent privileged accounts, or broadly assigned access that’s difficult to unwind.
But none of these approaches align with Zero Trust. They expand the attack surface instead of reducing it.
At the same time, PowerShell introduces its own risks such as inconsistent logging, unrestricted script execution, and limited control over who can run what. When you combine powerful tooling with weak privilege controls, you get increased identity-driven attacks.
How to Secure PowerShell?
Monitoring PowerShell isn’t enough. Logging and session recording help after the fact, but they don’t stop misuse in the moment.
To actually secure PowerShell, control needs to happen at the point of execution. That means:
No exposed administrator credentials
No standing privilege
No blind spots in session activity
No dependency on endpoint agents
Just as important, it has to work without slowing teams down. If security adds friction, it will be bypassed.
Brokered Privilege Elevation for PowerShell
What if privilege elevation on Windows worked more like it does in modern Zero Trust systems?
Instead of logging in as an admin or distributing credentials, a Privileged Access Management (PAM) solution can broker the session itself.
At 12Port, we’ve taken this approach with a new PowerShell proxy capability. The idea is simple. Users shouldn’t need to possess privileged credentials to use them.
Here’s how it works. A user connects to a Windows system using their standard privileges. When they need to run something that requires elevated rights, they initiate the action through the 12Port PAM platform using their standard PowerShell client. Behind the scenes, 12Port brokers the session. The platform connects back to the same endpoint, retrieves the appropriate credentials from the vault, and injects them into the session dynamically.
From the user’s perspective, it feels native. But the credentials are never exposed, stored, or reusable.
That shift—removing credentials from the user entirely—is what changes the security model.
Brokering PowerShell sessions through PAM reduces risk while simplifying how administrators work. Instead of juggling privileged accounts or managing passwords, users can run elevated commands within their normal workflow. Access can be precisely scoped to specific systems, commands, or timeframes, with approvals built directly into the process rather than handled informally.
This approach also provides clear, centralized visibility into privileged activity. Security teams can see not just who accessed a system, but exactly what actions were taken and when. Because the model is agentless, there’s no need to deploy or maintain software across endpoints—control is enforced at the session and network layer, making it easier to scale.
The impact is immediate across common scenarios. Routine administrative tasks like patching or service updates can be performed within defined guardrails. Delegated access becomes more controlled, allowing specific elevated actions instead of broad permissions. During incident response, teams can review session activity and reconstruct events with confidence. The same visibility and policy enforcement also help simplify compliance with frameworks such as NIST, ISO, and SOC 2.
Rethinking PowerShell Security with Zero Trust Privilege Control
What we’re really doing is shifting the model of trust. Instead of handing users credentials and hoping they’re used correctly, access is enforced in real time by the system. Privilege isn’t assumed or persistent. It’s conditional, granted only when needed and governed by policy. The focus moves away from managing endpoints and toward controlling access itself.
PowerShell isn’t going anywhere, and it’s only becoming more central to Windows operations. The question is whether it remains an open risk or becomes a controlled, secure interface. Privilege elevation is the turning point. Get that right, and you materially reduce risk across the entire Windows environment.
Download a free trial of 12Port to try the new PowerShell Proxy.
The post PowerShell Is a Security Risk – Here’s How to Fix It appeared first on 12Port.
*** This is a Security Bloggers Network syndicated blog from 12Port authored by Peter Senescu. Read the original post at: https://www.12port.com/blog/powershell-is-a-security-risk-heres-how-to-fix-it/
About Author
