Windows Admin Center Security: Harden the Gateway, Access and Extensions

A Windows Admin Center gateway is a browser front door to PowerShell and WMI on every server it manages, so whoever controls the gateway can reach a large part of the Windows estate. Microsoft's documentation is explicit that access to the gateway does not by itself grant access to servers, but in practice gateways are often installed with no access groups (which lets anyone who can reach the URL sign in), with a 60-day self-signed certificate, with Kerberos delegation configured broadly for single sign-on, and with extensions nobody reviews. Two elevation of privilege flaws published in December 2025 and February 2026 are a reminder that the gateway itself needs patching like any other tier zero tool. This guide covers the gateway: deployment choices, gateway access, role-based access control (RBAC) on managed servers, delegation and CredSSP, extensions, logging and a hardening baseline. It is for Windows server and identity engineers. Host hardening of the servers themselves is in the Windows Server Hardening Guide and is not repeated here.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Define gateway access groups immediately. If no security group is specified on the Users tab, any user who can reach the gateway URL has gateway access; local administrators on the gateway are always gateway administrators and cannot be removed.
• Use Entra ID or smart card groups for strong authentication. Entra ID adds conditional access and MFA in front of the gateway, but set User assignment required to Yes on the enterprise application or every tenant member gets user access.
• Turn on RBAC on managed servers. The JEA endpoint Microsoft.Sme.PowerShell gives Administrators, Hyper-V Administrators and Readers roles, so staff can manage servers without being local administrators.
• Constrain delegation and CredSSP. Single sign-on on Windows Server uses resource-based constrained delegation per target, and CredSSP is used only for specific features after consent; neither should be enabled estate-wide by default.
• Treat the gateway as tier zero. Install it on a dedicated server (never a domain controller), use a CA-issued certificate, keep it on the latest release (only the latest non-preview release is serviced), and collect Event ID 4000 from the WindowsAdminCenter log.

How identity and access work in Windows Admin Center

Windows Admin Center (WAC) has two separate authorisation decisions. First, can this person use the gateway? Second, what can they do on the target server? The gateway uses HTTPS from the browser and manages servers with Remote PowerShell and WMI over WinRM. The modernised gateway, built on .NET 8 and the ASP.NET Core Kestrel web server with a multi-process architecture, keeps the same model.

Smart card groups: a required smart card group is evaluated with AND logic alongside the security group, so a user must be in both. Entra ID: it adds a layer on top of Windows authentication; the user's Windows account still needs gateway access and must be in the gateway server's local Users group. Two behaviours matter for design: users with Windows administrator rights on the gateway skip the Entra prompt, and local administrator rights cannot be restricted by the Entra configuration. Enabling Entra authentication restarts the gateway service. Group-based access is not supported in workgroups or across non-trusted domains. Apply your conditional access baseline to the WAC enterprise application (named SME-<gateway> in the GA release); see the Conditional Access Guide.

Choosing a deployment type

Installing WAC on a domain controller is not supported. A gateway that can manage domain controllers is itself tier zero under the Tiered Administration and Enterprise Access Model Guide: separate gateways per tier are the clean answer in larger estates, and browsers that reach a tier zero gateway should be on a privileged access workstation.

Admin roles and privileged access

RBAC applies to the Server Manager and Failover Cluster solutions. Enabling it on a target installs Microsoft.Sme* PowerShell modules under C:\Program Files\WindowsPowerShell\Modules, configures the JEA endpoint Microsoft.Sme.PowerShell through a one-time DSC configuration, creates three local groups and restarts WinRM (provisioning can take up to 10 minutes, and WAC, PowerShell and WMI sessions drop).

• Custom roles: not supported. If the three roles do not fit, use the WinRM and JEA tooling directly rather than adding people to local Administrators.
• Temporary local administrator: when a user connects to the restricted endpoint, a temporary local administrator account is created and removed when they stop managing the machine. Role membership therefore still deserves review.
• Domain groups: for many servers, export the RBAC package from the gateway and deploy it with DSC or your configuration tool, replacing the local group names with domain groups. Each role needs a unique group, or configuration fails. For small estates, Group Policy Restricted Groups keeps the local groups consistent.
• Cluster limitation: RBAC is not supported for cluster management where CredSSP-dependent features are needed; plan cluster administration accordingly (see the Windows Failover Cluster Security guide).
• LAPS: WAC supports LAPS credentials, and the logged event records whether LAPS was used. Using per-server LAPS passwords instead of a shared admin password limits lateral movement; see the LAPS Guide.

