CrowdStrike Falcon Stuck in Reduced Functionality Mode: Diagnosis Guide
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
Reduced Functionality Mode is the CrowdStrike Falcon failure mode that does not look like a failure. The host keeps its network connection to the CrowdStrike cloud, keeps sending heartbeat check-ins, and keeps showing up in inventory as an enrolled, communicating endpoint. What it stops doing is the part that actually matters: processing most events and registering most detections. A host in RFM is, for practical purposes, running without meaningful EDR coverage while every dashboard that only checks connectivity says otherwise.
This is a troubleshooting guide for a problem that has almost certainly already happened somewhere in your fleet, not a deployment guide. If you have not yet deployed CrowdStrike, Microsoft Defender for Endpoint, or SentinelOne and want the rollout sequence, see the EDR deployment and rollout guide instead. This guide assumes the sensor is already installed and focuses on the narrower, more urgent question: some hosts are silently degraded, how do you find them, and how do you fix the specific cause on each one.
Causes: the three things that put a Falcon sensor into RFM
RFM is not a single condition. It is a safety mechanism the sensor applies whenever it determines that loading its full kernel-mode or system-level hooks on the current host configuration is unsafe or unsupported, and the trigger is different on each operating system. Nearly every real-world case traces back to one of three causes, and the fix for one does nothing for the others, so identifying which cause applies to a given host is the first branch point in any RFM investigation.
All three causes share a pattern: something about the host's underlying OS state changed (a kernel update, a permission that was never granted, an unsupported build) and the sensor responded by protecting itself rather than running in a partially broken state. That design choice is reasonable from a stability standpoint, but it means the security team has to actively look for RFM rather than waiting for an alert, since a degraded sensor does not raise one.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Diagnostics: confirming RFM before you start fixing anything
Do not skip straight to a fix based on a guess about which cause applies. Confirm the host is actually in RFM, then confirm which cause applies to that specific host, before touching kernel versions or permission settings. The console and the local sensor each give you part of the picture, and using both prevents wasted effort chasing the wrong root cause.
In the Falcon console, the Host Management page is where RFM status is exposed. A host in RFM will still show a recent last-seen time and can still look 'online' in summary views, which is exactly why relying on last-seen alone misses it. Filter or sort the host list specifically for reduced functionality mode status rather than trusting the general online/offline indicator, and check the host's OS version and kernel build against what you expect for that fleet segment. Once you have a candidate host, confirm locally.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes: resolving each root cause
The fix branches entirely on which of the three causes applies. There is no single remediation step that clears RFM regardless of platform, and applying the wrong fix (for example, reinstalling the sensor on a Linux host whose real problem is an uncertified kernel) wastes time without resolving anything, since the sensor will simply re-enter RFM on the next boot into the same unsupported kernel.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Validation: confirming the fix actually worked
Exiting RFM is not always instantaneous, and a host that looks fixed immediately after your change may re-enter RFM on the next boot if the underlying condition was not fully resolved. Validate with the same local commands and console fields you used to diagnose the problem, not just by assuming the fix worked because you made the change.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Failure cases: when the standard fix does not resolve RFM
Each platform has a documented case where the straightforward fix does not work, or where RFM is flagged incorrectly in the first place. Knowing these in advance saves time troubleshooting a fix that was never going to succeed.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Escalation criteria: when to open a CrowdStrike support case
Most RFM cases resolve with the platform-specific fix above and normal certification timing. Escalate to CrowdStrike support rather than continuing to troubleshoot locally when any of the following apply, and include the host's platform, kernel or build version, the falconctl output or console RFM status, and how long the host has been in RFM in the case.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
RFM is dangerous precisely because it does not announce itself: the host keeps heartbeating, keeps showing as online, and keeps looking protected in every view that only checks connectivity. Treat RFM detection as a recurring check against the Falcon console's Host Management page and the local falconctl commands on Linux and macOS, not a one-time audit, since a host can silently re-enter RFM on its next kernel update or OS upgrade. The fix is always specific to the cause: wait out or defer kernel certification on Windows, grant and confirm Full Disk Access on macOS, and match sensor version to kernel version on Linux. If you are still deciding between EDR platforms rather than troubleshooting an existing deployment, the comparisons in CrowdStrike vs. SentinelOne and the best EDR platforms roundup cover that evaluation separately from this operational problem.
Frequently asked questions
Can a host be in CrowdStrike RFM and still show as online in the Falcon console?
Yes. This is what makes RFM dangerous operationally: a sensor in Reduced Functionality Mode continues to send heartbeat check-ins to the CrowdStrike cloud, so the host still shows a recent last-seen timestamp and an online or normal-looking status in most console views. What it is not doing is processing most events or registering most detections. The host inventory alone will not surface RFM. You need to check the sensor health or RFM-specific field on the Host Management page, or filter the host list for reduced functionality mode, to find affected endpoints.
What causes CrowdStrike Falcon to enter Reduced Functionality Mode on Windows?
On Windows, RFM is triggered when the sensor detects that the running kernel build has not yet been certified by CrowdStrike. CrowdStrike tests and certifies new Windows kernel builds against the Falcon sensor before enabling full kernel-mode hooking, and this certification process typically completes within about 48 hours of a new build's release, though it can take longer for less common builds or feature updates. Until certification completes and the cloud pushes the update that restores full functionality, any host that has already installed the new kernel build runs in RFM. The fix is either to wait for certification or to hold the host back on a certified kernel build until certification catches up.
Why does CrowdStrike Falcon go into RFM on macOS, and how do I fix it?
On macOS, RFM is caused by the Falcon sensor not having Full Disk Access (FDA) granted at the operating system level. Without FDA, the sensor cannot observe file system activity, which is core to its detection capability, so macOS puts it into reduced functionality rather than running with partial, unreliable visibility. Fix it by granting Full Disk Access to the Falcon sensor, either through an MDM configuration profile (the scalable option for a managed fleet) or manually through System Settings, Privacy and Security, Full Disk Access on an individual Mac. A restart is often needed before the sensor picks up the new permission and exits RFM.
What Linux kernel issue puts CrowdStrike Falcon into Reduced Functionality Mode?
On Linux, RFM happens when the sensor's kernel-mode component does not support the exact kernel version currently running on the host. CrowdStrike certifies the Falcon sensor against specific kernel builds per distribution, and a kernel update, a distribution upgrade, or installing a kernel variant that has not been certified (including some custom or vendor-specific kernels) can put the sensor into RFM immediately after the next boot into that kernel. The fix is to either update the sensor to a version that supports the running kernel, or boot into a kernel version the current sensor build already supports, and to hold off on further kernel updates until CrowdStrike confirms support for the new kernel.
Is there a local command to check if a CrowdStrike sensor is in RFM?
On Linux, yes: run sudo /opt/CrowdStrike/falconctl -g --rfm-state on the host, which returns rfm-state=true or rfm-state=false directly. On macOS, falconctl stats agent_info (run as sudo /Applications/Falcon.app/Contents/Resources/falconctl stats agent_info) shows sensor and agent details, and RFM there is confirmed by checking whether Full Disk Access is granted to the sensor in System Settings rather than a dedicated flag. Windows does not have an equivalent single-command RFM check; sc.exe query csagent confirms the sensor driver and service are running, but RFM status itself is confirmed through the Falcon console rather than a local command.
When should I open a CrowdStrike support case instead of trying to fix RFM myself?
Escalate to CrowdStrike support when a host stays in RFM well past the timeframes each cause would normally explain: a Windows host still in RFM more than a few days after a kernel build's release (past the usual certification window), a Linux host running a kernel version you believe should already be supported per CrowdStrike's published support matrix, or a macOS host still in RFM after Full Disk Access has been confirmed granted and the sensor restarted. Also escalate any case where a kernel is flagged unsupported despite being a currently maintained, vendor-supported build (extended-update-support or long-term kernels have been reported as incorrectly flagged), since that is a certification data issue on CrowdStrike's side, not something you can resolve locally.
Sources & references
- Inventive HQ: Fix "Host is in RFM" (Reduced Functionality Mode) in CrowdStrike Falcon
- Duke OIT: CrowdStrike "Reduced Functionality Mode" (RFM)
- Duke OIT: Troubleshooting the CrowdStrike Falcon Sensor for Linux
- Duke OIT: Troubleshooting the CrowdStrike Falcon Sensor for Windows
- Red Hat: CrowdStrike Agent Operating in Reduced Functionality Mode for Fully Supported RHEL for SAP Systems
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.