CrowdStrike Falcon Sensor Explained: Install, Updates, Tokens and RFM Fixes

The CrowdStrike Falcon sensor is the one agent behind every Falcon module, and the same install, token and update decisions follow it onto every Windows, macOS and Linux host you manage. This guide covers what the sensor is, how it installs and uninstalls on each platform, what the CID, the maintenance token and sensor update policies do, and what the usual complaints (tampering alerts, CPU spikes, hosts not communicating, Reduced Functionality Mode) mean for the technician who gets the ticket. Every version number and support claim is dated November 2026 and taken from CrowdStrike's published support material or from practitioners on r/crowdstrike.

TL;DR

• What it is. The Falcon sensor is the one CrowdStrike agent per host: a kernel driver on Windows, a system extension on macOS, a kernel module or eBPF program on Linux.
• Install. One installer per OS plus your CID; Windows is one command, macOS needs three approvals, Linux needs a supported kernel.
• Manage. Sensor update policies set the ring (Auto N, N-1, N-2 or pinned); the maintenance token guards uninstall.
• Fix. RFM, not communicating and CPU complaints each get a checklist below.

What the Falcon Sensor Is

Falcon is sold as modules, but every module rides on one agent, and that agent is the Falcon sensor. It installs once per host, registers with your CrowdStrike tenant under an Agent ID (AID), and from then on streams process, file, network and identity telemetry to the Falcon cloud over outbound HTTPS on port 443. Prevention happens on the box: the sensor blocks or kills on its own policy, so a laptop on hotel Wi-Fi is protected whether or not the cloud is reachable at that moment.

How deep it sits depends on the OS. On Windows the sensor loads as a kernel-mode driver, which is why the service you check is csagent, a file-system driver, and not an ordinary user-mode process. On macOS it runs as an Apple-approved system extension with a network content filter, because Apple closed kernel extensions to third parties. On Linux it loads a kernel module where CrowdStrike has certified the kernel, and falls back to a user-mode eBPF backend where it has not. If kernel-mode versus user-mode is fuzzy, the primer on what a kernel is explains why an agent at that layer has to be versioned so carefully.

The buying consequence is that the sensor is never the line item. Falcon Prevent, Insight XDR, Spotlight, Discover, Identity Protection and Falcon for IT are all licences that switch on inside the same agent, which is how CrowdStrike gets to "one agent, one console" in every pitch. Our CrowdStrike Falcon review covers what each module costs; this post stays on the agent itself.

Supported Operating Systems in November 2026

CrowdStrike's public product FAQ carries the live support matrix, and it moves every month. As read in November 2026, the Windows sensor supports Windows 11 21H2 through 25H2, Windows 10 1507 through 22H2, Windows 7 SP1 and Windows Server 2008 R2 SP1 through Server 2025, including Server Core and Azure Local, plus ARM64 builds of Windows 10 and 11. Older systems (XP, Server 2003, Vista, 2008, Windows 8 and 8.1, POSReady 2009) are covered only through the separate Falcon for Legacy Systems product.

Two patterns in that table matter for planning. A new OS release needs a new sensor floor (Golden Gate 27 on 8.10, RHEL 10.2 on 7.38), so an estate pinned to an old build will fail on new hardware before anything else breaks. And the Linux row is distribution-level only; kernel support is listed per kernel in the sensor documentation, and a kernel the sensor does not know puts the host into Reduced Functionality Mode, covered below.

Installing the Sensor on Windows

The Windows installer is a single executable from the Falcon console under Host setup and management, then Sensor downloads. The only mandatory value is your CID, a 32-character Customer ID followed by a two-character checksum, shown on the same download page. Run it silently from an elevated prompt:

code
WindowsSensor.exe /install /quiet /norestart CID=<your CID with checksum>

Optional parameters do the fleet work. GROUPING_TAGS= stamps the host with Falcon grouping tags at install time, so a Server,Finance tag lands it in the right host group and policy on first check-in. APP_PROXYNAME= and APP_PROXYPORT= point the sensor at an explicit proxy. ProvToken= passes an installation token if your tenant requires one, and NO_START=1 installs without starting the service for gold-image builds. Verify with sc.exe query csagent; a healthy host returns STATE: 4 RUNNING for a FILE_SYSTEM_DRIVER.