Integrations, API tokens and service accounts

• Kerberos delegation for single sign-on: on Windows 10 SSO works out of the box; on Windows Server it needs resource-based constrained delegation, set on each target by adding the gateway computer account to PrincipalsAllowedToDelegateToAccount. This makes the gateway's computer account a powerful machine identity: anyone who controls it can act as delegated users towards those targets. Configure it only for the servers that need it and remove it (set the attribute to null) when a server leaves scope. The Kerberos Delegation Security Guide explains the risks of each delegation type.
• CredSSP: WAC uses CredSSP when credentials must reach a machine beyond the managed server, currently for disaggregated SMB storage in the Virtual Machines tool and for the Updates tool (Cluster-Aware Updating) in the failover and hyper-converged cluster solutions. It configures CredSSP only after you consent and first checks that the related CredSSP security updates are installed. CredSSP exposes reusable credentials on the remote host, so keep it to the features and hosts that need it.
• Manage as credentials: when a user supplies separate credentials, the event log records both UserOnGateway and UserOnTarget. Use named admin accounts, not shared ones, so this stays meaningful.
• Gateway certificate: the TLS certificate needs the Server Authentication EKU (1.3.6.1.5.5.7.3.1) in LocalMachine\My. The installer's self-signed certificate expires after 60 days and Microsoft recommends it for testing only. Issue a certificate from your CA, record its expiry and owner, and renew it before it lapses.
• Azure registration: registering the gateway with Azure creates an Entra application, which is an identity your Entra administrators should own and review. WAC does not require internet access or Azure; skip the registration if you do not use the integrations.
• WinRM transport: custom setup offers WinRM over HTTPS and a trusted hosts mode. Prefer Kerberos in a domain, and WinRM over HTTPS where you need encryption guarantees beyond Kerberos session protection or manage non-domain machines; avoid broad TrustedHosts entries.

Extensions

Extensions run inside the gateway and act on managed servers, so they are code with administrative reach. The default feed is Microsoft's official NuGet feed, which hosts extensions from Microsoft and other developers. Custom feeds can be any NuGet V2 feed or a file share of .nupkg files; packages from a file share must be signed unless the gateway's operation mode is set to Development. Modifying extensions with PowerShell requires gateway administrator rights.

• Keep an approved list of extensions and remove unused ones from Settings > Extensions > Installed Extensions.
• Never run a production gateway in Development operation mode.
• For a private feed, lock down write access to the file share so only the team that approves extensions can publish to it.
• Review third-party extensions the way you review any privileged software purchase; see the Remote access and PAM vendors as tier-zero suppliers guide.

Logging and detection

WAC writes management actions to the WindowsAdminCenter event log channel on each managed server, as Event ID 4000 with source SMEGateway; gateway activity goes to the same channel on the gateway. Read-only access is not logged. Each event carries these fields: PowerShell (script name), CIM (call), Module, Gateway, UserOnGateway, UserOnTarget, Delegation (true when credentials were delegated), LAPS (true when LAPS credentials were used) and File (for uploads). Forward this channel from every managed server and the gateway to your SIEM with Windows Event Forwarding or your agent.

PowerShell script block logging on targets complements Event 4000, because it shows what the WAC scripts actually ran; see the PowerShell Security Guide.

Metrics:

• Number of gateways with no Users access group defined (target: zero).
• Percentage of gateway sign-ins protected by Entra MFA or smart card.
• Percentage of managed servers with RBAC applied, and number of people in each server's local Administrators group.
• Days until the gateway certificate expires, and gateways still on a self-signed certificate.
• Gateways on the latest non-preview release, and days since its release.
• Percentage of managed servers forwarding the WindowsAdminCenter channel.

Hardening baseline

