What Is File Integrity Monitoring (FIM)?

An attacker who lands on a host rarely leaves the files alone. They drop a web shell into the web root, swap a signed binary for a trojaned one, add a key to authorized_keys, edit /etc/sudoers, or plant a scheduled task in C:\Windows\System32. Each of those is a change to a file that, a minute earlier, was exactly what the vendor or your build pipeline shipped. The log might not record it. The endpoint agent might not flag the specific binary. But the file is now different from the version you trusted, and that difference is detectable.

File integrity monitoring (FIM) is the control that detects it. FIM records a cryptographic fingerprint of the files and settings that matter, then watches for any deviation from that known-good baseline. When a monitored file changes in a way nobody authorized, FIM raises an alert with what changed, when, and ideally who. This guide covers what FIM is, the six-step process it runs, what it should and should not watch, how it differs from an endpoint agent and from a SIEM, where compliance mandates it, and the failure mode that sinks most deployments: alert noise.

What is file integrity monitoring?

File integrity monitoring is a security process that watches critical files, directories, and system settings for unauthorized change, by comparing their current state against a trusted baseline. The monitored objects are not only files in the everyday sense. FIM covers operating system binaries, configuration files, application code, registry keys on Windows, database schema and content, and the configuration of network devices. Anything whose unexpected modification would signal compromise or a control failure is a candidate.

The mechanism is comparison, not reasoning. FIM does not decide whether a change is malicious by inspecting behavior. It establishes what "correct" looks like, then continuously checks whether reality still matches. A change is a change whether it came from an attacker, a misconfigured automation job, or an administrator who skipped the change-control process. That blunt definition is the point: FIM catches the modification regardless of how clever the actor was about hiding it elsewhere.

This is why FIM survives evasion that defeats log review. A sophisticated intruder will tamper with logs to erase their tracks, deleting entries or stopping the logging service entirely. FIM does not depend on the host's own account of what happened. It depends on the bytes of the file itself. Comparing a file's current hash to its baseline hash exposes the tampering even when every log that should have recorded it is gone. That independence from the attacker-controlled audit trail is FIM's core value, and it is why FIM and log analysis are complementary controls rather than substitutes.

How file integrity monitoring works

FIM runs as a repeating six-step process. The first two steps set up what "good" means; the rest detect and report deviation from it.

1. Define the integrity policy. Decide what to monitor and what counts as a meaningful change. Scope is a deliberate choice: monitoring every file on a host produces unusable noise, so the policy targets the directories, binaries, and keys whose modification actually matters. The policy also defines which attributes are in scope, content, permissions, ownership, size, or all of them.
2. Establish the baseline. Capture the known-good state of every in-scope object: its content, size, permissions, ownership, and other attributes. The baseline is only trustworthy if it is taken from a clean system, so it should be created from a freshly provisioned, patched, hardened host, not from one that has been running in production for a year and may already be compromised.
3. Generate cryptographic hashes. For each monitored file, compute a cryptographic hash (for example SHA-256) of its contents. A hash is a fixed-length fingerprint where any change to the input, even a single byte, produces a completely different output. Storing the baseline as hashes rather than full copies makes comparison fast and makes undetected tampering with a monitored file effectively impossible.
4. Monitor and verify. Recompute the hash and re-read the attributes of each monitored object, then compare against the baseline. This runs either on a schedule (periodic scans) or in real time by hooking filesystem change events. Any mismatch, a different hash, a changed permission set, a new owner, is flagged as a deviation.
5. Alert on unauthorized change. When a deviation is detected, raise an alert. The alert that is actually useful says what object changed, how it changed (old value versus new), when, and where possible which process or user account made the change. The hard part here is distinguishing authorized change (a patch, a sanctioned deploy) from unauthorized change, which is the noise problem covered below.
6. Report and remediate. Feed confirmed findings into incident response and into compliance reporting. A genuine unauthorized change to a sensitive file is an incident input. The same change records also serve as audit evidence that monitoring of in-scope systems is in place and working.

