What is Host Inventory?
Host Inventory is the central list of all endpoints that have the Falcon sensor installed and are reporting back to the Falcon Cloud. It’s where you can see and manage every protected device in your environment.
Log in to the Falcon Console.
Navigate to “Host Management” → “Hosts”.
This screen shows a table of all active and inactive hosts, including details about their configuration, health, and activity.
| Column Name | Description |
|---|---|
| Hostname | The device name reported by the OS. |
| OS Type | Windows, macOS, Linux – includes version. |
| Group Membership | The host’s assigned Falcon group (used for policies). |
| Sensor Version | The exact version of the installed sensor. |
| Last Seen | Timestamp of last communication with Falcon Cloud. |
| Policy Applied | The policy bundle currently applied to the sensor. |
| Status | Whether the host is Online, Offline, or Contained. |
Click a hostname to open a detailed view, including:
Detection history
Sensor install logs
Assigned policies
Launch actions (e.g., contain, RTR, or update sensor) from here.
Export host lists to CSV format for reports or audits.
You want to confirm whether all machines in your Finance department have the latest sensor installed:
Use filters (see next part) to narrow to the Finance group.
Check the Sensor Version column.
Click into hosts with outdated versions and plan updates.
When you're managing dozens, hundreds, or even thousands of endpoints in Falcon, you need a way to quickly find, group, and manage specific hosts. That’s where filters and tags come in.
The filtering system in Falcon is very powerful and flexible.
Hostname (e.g., starts with "WIN-")
OS Type/Version (e.g., Windows 10, macOS 13)
Group Name
Sensor Version
Online/Offline Status
Policy Name
Tag Value
Containment Status
Go to Host Management → Hosts.
Click “Add Filter”.
Choose a category (e.g., "Policy Applied").
Choose an operator (e.g., "equals", "contains").
Enter a value (e.g., "Windows Policy Set").
You can add multiple filters together to create complex searches.
Tags are custom labels you can assign to hosts. They're extremely useful for:
Categorizing machines by department, location, or usage.
Grouping machines that share the same risk level.
Linking devices to projects, tickets, or external systems.
Department: Finance
Location: Tokyo
Role: WebServer
Owner: John.Smith
Select one or more hosts in the host list.
Click “Actions → Add Tag”.
Choose existing tags or create a new one.
Tags will now be visible in the host list and searchable via filters.
Use a consistent naming convention (e.g., Dept:HR, Dept:IT).
Review and clean up unused or outdated tags regularly.
Use filters to create custom dashboards that track specific segments of your environment.
You’re planning a phased rollout of a new policy and want to apply it only to servers in New York.
Steps:
Use a filter: Tag contains Location:NYC.
Review the list and verify roles.
Apply the new policy only to that filtered group.
Falcon provides visual indicators and status information for each host. These statuses help you understand at a glance whether a machine is:
Properly connected
Running a healthy sensor
Protected by the correct policies
Online:
The host has recently communicated with the Falcon Cloud.
Offline:
The sensor has not communicated in a while (e.g., 7+ days).
Use filters like Last Seen > 7 days ago to find stale/inactive hosts.
Offline does not always mean broken—could just be a laptop that’s turned off.
These show whether the sensor is:
Installed and functioning correctly.
Communicating with Falcon Cloud.
Updating properly.
Green: Healthy and connected.
Yellow: Warning – sensor may be outdated or partially connected.
Red: Error – no communication, invalid CID, or other issue.
Click a host → look at the Sensor Health section in the details panel.
This tells you:
Whether a policy is applied.
Which policy is assigned (by name).
If any errors occurred during policy application.
Policy Applied (shows the name)
Missing Policy – happens if the host group doesn’t have one assigned.
Policy Error – policy failed to load due to conflict or version mismatch.
Indicates whether the host is isolated from the network (except to Falcon Cloud).
Contained: Host has been placed in quarantine.
Not Contained: Normal state.
Containment is used in incident response to stop potential threats from spreading.
Shows whether the sensor has tamper protection enabled, which prevents unauthorized uninstallation or modification.
Enabled: Sensor cannot be removed without a maintenance token.
Disabled: Sensor could be uninstalled by local admin.
Your SOC analyst sees a host that triggered a critical detection. You:
Go to the Host Inventory.
Filter for that hostname.
See that it’s online, but sensor health = yellow and policy missing.
Investigate further—maybe the machine isn’t in the right group.
These are powerful administrative functions that let you take direct action on a host from the Falcon UI. They’re essential for incident response, sensor troubleshooting, and host maintenance.
RTR is a secure command-line shell that gives security analysts and administrators remote access to an endpoint.
Run investigative commands (e.g., view files, check registry keys).
Kill malicious processes.
Delete or quarantine suspicious files.
Collect forensic data (e.g., memory dumps).
Upload tools for deeper investigation.
Go to Host Inventory → Click a Host → Click “Connect to Host (RTR)”.
You must have RTR permissions in your role.
You'll enter a session where you can type commands like:
ps # List processes
netstat # View network connections
getfile # Download a file from the endpoint
Sessions are logged.
Requires elevated privileges.
You can terminate the session at any time.
This action isolates a host from the network, while still allowing it to communicate with Falcon Cloud.
Stops lateral movement of threats.
Prevents ransomware from spreading.
Gives time to investigate without risking more damage.
From the host details page, click “Contain Host”.
A red banner will confirm containment is active.
You can release it later with “Lift Containment”.
If a host is running an outdated sensor version or experiencing issues, you can:
Trigger a sensor update manually.
Restart the sensor service from the console.
Useful after applying policy changes or during troubleshooting.
You can command a host to:
Send diagnostic logs to Falcon Support.
Help troubleshoot issues like sensor crashes or connectivity problems.
While not technically “actions” in the same way as RTR or containment, you can:
Reassign a host to a different group to change its policies.
Add or remove tags dynamically.
You receive an alert that malware was detected on a finance team laptop.
Step 1: Use the host filter to find the affected machine.
Step 2: Click “Contain Host” to isolate it.
Step 3: Launch an RTR session to check for suspicious files and processes.
Step 4: Pull logs or memory dumps for deeper analysis.
Step 5: After resolving the issue, lift containment and optionally update the sensor.
This section deals with how you can fine-tune and control host-level settings beyond the usual group-based policy management. It’s especially useful for unique environments or special-case hosts.
Local overrides allow a host to behave differently than what its group-level policy specifies.
For troubleshooting or testing.
To provide temporary exceptions for high-risk or specialized machines.
A developer machine in the R&D department needs to run unsigned code that would normally be blocked. You can apply a local override to reduce sensor strictness without changing policy for the whole group.
In the host’s detail page, click “Actions” → “Edit Settings”.
Modify detection sensitivity, logging, or real-time protections.
Overrides are visible and auditable, but should be used sparingly.
Tamper Protection prevents local users—even administrators—from:
Uninstalling the sensor.
Stopping or modifying the sensor service.
Can be enabled per host or as part of a policy.
When enabled, a maintenance token is required to uninstall or stop the sensor.
Prevents attackers from removing protection after gaining local admin rights.
CrowdStrike automatically identifies hosts by their hostname, but sometimes hostnames change—especially in VDI or cloud environments.
Rules that:
Automatically update the display name in Falcon to reflect new hostnames.
Ensure data continuity (e.g., alerts stay associated with the correct machine).
Use regular expressions to match and rename.
Create rules that extract machine name from asset tags or naming standards.
In general, policies are applied to groups, not directly to hosts. However:
If a host is moved to a group, it immediately inherits that group’s policy.
This is how you can manually reassign policy on a per-host basis—by changing group membership.
Advanced users can:
Use scripts or external systems (like CMDB) to assign tags automatically to hosts via Falcon’s API.
Keep metadata up to date (e.g., business unit, owner, criticality).
You’re preparing for an audit, and one of your cloud servers has a sensor issue. You:
Enable local override to temporarily reduce detection strictness.
Enable tamper protection to prevent manual removal.
Apply a rename rule to reflect the asset ID.
Add tags for audit: Owner:Security, Env:Prod.
| Feature | Purpose |
|---|---|
| Inventory | View and manage all hosts |
| Filters & Tags | Organize and search |
| Status Indicators | Check host and sensor health |
| Host Actions | RTR, containment, updates |
| Settings Management | Overrides, protection, metadata |
In Falcon administration, filtering is often the last safety barrier between “a targeted action” and “an accidental broad change.” Exam scenarios commonly test whether you can narrow scope confidently before taking any host-impacting step.
Use a “two-key confirmation” habit:
Start with a stable identifier (hostname pattern, device ID, or another durable attribute).
Confirm with a second attribute that is less likely to collide (OS, site, tags, last seen window, group membership).
Operational guardrails you can reuse:
Result-count sanity check: if your filter returns 10× more hosts than expected, treat it as wrong until proven otherwise.
Spot-check: open 2–3 random hosts from the filtered set and confirm they match the intended population.
Attribute stability awareness: avoid relying on frequently changing values (e.g., short-lived IPs) as the only selector.
When “the host isn’t there,” separate these causes quickly:
Data mismatch (wrong hostname variant, renamed asset, duplicate naming pattern),
Lifecycle state (inactive/decommissioned),
Visibility issue (sensor not checking in or never registered).
Best next step is to widen cautiously: broaden the identifier, then re-add constraints one by one until the host appears.
Trap pattern: choosing a broad filter and acting immediately. Better answers mention narrowing, result count validation, and spot-checking.
Trap pattern: relying only on IP. Better answers mention multi-attribute confirmation.
What is the most common reason a Falcon sensor enters Reduced Functionality Mode (RFM)?
The host operating system or kernel version is unsupported by the sensor.
Reduced Functionality Mode occurs when the sensor cannot fully operate due to compatibility limitations. A common cause is a Linux kernel version or operating system configuration not supported by the installed sensor version. In this state, the sensor continues basic telemetry reporting but disables advanced prevention or detection capabilities. Administrators should verify compatibility matrices and update either the operating system or the sensor version to restore full functionality.
Demand Score: 84
Exam Relevance Score: 86
How can administrators quickly identify hosts with inactive sensors in the Falcon console?
By filtering hosts based on last seen time or sensor status in the Host Management page.
The Host Management page allows administrators to apply filters that highlight hosts with sensors that have not communicated with the cloud within a defined timeframe. Filtering by “last seen” or sensor status enables quick identification of inactive endpoints. This process helps security teams locate systems that may be offline, improperly configured, or experiencing communication issues. Regular monitoring of inactive sensors helps maintain endpoint visibility across the environment.
Demand Score: 80
Exam Relevance Score: 84
Why is host filtering an important feature in the Falcon Host Management page?
It allows administrators to quickly locate endpoints based on operational or security conditions.
Large environments may contain thousands of endpoints. Filtering tools enable administrators to identify hosts based on attributes such as operating system, sensor version, host group membership, or activity status. This capability is essential for tasks such as identifying outdated sensors, locating systems requiring investigation, or verifying policy deployment across specific groups. Effective use of filtering significantly improves operational efficiency when managing large endpoint fleets.
Demand Score: 75
Exam Relevance Score: 80
What is the effect of disabling detections on a specific host in Falcon?
The sensor continues monitoring activity but detection alerts are suppressed.
Disabling detections for a host prevents Falcon from generating detection alerts for events on that system. This option is sometimes used during troubleshooting or when investigating false positives affecting critical workloads. However, disabling detections reduces security visibility because malicious activity may occur without generating alerts. Administrators should use this configuration carefully and only temporarily while resolving specific operational issues.
Demand Score: 72
Exam Relevance Score: 82
Why do administrators regularly review inactive sensors in the Falcon console?
To ensure all endpoints remain protected and communicating with the platform.
Inactive sensors indicate systems that have stopped communicating with the Falcon cloud. Causes may include system shutdown, network connectivity issues, sensor malfunction, or device decommissioning. Regular review helps administrators identify endpoints that may no longer be protected or visible to security monitoring. Maintaining active sensors ensures consistent threat detection coverage across the environment and helps identify operational gaps in endpoint protection.
Demand Score: 70
Exam Relevance Score: 78