Compliance

Enable file integrity monitoring

One capability for your servers: detect, and keep a tamper-evident record of, every change to the operating system files, binaries and registry keys an attacker has to touch to gain persistence, so a quiet change to a critical file stops being invisible.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-file-integrity-monitoring-machines

File integrity monitoring: the basics

What does 'File integrity monitoring should be enabled on machines' actually check?

File integrity monitoring, or FIM, watches the files and registry keys that should almost never change on a healthy server: operating system binaries, system libraries, boot files, scheduled-task definitions and the Windows registry run keys an attacker has to modify to gain persistence. When one of those changes, FIM records what changed, when, and on which machine, and surfaces it for review. Defender for Cloud expresses the gap as a single recommendation, 'File integrity monitoring should be enabled on machines', and it fails for every virtual machine, scale set or Azure Arc-connected server in scope that does not have FIM collecting change events.

This is a Microsoft Defender for Servers Plan 2 capability, not a free posture check. The recommendation only clears once the machine is covered by Defender for Servers Plan 2, the Defender for Endpoint agent on it is reporting change data, and the subscription has FIM enabled against a Log Analytics workspace where the change events are stored. Because the data collection moved to the Defender for Endpoint agent, the older Log Analytics agent and Change Tracking extension path is retired: support for the Microsoft Monitoring Agent ended in November 2024, so a machine still relying on it is not a passing configuration, it is a migration you have not finished.

The point of the control is not to stop changes, changes are normal, it is to make unauthorised changes visible. A server where FIM is off can have its sshd binary swapped, a new admin run key added or a system library replaced, and nothing in the platform will tell you. A server where FIM is on turns each of those into a recorded, queryable event. The work in this lesson is to get FIM collecting on every server in scope, point it at a workspace you actually review, and tune the default rules so the signal is useful rather than noise.

In this lesson you will learn what file integrity monitoring detects, how Defender for Cloud decides a machine is covered, and how to enable FIM across a subscription without drowning in noise from legitimate change. The Controls this lesson covers section lists the Defender for Cloud recommendation in this capability, linking to a deep page with the exact check and a copy-and-paste path to remediation.

Fun fact

The change nobody saw for months

The reason file integrity monitoring is written into PCI DSS, as a required change-detection mechanism on critical files, is that supply-chain and persistence attacks almost always leave their fingerprints in exactly the files FIM watches: a modified system binary, a new service, an altered startup script. In several of the most damaging intrusions on record, the malicious change sat on production servers for months because no control was comparing those files against a known-good baseline. FIM does not prevent the change. It makes sure that when investigators finally look, there is a dated record of precisely what changed and when, instead of a shrug.

Finding which servers have no file integrity monitoring

Priya is the security lead at a payments company moving from a single flat subscription to a governed landing zone ahead of a PCI DSS assessment. Defender for Cloud flags 'File integrity monitoring should be enabled on machines' across most of the server fleet, because FIM was never switched on after Defender for Servers was enabled.

Before turning anything on, Priya checks which subscriptions even have Defender for Servers Plan 2, since FIM is a Plan 2 capability and the recommendation cannot clear on a machine that is only covered by Plan 1 or by no plan at all.

Start by checking the Defender for Servers plan on the subscription. FIM needs Plan 2 ('P2'); Plan 1 will not satisfy the recommendation.

$ az security pricing show -n VirtualMachines --query "{tier:pricingTier, subPlan:subPlan}" -o table

Tier SubPlan

-------- --------

Standard P1

# Plan is on, but it is Plan 1. FIM is a Plan 2 capability, so the

# recommendation cannot clear until this subscription moves to P2.

FIM is gated behind Defender for Servers Plan 2. A subscription on Plan 1, or with no plan, can never pass this recommendation no matter how the machines are configured. Confirm the plan first.

How Defender for Cloud decides a machine has file integrity monitoringdeep dive

The recommendation resolves to a chain of conditions, and all of them have to hold. First, the machine must be covered by Microsoft Defender for Servers Plan 2, because FIM is a Plan 2 feature; a machine on Plan 1, or on no plan, fails regardless of anything else. Second, the Defender for Endpoint agent on the machine must be present and recent enough to report change data: on down-level Windows that means MDE agent version 10.8799 or later, and on Linux it means version 30.124082 or later. Third, FIM must be enabled at the subscription level and pointed at a Log Analytics workspace, which is where the change events are stored and queried.