Two things trip an otherwise clean rollout. The sensor depends on Windows services that hardened images sometimes disable: Duke University's deployment notes list LMHosts, the Base Filtering Engine, DNS Client, WinHTTP AutoProxy and, if you use WPAD, DHCP Client, with the tell-tale log line "A required Windows service is disabled, stopped, or missing." And on Windows Server, Microsoft Defender Antivirus does not step aside on its own; Microsoft's documentation has clients switch Defender to passive mode when a third-party AV registers with Windows Security Center, while servers need passive mode set by policy or Defender removed, or you run two engines scanning each other.

For Intune, package the executable as a Win32 app with the install command above, /uninstall /quiet MAINTENANCE_TOKEN= as the uninstall command, and a detection rule on the csagent service or the Falcon registry key. Group Policy startup scripts and any RMM script engine do the same job; the installer is idempotent and exits cleanly if the sensor is already present.

Installing the Sensor on macOS

The macOS sensor ships as a signed PKG, and the install itself is the easy part. Run the package, then license it with your CID:

code
sudo /Applications/Falcon.app/Contents/Resources/falconctl license <your CID with checksum>

The hard part is the three permissions Apple requires, and this is where unmanaged Macs stall. The Falcon system extension needs approval, Full Disk Access must be granted to the Falcon sensor, and the network content filter has to be allowed, which is the "Falcon would like to filter network content" prompt users search for. Miss the Full Disk Access grant and the sensor runs in Reduced Functionality Mode: it still talks to the cloud, but anything that reads the file system is cut back until the grant lands and, often, the Mac restarts.

On a managed fleet, none of that reaches the user. A Jamf, Intune, Kandji or Hexnode configuration profile pre-approves the system extension by CrowdStrike's Team ID (X9E956P446), ships a PPPC payload granting Full Disk Access, and allows the content filter, so the PKG installs and goes green with no prompts. Since macOS 15.0.1 the vendor guides add a fourth payload that stops users removing the extension from System Settings. If your MDM choice is still open, the Apple MDM comparison covers which tools handle PPPC cleanly.

Verify with two commands. systemextensionsctl list should show com.crowdstrike.falcon.Agent as activated enabled, and sudo /Applications/Falcon.app/Contents/Resources/falconctl stats agent_info returns the version, AID, CID and a Sensor operational: true line. The two-minute walkthrough below shows every click on an unmanaged Mac, including the network filter prompt.

Installing the Sensor on Linux

Linux gets a falcon-sensor package per distribution family, .rpm for RHEL, SLES and Oracle, .deb for Ubuntu and Debian, installed with the native package manager. Then set the CID and start the service:

code
sudo /opt/CrowdStrike/falconctl -s --cid=<your CID with checksum>
sudo systemctl start falcon-sensor

The same binary answers the health questions. falconctl -g --aid confirms registration, falconctl -g --version shows the build, and falconctl -g --rfm-state with --rfm-reason tells you whether the sensor is in Reduced Functionality Mode and why. Running processes should show falcon-sensor, and on a kernel-mode host lsmod | grep falcon lists the module.

Kernel support is the whole game on Linux. Where CrowdStrike has certified your exact kernel, the sensor runs in kernel mode; where it has not, newer sensors fall back to the user-mode eBPF backend, and where neither applies the sensor enters RFM and only heartbeats. Two configurations cause the bulk of RFM tickets: Secure Boot hosts that have not imported CrowdStrike's signing key into the Machine Owner Key list, so the kernel refuses the module, and distributions set to auto-update kernels, which land a kernel the sensor has not seen yet. Duke's guidance is blunt about the second one: pin the kernel and upgrade it once the sensor supports it, rather than letting unattended-upgrades decide your detection coverage.

The CID, the Maintenance Token and Uninstalling

Three identifiers do all the access control around the sensor, and technicians mix them up. The CID is the tenant identifier with its checksum; every installer needs it, and it is not secret in any meaningful sense, which is why tenants can also require an installation (provisioning) token so a leaked CID cannot enrol a stranger's machine. The AID is the per-host identity the cloud assigns at first check-in. The maintenance token is the per-host secret that unlocks uninstall or a manual sensor change when "uninstall and maintenance protection" is on, which CrowdStrike switches on in its default policy.

