Ask the IT team how the workstation estate is configured today and the honest answer is usually “open the portal and look”. BitLocker policy, firewall rule, an exception created at three in the morning during an incident: all of it lives inside a web console, with no legible history, no review and no way back. This is the problem infrastructure solved with versioned code — except almost nobody applied the idea to endpoint management.

That is what we did on a project with a Brazilian insurer: a PowerShell framework on top of the Microsoft Graph API that exports the state of the Intune tenant to versioned files and applies them back in a controlled way. The estate’s policies became code in git — reviewable in a pull request and reproducible. With AI assistants writing the framework, what would have been a month of work turned into days.

A click leaves no trail

Workstation management done by clicking fails at three predictable points. The first is traceability: the portal records that something changed, but it does not tell you why, nor does it show the before and after of a policy with dozens of settings. The second is reversibility — undoing a bad change depends on somebody remembering the previous value.

The third is the most expensive: reproducibility. A well-configured estate is an asset that exists in a single place. If the tenant has to be rebuilt, or if you need to stand up a faithful test environment, the only route is to redo it click by click — and the result is never identical. That is why the subject is a discipline of infrastructure.

What “as code” solves in Intune

The idea is simple. Instead of the tenant being the single source of truth, it becomes the destination of a configuration that lives in a repository. Four practical effects:

• Export the state. Configuration policies, compliance rules, Autopilot profiles, scripts and assignments come out as readable JSON. That alone is the inventory nobody had.
• Version it. “What changed in the BitLocker policy last quarter” becomes a command, not an investigation — and the history serves as evidence in an audit.
• Review in a PR. A baseline change stops being a solitary decision: two people read the diff before anything reaches the machines.
• Apply it again. The same set of files goes up in another tenant, in a test environment, or back into the original after a problem.

What AI genuinely accelerated

It is worth separating promise from result. AI did not design the customer’s security policy or decide what was acceptable for that estate. It shortened three concrete pieces of work.

Writing the framework. The tedious part of talking to Graph is always the same: application authentication with minimum permissions, @odata.nextLink pagination, handling throttling — the HTTP 429 with Retry-After, which shows up precisely when exporting the whole tenant — and normalising the JSON so the diff does not flag a change because of field order or a timestamp. Describing that in prose and receiving structured functions, with error handling and logging, saved nearly all the mechanical effort.

Translating baseline policies. Security recommendations arrive as text: require disk encryption, block external macros, enable the attack surface reduction rules. Turning each of those lines into the correct identifier in the Intune settings catalogue is documentation prospecting. AI made the first cut; the engineer checked and corrected — and there was plenty to correct.

Unblocking enrolment troubleshooting. This is where the gain surprises. An enrolment failure returns unfriendly hexadecimal codes, with clues scattered between the event viewer and the MDM diagnostic report. Throwing that raw material in for analysis shortens the path between “the machine will not join” and “the automatic enrolment scope does not include that group”.

The method: export, compare, version, apply

The order matters, and it starts with the safest step: no writing the ideal configuration before you know the real one.

1. Export the whole tenant with a read-only credential. It is the photograph of what exists — including the duplicated policies and orphaned assignments nobody knew were still active.
2. Compare the export against the intended baseline. The list of differences is the project’s real agenda: what is missing, what is surplus and what is in conflict.
3. Version the approved configuration, with assignments referencing groups by name, not by identifier. An identifier does not survive a change of tenant; a name does — and that is what makes the repository portable.
4. Apply by ring: a pilot of ten machines within IT itself, then all of IT, then one business area and only then the whole estate. Each ring stays under observation for days.

Guard-rails: the tenant is production

Automating change across a workstation estate is powerful and dangerous in equal measure. Four rules are not negotiable. Separate credentials: what exports uses read permission; what applies uses write and lives in the pipeline. Back up before every apply — an export of the current state, tagged in the repository: it is the difference between rolling back and rebuilding.

Nothing is applied without review — the approved diff is what runs, and the approval is recorded. And rings with stopping criteria defined in advance: if the pilot generates more tickets than agreed, the next ring does not go ahead. Add to that one cheap practice — run the apply in simulation mode and read what it intends to change. This is operational continuity just as much as it is cybersecurity.

Before and after: migrating the workstations

The case was the migration of Windows workstations from the hybrid model — joined to the local domain and merely registered in the cloud — to Entra Join with provisioning via Autopilot: the device comes out of the box, joins the tenant and reaches the user already configured, without passing through the IT workbench.

Before, building the security baseline and the equivalent policies in the new model was weeks of manual configuration, with the risk of silently forgetting a rule from the old world. With the framework, it became a matter of days. More important than the speed: the estate became reproducible — the entire state fits in a repository that any engineer on the team can read and review.

Two pitfalls are worth noting. The first is access to local resources: leaving the hybrid model without settling how the machine authenticates to datacentre file shares and printers breaks people’s daily routine. The second is the legacy domain policies, which have to be translated one by one — and that is where the comparison pays for itself.

The bridge to Zero Trust

None of this is an exercise in tidiness. Zero Trust starts from a simple principle: no access is granted merely for being inside the network. It depends on a verified identity and a device that is known, managed and compliant. The workstation is half the equation, not a footnote in the inventory.

But “compliant” has to have a technical meaning. It comes from the policy Intune evaluates — encrypted disk, active threat protection, minimum system version — and that conditional access consults before releasing e-mail, files and applications. If that policy is neither versioned nor reviewed, the device pillar of Zero Trust rests on clicks nobody audits.

To go deeper, Inove Academy offers the e-book on cybersecurity and LGPD (Brazil’s data protection law), which covers the part usually missing from this conversation: which technical controls underpin the legal obligations, and how to demonstrate that when somebody asks for evidence.

One final caveat. Putting the estate into code does not eliminate technical decisions; it changes where they happen. What to block, what to allow and how much friction the user will tolerate remain human choices. What the framework guarantees is that the choice ends up written down, reviewed and reversible — instead of becoming one more portal change nobody can explain six months later.