The New-Machine Security Checklist: Audit Before It Touches the Network

The paradox of the fresh install

Ask any security team when a machine gets audited and you will hear the same rhythm: at purchase, never; during provisioning, maybe; at incident time, definitely. A fresh Windows machine walks onto the network carrying an assumption of cleanliness — it's new, so it's safe. That assumption is doing heavy lifting. OEM images ship with bloatware and trial AV that fights your real protection stack. Gold images drift: the "standard build" captured in March is already six patches behind by October, and nobody re-captured it. Sysprep left autologon credentials in the registry on more builds than anyone admits. The new machine is often the dirtiest machine in the fleet — it just hasn't met a scanner yet.

The fix is cheap and procedural: audit every new machine before it joins the domain, fix what the audit finds, and snapshot the result as the baseline that every future scan is measured against. Here is the checklist, in order.

1. Run the audit offline first

Finish the OS install, then audit before the first real network session. Joining a domain or browsing for drivers before you've looked at the machine means any compromise that landed in transit — bad USB stick, poisoned driver pack, compromised deployment share — starts life inside your perimeter. Run winsentinel --audit on the fresh machine while it's still isolated. Auditing is read-only, so there is no reason to delay it: look before you connect.

2. Confirm Defender is actually on

New builds are where Defender goes quietly missing: a trial AV bundled by the OEM disables real-time protection and then expires; tamper protection is off because "we'll configure it in the policy later"; exclusions from a careless image get inherited machine-wide. The audit will flag real-time protection state, tamper protection, and any exclusions — treat a disabled Defender on a fresh box as a critical, not a cosmetic issue. If your build pipeline disables Defender for imaging, the checklist is where that gets reversed.

3. Verify the firewall profiles

Provisioning folklore says to turn the firewall off "temporarily" for setup — then the GPO that was supposed to turn it back on misses one OU and the machine runs unprotected for a year. Check all three profiles (domain, private, public) on the new machine, not just the domain one. A fresh box that will eventually touch coffee-shop Wi-Fi should not depend on a GPO to re-enable its public profile.

4. Shrink the remote surface

RDP gets enabled during setup and never disabled. WinRM is left listening because the provisioning scripts needed it. SSH servers sneak in through dev tooling. Audit the listening ports on the new machine and kill everything the machine's role doesn't need. If remote administration is required, lock it to Network Level Authentication with strong account restrictions — configured now, while the machine is still clean.

5. Clean up the local accounts

Fresh builds accumulate credential debt fast: the built-in Administrator left enabled with a well-known password, a leftover setup account nobody deleted, autologon credentials baked into the registry by the imaging process, cached credentials from whoever built the machine. The audit checks local account state, password policy, and autologon remnants. Every local account that survives provisioning should be deliberate, named, and have a rotated password — everything else gets disabled before domain join.

6. Measure the patch delta

Your gold image is a point in time, and time has passed. Compare the installed update state against current: a machine imaged in spring and deployed in autumn can be months behind, including on vulnerabilities that already have working exploits. Set the Windows Update policy — reboot deadlines, deferral windows, active-hours behavior — before the machine reaches a user's desk, when a reboot doesn't cost anyone a deadline. The first patch cycle is the best time to discover that your update policy is broken.

7. Cut the bloat attack surface

OEM preloads, unused optional features, services enabled by default — every one of them is code an attacker can reach. The print spooler has no business running on a laptop. Windows Media features and SMBv1 remnants don't belong on a fresh 2026 build. Strip the machine to its role: if it doesn't need it, the feature is disabled, the service is stopped, the bloatware is uninstalled. This is also where BitLocker gets verified — encryption should be provable at provisioning, not discovered missing during a laptop-loss incident.

8. Snapshot the baseline

After fixes, export the audit as the machine's known-good reference. Every future scan on this box is now a comparison, not a first look: drift detection needs a starting point. Store the baseline where you'll find it when an alert fires six months from now — "was this always like this?" is the question that kills investigations, and a baseline answers it in seconds.

The one-line rule

Never join a box you haven't baselined. The thirty minutes it costs at provisioning is the cheapest security review that machine will ever get.

A new machine is a promise: this is what "secure" looks like for this role. The checklist is how you keep the promise before the network gets its hands on the machine.

At fleet scale, the checklist needs a central node

None of this requires anything beyond the free WinSentinel running on the one machine — the full audit, the fixes, the baseline export are all single-box work, and that is exactly where they belong. What changes at scale is visibility: with fifty machines being provisioned, how do you know every one got its checklist run? How do you prove to an auditor that the baselines exist? How do you notice when a node regresses from its baseline three months later?

That is the fleet orchestration layer — what Pro is for. A central node that shows which machines have a recorded baseline and which skipped the checklist, compliance rollups across the whole fleet, and drift alerts when a node slides away from its baseline. The audit itself doesn't get deeper on Pro — it can't, free already runs the full audit on the machine. Pro answers the organizational question: did the checklist actually happen everywhere, and is every machine still holding its baseline?

One machine, one checklist, thirty minutes. Fifty machines, one central view. Start with the box in front of you.