Windows endpoints as code

Copilot and AI workloads demand consistent, well-managed devices. Under Zero Trust, every device now has to prove its health before it can reach a resource. Remote and hybrid work patterns have obliterated the traditional network perimeter. In this environment, a fragmented, inconsistent Windows estate is inefficient and, increasingly, a liability.

Standardisation is the antidote. It's the practice of aligning your devices, configurations, and deployment processes to a defined, repeatable baseline. Executed properly, it turns endpoint management from reactive firefighting into predictable, auditable operations. Neglecting it, or doing it half-heartedly, leaves you exposed to configuration drift, security gaps, and an endless stream of "works on my machine" incidents.

This post focuses on Windows, but the principles apply equally to macOS, iOS, and Android. The tooling varies from platform to platform, though the underlying philosophy stays the same.

Every change you make in the Intune console is a liability, because a console click leaves no record of intent. The console itself is not to blame.

There is an audit log, and it will tell you that someone changed a configuration profile at 14:32 on Tuesday. It won't tell you why, whether anyone tested the change, or whether it was deliberate. You feel the gap three weeks later, matching symptoms against audit entries by hand while something is broken.

This is how configuration drift starts. An engineer tweaks a setting to fix an urgent issue. Unaware of it, a second engineer makes a conflicting change in a different profile, and a third copies a profile for a new use case and changes it slightly. Six months later you have seventeen "Standard Device Configuration" profiles, none of them match, and nobody can say what "standard" means.

Configuration as Code moves the configuration into files in a Git repository. That changes five things:

• You read the configuration as files, instead of as state in a database somewhere in Microsoft's infrastructure.
• Every change records who made it and when, and the commit message records why.
• Changes go through pull requests, so a second person sees a mistake before it reaches production.
• The same files rebuild the configuration in a test tenant, after a disaster, or for a new team member to study.
• If a change breaks something, you revert the commit, run the pipeline, and the tenant returns to the last known good state.

In Part 2, we talked about managing your endpoint configuration as code, treating Intune policies like source code, with version control, pull requests and pipelines. But configuration is only half the story. The other half is what you deploy to those endpoints: applications.

And this is where things get messy.

Most organisations I encounter still package everything as Win32, not because they've evaluated the alternatives and made a deliberate choice, but because it's what they've always done. The tooling is familiar, the processes are established, and nobody's made a compelling case for change.

This post is that case.