The CrowdStrike Falcon sensor. And whether it is really working.
The commands are the easy part. The part that catches people is that a sensor can be running, reporting in, and visible in the console while it protects nothing at all.
The CrowdStrike Falcon sensor is the single lightweight agent CrowdStrike installs on an endpoint. It runs on Windows, macOS and Linux, performs prevention locally, and streams telemetry to the Falcon cloud where the heavier correlation happens. The same sensor serves the other Falcon modules, so adding endpoint protection, identity protection, cloud security or Next-Gen SIEM is a licensing change rather than another agent.
The Falcon sensor service is what keeps that agent running. On Windows it is two services: CSFalconService, which appears in services.msc as "CrowdStrike Falcon Sensor Service", and csagent, the kernel driver service beneath it. On macOS and Linux the equivalent is a daemon queried through falconctl.
Confirming the service is running is not the same as confirming the endpoint is protected. A sensor in Reduced Functionality Mode continues sending heartbeats, so the host still appears in the Falcon console, while it stops processing events and registering detections.
One sensor. Not one per thing you bought.
One agent per host
A single lightweight sensor covers Windows, macOS and Linux. It deploys without a reboot, which is the detail that makes a fleet-wide rollout a scheduling question rather than a change-window question.
Local prevention, cloud correlation
The sensor blocks what it can decide about on the spot and streams the rest to the Falcon cloud, where it is correlated against telemetry from every other customer. That split is why the agent stays small.
Modules are licensed, not installed
The same sensor already on the host serves endpoint protection, identity protection, cloud security and Next-Gen SIEM. Adding one is an entitlement change. There is no second agent to deploy and no second thing to keep running.
It registers, then it reports
On install the sensor is given a customer ID and is issued an agent ID once it registers. A sensor with a running service and no agent ID started but never checked in, which is a different fault with a different fix.
Checking it is running.
Two services, not one. CSFalconService is the user-mode service, shown in services.msc as "CrowdStrike Falcon Sensor Service". csagent is the kernel driver service underneath it.
sc.exe query CSFalconServicesc query csagentGet-Service "CrowdStrike Falcon Sensor Service" | Select Status, StartTypeThe binaries live at C:\Program Files\CrowdStrike\CsFalconService.exe and C:\Windows\System32\drivers\CrowdStrike\csagent.sys. A service that stops repeatedly in a short window usually points at the kernel driver rather than the service itself.
A daemon rather than a service, queried through falconctl inside the Falcon application bundle.
sudo /Applications/Falcon.app/Contents/Resources/falconctl statsOn macOS the usual cause of a sensor that is installed but not protecting is Full Disk Access not being granted to Falcon. The sensor runs, reports in, and sees very little.
A systemd unit called falcon-sensor, with falconctl for everything the unit does not tell you.
systemctl status falcon-sensorsudo /opt/CrowdStrike/falconctl -g --aidsudo /opt/CrowdStrike/falconctl -g --cidsudo /opt/CrowdStrike/falconctl -g --rfm-stateOn Linux the common cause of Reduced Functionality Mode is a kernel the installed sensor version does not support, which is something a routine patch can introduce without anyone touching Falcon.
Reduced Functionality Mode looks exactly like working.
RFM is a safety state. When the sensor cannot run correctly on the host, it steps back rather than breaking the machine. On Linux that is usually a kernel version the installed sensor does not support, which an ordinary patch cycle can introduce without anyone touching Falcon. On macOS it is usually Full Disk Access never having been granted.
In that state the sensor stops processing events and stops registering detections. It carries on sending heartbeats. So the host keeps appearing in the console, reporting in, apparently fine, and it is not protected. Nothing alerts, because nothing is watching, because the thing that watches is the thing that stepped back.
sudo /opt/CrowdStrike/falconctl -g --rfm-stateFour checks, not one.
- 01Check the service is runningOn Windows run sc.exe query CSFalconService and confirm STATE reads RUNNING. On Linux run systemctl status falcon-sensor and expect active (running). On macOS run falconctl stats and look for Sensor operational: true.
- 02Confirm the sensor actually registeredOn Linux run falconctl -g --aid to read the agent ID and falconctl -g --cid to confirm the customer ID. A sensor that started but never registered will show a running service and no agent ID.
- 03Rule out Reduced Functionality ModeOn Linux run falconctl -g --rfm-state. A sensor in Reduced Functionality Mode keeps sending heartbeats while it stops processing events, so the host looks healthy in the console while it is unprotected.
- 04Confirm someone is reading the telemetryA healthy sensor sends detections to the Falcon console. Whether anyone sees one at 3am is a separate question from whether the sensor is working, and it is the question that decides the outcome of an incident.
Common questions
What is the CrowdStrike Falcon sensor?
It is the single lightweight agent CrowdStrike installs on an endpoint, available for Windows, macOS and Linux. It prevents what it can locally and streams telemetry to the Falcon cloud for correlation. The same sensor serves the other Falcon modules, including identity protection, cloud security and Next-Gen SIEM, so adding one of those is a licensing change rather than a second agent to deploy.
What is the CrowdStrike Falcon sensor service?
It is the component that keeps the Falcon agent running on a host and talking to the Falcon platform. On Windows it is two services: CSFalconService, which appears in services.msc as "CrowdStrike Falcon Sensor Service", and csagent, the kernel driver service beneath it. On macOS and Linux the equivalent is a daemon you query through falconctl.
How do I check the Falcon sensor is running?
On Windows, run sc.exe query CSFalconService from an elevated prompt and confirm the state reads RUNNING. On Linux, run systemctl status falcon-sensor and expect active (running). On macOS, run falconctl stats from inside the Falcon application bundle and look for "Sensor operational: true".
Why can I not stop the Falcon sensor service?
By design. Tamper protection stops the sensor being disabled by anything short of an administrator holding a maintenance token from the Falcon console, because a security agent an attacker can switch off is not a security agent. If you need it stopped for legitimate maintenance, that token is the supported route.
What is Reduced Functionality Mode, and why does the host still look fine?
Reduced Functionality Mode is a safety state the sensor enters when it is incompatible with the host, most often an unsupported Linux kernel after a patch, or Full Disk Access not being granted on macOS. In that state it stops processing events and registering detections but keeps sending heartbeats, so the host continues to appear in the console as though it is reporting normally. That is the failure worth knowing about: the console looks healthy and the endpoint is not protected.
Does the sensor running mean the endpoint is protected?
No, and conflating the two is the most common mistake we see. A running service proves the process started. It does not prove the sensor registered with the right customer ID, that it is out of Reduced Functionality Mode, that its policies applied, or that anything is reading what it sends. Those are four separate checks.
Does Vijilan manage CrowdStrike Falcon?
Yes. We are a CrowdStrike Powered Service Provider, the partner program designation that lets us license, deploy and operate Falcon modules on a customer behalf, and our SOC runs Falcon around the clock for organizations that would rather not do sensor health checks by hand. We also operate Falcon for organizations that bought it themselves.
Running these checks across four hosts is a Tuesday. Across four hundred is a job.
We are a CrowdStrike Powered Service Provider, which is the partner designation that lets us license, deploy and operate Falcon modules on your behalf. Our SOC watches sensor health and the detections alongside it, around the clock. If you already own Falcon, we will run it. If you do not, we can license it, and we will tell you honestly when you do not need us to.
- Sensor health monitored, including hosts that quietly entered RFM
- SOC 2 Type II and ISO/IEC 27001 certified
The review checks coverage gaps, policy drift and unmanaged hosts. No charge, no obligation.
- CrowdStrike, Repairing Falcon Windows Sensors, and the CrowdStrike/falcon-windows-repair scripts, for the Windows service names, paths and status commands.
- CrowdStrike falconctl documentation, for the macOS and Linux status, agent ID and RFM commands.
- The CrowdStrike Falcon platform documentation, for the single-sensor architecture, the module entitlement model and no-reboot deployment.
- Verified against published university IT support material (Duke OIT, Brown OIT) for the same commands.
CrowdStrike and Falcon are trademarks of CrowdStrike, Inc. This page is reference material published by Vijilan Security, a CrowdStrike Powered Service Provider.