How to Configure File Integrity Monitoring (FIM) for the Registry

Overview:

Why a compromise often looks like a quiet edit, not a loud alarm

Most endpoint compromises and most policy drift don't announce themselves. A registry key gets modified to establish persistence, a configuration file gets quietly altered to disable a control, or a value gets deleted to remove evidence, and none of it triggers a traditional alert because nothing crashed and no antivirus signature matched. The change simply happened, and unless something was watching that specific location, it's invisible until the consequences show up somewhere else, sometimes weeks later.

File Integrity Monitoring (FIM) closes that gap by watching specific files, folders, or registry keys for exactly this kind of change: modify, delete, or other integrity-relevant events, and recording who or what process made it, when, and on which endpoint. Unlike a general log stream, FIM is scoped: you tell it precisely what to watch, and it reports on that scope specifically, which keeps the signal usable instead of drowning in noise.

This guide walks the full workflow end to end: creating a FIM configuration, targeting it to specific endpoints and an operating system, defining a monitoring rule for files or for the registry with include and exclude paths, confirming the configuration is capturing real events by making a test change, and reading the resulting event detail, category trends, and per-event process and identifier information.

• Watch what actually matters: scope monitoring to specific paths or registry keys instead of trying to watch everything.
• Cover files and registry alike: the same configuration model applies whether you're watching a config file or a registry key used for persistence.
• See trends, not just a raw log: category-wise event counts and a timeline trend make it possible to notice a spike before reading every individual event.
• Attribute every change: each event records the process, PID, username, and a unique event ID, not just that something changed.
• Cross-platform by design: configurations target Windows, Linux, or Mac endpoints, keeping file and registry integrity monitoring consistent across a mixed fleet.

Prerequisites

Confirm all four before creating a configuration. A monitoring rule pointed at the wrong path, or scoped to no endpoints at all, produces a configuration that looks complete and generates no events.

1. Administrator access: your account holds a role permitted to manage FIM Configuration. Read-only operators can view FIM events but cannot create or modify configurations.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device.
3. Exact path or registry key identified: know the precise file/folder path or registry key you intend to monitor, e.g. HKEY_CURRENT_USER\Software\FIMTest, verified against a real endpoint rather than assumed.
4. Target OS and endpoint scope decided: know whether this configuration targets Windows, Linux, or Mac endpoints, and which specific endpoints, departments, or locations it applies to.

Architecture: how a monitored path becomes an attributed event

A configuration defines what to watch (a category of Files or Registry, with include/exclude paths) and where (scope endpoints, OS). The endpoint agent watches that exact scope and reports each change as an event, attributed to a process, user, and timestamp, into the FIM Events dashboard.

Step 1: Open FIM Configuration

Get oriented before creating anything, so you know what's already being watched.

Instructions

1. From the main console, go to Endpoints → FIM Configuration.
2. Review the existing configuration list: each row shows Name, Description, and Status.

Path: Console / Endpoints / FIM Configuration

Result: You have visibility into existing FIM configurations before creating a new one.

Step 2: Create a FIM configuration and set its details

Start the configuration with a name, an enabled status, and a description of its intent.

Instructions

1. Select Create FIM Configuration.
2. Enter a Name describing what's being watched, e.g. Monitor Registry FIM.
3. Toggle Status on to enable the configuration.
4. Add a Description, e.g. Monitor Registry FIM, stating the intent in plain language.

Path: Console / FIM Configuration / Create FIM Configuration / Details

Console: configuration details

Result: A named, enabled configuration shell exists. Targeting and the actual monitoring rule are defined next.

Step 3: Set the targeting scope

Decide which endpoints and which operating system this configuration applies to.

Instructions

1. Under Targeting, set Scope Endpoints to All Endpoints, Specific Endpoints, Specific Departments, or Specific Locations.
2. For Specific Endpoints, select the exact target device(s), e.g. a specific desktop by hostname.
3. Select the target OS the monitoring rule applies to: Windows, Linux, or (where applicable) Mac.

Path: Console / FIM Configuration / Create FIM Configuration / Targeting

Console: targeting fields

Result: The configuration now has a defined population of endpoints it will actually run on.

Step 4: Configure a Files monitoring rule

Watch a specific file or folder path for integrity-relevant changes.

Instructions

1. Under Monitoring rule, set Category to Files.
2. Set Configuration Type to Files to match.
3. Under Include Paths, enter the specific file or folder path to watch.
4. Under Exclude Paths, enter any subpaths that should be excluded from monitoring, useful for reducing noise from files that change frequently but aren't security-relevant.

