Security

How to Address Reduced Functionality Mode (RFM) in CrowdStrike

February 12, 2025
Reduced Functionality Mode (RFM) prevents the Falcon sensor from running expected detection and prevention activities, hampering CrowdStrike's ability to proactively manage threats.
Chris Singlemann

Agent-based security tools like your EDR rely on kernel mode drivers and other low-level components to ensure that they are able to action on the device. In some cases, sensors end up out of sync with the operating system of the device and fall into a suboptimal state.

In the case of CrowdStrike's Falcon sensor, this state is known as Reduced Functionality Mode (RFM). When RFM is active on a Falcon sensor, CrowdStrike will be unable to perform many of its intended functions beyond a heartbeat that indicates the sensor is still present on a device.

This guide will provide guidance on how to understand, identify, and resolve RFM across devices.

What is Reduced Functionality Mode (RFM)?

Reduced Functionality Mode (RFM) is effectively a safe mode for the CrowdStrike Falcon sensor, which activates to prevent compatibility or performance issues on a device. This typically occurs when the host's kernel is uncertified or recently updated, such as after an operating system (OS) update or kernel modification. Without RFM, an outdated Falcon sensor might fall into conflicts with other software or system-level operations, causing system instability, crashes, or degraded performance on the device. And so RFM exists.

While the sensor remains operational in this state and continues to have a heartbeat, its capabilities are heavily limited. Devices running in RFM don’t fire detections or process execution events because the sensor is fully dependent on access to the kernel to handle these activities.

When does RFM occur?

  • Operating system (OS) updates: The most common reason for RFM, and usually occurs when the operating system or kernel version is either too outdated or too new to be compatible with the sensor in kernel mode.
    • In large organizations where OS updates happen automatically, these aren't always coordinated across teams and can be deployed before CrowdStrike is updated for an OS. In organizations with less structured device management, users can easily update their own devices, causing gaps across your estate.
  • Unsupported kernels: Hosts running unsupported Linux or Mac kernels can default into RFM until compatibility is restored.  
  • Failed permissions or settings: Specific to macOS, devices that fail to grant the Falcon sensor Full Disk Access (FDA) can also limit its functionality.

Why does this matter?

When a Falcon sensor enters RFM, it temporarily unhooks from critical kernel elements, reducing its ability to detect and remediate threats. For all the work your team does to tune your EDR for maximum efficacy, those efforts are significantly reduced on those devices.

Depending on the nature of your detection patterns, they might not trigger on devices in RFM. Without an ability to impact the kernel, CrowdStrike can't run any preventative actions. Devices running in this state are thus far more susceptible to attack than those running normally. Even if temporary, RFM is simply greater risk exposure. RFM on your CEO's laptop? Less than ideal.

Methods for identifying devices in RFM

All that said, RFM is one of those situations where what you don't know can hurt you. CrowdStrike has a number of ways to visualize your estate's sensor statuses, but these are manual efforts:

  1. Via CrowdStrike console: Within the Host Management dashboard in Falcon console, you can filter to sensors flagged as RFM. The Executive Summary dashboard also provides a full count of RFM devices but additional search via Investigate (below) or Host Management is required to get a detailed list of hostnames.
  2. Via CrowdStrike query language (CQL): In Falcon console's Investigate tool, you can leverage CQL queries to query the SensorStateBitMap of your environment, changing event_platform to Win, Mac, or Lin and ConfigIDBuild to 17206, 15301, or 17506 respectively depending on the OS.
#event_simpleName=SensorHeartbeat event_platform=UPDATE SensorStateBitMap=2 ConfigIDBuild>=UPDATE
| groupBy([aid], function=(selectFromMax(field="@timestamp", include=[@timestamp, ComputerName, aid, ConfigBuild])))
| rename([[ComputerName, Hostname], [aid, "Sensor ID"], [FileName, "OSFM Filename"], [ConfigBuild, "Agent Build"]])

Regularly performing either of these activities requires time out of your team's day. When every minute counts, even 30 minutes a week for regular checks of RFM adds up to time (26 hours, to be exact) your team is spending on making sure the tools you're paying for are working as expected.

Prelude automatically ingests this information, flags devices in RFM, and alerts teams as devices fall into that state. It's even available for a free trial. </shill>

Resolving RFM across operating systems

Getting sensors out of RFM ensures your Falcon sensor operates optimally. Resolving those devices mitigates the risk associated with the underperforming sensor.

Windows

If a Windows update has altered the kernel, CrowdStrike will release an OSFM certification file once the kernel is certified. On major updates, typically this occurs within the same day. Sensors will automatically apply the certification file and resume full functionality. To verify the OSFM file, use the CrowdStrike console or run the query below to ensure the current certification file is applied.

#event_simpleName=LFODownloadConfirmation CompletionEventId=Event_OsfmDownloadCompleteV1 FileName=Osfm-*.bin
| groupBy([aid], function=(selectFromMax(field="@timestamp", include=[@timestamp, ComputerName, aid, FileName, ConfigBuild])))
| rename([[ComputerName, Hostname], [aid, "Sensor ID"], [FileName, "OSFM Filename"], [ConfigBuild, "Agent Build"]])

In organizations with less frequent updates or without stringent device management, hosts can run outdated or unsupported Windows builds with greater frequency. Those builds need to be updated to a compliant version in order to restore the sensor to its optimal state.

Linux

On Linux devices, you can resolve a sensor in RFM and return it to kernel or user mode by either upgrading the Falcon sensor to a version that supports the host's current kernel or changing the host's kernel to one that meets the specifications for the Falcon sensor.

Automatic kernel updates are typically a driver for RFM on Linux estates. By disabling automatic updates, you can prevent RFM in most cases and updating only when the host's kernel is supported by the Falcon sensor.

Mac

Mac devices require Full Disk Access (FDA) to remediate RFM. Depending on whether your estate is managed with an MDM solution, the implementation can be done by installing a profile. Otherwise, FDA needs to be granted on a device-by-device bases via the system preferences on the device. The device should automatically leave RFM once FDA is enabled for the Falcon sensor.

Final thoughts on managing RFM

You invest heavily in security tools to bolster your defenses, and EDR is typically chief among them. Regularly detecting and preventing threats means your primary defensive tool needs to be running in an optimal way as often as possible.

With RFM in effect, a device is far more vulnerable to attack. Decreased detection and prevention capabilities. Understanding which devices are in RFM is not a proactive exercise in most cases, but Prelude's continuous monitoring platform does offer additional visibility and automation to ensure your CrowdStrike deployment is working as expected.

Start monitoring controls free for 14 days

Connect your controls and see how your tools stack up against the latest threats