The loop then repeats. After an authorized change, such as a patch, the baseline is updated so the new approved state becomes the reference, and monitoring continues against it.

What FIM should watch (and what it should not)

The single biggest determinant of whether a FIM deployment is useful or ignored is scope. Watch too little and you miss the compromise. Watch too much and the real alert drowns in churn.

High-value targets that belong in scope:

• OS and application binaries. System executables and libraries in locations like /bin, /sbin, /usr/lib, and C:\Windows\System32. These should almost never change outside of a patch, so a change is high signal.
• Configuration files. /etc/passwd, /etc/sudoers, /etc/ssh/sshd_config, web server and database configs, and the Windows registry keys that control startup, services, and security policy. Attackers edit these to establish access and persistence.
• Web content and code. Web roots and application directories where a planted web shell or a modified page would live.
• Credential and access files. SSH authorized_keys, certificate stores, and key material.
• Audit and security tooling config. The configuration of the logging and security agents themselves, because disabling them is a common early step.

Objects to keep out of scope, or handle with care:

• Files that legitimately change constantly. Log files, caches, temp directories, spool files, and databases under normal write load will trip a naive content check on every scan. Monitor their permissions and ownership rather than their content, or exclude them and watch them by other means.
• User home directories at large. High churn, low signal. Target the specific dangerous files inside them (such as shell profiles and authorized_keys) instead of the whole tree.

The discipline is to monitor the files that should be stable and would be dangerous if changed, and to leave alone the files that change all day as a matter of normal operation.

FIM vs EDR vs SIEM

FIM is frequently confused with the controls it sits beside. They overlap at the edges but answer different questions, and a mature program runs all three.

Endpoint detection and response watches process execution, memory, and behavior in real time to detect and stop malicious activity as it happens. FIM watches the persistent state of files and settings. EDR is strong against fileless and in-memory attacks that FIM cannot see, because nothing on disk changed. FIM is strong against quiet, persistent tampering, a swapped binary or an edited config, that looks benign at the process level. Many EDR platforms now bundle a FIM capability, but the two functions remain distinct.

A SIEM does not generate file-change events; it aggregates and correlates them. FIM is a source that feeds the SIEM. A FIM alert on a changed sshd_config becomes far more valuable when the SIEM correlates it with a preceding failed-login burst and a new outbound connection from the same host. FIM produces the integrity signal; the SIEM puts it in context with everything else.

The relationship is layered. FIM tells you the file changed. EDR tells you what ran. The SIEM ties the file change, the process, and the network activity into one incident.

Why FIM matters: detection and compliance

FIM earns its place for two reasons that pull in the same direction: it shortens detection time, and it is mandated by regulation.

On detection, an unauthorized change to a critical file is one of the more reliable indicators of compromise a defender can collect. A trojaned binary, a new web shell, or an edited startup key is hard to commit without changing a file, and FIM catches that change directly rather than inferring it from secondary signals. Because it does not rely on the host's logs, it keeps working against attackers who tamper with the audit trail, which is precisely the population you most want to catch.

On compliance, FIM is named or required by every major data-protection standard:

• PCI DSS explicitly requires change-detection on critical files and alerting on unauthorized modification, with weekly comparison against the baseline (Requirement 11.5 in the current standard). For anyone handling cardholder data, FIM is not optional.
• HIPAA requires mechanisms to protect electronic protected health information from improper alteration, which FIM directly supports.
• GDPR requires appropriate measures to ensure the integrity of personal data, and demonstrable integrity monitoring is part of meeting that obligation.
• NIST SP 800-53 calls for integrity verification of software, firmware, and information (the SI-7 control family), with FIM as a standard implementation.

The two motivations reinforce each other. The same change records that prove an auditor that monitoring is in place are the records an analyst uses to detect and scope an intrusion. A FIM deployment built only to pass an audit, with alerts nobody reads, satisfies neither goal.

The hard part: alert noise

Most FIM deployments fail the same way. They are scoped too broadly, every patch and every sanctioned deploy fires an alert, the alerts are indistinguishable from real findings, and the team stops reading them. A control that everyone ignores detects nothing.

