Keep privileged administration off ordinary workstations

MFA cannot make an already-compromised workstation trustworthy. Dedicated privileged access workstations separate administration from email, general browsing, and everyday applications so high-impact credentials and sessions begin from a controlled device.

Governed cloud identity system with connected service and lifecycle nodes.
DSE visual intelligenceIdentity & cloudGuide · 4 min read
Executive summary

What you need to know

MFA cannot make an already-compromised workstation trustworthy. Dedicated privileged access workstations separate administration from email, general browsing, and everyday applications so high-impact credentials and sessions begin from a controlled device.

Potentially affected

Microsoft Entra ID, Active Directory, hypervisors, backup platforms, firewalls, cloud portals, RMM tools, certificate services, security platforms, and other high-impact administration interfaces.

DSE recommendation

Classify privileged roles and interfaces, issue separate administrator identities and dedicated hardened devices, restrict where those identities can sign in, and continuously monitor privileged activity.

Source fact: the originating device is part of the security decision

Microsoft’s privileged-access guidance says that protecting roles and accounts is not enough. The device, administrative interface, and any intermediary—such as a jump server, VPN, or virtual desktop—form part of the end-to-end privileged session. If an attacker controls the originating device, the attacker may impersonate the administrator during the session or steal credentials and tokens for later use.

Microsoft defines a Privileged Access Workstation (PAW) as a dedicated, hardened device used only for administrative tasks. It is separate from ordinary user devices and restricts general browsing and productivity activity. The objective is to prevent privileged credentials and actions from being exposed to an untrusted environment.

The current Microsoft model describes privileged access as explicitly controlled, isolated from normal activity, continuously monitored, and assumed to be a primary target. Recommended safeguards include strong authentication, managed and compliant devices, time-bound elevation, device hardening, restricted connectivity, and monitoring of identity and endpoint behavior.

Source fact: MFA does not repair a compromised endpoint

Strong multifactor authentication is essential, but it proves only the factors and conditions evaluated by the authentication system. Malware controlling the workstation may still capture a session, abuse an already-authorized browser, alter an administrator’s intended command, or wait until privilege is activated. A separate trusted administrative device reduces the opportunity for email attachments, arbitrary websites, consumer software, and ordinary user activity to share the same execution environment as high-impact administration.

DSE recommendation: define the privileged plane first

Create an inventory of roles and interfaces capable of changing identity, security policy, code, backups, network traffic, or business-critical systems. Include Global and Domain Administrators, hypervisor and backup administrators, firewall and switching control, RMM platforms, certificate authorities, password and secret stores, security-management consoles, domain registrars, video-management systems, and access-control administration.

Classify each role by potential impact rather than job title. A technician with authority to deploy software to every endpoint may present more organizational risk than a conventional server administrator. Document the approved device, account, interface, elevation method, and monitoring source for every privileged path.

DSE recommendation: separate identities, devices, and activities

  1. Issue separate accounts. Ordinary email and collaboration should use a standard identity. Administration should use a distinct account that is not licensed or configured for routine productivity unless a documented requirement exists.
  2. Provide a dedicated device or isolated service. Use a PAW, tightly controlled virtual administrative desktop, or comparable architecture whose security assurance is maintained end to end.
  3. Restrict sign-in locations. Permit privileged identities only from approved compliant devices and administrative paths. Block their use from unmanaged devices and ordinary workstations.
  4. Use phishing-resistant authentication. Choose supported FIDO2/passkey, certificate, or other phishing-resistant methods and maintain separately protected emergency access.
  5. Minimize software and destinations. Remove local administrative rights where unnecessary, control application execution, disable general email, and restrict browsing to required administration sites.
  6. Encrypt and harden the device. Maintain secure boot, TPM-backed protection, full-disk encryption, endpoint detection, host firewall policy, timely updates, and controlled provisioning.

DSE recommendation: do not weaken the chain through an intermediary

A jump server does not automatically create a trusted path. It must be managed, monitored, patched, and restricted to at least the assurance required by the target system. Clipboard transfer, drive mapping, downloads, browser use, and outbound connectivity should be allowed only when required. Administrative connections should terminate at named systems through approved protocols rather than opening broad network access.

Apply the same principle to vendor support. A third party should not enter the privileged plane through a shared VPN account or an unmanaged technician laptop. Use individually attributable identities, approved access devices or controlled intermediaries, limited destinations, time bounds, and recorded approval.

DSE recommendation: prove that the model is operating

Alert on privileged sign-ins from unapproved devices, unexpected role activation, security-policy changes, disabled monitoring, new local administrators, and attempts to use administrative accounts for email or general applications. Review PAW compliance and administrative group membership regularly.

Test replacement, recovery, and emergency access before a device failure or tenant lockout. A PAW program is complete only when administrators can perform necessary work, emergency paths remain available, and high-impact credentials no longer appear on ordinary endpoints.

Official references

Primary reference

Review the official source

Microsoft Learn: Privileged access · Published May 31, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE