The CrowdStrike Falcon console shows a host with the warning:
Warning: Host is in RFM (Reduced Functionality Mode)
This is not a cosmetic status. A sensor in Reduced Functionality Mode does not process events or register detections — the endpoint is effectively running without protection, while still appearing in the console because the sensor continues to send heartbeats.
That combination is what makes RFM dangerous operationally: the host looks present and accounted for on the dashboard, and nothing about the endpoint's day-to-day behaviour signals a problem.
Why This Happens
RFM is a deliberate safe mode. Rather than risk destabilising a machine it cannot fully support, the sensor steps back to a minimal state. The trigger differs by platform:
Linux — the running kernel is not supported by the sensor in kernel mode, and does not meet the sensor's user-mode requirements either. This is overwhelmingly the most common cause, and it usually appears the first time a host boots after a routine kernel package update.
Windows — the running kernel build has not been certified by CrowdStrike yet. New Windows feature updates and cumulative updates can briefly outrun sensor certification.
macOS — Full Disk Access has not been granted to the Falcon sensor, so it cannot observe the file system events it depends on.
In every case the sensor is installed and the service is running. Nothing is broken; the sensor has decided it cannot safely do its job.
Fix 1: Confirm RFM and Find the Reason (Linux)
Before changing anything, get the sensor to tell you why. On the affected host:
sudo /opt/CrowdStrike/falconctl -g --rfm-state
If RFM is enabled, get the reason:
sudo /opt/CrowdStrike/falconctl -g --rfm-reason
The reason is what determines the fix — an unsupported kernel and a licensing or configuration problem lead to completely different remediation, and guessing wastes a maintenance window.
Confirm the sensor is otherwise running normally:
ps -e | grep -e falcon-sensor
lsmod | grep falcon
And check the running kernel against what the sensor supports:
uname -r
sudo /opt/CrowdStrike/falcon-kernel-check
falcon-kernel-check reports whether the active kernel is supported by the installed sensor. You can also test a specific kernel before booting it:
sudo /opt/CrowdStrike/falcon-kernel-check -k 5.15.0-119-generic
That last command is the useful one for planning: it lets you find out whether a pending kernel upgrade will drop the host into RFM before you reboot into it.
Fix 2: Resolve an Unsupported Kernel (Linux)
There are two supported ways out, and which one you choose depends on what you control more easily.
Option A — upgrade the sensor. Move the host to a sensor version that supports your running kernel. This is usually the right answer, since it moves you forward rather than backwards and does not require a kernel rollback. Sensor upgrades are managed through your sensor update policies in the Falcon console.
Option B — boot a supported kernel. If a sensor version that supports the new kernel is not available yet, boot the previous known-good kernel:
# List installed kernels
grep ^menuentry /boot/grub2/grub.cfg # RHEL/CentOS
grep ^menuentry /boot/grub/grub.cfg # Debian/Ubuntu
# Boot a specific kernel next restart (RHEL family)
sudo grubby --set-default /boot/vmlinuz-<supported-version>
sudo reboot
After the reboot, re-check the state:
sudo /opt/CrowdStrike/falconctl -g --rfm-state
Do not "fix" RFM by uninstalling or masking the sensor. That converts a degraded endpoint into an entirely unmonitored one, and the host disappears from the console rather than being flagged.
Fix 3: Grant Full Disk Access (macOS)
On macOS, grant Full Disk Access to the Falcon sensor. At scale this must be an MDM configuration profile — a Privacy Preferences Policy Control (PPPC) payload targeting the Falcon sensor — pushed from Intune, Jamf or your MDM of choice. Manual approval on each Mac does not scale and tends to regress after OS upgrades.
To confirm on an individual machine, check System Settings → Privacy & Security → Full Disk Access and verify the Falcon sensor is listed and enabled. A restart may be needed before the sensor leaves RFM.
Check sensor status directly with:
sudo /Applications/Falcon.app/Contents/Resources/falconctl stats
Fix 4: Wait for Kernel Certification (Windows)
On Windows, RFM after a Windows update usually resolves itself. CrowdStrike certifies new Windows kernel builds — typically within about 48 hours — and the sensor then receives a file from the CrowdStrike cloud instructing it to resume full functionality. No action is required on the endpoint.
Two things are worth doing while you wait:
- Confirm the host has cloud connectivity, since the sensor cannot receive the certification file without it. Check the host is checking in under Hosts → Host Management.
- Treat the host as unprotected in the interim. If it is a high-value system, consider compensating controls for the window rather than assuming the gap is trivial.
If the host is running a Windows version that is no longer supported by your sensor, waiting will not help — upgrade the OS or move to a sensor version that supports it.
Verify the Fix
On Linux, confirm RFM has cleared:
sudo /opt/CrowdStrike/falconctl -g --rfm-state
Then confirm the sensor is connected to the cloud:
sudo netstat -tapn | grep falcon
And check recent sensor log entries for errors:
sudo grep falcon /var/log/messages | tail -n 100
Finally — and this is the step people skip — confirm in the Falcon console that the host no longer carries the RFM warning and is generating telemetry. A clean local state with no console-side confirmation is not a completed fix.
Prevention
- Audit for RFM on a schedule. Filter Host Management by RFM status weekly. Because RFM hosts still send heartbeats, they will never surface as "missing" on their own.
- Test kernels before you deploy them.
falcon-kernel-check -k <version>tells you in advance whether a pending kernel will be supported. - Control the kernel upgrade cadence on Linux. Pin kernels and upgrade deliberately once the sensor supports them, rather than letting unattended upgrades pull in arbitrary new kernels. Balance this against your patching obligations — the goal is controlled timing, not deferred patches.
- Deploy macOS Full Disk Access by MDM profile, so it survives OS upgrades and machine rebuilds.
- Keep sensor versions current with staged update policies, so kernel support arrives before your kernels do.