The data collection model changed, and this matters when you read an old runbook. FIM used to rely on the Log Analytics agent or the Azure Monitor Agent plus a Change Tracking extension. That path is retired: the Microsoft Monitoring Agent reached end of support in November 2024, and FIM now collects through the Defender for Endpoint agent that Defender for Servers already deploys. A machine that looks like it has FIM but is still on the legacy agent is not a healthy state, it is an unfinished migration, and it will eventually stop reporting.

Once enabled, FIM applies a set of default rules covering the files and registry keys most worth watching: core operating system binaries and libraries, boot and startup files, and on Windows the registry run keys used for persistence. You can add custom rules for application-specific paths, within the platform's validation limits: a path may contain at most three asterisks, wildcards are only allowed at the start or end of a path segment, and Windows registry rules must begin with HKLM. Defender for Cloud assesses the recommendation on a periodic cycle, so enabling FIM clears the finding on the next assessment rather than instantly. One known behavioural nuance: on Linux, FIM does not distinguish a file being created from a file being modified, it logs both as a modify event, which is worth knowing before you build alerting on top of the data.

What is the impact of leaving file integrity monitoring off?

The direct impact is a blind spot at exactly the layer attackers operate. Persistence, privilege escalation and defence evasion almost all involve touching files or registry keys that should be stable: replacing a system binary, dropping a malicious library, adding a startup entry, altering a scheduled task. Without FIM, those changes leave no platform-level record, so an intrusion can live on a server for as long as it stays quiet. With FIM, each of those becomes a dated, attributable event you can find later, which is often the difference between scoping an incident in hours and reconstructing it from guesswork.

The second-order impact is incident response. When something does go wrong, the first questions are what changed, when, and on which hosts. A server with FIM enabled can answer those questions from its change log. A server without it cannot, which lengthens dwell time, widens the apparent blast radius because you cannot rule machines out, and makes a confident all-clear almost impossible to give.

On the compliance side, file integrity monitoring is not optional decoration. PCI DSS explicitly requires a change-detection mechanism on critical system, configuration and content files, configured to compare them at least weekly, and frameworks such as ISO 27001 and SOC 2 expect equivalent integrity controls. A clean 'File integrity monitoring should be enabled on machines' across the in-scope fleet is the artefact that demonstrates the requirement is met, rather than asserted.

How do you enable file integrity monitoring safely?

Work the capability in order. FIM cannot run without the right plan and a workspace to store its data, so get those in place first, then enable the capability, then tune it so the change log stays useful rather than becoming noise nobody reads.

1. Confirm Defender for Servers Plan 2 on the in-scope subscriptions

FIM is a Plan 2 capability, so the first move is to make sure the subscriptions holding the servers you care about are on Plan 2, not Plan 1 or no plan. Prioritise the subscriptions in regulatory scope, where the change-detection requirement is non-negotiable, before broadening to the rest of the estate.

2. Enable FIM and point it at a workspace you review

Turn on file integrity monitoring in the Defender for Servers plan settings and select the Log Analytics workspace where change events will be stored. Choose a workspace the security team actually queries, because FIM only delivers value if someone reads the change log. Make sure the Defender for Endpoint agent on each machine meets the minimum version, since older agents will not report change data.

3. Accept the default rules, then tune for noise

Start with the default rules covering OS binaries, boot files and Windows registry run keys, which is the high-value set, then add custom rules for application paths that matter to you. Identify the legitimate change sources, a configuration-management tool or a patch window, so expected churn is understood rather than treated as suspicious. Remember that on Linux a create and a modify both log as a modify event when you build any alerting.

4. Ratchet it shut with Azure Policy

Assign the built-in policy for this recommendation so new and existing machines are continuously assessed for FIM coverage, and your governance reports the gap instead of relying on someone to check. Look the policy up by its exact display name at assignment time rather than pasting a definition ID, so you are always binding to the current built-in.

# 1. Ensure the subscription is on Defender for Servers Plan 2 (subplan P2).
#    FIM is a Plan 2 capability; Plan 1 cannot satisfy the recommendation.
az security pricing create \
  --name VirtualMachines \
  --tier standard \
  --subplan P2

