macOS - Configuration - Ensure the Crowdstrike Service is Running

What the CrowdStrike Falcon sensor verification does

This Automox Worklet™ verifies that the CrowdStrike Falcon sensor is installed and actively connected to the CrowdStrike cloud on macOS endpoints. The Worklet inspects the endpoint for the Falcon application bundle, queries the sensor for live statistics, and reloads the agent when the sensor is present but no longer responding. Endpoints that already have a healthy sensor pass evaluation unchanged, so the policy is safe to run on a recurring schedule across a mixed fleet.

The evaluation script checks for the /Applications/Falcon.app bundle on disk and then invokes /Applications/Falcon.app/Contents/Resources/falconctl stats to confirm the sensor process is alive and exchanging data with the CrowdStrike backend. If the bundle is missing, the Worklet exits cleanly so install policies own the deployment path. If the bundle is present but falconctl reports a stopped agent, evaluation returns non-zero and Automox schedules remediation on the endpoint.

On macOS, Falcon depends on a system extension and full-disk access permissions granted to falconctl. When either is revoked, the sensor can sit installed but blind, with no kernel callbacks reaching the cloud console. The Worklet surfaces that state instead of letting it persist as a silent gap in the asset inventory.

Why enforce Falcon sensor health across a Mac fleet

A Falcon agent can stop sending telemetry after a macOS upgrade rewrites system extension approvals, after a user revokes full-disk access in System Settings, or after a kernel-level conflict with another security product. The endpoint then sits in the CrowdStrike console as an installed host that is no longer producing detections. The console will eventually flag the host as stale, but the lag between sensor failure and dashboard alert is the window an attacker uses to move laterally, install persistence, or exfiltrate data. CIS Critical Security Control 10 (Malware Defenses) calls for continuously monitored anti-malware coverage on every endpoint, which is exactly what a stopped Falcon agent breaks.

Sensor health drifts faster than a security team can chase by hand on a fleet of Mac laptops. The Worklet re-evaluates Falcon state on every policy run, so a stopped sensor surfaces in the next cycle instead of waiting on a console staleness alert. Pair the policy with a short evaluation interval on at-risk groups and a daily run on the rest of the fleet to keep the gap between sensor failure and recovery measured in hours rather than days.

How Falcon sensor verification works

1. Evaluation phase: The Worklet checks for the /Applications/Falcon.app bundle. If the bundle is absent, the script exits 0 and the endpoint is treated as out of scope for this policy. If the bundle is present, the script runs /Applications/Falcon.app/Contents/Resources/falconctl stats and inspects the return code. A zero return code means the sensor is loaded and talking to the CrowdStrike cloud, so evaluation exits 0 with no remediation needed. A non-zero return code means the sensor is installed but not running, and evaluation exits 1 to schedule remediation.

2. Remediation phase: The remediation script re-runs falconctl stats as a final guard against a race with evaluation. If the sensor is already healthy, it exits 0. Otherwise it opens the Falcon application with open /Applications/Falcon.app to trigger the launch agent, sleeps three seconds for the helper to initialize, then runs falconctl load to bring the sensor back online. After the reload, the script calls falconctl stats again and prints the first seven lines of output to the Automox activity log so reviewers can confirm the sensor is connected. A failure to reconnect surfaces as exit 1 with the message "CrowdStrike Falcon could not start or connect to CrowdStrike."

Falcon verification requirements

• macOS 10.12 (Sierra) or later, including Apple Silicon endpoints running macOS 14 Sonoma and macOS 15 Sequoia

• CrowdStrike Falcon sensor already provisioned at /Applications/Falcon.app through your CrowdStrike deployment path

• Root or sudo privileges for the Automox agent so it can invoke falconctl load and read sensor statistics

• Outbound TCP 443 reachability from the endpoint to your tenant's CrowdStrike Falcon cloud host (the cloudsink.net domain assigned to your CID)

• Full-disk access granted to /Applications/Falcon.app/Contents/Resources/falconctl in System Settings under Privacy and Security

• System extension from CrowdStrike approved under System Settings, Privacy and Security, before remediation runs

• FixNow enabled in Automox for immediate remediation when a sensor stops responding outside the regular policy window

Expected Falcon sensor state after remediation

After the Worklet runs successfully, falconctl stats returns zero and prints sensor version, agent ID, and connection state. The endpoint appears with a healthy host status in the CrowdStrike console and resumes sending process, file, and network telemetry. Subsequent Automox policy runs report the endpoint as compliant without applying remediation, because the evaluation phase finds the sensor already loaded and reporting.

When remediation cannot recover the sensor, the activity log records "CrowdStrike Falcon could not start or connect to CrowdStrike" with exit code 1. The most common root causes are a revoked full-disk access grant or a pending system extension approval after a macOS upgrade. Other likely causes include a blocked outbound 443 connection to the CrowdStrike cloud, or a Falcon sensor build too old to load on the current macOS release. Address the underlying permission or network issue, then re-run the policy or trigger FixNow to validate that falconctl stats returns a connected sensor.