What Is WinRM? Remote PowerShell Setup and Security

Updated: October 2026

Every Windows machine ships with a remote management service that users never see. It sits idle until an admin, a script or an attacker asks it to run something. Here's what WinRM is, how to enable it on one PC or a whole domain, how to fix the errors it throws, and how to lock it down.

What Is WinRM?

WinRM, short for Windows Remote Management, is Microsoft's implementation of WS-Management, an open standard for managing machines over HTTP. It's installed on every supported version of Windows. The service can be running and still accept nothing, because by default no listener is configured.

A listener is what turns WinRM on in practice. Once one exists, other tools can send commands to the machine and get results back. PowerShell Remoting (Enter-PSSession, Invoke-Command, New-PSSession) rides on it. So do winrs for one-off remote commands and Windows event forwarding. Windows Admin Center, Ansible for Windows and a range of monitoring and RMM products use it to reach Windows machines too.

One detail trips people up. Running a cmdlet with -ComputerName, like Get-Service -ComputerName SRV01, doesn't use WinRM at all. Microsoft's docs point out it uses Remote Procedure Call (RPC). PowerShell Remoting is the WinRM path.

WinRM Ports: 5985 and 5986

WinRM listens on TCP port 5985 for HTTP and 5986 for HTTPS. Old versions used 80 and 443, and Windows can still add those as compatibility listeners, but they're off by default.

HTTP on 5985 doesn't mean plain text. After authentication, WinRM encrypts the session with the key that Kerberos or NTLM negotiated. Microsoft's PowerShell remoting security guide says WinRM always encrypts remoting traffic after initial authentication, whichever transport you pick. The exception is Basic authentication, which sends credentials in clear text and adds no encryption. On the service side, Basic is off by default.

What HTTPS adds is proof of the server's identity when Kerberos can't provide it. The TrustedHosts section below covers when that matters.

How to Enable WinRM on One Machine

On Windows Server, PowerShell Remoting is on by default. On Windows 10 and 11, the WinRM service is disabled until you turn it on. Two commands do the job from an elevated prompt:

powershell
# PowerShell: configures WinRM and the PowerShell endpoints
Enable-PSRemoting -Force

# Command prompt: configures WinRM only
winrm quickconfig

Enable-PSRemoting starts the WinRM service, sets it to start automatically, creates a listener on every IP address and adds a firewall exception. It also registers the PowerShell session endpoints, which winrm quickconfig doesn't.

On a laptop whose network is set to Public, Enable-PSRemoting refuses to run. The -SkipNetworkProfileCheck switch gets past that, and it limits the Public firewall rule to the local subnet. Fix the network profile instead if the machine is on your own network.

Check the result from another machine:

powershell
Test-WSMan -ComputerName PC-042
winrm enumerate winrm/config/listener

Test-WSMan answers with the protocol version if the listener responds. Our list of PowerShell commands covers what to run once you're connected.

Enable WinRM Across a Domain With Group Policy

Running a command on 300 PCs defeats the point. In a domain, three Group Policy settings do the same thing for every machine in an OU.

1. The listener. Under Computer Configuration, Administrative Templates, Windows Components, Windows Remote Management (WinRM), WinRM Service, enable "Allow remote server management through WinRM". Older templates call it "Allow automatic configuration of listeners". Set the IPv4 filter to the addresses the listener should bind to.
2. The service. Set the Windows Remote Management (WS-Management) service to Automatic, through System Services or a Group Policy Preference.
3. The firewall. Enable the predefined Windows Remote Management inbound rule, and scope its remote addresses to your management hosts, not Any.

If the policy is wrong, clients show a listener with an empty ListeningOn value, and connections fail with "The client cannot connect to the destination specified in the request". Get-WSManInstance winrm/config/listener -Enumerate shows it.

Tools that depend on WinRM inherit this setup. Windows Admin Center is the common one, and a server that WAC can't reach usually has a WinRM problem underneath.

Kerberos, TrustedHosts and HTTPS

How WinRM authenticates depends on how you name the target.

Connect to a domain machine by its name, and the default is Kerberos. Kerberos proves both sides: you know the user is who they say, and you know the server is the one you meant. No reusable credential crosses the wire.