# 2. Enable file integrity monitoring and select the workspace that stores
#    change events. This is configured in the Defender for Servers plan
#    settings (Azure portal or the Microsoft.Security/pricings REST API);
#    there is no dedicated 'az' flag to toggle FIM itself. Point it at a
#    Log Analytics workspace the security team actually reviews, and confirm
#    the Defender for Endpoint agent meets the minimum version on each host
#    (Windows down-level 10.8799+, Linux 30.124082+).

# 3. Ratchet it shut: assign the built-in policy by EXACT display name so the
#    fleet is continuously assessed for FIM coverage. Look the id up at
#    runtime rather than hardcoding a definition GUID.
pid=$(az policy definition list \
  --query "[?displayName=='File integrity monitoring should be enabled on machines'].name" \
  -o tsv)

az policy assignment create \
  --name require-fim-on-machines \
  --display-name "Require file integrity monitoring on machines" \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows 'File integrity monitoring should be enabled on machines' across most of a subscription's servers. What is the first thing to confirm?

Keep learning

Go deeper on how file integrity monitoring works in Defender for Cloud, what it monitors, and how to enable it through the Defender for Endpoint agent.

You can now treat file integrity monitoring as one capability rather than a scatter of findings: confirm the in-scope subscriptions are on Defender for Servers Plan 2, enable FIM against a Log Analytics workspace the security team reviews, accept the default rules and tune out the known change sources, and ratchet it shut with an audit policy. The Controls this lesson covers section below links the recommendation in this group to its deep page and the path to remediation.

Back to the library

File integrity monitoring: the cost and risk view

A licensed detection capability whose cost is the Defender for Servers plan, not a per-server add-on

Unlike most hardening controls, FIM is not free: it is part of Microsoft Defender for Servers Plan 2, which is billed per server hour, so enabling the capability means committing to the plan on the machines in scope. The good news for forecasting is that the cost is predictable and already partly absorbed: Plan 2 bundles a daily data allowance per protected server for FIM and the other Defender data types, so the workspace ingestion for change events usually sits inside the included allowance rather than adding a separate Log Analytics bill.

Frame the decision as detection coverage, not a line item to minimise. Plan 2 is the same plan that delivers vulnerability assessment, just-in-time VM access and the other server protections, so FIM rarely justifies the plan on its own, it is one of several capabilities you are already paying for once Plan 2 is on. The marginal question is narrow: which servers genuinely need Plan 2, and is FIM switched on for them, rather than whether FIM has its own budget.

The risk side is where the arithmetic turns one-sided. The capability is a named requirement of PCI DSS, which mandates a change-detection mechanism on critical files, and it is the control that converts a silent persistence change into evidence during an incident. Against the bounded, forecastable plan cost sits the unbounded cost of an intrusion that lived on a server for months because nothing was watching the files it altered.

This lesson is for the finance partner who sees 'File integrity monitoring should be enabled on machines' on the security report and wants to know what it costs and what it buys. It covers why FIM is licensed through Defender for Servers Plan 2 rather than free, why its ingestion usually fits the included data allowance, and how to weigh the bounded plan cost against the compliance requirement and incident risk it covers.

Fun fact

The change nobody saw for months

How a finance partner frames the FIM decision

Priya is the finance partner supporting the payments company's PCI DSS push. The recommendation lands against most of the server fleet, and the platform team's first instinct is to ask for budget to 'turn on FIM'. Priya reframes it: FIM is not its own purchase, it is one capability inside Defender for Servers Plan 2, which is billed per server hour and which the company is already partly paying for where Plan 2 is enabled. The real spend question is which subscriptions need to move from Plan 1 to Plan 2, because Plan 1 cannot run FIM at all, and the change-event ingestion itself usually fits inside the daily data allowance Plan 2 already bundles per protected server.

Priya asks the team to split the fleet into machines that are in PCI scope, where the change-detection requirement is non-negotiable and Plan 2 is justified by the assessment alone, and the rest, where Plan 2 is a broader posture decision. The finance pack reads: 'FIM has no separate budget line; the cost is the Plan 2 upgrade on the subscriptions that hold cardholder-data servers, which is forecastable per server hour and which we need for the assessment regardless. Ingestion for change events sits inside the plan's included data allowance. The control we are buying is the documented change-detection mechanism the assessor will ask for.'

Why file integrity monitoring earns its plan cost

