Many organisations agree that administrators should use privileged access workstations, then never write down what a compliant one is, who must use it, or what happens when someone cannot. This template gives [Organisation] a policy-style standard for privileged access workstations (PAWs): the mandatory build baseline, permitted and prohibited use, how use is enforced at the target, and the exception process. It does not repeat the design rationale; for why a clean admin device matters and how to choose a design, see the Privileged Access Workstations Guide, and for when a jump server or broker fits, the Privileged Access Workstations vs Jump Servers guide. It is written for security architects, endpoint engineers, IAM teams and the administrators the standard applies to. Microsoft Windows and Intune settings are used as worked examples because Microsoft publishes a detailed PAW reference; translate them to your own platform where it differs. Replace every [bracketed] placeholder.
How to use this template
- Decide the scope first: section 2 says which roles must use a PAW. Agree it with the CISO and platform owners before writing the build baseline, because scope drives the number of devices and the cost.
- Use "must" and "should" as written: "must" items are mandatory and need an approved exception to deviate; "should" items are expected unless there is a documented reason.
- Attach the build record: section 4 lists controls; the engineering build document (Intune profiles, images, scripts) is referenced from it, not pasted into it.
- Owner and review: [Head of Security Architecture] owns the standard. Review every [12] months, after any change to the admin tiering model, and when the device platform reaches a new major release.
1. Purpose
1.1 This standard sets the minimum requirements for devices used to administer [Organisation]'s high-impact systems, so that an administrator's credentials and sessions are never exposed on a device that also reads email or browses the web.
1.2 It applies the principle the UK National Cyber Security Centre calls browsing down: administration is carried out from a device trusted at least as much as the system being managed. Administering a more trusted system from a less trusted device (browsing up) is not permitted for systems in scope.
2. Scope
2.1 A PAW must be used for all administration of the systems and roles below:
| Scope group | Examples | PAW requirement |
|---|---|---|
| Tier 0: identity and control plane | [Active Directory domain controllers and AD CS], [Microsoft Entra ID Global Administrator, Privileged Role Administrator], [IdP super admins], [AWS root and organisation admins], [Azure Owner at management group scope], [PAM vault administration] | Must: dedicated PAW, privileged profile |
| Tier 1: infrastructure with broad reach | [Hypervisor and vCenter], [backup platform], [EDR and MDM consoles], [CI/CD administration], [production cloud subscriptions] | Must: PAW, privileged profile, or an approved brokered session launched from a PAW |
| Sensitive business administration | [Payment systems], [HR and finance platform admins], [SaaS tenant admins] | Should: PAW or specialised device (section 4.4) |
2.2 Out of scope: [end-user support with no privileged rights], [developer workstations without production access]. These roles follow the [Endpoint Security Standard].
2.3 Third parties who administer in-scope systems must meet this standard or use a [Organisation]-issued PAW or approved brokered session. The NCSC advises not to trust management devices until you have the assurance you need, especially where a third party runs operations.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Standard owner | [Head of Security Architecture]: maintains this standard; approves changes to section 4 |
| PAW service owner | [Endpoint Engineering Lead]: builds, patches and replaces PAWs; holds the build record |
| IAM team | Maintains the PAW user group, admin accounts and the access policies in section 6 |
| PAW user | Uses the PAW only as permitted in section 5; reports loss or suspected compromise within [1] hour |
| SOC | Monitors PAW telemetry and the alerts in section 9 |
| Exception approver | [CISO] for Tier 0, [Deputy CISO] for Tier 1 and below |
4. Build baseline
4.1 Hardware and supply. A PAW must be a [Organisation]-owned device bought through [approved channel] and registered for zero-touch provisioning before issue. Personally owned devices must not be enrolled as PAWs. Hardware must support TPM 2.0, UEFI Secure Boot, virtualisation-based security with hypervisor-protected code integrity (HVCI), and DMA protection, which are among the root of trust criteria Microsoft lists for privileged devices.
4.2 Mandatory controls:
| Control area | Requirement | Worked example (Windows and Intune) |
|---|---|---|
| Disk encryption | Must: all local disks encrypted, recovery keys escrowed centrally | BitLocker on all local disks |
| Boot and OS integrity | Must: secure boot, measured boot with health attestation | UEFI Secure Boot, Device Health Attestation, System Guard |
| Credential protection | Must: OS credential isolation enabled | Credential Guard |
| Local administrator | Must: PAW users have no local admin rights | Entra device setting "Additional local administrators on Microsoft Entra joined devices" set to None |
| Application control | Must: allow list enforced, not in audit mode; software installed only by the management service | AppLocker in enforce mode; apps deployed only through Intune and Company Portal |
| Web access | Must: deny by default, allow only approved admin and identity endpoints | Local URL lock proxy with an allow list of identity and management endpoints |
| Network | Must: inbound blocked; outbound limited to required services and approved destinations; local firewall rules not merged | Privileged firewall profile: inbound block, outbound block with exceptions for DNS, DHCP, NTP, NCSI, HTTP and HTTPS to approved destinations |
| Endpoint detection | Must: EDR onboarded and reporting | Microsoft Defender for Endpoint |
| Management | Must: managed by the PAW service only, security baseline applied, compliance evaluated before access | Intune security baseline, compliance policy, dedicated device group |
| Patching | Must: OS and application updates installed within [7] days of release, [48 hours] for actively exploited flaws; users cannot defer | Dedicated update ring, users cannot pause updates |
| Removable media | Must: blocked except approved encrypted devices for named tasks | [Device control policy name] |
| Unneeded features | Should: legacy components removed | Microsoft's reference script removes PowerShell 2.0 and Internet Explorer and prevents saving network credentials |
4.3 Build assurance. Each build version is recorded in [build record location] with its version number, the profiles applied and the date of test. A new build version must pass the acceptance tests in section 8 before release.
4.4 Specialised profile. For "should" scope in 2.1, a specialised device may be used: no self-administration, applications installed only by an administrator, but email and web browsing allowed. Microsoft describes this as the middle of its three device profiles. It must not be used for Tier 0 or Tier 1.
5. Permitted and prohibited use
5.1 Permitted on a PAW:
- Signing in with the user's dedicated admin account for the tier (never a daily-use account).
- Administration portals, command-line tools and remote sessions to in-scope systems, through the approved access path.
- Reading the documentation and ticket sites on the allow list.
5.2 Prohibited on a PAW:
- Email, instant messaging, social media and general web browsing.
- Signing in with a standard user account or any personal account.
- Installing software, browser extensions or scripts not deployed by the PAW service.
- Opening files received by email or downloaded on another device, unless scanned and transferred through [approved transfer method].
- Connecting to untrusted networks without the always-on [VPN or secure access client].
- Using the PAW to administer systems of a lower tier when that tier is managed from a separate device under [tiering standard].
5.3 Productivity. Because email and browsing are blocked, every PAW user also holds a separate standard device or a [virtual desktop] for daily work. Admin credentials must never be entered on that device.
5.4 Physical handling. PAWs are locked when unattended, carried in person when travelling, and never left with third parties. Loss or theft is reported to [Service Desk and SOC] within [1] hour so the device can be blocked and the admin account's sessions revoked.
6. Enforcement at the target
6.1 Policy alone is not enough: in-scope systems must refuse administrative sign-in from devices that are not PAWs.
- Cloud and identity portals: access policies require a compliant device carrying the PAW attribute plus MFA for privileged roles, and block management portals and PowerShell from other devices. Emergency access accounts are excluded and covered by the Break Glass Access Procedure Template.
- Authentication: admin accounts use phishing-resistant MFA (for example FIDO2 security keys or Windows Hello for Business) bound to the PAW user.
- On-premises Tier 0: domain controllers and Tier 0 servers accept remote administration only from PAW subnets or the approved broker, enforced by [firewall rules or IPsec policy].
- Brokered sessions: where a jump host or PAM session broker is used, its gateway accepts connections only from PAWs, so the broker never becomes a browse-up path.
7. Exception process
7.1 An exception is required for any deviation from a "must" item in sections 4 to 6, including an administrator who needs to work without a PAW.
- Request: the requester submits [exception form] stating the requirement, the systems affected, the reason, the compensating controls and the requested end date.
- Risk review: the standard owner assesses the request and records the residual risk.
- Approval: the exception approver in section 3 approves or rejects. Tier 0 exceptions need [CISO] approval in all cases.
- Time limit: exceptions last no longer than [90] days for Tier 0 and [6] months for other scope; renewal needs a fresh request and a remediation plan.
- Register: all exceptions are held in [GRC tool], reviewed monthly by the standard owner and reported quarterly to [risk committee].
7.2 Typical compensating controls: brokered and recorded sessions for the excepted user, just-in-time elevation with approval for each use, a specialised device in place of a PAW, or restricting the excepted access to read-only roles.
7.3 Never permitted, even by exception: entering a Tier 0 credential on a device that reads email or browses the open web.
8. Compliance and verification
| Check | Method | Frequency |
|---|---|---|
| Every in-scope admin has a PAW | Compare the PAW device group with the privileged role inventory | [Monthly] |
| PAW compliance state | Management service compliance report: encryption, baseline, EDR, patch level | [Weekly] |
| Admin sign-ins from non-PAW devices | Identity provider sign-in logs filtered on privileged roles and device attribute | [Continuous, alerted] |
| Application control blocks | EDR or event log review of blocked executions | [Weekly] |
| Build acceptance | Test that email and an unlisted website are blocked, local admin is absent and unsigned software cannot run | [Each new build version] |
| Exception register | Count of open exceptions and those past end date | [Monthly] |
9. Monitoring and metrics
- PAW coverage: share of in-scope admin accounts with an issued PAW. Target [100%] for Tier 0. Microsoft's rapid modernisation plan sets the key result that every privileged account has a dedicated workstation.
- Enforcement coverage: share of Tier 0 and Tier 1 systems that refuse admin sign-in from non-PAW devices. Target [100%].
- Non-PAW admin sign-in attempts: blocked attempts per month, each one reviewed. Rising numbers mean either training gaps or attempted misuse.
- PAW compliance: share of PAWs compliant at the last check. Target [above 98%].
- Open exceptions past end date: target [0].
10. Non-compliance
10.1 Administrative access found to breach this standard is suspended until the account owner confirms remediation. Repeated or deliberate breaches are handled under [disciplinary policy]. A suspected PAW compromise is handled under the [Incident Response Plan] and the device is reimaged, not cleaned.
Implementation guidance
Rollout order. Issue PAWs and enforce section 6 for Tier 0 first, then Tier 1. Start enforcement in report-only mode for [2] weeks to find administrators still signing in from other devices, then switch to block. Microsoft's rapid modernisation plan suggests starting from its enterprise level and raising to specialised and privileged levels as soon as possible; for Tier 0, go straight to the privileged profile.
Testing and rollback. Pilot each build version on [5] PAWs used by volunteers from different admin teams. Keep the previous build version available so a failing profile can be reverted through the management service without reimaging. Keep the emergency access path outside PAW enforcement so a broken policy cannot lock out every administrator.
Small versus large organisations. The NCSC accepts that a small organisation with low-impact systems may administer from internet-connected devices hardened under its mobile device guidance, and that a critical infrastructure operator accepts the cost and friction of dedicated PAWs because the consequences of compromise are serious. A small team can meet this standard with a handful of PAWs for Tier 0 only and a brokered session for everything else. A large organisation should run the PAW as a service with its own build pipeline and a dedicated device group per tier.
Common failure patterns.
- Standard without enforcement: PAWs are issued but portals still accept admin sign-ins from any device, so administrators drift back to their laptops.
- Allow list creep: the URL allow list grows until it includes general sites, recreating the browsing risk the PAW was meant to remove.
- Exceptions as the default: long-running exceptions for whole teams; enforce the time limit in 7.1.
- Jump server reached from ordinary laptops: the broker is hardened but the device driving it is not. See the jump server comparison guide linked above.
- Daily account on the PAW: signing in with a mail-enabled account defeats the separation; section 5.2 prohibits it and section 8 detects it.
Framework mapping. NIST SP 800-53 Rev. 5 AC-6(2) Non-privileged Access for Nonsecurity Functions, AC-6(5) Privileged Accounts, SC-7(15) Networked Privileged Accesses, CM-7 Least Functionality, CM-11 User-installed Software and IA-2(1) Multi-factor Authentication to Privileged Accounts; NIST CSF 2.0 PR.AA-05 and PR.PS-01; ISO/IEC 27001:2022 Annex A 8.1 User endpoint devices and 8.2 Privileged access rights; CIS Controls v8.1 Safeguard 12.8 (dedicated computing resources for all administrative work) and Safeguard 5.4. ATT&CK techniques this standard makes harder include T1003 OS Credential Dumping and T1550.002 Pass the Hash against admin credentials cached on daily-use devices.
References. Microsoft: Securing devices as part of the privileged access story · Microsoft: Privileged access deployment · Microsoft: Privileged access security rapid modernization plan · NCSC: Gain trust in your management devices · NIST: SP 800-53 Rev. 5 · CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Privileged Access Workstations Guide · Privileged Access Workstations vs Jump Servers · Active Directory Tiering vs Red Forest · Privileged Session Management Guide · Privileged Access Management Guide