1. Place: a dedicated gateway server per administrative tier, never a domain controller, reachable only from admin networks or privileged access workstations, not published to the internet.
2. Certificate: CA-issued certificate with Server Authentication EKU; replace the 60-day self-signed certificate before go-live.
3. Gateway access: named Users and Administrators groups; strip the gateway's local Administrators group to a break-glass account and the platform owners.
4. Strong authentication: Entra ID with User assignment required set to Yes and a conditional access policy, or a required smart card group.
5. RBAC: apply the JEA endpoint across managed servers with domain groups per role; move operators out of local Administrators.
6. Delegation and CredSSP: resource-based constrained delegation only for targets that need SSO; CredSSP only for the features that need it; populate WAC CredSSP Administrators narrowly.
7. Extensions: approved list, signed packages, no Development mode, private feed with restricted write access.
8. Updates: keep automatic updates on (the installer default) or upgrade within 30 days of each release to stay supported; track WAC CVEs.
9. Logging: forward the WindowsAdminCenter channel and PowerShell logs; alert on role group changes.

Rollout and testing: build a new gateway alongside the old one, pilot RBAC on a small ring of non-critical servers (expect the WinRM restart), confirm the three roles behave as documented with test accounts, then expand by tier. Enabling Entra authentication restarts the gateway service, so schedule it. To roll back RBAC on a server, remove users from the roles and fall back to existing admin access while you fix the configuration; keep a break-glass path that does not depend on the gateway, such as direct RDP from a privileged access workstation.

Small vs large estates: a small team can run WAC as a local client on hardened admin workstations and skip the shared gateway altogether. Larger estates benefit from a gateway because it centralises access, MFA and logging, but they then need per-tier gateways, DSC-deployed RBAC and change control for extensions.

Patching the gateway

Microsoft publishes Windows Admin Center security updates in the Microsoft Security Update Guide. Apply them promptly, because the gateway holds administrative reach over your servers. NHI Mgmt Group recommends checking the guide for the fixed build that applies to your release channel and upgrading a test gateway first.

Common misconfigurations

• No access group on the gateway: anyone who can reach the URL can use the gateway, leaving only target credentials between them and your servers.
• Entra app without assignment: enabling Entra ID but leaving User assignment required at No gives every tenant member user access.
• Everyone a local administrator: skipping RBAC means every WAC user also has PowerShell and RDP on every server.
• Delegation everywhere: setting resource-based constrained delegation for every server to get SSO turns the gateway's computer account into a skeleton key.
• Self-signed certificate in production: it expires after 60 days, and users trained to click through certificate warnings will also click through an attacker's.
• Gateway on a domain controller or a tier one server managing tier zero: unsupported in the first case and a tier violation in the second.

Framework mapping

Practitioner checklist

• Inventory every WAC gateway and local client install, with version and owner.
• Define Users and Administrators access groups on each gateway and minimise its local Administrators.
• Enable Entra ID with User assignment required and conditional access, or require a smart card group.
• Apply RBAC to managed servers with a unique domain group per role.
• Limit resource-based constrained delegation and CredSSP to the servers and features that need them.
• Replace self-signed certificates with CA-issued ones and track expiry.
• Maintain an approved extension list, require signed packages and never use Development mode in production.
• Keep gateways on the latest non-preview release and apply Microsoft security updates promptly.
• Forward the WindowsAdminCenter channel (Event ID 4000) and PowerShell logs to the SIEM.

Standards and references

• Microsoft Learn: Configure User Access Control and Permissions in Windows Admin Center
• Microsoft Learn: Windows Admin Center User Access Options
• Microsoft Learn: Use Event Logging in Windows Admin Center
• Microsoft Learn: Windows Admin Center Installation Options
• Microsoft Learn: Install Windows Admin Center
• Microsoft Learn: Install and Manage Extensions
• Microsoft Learn: Windows Admin Center FAQ
• Microsoft: Security Update Guide

Related NHI Mgmt Group resources: Windows Server Hardening Guide · Windows Remote Management and WinRM/PowerShell Remoting Security Guide · Kerberos Delegation Security Guide · Tiered Administration and Enterprise Access Model Guide · LAPS Guide