Systems Hardening and IT Automation, Delivered Remotely

Systems hardening and automation are usually sold as two things. They are one thing, because the difference between a control that works and a control that quietly stops working is almost always whether a human has to remember to apply it.

Every manual step in an IT process is a place where the process can fail silently on a busy week. Removing the step removes the failure mode. That is the entire argument, and it holds whether the step is applying a security baseline, removing a leaver’s access, or checking that a report ran.

What systems hardening means in practice

Not a product. A set of configuration decisions applied consistently and provably:

• A device baseline applied by policy rather than by hand at setup — disk encryption, local administrator rights removed, firewall on, screen lock enforced, updates mandatory.
• Identity defaults that are secure without anyone opting in: MFA required, legacy authentication blocked, privileged roles separated from daily accounts and time-bound where the licensing allows.
• Attack surface reduction — macros from the internet blocked, unnecessary services off, remote access not exposed directly to the internet.
• Update rings, so patches reach a pilot group before everyone, and so "we are behind on updates" stops being a recurring finding.

The critical property is that these are enforced by policy, so a machine that drifts is brought back automatically and a new machine arrives compliant. A baseline applied manually at setup is accurate on day one and decreasingly true every day after. Systems hardening that depends on somebody remembering is not hardening, it is a suggestion.

Configuration drift is the real enemy

Nobody deliberately weakens a system. Drift happens for good reasons: an exception granted for a genuine problem and never withdrawn, a policy loosened to get someone working before a deadline, a machine rebuilt in a hurry and not enrolled.

Six months of reasonable individual decisions produce an estate where the documented configuration and the actual configuration have diverged, and nobody knows by how much. Automated systems hardening solves this by making the documented state the enforced state — compliance is reported rather than assumed, and an exception has to be created explicitly, which means it can be reviewed.

The reporting matters as much as the enforcement. "Are all our laptops encrypted" should be a question answered by opening a dashboard, not by asking around.

Joiner, mover, leaver

The single highest-value automation in most businesses, and the one most often done by hand.

Joiner. A new employee should get their account, licences, group memberships and device configuration from their role, not from someone copying the permissions of whoever sits nearest. Copied permissions accumulate: three years of copying produces staff with access to systems they have never heard of.

Mover. The step almost everyone skips. When someone changes role they gain the new access and keep the old, because removal is nobody’s job. Long-tenured staff end up with more access than the finance director, without anyone deciding they should.

Leaver. Access removed the same day, including third-party and supplier systems, and including the accounts that are not in the main directory. Dormant accounts belonging to former staff are one of the most common findings in a first assessment, and they are a live route into the business — the reasoning is in our piece on why identity attacks now beat exploits.

Automating this turns an access review from an archaeology project into a report.

Automation that is worth doing

The test is simple: does the task happen repeatedly, does it matter if it is missed, and is it deterministic? Three yeses and it should not be manual. Typical candidates:

• Onboarding and offboarding, as above.
• Licence reconciliation — who is paying for what, and which licences are assigned to people who left.
• Backup verification reporting, so a failed job raises something rather than sitting silently in a dashboard nobody opens.
• Certificate and domain expiry monitoring. Outages caused by an expired certificate are entirely preventable and reliably embarrassing.
• Compliance evidence collection — the artefacts that insurers, clients and auditors ask for, gathered on a schedule rather than assembled in a panic. We covered what they ask for in the controls underwriters check.

Each of those is a systems hardening measure as much as an efficiency one, because in every case the risk being removed is that a person forgets. Equally important is what should not be automated: anything requiring judgement, anything run rarely enough that the automation will be stale by the time it is needed, and anything where a wrong outcome is worse than no outcome. Automation that deletes things unsupervised is a category to approach carefully.

Building it so it survives you

An automation nobody understands is a liability, and this is where a lot of well-intentioned work goes wrong. A script on somebody’s workstation, authenticating as their personal account, is worse than the manual process it replaced — it fails when they leave, and it fails in a way that is hard to diagnose.

What we build runs under a service identity with scoped permissions, logs what it did somewhere durable, is stored in version control rather than on a desktop, fails loudly rather than silently, and is documented well enough for a competent stranger to modify. Anything that cannot meet those five conditions is better left manual and honest.

Those five conditions are not theoretical for us — they are the same standards the software we build and run is held to, and the reason we are unsentimental about automation that only works while its author is still around.

Microsoft publishes its security baseline content and configuration guidance publicly through the Intune security baselines documentation, which is a reasonable place to check any recommendation you are given against a vendor-neutral starting point.

Where this fits with the rest

Systems hardening implements the decisions that risk management work identifies and that architecture work designs. On its own it is a set of settings; downstream of those two it is the mechanism that makes the design real and keeps it real.

It is also usually the cheapest phase, because the capability is frequently already licensed. Businesses on Microsoft 365 Business Premium generally own the policy and device management tooling required and have not configured it.

The most remote-friendly work we do

This is policy and configuration rather than hardware, so it is remote by nature — distance is not a constraint and never has been. Baselines, update rings and joiner-mover-leaver automation are built and verified through the same management surfaces whether we are in the next town or on another continent. Clients across South Africa, the UK and Europe run it this way; on-site work is available across the Helderberg and Cape Town but is almost never what this needs.

The starting point is a systems hardening review: what the current baseline actually is on real machines rather than in a document, where the exceptions are, and which of them anyone can still justify. That review is short, and it usually surfaces two or three controls that can be turned on the same week at no additional cost.

For what that review keeps finding, we wrote up seven controls that fail without ever raising an error — baseline profiles frozen read-only by a newer version, update rings that resumed after a pause expired, Windows LAPS left off despite being free. Each is traced to Microsoft’s own documentation, and each is the sort of thing an office would have surfaced by accident and a distributed fleet does not.