Windows security and hardening audit
23 checks, without touching your files

What does a Windows security audit actually read?

The XIT security audit looks at 23 protection mechanisms built into Windows and asks one plain question about each: is it on or off. The agent reads the state of the setting — not the contents of your files — and sends that picture every 15 minutes. It becomes the security section of the report you receive.

Three things are worth knowing up front. Most of the 23 checks are not faults, they are hardening recommendations: a computer with every one of them switched off still works perfectly well, so they never reduce its health score.

A check that could not run does not appear in the report at all. If the agent could not read a value it leaves it blank rather than guessing — silence is a more honest answer than a false "off", and that rule is enforced in the code itself.

And nothing gets changed behind your back. The report says what was found and what is recommended; the decision is yours. Even when a setting needs a restart, we recommend, we never force.

Why antivirus is the last line of defence, not the first

The common assumption is that a computer is protected if it has antivirus on it. That gets the order backwards. Antivirus acts at the moment malicious code is already running or about to run — it recognises the code and tries to stop it in real time. That is the last line.

Most of the 23 checks address a much earlier question: can the malicious code start at all. A Word document with a macro cannot execute anything if the macro policy blocks it. An infected USB stick runs nothing if AutoRun is disabled. Unsigned code does not load if application control is enforcing. There is nothing to detect, because nothing runs.

That distinction matters because signatures always lag behind the threat. The audit warns when antivirus definitions have not updated for more than 72 hours, for exactly this reason: an engine with three-day-old signatures does not recognise something written yesterday. Settings that prevent execution do not go stale — and they are already on the machine. You are not buying a product, you are switching on capabilities you paid for with Windows.

Office macros: the most common email infection route

A macro is code embedded inside a Word, Excel or PowerPoint file that runs when the file is opened. It began as an office automation feature and became the single most common infection route in email: a file that looks like an invoice or a CV, carrying code that downloads and runs malware the moment it opens.

Office stores that policy as one number. The audit reads it for Word, Excel, PowerPoint, Outlook and Access, across every installed Office version, and takes the worst of them:

• 1 — all macros enabled. The dangerous state: an infected document runs code immediately on open, without asking. The report flags it as a finding that needs action, not a suggestion.
• 2 — disabled with notification. The Office default. The document does not run by itself, but a yellow bar appears offering to enable it — and that click is exactly what the attacker asks for in the email.
• 3 — signed macros only and 4 — disabled silently. These are the safe states.

One technical detail decides whether this check means anything. The macro policy is stored per user, and the agent runs as a system service — reading its own profile would report "safe" on every machine on earth. It reads the profile of the user actually logged in, and only the policy number, never a document.

Alongside it, the audit reports Windows attack surface reduction rules: a separate layer that blocks dangerous patterns at system level, such as an Office document launching another program. The report counts how many rules are in full blocking mode, because a rule set to audit only reports and stops nothing.

SMBv1: how ransomware moves from one PC to all of them

SMB is the protocol Windows computers use to share files and printers on a local network. Version 1 dates from 1983 and contains nothing resembling modern protection. The risk is not theoretical: the large ransomware outbreaks that shut down hospitals and office networks spread exactly this way — one machine infected by email, and from there the malware crawled to every other computer over SMBv1, with nobody clicking anything else.

That is the difference between an incident and a disaster. One infected PC costs a working day. An entire office encrypted at once stops the business.

The audit checks both sides: the server configuration (whether the machine accepts SMBv1 connections) and the client-side driver (whether it is fully disabled). A clean Windows 11 install is usually fine. A machine upgraded from an older version, or one where somebody enabled SMBv1 to reach an old NAS or printer, can sit exposed for years. This check pays off most across every computer in the office rather than one.

The USB stick that runs software on its own

Windows AutoRun was designed as a convenience: insert a disc, the program starts. With a USB device it becomes the ability of anyone holding a memory stick to run code on your computer — no password, no click. The stick handed out at a conference, the one left on a desk: either is enough.

Windows stores this as a single registry value, and full disablement across every drive type is one specific value. The audit looks for exactly that value. If it is missing entirely, AutoRun is reported as not disabled, because the absence of a policy means default behaviour, not protection.

This is probably the best effort-to-benefit ratio on the page: one setting, no effect on daily work, an entire physical attack route closed.

When malware switches the antivirus off before it acts

Modern malware does not try to evade antivirus. It turns it off. The first action of a great many ransomware families is to disable real-time protection and only then start encrypting — antivirus that is off detects nothing, and the Windows security interface keeps looking healthy for a while afterwards.

Tamper Protection blocks precisely that. When it is on, real-time protection cannot be disabled by a command, a registry edit or a script — only by hand, inside Windows Security. It exists in every current Windows 10 and 11, and on many machines it is off because somebody switched it off once to install software Windows was blocking, and never switched it back.

Three further checks share that purpose: stopping malicious code from getting what it needs to continue.

• Credential Guard — prevents stored passwords being extracted from memory. Without it, malware on one machine can harvest credentials and reuse them on other computers on the same network.
• LSA Protection — protects the Windows process that holds those credentials in the first place.
• Memory Integrity (HVCI) — prevents malicious drivers loading into the kernel. Next to it, the audit counts how many unsigned drivers are installed, because an unverified driver is the standard route to kernel privileges.

Finally, a check that mainly serves us: PowerShell script-block logging. If it is off, an infected machine and a clean machine look identical — there is nothing to detect from. The audit reports the setting itself, so we never mistake silence for cleanliness.

All 23 checks, what each one stops, and the usual state

All 23 checks: what each prevents, and the typical state on a computer nobody has hardened.

The right-hand column describes Windows default behaviour when nobody has set a policy. It is not a survey of real computers. The actual state of your machine appears in your report, and only there.

Alongside those 23, the report counts failed logon attempts in the last 24 hours. Five or more is flagged as suspicious — the early signal of password guessing, manual or automated.

What this audit does not do

This is worth stating explicitly, because a security audit sounds like it scans your files. It does not.

The agent reads configuration state only: registry values, system policy and service status. It does not open documents, read photos, access your mailbox or collect browsing history. From the macro check it reads a policy number, never a document. From the startup folder it reads shortcut names only, never their contents. From the background-persistence check it keeps entry names, not what they launch.

The practical consequence: nobody at XIT can open a file of yours through this system, because the system never received one. A full field-by-field breakdown is on the what the report contains page.

What happens after the audit?

The audit itself is only the start. The server runs all 23 checks on every report, meaning every 15 minutes, and keeps 60 days of history. So you can see not only what is off today but when it changed: a firewall profile switched off last week, antivirus that stopped updating, RDP that got opened.

Findings reach you in plain language, split into two categories that never get mixed: faults, which need attention, and hardening recommendations, which are improvements rather than failures. After that it is a human process — a technician goes through the list, explains what is worth enabling, and says plainly what it costs in convenience when it costs anything. Some changes need a restart, and you choose when.

Read about pending security updates as well — the most common ransomware entry point is a known vulnerability whose fix already exists and simply was not installed. For what else the same report covers, see the hardware audit and continuous monitoring. Pricing is $5 per computer per month for monitoring, or $10 with a human technician acting on what it finds.

FAQ

Read next

• Updates and maintenance — the vulnerability that already has a fix is the most common way in
• What the report contains — every field collected, and what is deliberately not
• Hardware audit — SMART, battery, temperatures and what breaks before it breaks
• Continuous monitoring — what happens between reports, and when a human actually looks