CrowdStrike Falcon Architecture — One Agent, the Cloud & Threat Graph

① The single lightweight agent — one sensor, not a suite

The first idea to fix in your head: Falcon installs one sensor per endpoint, not a stack of separate products. That single sensor is a kernel-mode driver plus a user-mode service working together.

The kernel driver sits low in the operating system so it can see activity early (it loads during boot via the Early Launch Anti-Malware path on Windows), resist tampering by an attacker, and observe events that a user-mode-only tool would miss. The user-mode service processes what the driver sees, applies policy, and handles the secure connection to the cloud.

It is called lightweight for a real reason: the sensor is designed to be small and low-overhead, because the expensive correlation work is pushed to the cloud rather than run on your laptop. There is no on-prem management server to build and no daily signature download to schedule.

② The cloud brain — a cloud-native SaaS model

Falcon is cloud-native SaaS: CrowdStrike runs the management plane, the console and the analytics as a service. You do not stand up your own servers — you log into the Security Cloud and your sensors phone home to it.

Why push the heavy work to the cloud

Keeping the brain in the cloud means three things at once. The endpoint stays light because it is not running giant analytics locally. Detection improves for everyone because the cloud sees patterns across all customers, not just yours — what hits one tenant can protect the rest. And upgrades are continuous: new logic and intelligence ship from the cloud, with no fleet-wide reinstall.

The interview line: the sensor senses, the cloud thinks. The agent does fast local prevention; the Security Cloud does the deep, cross-customer correlation.

③ Threat Graph — streaming telemetry into one giant graph

Telemetry does not just sit in a log. The sensor streams events — process starts, file writes, network connections, registry changes — up to the cloud over a secure channel, and they land in Threat Graph: a purpose-built, cloud-native graph database.

Threat Graph correlates trillions of events per day across endpoints, identities, cloud workloads and more — modelling them as nodes and the relationships between them — so an attack can be spotted by how events connect, not just by a single bad file. Because the graph spans every customer, an indicator seen anywhere can defend everyone.

Smart filtering keeps it cheap

The sensor does not blindly fire-hose raw data. It applies smart filtering on the endpoint — sending the security-relevant signal and suppressing noise — which keeps both the network cost and the endpoint overhead low while still feeding the graph what it needs.

④ One agent, many modules — regions, tenancy and offline

The payoff of one sensor: one agent unlocks many modules. From a single console you license capabilities — EDR, next-gen antivirus, identity, cloud, and more — and the same deployed sensor lights them up. No new agent to roll out per feature.

The platform runs in regional clouds (for example US-1, US-2, EU-1 and government clouds, with in-country regions being added for data sovereignty). Each customer is a tenant with logically isolated data, so multi-tenancy gives shared intelligence without mixing one customer's records into another's.

What happens offline

If an endpoint loses the cloud, the sensor keeps doing local, on-box prevention using its cached logic and queues telemetry to sync later. A related safety state is Reduced Functionality Mode (RFM), which the sensor enters when the OS/kernel is unsupported or misconfigured — it runs in a limited, safe capacity until compatibility is restored, then resumes full function.