Protection is a property of the sensor update policy, not of the host. That gives you two legal ways to remove a sensor. Reveal the host's maintenance token in Host management and pass it to the uninstaller, or move the host into an update policy with protection off and uninstall it like any other package. A bulk maintenance token covers the whole policy for imaging teams who would otherwise reveal tokens one host at a time.

code
WindowsSensor.exe /uninstall /quiet MAINTENANCE_TOKEN=<token>
sudo /Applications/Falcon.app/Contents/Resources/falconctl uninstall --maintenance-token

On Linux, remove the package with the package manager after the policy change or token step, and on any platform confirm the removal in the console rather than the host: the AcUnloadConfirmation and AcUninstallConfirmation events in Advanced event search are the receipt. The thread below is the common hard case, an ex-employee's laptop with Real Time Response access and a token in hand but no working command, and the comments walk through the fix (run the uninstaller from a scheduled task, not from inside the RTR session) and the policy shortcut.

Sensor Update Policies and the N-1, N-2 Rings

CrowdStrike ships a new sensor build for each platform every few weeks, and a sensor update policy decides which one each host group runs. The build setting has five positions: Auto N (always the newest general-availability build), Auto N-1 (one release behind), Auto N-2 (two behind), a pinned specific version, or updates off. The Auto positions move on their own as CrowdStrike promotes builds. A customer email quoted on r/crowdstrike in April 2025 read: "On Monday April 28th, 7.23.19508 will be promoted to Auto - N-1, and 7.22.19410 will be promoted to Auto - N-2," which is the whole mechanic in one sentence.

The ring design that practitioners converge on puts a pilot group of IT and security machines on Auto N, the workstation estate on Auto N-1, and servers plus anything with a change board on Auto N-2 or a pinned build with a scheduled bump. Two caveats from the field. First, if CrowdStrike pulls a build, hosts on N-1 and N-2 stay where they are rather than reverting, so a pinned ring is not more stable than an Auto ring, only slower. Second, updates off is a tempting setting that quietly accrues risk: CrowdStrike published advisories for vulnerabilities in the sensor itself in February 2025, October 2025 and September 2026, all fixed by moving to a current build, so a frozen sensor is a known-vulnerable sensor.

The policy also owns the update window (a maintenance window so sensors do not upgrade mid-shift) and the uninstall protection switch described above. The state to watch on the Hosts page is "Pending changes" on a sensor version: a January 2026 r/crowdstrike thread had 2,000 Windows workstations stuck pending on an N-1 policy, and CrowdStrike staff in the thread explained the state as a host that had enough connectivity to learn it was out of sync but not enough to pull the new package. Missing MSI packages in C:\Windows\Installer and very old sensors that cannot jump several builds at once are the other two causes, and moving stuck hosts into a temporary immediate-update policy cleared most of them within days.

Reduced Functionality Mode on Windows

Windows RFM is the complaint that arrives every second Wednesday. When Microsoft's Patch Tuesday update changes the kernel, the sensor on a patched host drops into Reduced Functionality Mode until CrowdStrike certifies that build, which Duke University's deployment notes, drawn from CrowdStrike's documentation, put at usually within 48 hours; practitioners in the thread below put it at Thursday night to Friday. In RFM the Windows sensor keeps monitoring, reporting and detecting, but it unhooks from some kernel elements, so a subset of detection patterns and a small number of preventions are unavailable. It is reduced, not off, and the host still shows a current last-seen time.

That creates a scheduling argument between the patch team and the security team, and the thread below has both sides making it with numbers. One admin deploys to a small test ring the day after Patch Tuesday, accepts roughly 24 hours of RFM on those machines, and holds the rest until certification. Falcon Complete customers add a contractual point: the breach warranty treats an RFM host differently from a fully functional one, which is reason enough to let the ring finish before the broad push. Either way the fix is time, not a reinstall; the sensor pulls the certification file from the cloud and resumes on its own.

