How to know what changed on an endpoint

Something on a machine is different and nobody wrote it down. A service that was disabled is running, a port that was closed is open, an account you do not recognize is in the local administrators group. You need to know what changed, when, and ideally what it looked like before. The frustrating part is that the operating system, the thing that made the change, does not hand you that answer in one place.

You can get most of the way there by hand, and the tools are worth knowing even if you never run anything central. What you cannot do by hand is make it fast, complete, and consistent across a fleet. Below is what each OS gives you, where it stops, and the approach that closes the gap.

Why the OS does not just tell you

Each platform logs some of what happens, but no platform keeps a single before-and-after view of the machine. Account changes land in one place, package installs in another, security settings in a third, and most of it is event-by-event rather than state-over-time. To answer "what is different now versus last Tuesday?" you stitch several sources together, on the one box, and you only see what something was already configured to record.

Windows: what you can check by hand

Windows gives you several windows into change, none of them complete on its own:

• Security Event Log. Account and group changes are auditable events: 4720 when a local user is created, 4732 when a member is added to a security-enabled local group (such as Administrators), and related IDs for resets and deletions. Useful, but only for the events the audit policy is set to record.
• State snapshots with WMI/CIM. Get-CimInstance (or the older Get-WmiObject) dumps installed software, services, accounts, and hardware. Save the output, compare it later, and you have a manual diff.
• Audit policy. auditpol /get /category:* shows what is actually being audited, which is also the first thing to check when an expected event never appeared.
• Registry comparison. Export keys with reg export at two points in time and diff them to catch config that lives nowhere else.

These work. The limits are that the data is noisy, it lives on each box, and there is no easy point-in-time diff of the whole machine without scripting one yourself.

macOS: what you can check by hand

macOS is similar in shape, different in commands:

• System inventory. system_profiler reports hardware, software, and network configuration. Capture it on a schedule and compare snapshots.
• Disk encryption. fdesetup status tells you whether FileVault is on, one of the changes you most want to catch.
• Unified log. log show --predicate ... reads the system log for events in a time window, though it is verbose and built for tracing, not for a tidy config diff.
• Preferences. Reading and comparing defaults values catches setting changes that do not surface anywhere obvious.

Same trade-off as Windows: per-host, manual, and no fleet rollup.

Linux: what you can check by hand

Linux has the richest set of purpose-built tools, and they take the most setup:

• Package state. dpkg -l or rpm -qa lists installed packages and versions; diff two captures to see what was added, removed, or upgraded.
• Syscall auditing. auditd records security-relevant events (file access, account changes) against rules you define, which is powerful and noisy in proportion to how much you tell it to watch.
• Versioned /etc. etckeeper puts /etc under version control so every config edit becomes a commit you can review and revert.
• File integrity. AIDE or Tripwire baseline a set of files and report when they change, which is strong for tamper detection but limited to the files you enrolled.

Each is genuinely useful. None of them, on its own, answers "what changed across all my Linux hosts this week," and standing several of them up per machine is real work.

The approach that scales: snapshot and diff

The manual methods all share the same shape (capture state, capture it again later, compare) and the same ceiling (one machine, by hand, after the fact). The durable version automates that shape:

• Snapshot each endpoint's full state on a schedule, the same way every time.
• Diff each report against the previous one.
• Store the field-level delta with the host and the timestamp, so the record is "local_admins +CORP\\j.harlow on host db-03 at 14:05," not "something changed."
• Flag the security-relevant deltas (new local admin, disk encryption off, firewall change, stale antivirus, new service, cert nearing expiry) apart from routine updates.

This is what change detection is. It does not replace auditd or the Event Log; it sits on top of the same kind of state those tools expose and keeps the history for you. The payoff is that "what changed on this endpoint?" stops being an investigation you run after something breaks and becomes a lookup you can answer in seconds, including for a point in the past.

Frequently asked questions

Related reading: how to track configuration changes across servers, which covers the same problem at the fleet level and where each method fits.