The cost model here is unusual for a security control in that the spend is real and forecastable rather than free, which actually makes the trade-off easier to reason about. FIM costs the Defender for Servers Plan 2 plan on the machines in scope, billed per server hour, with change-event ingestion generally absorbed by the daily data allowance Plan 2 already includes per protected server. There is no surprise tail: the bill scales with the number of protected servers, and you can model it before you commit.

Against that bounded cost sits two things money cannot easily buy back. The first is a compliance requirement: PCI DSS names a change-detection mechanism as mandatory, so for cardholder-data servers FIM is the cost of being assessable at all, not a discretionary upgrade. The second is incident economics: the documented cost of an intrusion grows with dwell time, and FIM is precisely the control that shortens it by turning silent file changes into evidence. The finance role is to confirm the plan is on for the servers that warrant it and to treat FIM as one of the several capabilities that Plan 2 spend already covers.

What finance can do about the FIM gap

Finance cannot enable a Defender plan, but it owns the framing that keeps FIM from being mistaken for either a free toggle or an open-ended new budget. Three levers.

1. Tie the cost to the Plan 2 decision, not to FIM alone

Make explicit that FIM has no standalone price: it is one capability inside Defender for Servers Plan 2, billed per server hour, and the change-event ingestion generally sits inside the daily data allowance the plan already bundles per protected server. The budget question is which subscriptions move from Plan 1 to Plan 2, not how much FIM costs by itself. Framing it this way stops the team from either under-costing it as free or over-costing it as a separate tool.

2. Make regulatory scope the first cut

Servers holding cardholder data or other regulated data carry a hard requirement for a change-detection mechanism, so Plan 2 and FIM on those subscriptions is the cost of being assessable, not a discretionary upgrade. Fund those first and forecast the plan cost per server hour for that scope, then treat Plan 2 on the rest of the estate as a separate, broader posture decision rather than bundling it into the compliance ask.

3. Account for the capability you already pay for

Where Plan 2 is already enabled, FIM may simply be switched off rather than unpurchased. Ask the team to confirm whether the gap is a plan upgrade you need to fund or a capability inside a plan you are already buying that nobody turned on. The second costs nothing incremental, and surfacing the difference keeps the finance pack honest about what is actually a spend decision.

Quick quiz

Question 1 of 5

The platform team asks for budget to 'turn on FIM'. As the finance partner, what is the right way to frame the cost?

Keep learning

Go deeper on how file integrity monitoring works in Defender for Cloud, what it monitors, and how to enable it through the Defender for Endpoint agent.

You have finished the finance view of file integrity monitoring. You know the cost is not free and not open-ended: it is the Defender for Servers Plan 2 plan, billed per server hour, with change-event ingestion usually absorbed by the included data allowance. Next time the recommendation lands, you will fund Plan 2 first for the regulated servers where a change-detection mechanism is mandatory, check whether the gap is an unpurchased plan or an unenabled capability you already pay for, and weigh the bounded cost against the compliance requirement and incident risk it covers.

Back to the library

File integrity monitoring: the headline

Whether a quiet change to a critical system file on any server would be seen, or would pass unnoticed

Attackers who get onto a server rarely announce themselves. They modify a system file, add a persistence key, or replace a trusted binary, and then wait. File integrity monitoring is the control that decides whether those changes are recorded and reviewable, or invisible until the damage surfaces. The report shows the gap as a scatter of servers where nothing is watching the files that matter.

The leadership question is not 'have we bought the tool?' It is 'if something tampered with a server tomorrow, would we have a record of it?' The defensible end state is that every server in scope is covered by the Defender for Servers plan, FIM is collecting change events into a workspace the security team reviews, and the few intentional change sources are understood rather than treated as alerts.

This is a spend decision, but a contained one. FIM rides on the Defender for Servers Plan 2 you license for server protection, so the question is not a new budget line, it is whether the plan is switched on for the servers that warrant it and whether this specific capability is actually turned on within it.

A short read for the leader who needs to know what file integrity monitoring detects, why it is the control that makes a silent server intrusion visible, and what a defensible end state looks like across the server estate without it becoming an open-ended cost.

Fun fact

The change nobody saw for months

What it looks like when a server change can no longer hide