When the Sensor Looks Broken: Tampering, CPU and Not Communicating

Three ticket types make up the "is Falcon broken?" pile, and each has a short path. The diagram at the end of this section puts them side by side.

A sensor tampering detection is Falcon reporting that something tried to stop, unload or remove the sensor without the maintenance token. The usual culprit is a technician: an RMM script that stops services during maintenance, a third-party uninstaller sweep, or an imaging tool. Check the process tree in the detection first; if it is your own tooling, exclude the action from the script or add the token to the workflow rather than suppressing the detection, because the same detection is what fires when an attacker tries the identical thing.

High CPU from CSFalconService or com.crowdstrike.falcon.Agent is usually the sensor doing exactly what it was asked to do against a workload that generates a flood of events: build servers, database hosts, backup agents walking the whole disk, developer machines compiling. Measure over an interval before changing anything, confirm the sensor is on a current build (performance fixes ship in sensor releases), and then reach for the narrowest exclusion that fits. Falcon has three kinds for a reason: machine learning exclusions stop the ML engine scanning a path, IOA exclusions suppress a specific behavioural pattern, and sensor visibility exclusions stop the sensor collecting from a path at all. Visibility exclusions are the blunt one, and CrowdStrike's own guidance is to use them only when the other two cannot solve it, because a path the sensor cannot see is a path it cannot defend.

A host that is installed but "not communicating" has a networking problem until proven otherwise. The sensor needs outbound TCP 443 to CrowdStrike's cloud hosts for your region, it pins certificates, and it will not tolerate TLS inspection on that traffic, so the first check is whether a proxy or firewall is terminating the connection. On Windows the sensor logs, Event Viewer and CrowdStrike's CSWinDiag collector show the connection attempts; on macOS falconctl stats reports cloud connectivity; on Linux falconctl -g --rfm-state plus a look at the system journal does the same. A host that never appears in the console at all usually had the wrong CID or no CID, which the macOS and Linux license and --cid commands fix without a reinstall.

The Sensor Next to an RMM Agent, Intune and Jamf

Two or three agents on one endpoint is the normal state of a managed fleet, and the Falcon sensor is built for it. The sensor owns detection, prevention and telemetry. The RMM agent owns monitoring, scripting, patching and remote control. The MDM (Intune, Jamf, Kandji) owns enrolment and the configuration profiles that pre-approve the sensor in the first place. The friction points are predictable: an RMM script that stops the Falcon service triggers a tampering detection, an RMM that deploys the sensor needs the CID and tags in its install command, and a Mac without its PPPC profile sits in RFM until the MDM catches up.

Where the lines move is Falcon for IT. It adds live queries, remediation scripts and risk-based patching to the same sensor, which means some of what the RMM agent did can now run from the Falcon console. The Falcon for IT review covers what it does and does not replace; the short version is that the sensor becomes an IT agent as well as a security agent, and the RMM keeps everything outside the security team's remit.

If you are rebuilding the endpoint stack around that split, the endpoint management comparison lines up the RMM and UEM options that coexist with Falcon, including OpenFrame, Flamingo's own platform, which runs its own RMM agent beside the sensor at $1 per device per month with AI tokens included. Flamingo builds OpenFrame, which competes with some of the tools covered here.

The Call

Treat the sensor as infrastructure, not as an install. Deploy it from your MDM or RMM with the CID and grouping tags baked into the command, keep uninstall protection on and the token workflow documented, run Auto N-1 for workstations with a pilot ring ahead of it, pin Linux kernels and let Patch Tuesday certification finish before the broad push. Do that and the three recurring tickets shrink to the one that matters: a tampering detection that was not you.

For how an MDM and an RMM divide the rest of the endpoint, the Intune vs RMM review is the next read; the Falcon for IT review linked above covers the module side of the same agent.

Keywords: crowdstrike falcon sensor, falcon sensor, crowdstrike install, crowdstrike windows sensor, crowdstrike falcon sensor service, crowdstrike falcon agent, crowdstrike maintenance token, crowdstrike linux, crowdstrike cid, crowdstrike for mac, crowdstrike exclusions, what is crowdstrike falcon sensor, crowdstrike reduced functionality mode