Privileged Access Workstations & Golden Images

A Privileged Access Workstation is a dedicated device used for one purpose: administering the systems that, if lost, would cost you the organisation. It is not a laptop with extra policies applied. It is a machine with an intentionally small amount of software on it, running application control in enforcement, joined and managed separately from the general fleet, and permitted to reach a deliberately short list of destinations.

The design principle underneath is simpler than the acronym suggests. The security of any system is limited by the security of every system that can control it. Your cloud tenant may be immaculately configured, but if the administrator's session originates from a machine that also renders untrusted email and executes arbitrary JavaScript, then the tenant inherits that machine's risk. You cannot reason about the tenant in isolation, because it is not isolated.

So a PAW removes the things that make a general-purpose machine risky, rather than trying to make them safe. No mail client. No general web browsing. No arbitrary installs. Not because those activities are dangerous in themselves, but because each one is an execution path for code you did not choose, on the one device where code you did not choose must never run.

The result reads as austere to anyone who has not used one, and it is. That austerity is the control. There is very little to attack, which is why the attack that reaches everything else does not start here.

There is a rule that governs this whole area, and most PAW programmes that fail have quietly broken it. A secure system may only be built and managed from something at least as trustworthy as the system itself. Microsoft calls it the clean source principle. It sounds abstract until you trace where your admin image actually came from.

In a lot of organisations the answer is uncomfortable. The image was captured from a machine somebody had set up nicely, some years ago. It has been updated in place since. It contains agents nobody can fully account for, a local account created during a migration, and configuration that exists because it worked. Nobody can rebuild it from first principles, so nobody does - they clone it again.

A golden image is the answer to that, and it is a build process rather than a file. Start from vendor-original media. Apply hardening as code. Install only what is justified, from sources you verified. Produce a versioned, signed artefact through a pipeline - Azure Image Builder, Packer, whatever fits the estate - so that patching means running the pipeline again and re-imaging, not opening a change ticket and hoping.

This is why we treat PAW and golden image engineering as one piece of work rather than two. A hardened device built from an image you cannot reproduce is a device you cannot trust after the first patch cycle. The image pipeline is what makes the hardening durable instead of a snapshot of one good afternoon.

The fastest way to kill a PAW programme is to declare that all administrators need one. The cost lands everywhere at once, the operational friction becomes the story, and within a quarter somebody has been granted an exception that quietly reintroduces the original problem.

Tiering is the discipline that prevents this. Tier 0 is the set of systems that control identity and control everything else: the identity provider, domain controllers, the cloud tenant's global administrative plane, PKI, and the backup platform - because an attacker who owns your backups owns your ability to recover. Tier 1 is the servers and applications that run the business. Tier 2 is the user estate.

The rule that gives tiering its teeth is about direction of control, not sensitivity. A credential from a higher tier must never be exposed on a lower-tier device, and a lower-tier system must never be able to control a higher-tier one. Once that is stated plainly, a great many existing habits turn out to violate it - the management agent installed everywhere including domain controllers, the monitoring account with local admin across all tiers, the helpdesk tool that can execute code on anything.

In practice the tiering conversation is the most valuable part of the engagement, and it is rarely the part people expect. It produces a written, agreed answer to which systems are Tier 0 - and therefore a defensible boundary for where the expensive controls apply, and where they honestly do not need to.

PAW deployments rarely fail at go-live. They fail at month eight. The image falls behind on patches because rebuilding it is manual. An administrator needs a tool that is not on the approved list, and an exception is granted verbally. Someone joins the team and is issued a standard laptop because the PAW build takes a week. None of these is a decision to abandon the model; together they are exactly that.

Every one of those failures is operational rather than technical, so that is where we spend the back half of an engagement. The image is a pipeline run, so patching is scheduled rather than heroic. Adding an application has a documented request path with a named owner, so the answer to a legitimate need is a process rather than an exception. Joiner-mover-leaver for the privileged estate is written down and rehearsed, so a new administrator is provisioned in hours.

Enforcement has to be technical rather than cultural, and that is what Conditional Access is for. When Tier 0 administration is refused from any device that does not attest as a compliant PAW, drift stops being a matter of discipline. The non-compliant path is not discouraged - it does not work.

The last piece is the one people postpone: break-glass. Emergency access accounts, stored properly, excluded from the very policies that could lock everyone out, and tested on a schedule so that the first rehearsal is not during an outage. A privileged access model with no tested way back in has replaced one single point of failure with another.