Connect by IP address, or to a workgroup machine, and Kerberos can't work. WinRM falls back to NTLM, which proves the user but not the server. Windows then refuses the connection unless you do one of two things:

• Add an HTTPS listener with a certificate the client trusts. The certificate proves the server's identity.
• Add the target to TrustedHosts on the client. This doesn't make the target trusted. Microsoft describes it as the list of hosts for which you've chosen to suppress the identity check.

Keep TrustedHosts as short as possible. Set-Item WSMan:\localhost\Client\TrustedHosts -Value * appears in a lot of tutorials, and it switches the check off for every machine you'll ever connect to.

For HTTPS, the certificate needs the server's name in the subject and the Server Authentication purpose. Then create the listener and open 5986:

powershell
$thumb = (Get-ChildItem Cert:\LocalMachine\My |
  Where-Object Subject -eq "CN=$env:COMPUTERNAME.corp.example.com").Thumbprint
New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint $thumb -Force

Certificates are where HTTPS setups stall. In this r/sysadmin thread, an admin setting up WinRM over HTTPS for Windows Admin Center gets stuck on exactly that, and one reply calls HTTPS "a huge pain" and suggests securing plain WinRM by Group Policy instead.

On a domain with Kerberos, that advice holds. HTTPS earns its keep for workgroup machines, cross-domain access and anything reached by IP.

Common WinRM Errors and Fixes

WinRM errors are long, but each one points at a specific layer. These are the ones that fill tickets.

One "Access is denied" case deserves a warning. Admins from another domain connect with a filtered, standard-user token. Microsoft documents a registry fix, LocalAccountTokenFilterPolicy, and also warns that it disables UAC remote restrictions for every user on that machine. Use a local group membership instead where you can.

Is WinRM a Security Risk?

WinRM is a management channel, and attackers use management channels. MITRE ATT&CK lists Windows Remote Management as a lateral movement technique (T1021.006): with valid credentials, an attacker runs code on other machines the same way an admin would.

That's the concern in this r/msp thread, where an MSP asks whether to enable WinRM on every managed endpoint because an RMM vendor asked for it. A reply from a security vendor's staff warns that ransomware crews use it to run scripts across a whole fleet at once.

WinRM is safe to run when you treat it like any other admin door:

1. Enable it only where it's needed. Servers and management targets, yes. Every workstation, only with a reason.
2. Scope the firewall rule to your management hosts or jump boxes.
3. Keep Basic authentication and unencrypted traffic off. Both are off by default on the service side, so check that no script turned them on.
4. Limit who can connect. Only Administrators can use the default endpoints; use Remote Management Users for anyone else.
5. Use Just Enough Administration (JEA) for delegated jobs. A JEA endpoint exposes only the commands a role needs, can run them under a temporary virtual account, and logs every command.
6. Log it. Turn on PowerShell script block logging and collect the WinRM operational log, so a remote session leaves a trail.

PDQ's short walkthrough shows the enabling steps on screen.

When an RMM Agent Is the Better Tool

WinRM needs an inbound listener on every machine you want to reach. An RMM agent works the other way: it connects out to its server and picks up work. For a fleet of laptops that move between office, home and hotel Wi-Fi, the outbound model is simpler and leaves no port open on the endpoint.

So split the jobs. Keep WinRM for servers and management networks, where Windows Admin Center, Ansible and scheduled PowerShell expect it. Use the agent for workstation scripting, and don't enable WinRM on endpoints only because a tool's install wizard asks for it. Our guide on what an RMM does covers the agent side in more detail. OpenFrame runs scripts across a client's devices through its own agent and collects the output, so workstations don't need a WinRM listener for that job.

The Short Version

WinRM is Windows' built-in remote management service, the transport under PowerShell Remoting and tools like Windows Admin Center. It listens on 5985 and 5986 once a listener exists, and it encrypts sessions after authentication even over HTTP. Enable it with Enable-PSRemoting on one machine or three Group Policy settings on many, use Kerberos by name wherever you can, and keep TrustedHosts short. Then scope it, log it and leave it off the machines that don't need it.