Path: Console / FIM Configuration / Create FIM Configuration / Monitoring rule

Console: Files monitoring rule

Result: A file-level monitoring rule exists, generating events for changes within the included paths, minus anything explicitly excluded.

Step 5: Configure a Registry monitoring rule

Watch a specific registry key for changes, useful for detecting persistence mechanisms and unauthorized configuration changes on Windows.

Instructions

1. Under Monitoring rule, set Category to Registry.
2. Set Configuration Type to Registry to match.
3. Under Include Paths, enter the exact registry key path, e.g. HKEY_CURRENT_USER\Software\FIMTest.
4. Under Exclude Paths, enter any subkeys that should be excluded, if the included key has children that shouldn't be watched individually.
5. Save the configuration.

Path: Console / FIM Configuration / Create FIM Configuration / Monitoring rule

Console: Registry monitoring rule

Result: A registry-level monitoring rule exists, generating events for changes to the specified key and its values.

Step 6: Confirm the configuration is live

Verify the configuration is enabled and correctly scoped before relying on it.

Instructions

1. Return to the FIM Configuration list.
2. Confirm the new configuration shows Status: On.
3. Confirm its Description accurately reflects what it's watching, useful later when several configurations exist side by side.

Path: Console / FIM Configuration

Result: The configuration is confirmed live and ready to generate events from real changes on its target scope.

Step 7: Make a test change to confirm detection

Deliberately trigger a real change on the monitored path or key and confirm FIM captures it, rather than assuming the configuration works.

Instructions

1. On the target endpoint, make a real, deliberate change matching the monitored scope. For a registry rule, for example, create a test key and value using PowerShell:
   powershellCopy

   New-Item -Path "HKCU:\Software\FIMTest" -Force
   New-ItemProperty -Path "HKCU:\Software\FIMTest" -Name "TestValue" -Value "Hello" -PropertyType String -Force
   

2. Modify the value to confirm a Modify event is captured, not just a creation:
   powershellCopy

   Set-ItemProperty -Path "HKCU:\Software\FIMTest" -Name "TestValue" -Value "Changed"
   

3. Optionally delete the key or value to confirm a Delete event is also captured.

Path: endpoint-side, via PowerShell or the equivalent file operation

Result: A known, deliberate set of changes now exists on the endpoint, giving you a concrete baseline to check against the FIM Events dashboard in the next step.

Step 8: Review FIM event trends

Check the aggregate view before reading individual events, to spot volume or pattern changes at a glance.

Instructions

1. Go to FIM Events.
2. Review the File Integrity Monitoring Trends chart, showing event volume over time, broken down by OS (Windows, Linux, Mac).
3. Review the Category wise Event Count chart, showing the split between action types, e.g. Modify versus Delete.
4. Use these charts to notice an unusual spike or a shift in behavior before drilling into individual events.

Path: Console / FIM Events

Result: A high-level view of monitoring activity across the fleet, useful for spotting a trend before you'd otherwise notice it in a raw event list.

Step 9: Review individual FIM events and their detail

Drill into a specific event to see exactly what changed, when, and by which process.

Instructions

1. In the FIM Events table, review each row: Endpoint, Category, Target Path, Action (Modify, Delete), and Event Time.
2. Expand a specific event to see its full detail: Type, Category, Event Time, Username, Process (full path and PID), Hashed status, Event ID, Host, and for registry events, the specific Registry Value name and Registry Data.
3. Confirm the test change from Step 7 appears here with the expected Action and Target Path, verifying the configuration is working end to end.

Path: Console / FIM Events / <Event Row>

Console: event detail (example)

Result: A fully attributed record of the change, exactly what a security review or an incident investigation needs: what changed, who or what process changed it, and when.

Step 10: Tune monitoring scope based on real event volume

Use what Steps 8 and 9 revealed to refine the configuration, since a first-pass scope is rarely the final one.

Instructions

1. If a monitored path generates a high volume of routine, expected changes, add those specific subpaths to Exclude Paths rather than disabling the whole configuration.
2. If a configuration has generated no events at all despite expected activity, re-verify the exact Include Paths against the real file or registry location on the endpoint.
3. Periodically revisit the FIM Configuration list to confirm every configuration still reflects a genuine monitoring need, retiring ones tied to a decommissioned application or a resolved investigation.

Path: Console / FIM Configuration (review/edit)

Result: A monitoring scope that stays useful and readable over time, rather than one that either misses real events or drowns them in expected noise.

Best practices for file integrity monitoring

Troubleshooting: common issues and resolutions

Frequently asked questions