The fix is to separate authorized change from unauthorized change before the alert reaches a human. The levers are concrete:

• Scope tightly. Monitor the stable, high-value objects from the section above, not entire filesystems. Most noise is files that were never worth watching.
• Tie change to change management. Suppress or auto-acknowledge changes that match an approved patch window or a known deploy, so the alerts that survive are the unexpected ones.
• Update the baseline on authorized change. After a sanctioned patch, re-baseline the affected files so the new approved state is the reference and does not keep re-alerting.
• Enrich the alert. A finding that names the changed object, the before and after, the time, and the responsible process or account can be triaged in seconds. One that says only "a file changed" cannot.

When choosing a FIM tool, the criteria that matter follow directly from this problem: how well it integrates with the security stack (especially the SIEM), how precisely change policy can be customized, how much vendor support exists for tuning out false positives, and how actionable the alerts are out of the box. A tool that cannot suppress authorized change will recreate the noise problem no matter how good its detection is.

Frequently Asked Questions

What is file integrity monitoring in simple terms?

File integrity monitoring is a control that records a known-good fingerprint of important files and settings, then watches for any change to them. When a monitored file is modified without authorization, FIM raises an alert showing what changed and when. It catches tampering by comparing files to a trusted baseline rather than trusting the system's own logs.

How does FIM detect unauthorized changes?

FIM computes a cryptographic hash, such as SHA-256, of each monitored file and stores it as a baseline. On each check, it recomputes the hash and compares it to the baseline. Because any change to a file, even one byte, produces a completely different hash, a mismatch reveals that the file was modified. FIM also tracks attributes like permissions, ownership, and size.

What files should file integrity monitoring watch?

FIM should watch objects that are normally stable and dangerous if changed: OS and application binaries, configuration files such as /etc/sudoers and sshd_config, the Windows registry, web roots, credential files like SSH authorized_keys, and the configuration of security tooling. It should avoid high-churn files like logs, caches, and temp directories, which generate noise without signal.

Is FIM the same as EDR?

No. FIM watches the persistent state of files and settings for changes from a baseline, while endpoint detection and response watches process execution, memory, and behavior in real time. EDR catches fileless and in-memory attacks that FIM cannot see; FIM catches quiet on-disk tampering that may not look malicious at the process level. They are complementary, and some EDR tools include FIM.

What compliance standards require file integrity monitoring?

PCI DSS requires change-detection and alerting on critical files (Requirement 11.5). HIPAA requires protecting electronic health information from improper alteration. GDPR requires measures to ensure the integrity of personal data. NIST SP 800-53 calls for integrity verification under its SI-7 control family. FIM is a standard way to meet each of these.

Why does FIM work when attackers delete the logs?

FIM does not depend on the host's logs to detect change. It compares the current bytes and attributes of a file against a stored baseline. Even if an attacker stops the logging service and erases every entry that would record their activity, the modified file still differs from its baseline, so FIM still detects the tampering.

Why do FIM deployments generate so many false alerts?

Usually because they are scoped too broadly. Monitoring entire filesystems means every patch, deploy, and routine write fires an alert, burying the real findings. The fixes are to scope to stable high-value objects, suppress changes that match approved change windows, re-baseline after authorized patches, and enrich alerts so authorized and unauthorized change can be told apart quickly.

The bottom line

File integrity monitoring detects unauthorized change to the files and settings that matter by comparing them, continuously, against a cryptographically hashed known-good baseline. Its defining strength is independence from the attacker-controlled audit trail: it catches the swapped binary, the planted web shell, and the edited config even when the logs that should have recorded them are gone.

FIM runs a six-step loop, define policy, baseline, hash, verify, alert, report, and it lives next to EDR and the SIEM rather than replacing either. It is mandated by PCI DSS, HIPAA, GDPR, and NIST SP 800-53, but compliance is only half the value; the other half is detection. The deployments that deliver both are the ones that scope tightly and tune out authorized change, because a FIM console full of ignored alerts protects nothing.