When the payments company's board reviewed readiness for its first PCI DSS assessment, the question that stuck was simple: if someone tampered with a production server, would we know? The honest answer at the time was no, because file integrity monitoring had never been switched on, so a modified binary or a new persistence key on any of the in-scope servers would have left no trace the team could point to.

The team's response was to treat FIM as part of the server-protection baseline rather than a feature to evaluate later. They moved the subscriptions holding cardholder-data servers to Defender for Servers Plan 2, enabled file integrity monitoring against a Log Analytics workspace the security team actually reviews, accepted the default rules covering OS files and registry run keys, and tuned out the few known noisy change sources. The next time the board asked the question, the answer had changed from 'we would not know' to 'every in-scope server records changes to its critical files, and we have the dated evidence the assessor requires.' That shift, from a silent server to a tamper-evident one, is the confidence signal this capability delivers, and its cost is the Plan 2 the assessment requires anyway.

Why this is a board-level risk

Nearly every serious server intrusion involves a change to a file or registry key that should have been stable, and the damage is almost always proportional to how long that change went unseen. File integrity monitoring is the control that decides whether such a change is recorded the day it happens or discovered months later, and for regulated workloads it is a named requirement rather than a nice-to-have.

The cost of this one is real but contained and predictable: it is part of the Defender for Servers plan you license for server protection, not an open-ended new commitment. This is the rare case where the spend is easy to forecast and the downside of skipping it, an undetected intrusion on a critical server, is exactly the kind of event leadership least wants to explain after the fact.

The leadership move on file integrity monitoring

The executive handle is not to approve FIM line by line; it is to set the expectation that every server in scope can answer 'what changed and when', and that the plan which delivers it is on for the servers that warrant it.

1. Make regulated servers the non-negotiable baseline

For any server in PCI DSS or equivalent scope, a change-detection mechanism is a requirement, not a choice. Set the expectation that those subscriptions are on Defender for Servers Plan 2 with FIM enabled before the assessment, and that this is treated as the cost of being assessable rather than an optional upgrade to debate.

2. Ask for proof, not assurance

The proof that this is closed is a clean 'File integrity monitoring should be enabled on machines' across the in-scope fleet plus evidence the audit policy is assigned, not a verbal 'FIM is on'. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with lead time before any audit date rather than the morning of.

3. Insist the change log is actually read

FIM only earns its cost if someone reviews the change events it records. The leadership requirement is not just that FIM is enabled, but that it points at a workspace the security team monitors and that the known, legitimate change sources are understood, so a genuinely suspicious change stands out instead of drowning in routine churn.

Quick quiz

Question 1 of 5

At a board review you ask whether the company would know if a production server were tampered with. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how file integrity monitoring works in Defender for Cloud, what it monitors, and how to enable it through the Defender for Endpoint agent.

Two takeaways. File integrity monitoring is the control that decides whether a quiet change to a critical server is recorded the day it happens or discovered months later, and for regulated workloads it is a named requirement, not a nice-to-have. And the cost is real but contained: it rides on the Defender for Servers plan you license for server protection, so the question is whether that plan is on for the servers that warrant it and whether someone actually reviews the change log it produces.

Back to the library

Part of the learning path Turn on Azure detection

Enable file integrity monitoring

File integrity monitoring: the basics

The change nobody saw for months

Finding which servers have no file integrity monitoring

How Defender for Cloud decides a machine has file integrity monitoringdeep dive

What is the impact of leaving file integrity monitoring off?

How do you enable file integrity monitoring safely?

1. Confirm Defender for Servers Plan 2 on the in-scope subscriptions

2. Enable FIM and point it at a workspace you review

3. Accept the default rules, then tune for noise

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

File integrity monitoring: the cost and risk view

The change nobody saw for months

How a finance partner frames the FIM decision

Why file integrity monitoring earns its plan cost

What finance can do about the FIM gap

1. Tie the cost to the Plan 2 decision, not to FIM alone

2. Make regulatory scope the first cut

3. Account for the capability you already pay for

Quick quiz

Keep learning

File integrity monitoring: the headline

The change nobody saw for months

What it looks like when a server change can no longer hide

Why this is a board-level risk

The leadership move on file integrity monitoring

1. Make regulated servers the non-negotiable baseline

2. Ask for proof, not assurance

3. Insist the change log is actually read

Quick quiz

Keep learning

Related compliance lessons