Building privileged access workstations (PAWs) for AD
Design and build PAWs for Tier 0 admins: hardware, clean image, App Control allowlisting, no internet or email, and when a jump server is not enough.
A Tier 0 credential is only as trustworthy as the keyboard it is typed on. Deny-logon rights and authentication silos decide where a Domain Admin may authenticate, but if that place is a laptop that also opens email attachments and browses the web, one phishing payload captures everything. The privileged access workstation (PAW) closes this gap by applying the clean source principle: a system used to control an asset must be at least as trustworthy as the asset itself.
This guide covers how to build a PAW that holds up: hardware requirements, image provenance, management plane, application allowlisting, network restrictions, and how PAWs relate to jump servers. The overview of why PAWs exist sits in Tier 0 and privileged access. Here we build one.
Design decisions before you build
Physical PAW, VM host, or cloud PC
Three patterns are common:
| Pattern | Description | Trade-off |
|---|---|---|
| Dedicated device | Separate laptop used only for admin work | Strongest, but admins carry two devices |
| PAW host with user VM | PAW is the physical OS; daily-driver desktop runs as a Hyper-V guest or via VDI | One device, clean source preserved |
| Cloud PC / VDI PAW | Hardened Windows 365 or VDI session | Only as clean as the device connecting to it, and the tenant admins become part of Tier 0 |
The rule is that the most trusted tier must be the outermost layer. Running a Tier 0 VM on a standard laptop inverts it: the laptop's SYSTEM account and any malware on it can read the guest's memory and keystrokes.
Who manages the PAW
The PAW's management plane is Tier 0. If your enterprise SCCM, Intune tenant or EDR console can push scripts to PAWs, anyone who controls that console controls your Domain Admins. Either give PAWs a dedicated management path (a small Tier 0 WSUS and GPO-only configuration are enough for many organizations) or scope enterprise tools so Tier 1 operators cannot target PAW collections. Record the decision in your Tier 0 inventory.
Hardware and firmware baseline
Buy hardware that supports the virtualization-based protections you are going to enforce:
- TPM 2.0, UEFI with Secure Boot enabled, and a firmware (BIOS) admin password set and vaulted.
- CPU virtualization extensions and IOMMU (VT-d / AMD-Vi) for VBS and kernel DMA protection.
- Boot from external media disabled in firmware; Thunderbolt/DMA protection enabled.
- Ideally a single model, sourced through a controlled supply chain and stored securely before imaging.
Build a clean image
Install from Microsoft media whose hash you verified, not from the enterprise golden image, which carries agents and software owned by lower tiers. Join the machine directly into a dedicated OU (for example OU=Devices,OU=Tier0) with GPO inheritance reviewed so that only Tier 0 GPOs apply.
Then enable the platform protections through GPO linked to the PAW OU:
- VBS and Credential Guard:
Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Securityset to Enabled, with Secure Boot and DMA Protection, Virtualization Based Protection of Code Integrity enabled with UEFI lock, and Credential Guard Configuration set to Enabled with UEFI lock. - BitLocker with TPM+PIN:
Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Require additional authentication at startup. - Remote credential protection:
Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers, set to Require Remote Credential Guard or Restrict Credential Delegation, so that RDP sessions from the PAW do not leave reusable credentials on the target. - Removable storage:
Computer Configuration > Policies > Administrative Templates > System > Removable Storage Access > All Removable Storage classes: Deny all access, with an exception process for approved encrypted media if you need file transfer.
Local administrators on the PAW should be a break-glass LAPS-managed account only. The admin who uses the PAW logs on with a standard account for the device and elevates to their Tier 0 account for management tasks, or logs on directly with the Tier 0 account if the PAW is dedicated. Either way, they are not local administrators.
Allowlist applications
A PAW runs a short, known list of software: RSAT, PowerShell, the MMC snap-ins you use, the PAM client and perhaps a hardened browser restricted to internal admin portals. Enforce that list with App Control for Business (WDAC) or, at minimum, AppLocker.
AppLocker lives at Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Start with the default rules in audit mode, collect events 8003 and 8006 (would have been blocked) from Microsoft-Windows-AppLocker/EXE and DLL and MSI and Script, and then switch to enforce. Make sure the Application Identity service is set to start automatically, or AppLocker enforces nothing.
# Review what would be blocked during the audit phase
Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' -MaxEvents 500 |
Where-Object Id -eq 8003 |
Group-Object Message | Sort-Object Count -Descending |
Select-Object Count, Name
# Confirm the effective policy on a PAW
Get-AppLockerPolicy -Effective -Xml | Out-File "$env:TEMP\paw-applocker.xml"App Control for Business is stronger because it applies to kernel mode and is harder to bypass from an admin context. Microsoft's App Control Wizard and the ConfigCI PowerShell module (New-CIPolicy, ConvertFrom-CIPolicy) generate policies from a reference PAW.
Cut off internet and email
A PAW must not browse the internet or read mail. Implement this at two layers:
- Host firewall:
Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Set outbound to Block for all profiles and add allow rules only for Tier 0 destinations (DCs, Tier 0 servers, the PAM platform, the update source). Block all inbound connections. - Network: place PAWs in a dedicated VLAN whose egress is limited to the same Tier 0 destinations, so that a local admin disabling the firewall does not reopen the internet.
Do not install Outlook, Teams or a general browser. If admins need documentation, they read it on their standard device next to the PAW.
PAWs and jump servers
Jump servers (or Tier 0 admin servers running RSAT) are useful: they centralize tooling, keep Tier 0 sessions on servers you can log and snapshot, and reduce the number of machines that hold Tier 0 credentials in memory. They do not remove the need for a PAW, because the device that starts the RDP session sees every keystroke. The combination that works is PAW → Tier 0 jump server → DC, with the jump server hardened to the same standard and reachable only from the PAW VLAN.
Enforce the path in AD: Tier 0 accounts get Allow log on locally and Allow log on through Remote Desktop Services only on PAWs and Tier 0 servers, and are denied everywhere else through the tier deny-logon GPOs. Authentication policies and silos add the same restriction at the KDC.
Operating the PAW fleet
A PAW programme fails in operations more often than in design. Decide these points before the first device ships.
Provisioning and custody. Keep a register of every PAW: serial number, TPM endorsement key or hardware hash, assigned admin, OU and build date. Hand devices over in person, and have the admin set their BitLocker PIN on first boot. A PAW that was left unattended outside a controlled area, sent for repair or reported lost is reimaged or retired, never simply returned to service.
Rebuild cadence. Even a well-controlled PAW accumulates state. Rebuilding from the clean image on a fixed schedule (every six to twelve months is common) and after any security incident limits how long an undetected implant can survive. Because nothing personal lives on a PAW, a rebuild should take hours, not days.
Which accounts log on. Two models work. In the first, the admin signs in to the PAW with their Tier 0 account directly; the device is dedicated and nothing else runs there. In the second, the admin signs in with a PAW-specific standard account and uses runas or the PAM client to launch tools as the Tier 0 account. Avoid signing in with the everyday user account that reads email elsewhere: its password and tokens are exposed on non-Tier 0 machines by design.
Monitoring. Forward PAW security logs to the same pipeline as DC logs. Useful signals are new local administrators, AppLocker or App Control blocks in enforce mode, firewall rule changes, Credential Guard or BitLocker being disabled, and logons by any account that is not an assigned Tier 0 admin.
Break-glass. If the PAW itself is broken or unavailable during an incident, admins will find another path. Give them a documented one: a sealed spare PAW, or console access to a Tier 0 jump server in the datacentre, with the use of either logged and reviewed afterwards.
Verify
Run these checks on each PAW after build and on a schedule:
# Credential Guard and HVCI running (1 = Credential Guard, 2 = HVCI)
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning
# BitLocker protection on the OS drive
Get-BitLockerVolume -MountPoint $env:SystemDrive | Select-Object VolumeStatus, ProtectionStatus, KeyProtector
# Local Administrators contains only the expected LAPS-managed account
Get-LocalGroupMember -SID 'S-1-5-32-544'
# Outbound default action is Block on every profile
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction, DefaultInboundAction
# Internet should be unreachable
Test-NetConnection -ComputerName www.microsoft.com -Port 443 | Select-Object TcpTestSucceededTcpTestSucceeded must be False. On the DC side, review 4624 logon events for Tier 0 accounts and confirm the WorkstationName and source IPs map only to PAWs and Tier 0 jump servers.
What it breaks
- Admin convenience: admins lose copy-paste from email and web search on the same screen. Expect resistance for the first weeks and budget for a second monitor or the host/guest pattern.
- Remote Credential Guard and Restricted Admin do not work with every target: Remote Credential Guard needs Windows 10 1607 / Server 2016 or later on the target and Kerberos authentication. Restricted Admin gives no second hop as the admin at all, and Remote Credential Guard only redirects second-hop Kerberos requests back to the PAW while the session is connected, so scheduled or unattended scripts on the jump server that rely on the admin's delegated credentials will fail.
- App Control and AppLocker block ad hoc tools, portable binaries and many vendor installers. Every new admin tool needs a policy update, which is intended but requires an owner.
- Credential Guard breaks NTLMv1, MS-CHAPv2 based VPN and Wi-Fi with saved credentials, and unconstrained Kerberos delegation from the device.
- No internet breaks cloud consoles. Entra and Microsoft 365 administration need either an explicit allowlist of admin endpoints on the PAW or a separate cloud-admin PAW profile.
Related reading: the Tier 0 area overview, Windows LAPS deployment for the PAW's local admin account, and the enterprise access model for how PAWs fit a modern privileged access strategy.
Frequently asked questions
Can a jump server replace a PAW?
No, not on its own. A jump server protects the target, but the admin's keystrokes and credentials still originate on the device they sit in front of. If that device is a normal workstation with email and a browser, malware on it can capture the credentials typed into the RDP session or hijack the session itself. A jump server is acceptable only when it is reached from a PAW, and then it is an extension of Tier 0, not a substitute.
Can one physical PAW serve Tier 0 and Tier 1 administration?
Only if the higher tier is the host and the lower tiers run as guests. A Tier 0 PAW can host a Tier 1 or user VM, because the host controls the guest. The reverse, a Tier 0 VM on a Tier 1 or user laptop, gives the less trusted host full control over the Tier 0 session and breaks the clean source principle.
How should PAWs get Windows updates without internet access?
Point them at an update source that Tier 0 controls, such as a dedicated WSUS instance or a tightly scoped Windows Update for Business policy with an outbound allowlist limited to Microsoft update endpoints. Do not let the enterprise SCCM hierarchy patch PAWs unless that hierarchy is itself managed as Tier 0, because whoever deploys updates can deploy code.
Building privileged access workstations (PAWs) for AD