Falco vs Tetragon (2026): detection vs enforcement

01

Falco vs Tetragon at a glance

The short version, taken from each project's documentation. Neither column has overhead figures: both depend on your kernel, workloads, and configuration, so measure them on your own nodes.

Dimension
Detection model	Evaluates events, most commonly system calls, against rules in a userspace engine and emits an alert on a match	Tracing policies select kernel functions or tracepoints, filter their arguments in the kernel, and emit JSON events
Enforcement	None built in: Falco alerts and never blocks a workload; response is left to external tooling	In-kernel actions set in the policy: send a signal such as SIGKILL, or override a function's return value so the operation fails
Rule language	YAML rules: conditions over event fields, with macros, lists, and exceptions; a large default ruleset	TracingPolicy Kubernetes resources: hooks, argument selectors, and actions; a policy library of examples
Overhead	Scales with event volume, rule count, and driver; drops events under pressure	Scales with the hooks your policies select; in-kernel filtering reduces event volume
Kubernetes awareness	Container and Kubernetes fields such as namespace and pod name, usable in rule conditions and alert output	Events carry pod and namespace identity; namespaced policies and pod label selectors scope where a policy applies
Deployment without Kubernetes	Linux host packages or a container deployment; kernel-event collection requires host access	Standalone Linux packages or a container deployment; check kernel features, BTF, and host access
Project status	Open source; a CNCF graduated project	Open source; part of the Cilium project, hosted by the CNCF

02

Docker and Linux hosts without Kubernetes

Kubernetes is not required to evaluate either project. Falco documents Linux host packages and container deployment. Tetragon documents standalone packages and a container deployment without a Kubernetes cluster. Choose the installation method for the Linux host running your workloads, then check the project's current kernel and privilege requirements.

Running a sensor in Docker still requires access to the host for kernel-event collection. Review the documented capabilities, namespaces, and mounts rather than treating the sensor as an ordinary application container. Falco's requirements depend on the selected driver; Tetragon's installation also needs compatible eBPF features and BTF information.

Without Kubernetes, plan how responders will identify the host, container, image, and owning service; pod and namespace metadata will not be available. Use the same detection and investigation checks for standalone containers as for a cluster. If you are evaluating Primod, its deployment and coverage guidance covers supported Linux environments, including host mode without Kubernetes.

03

What each project is

Falco is a CNCF graduated runtime security project. It consumes events, most commonly system calls collected by a kernel driver or eBPF probe, and evaluates them against a rule set written in YAML: conditions built from fields, macros, and lists, with exceptions for legitimate cases. When a condition matches, Falco emits an alert with the fields named in the rule's output template, and downstream tooling routes it.

Tetragon is an eBPF-based security observability and runtime enforcement project from the Cilium community, also hosted by the CNCF. It is configured through tracing policies: Kubernetes resources that select kernel functions or tracepoints, filter their arguments in the kernel, and optionally attach actions. Events are emitted as JSON, enriched with process and Kubernetes identity, and some actions can enforce directly in the kernel.

The two are not interchangeable and not strictly competitors. Falco's center of gravity is a detection rule library with a large default set. Tetragon's center of gravity is precise kernel-level observation with the option to enforce. Teams run one, the other, or both, which is why Tetragon vs Falco is a question of requirements rather than a ranking.

04

Evaluation dimensions

Score nothing. Instead, write down what you need in each dimension, then run the practical test in the last column on a representative workload.

Evaluation dimension			Practical test
Sensor	eBPFor kernel moduleModern eBPF probe, legacy eBPF probe, or kernel module; plugins for other sources	eBPFeBPF programs on the kernel hooks your policies select; in-kernel argument filtering	Confirm driver or BTF support on your kernel versions before anything else
Detection and policy	RulesRule conditions with macros, lists, and exceptions; published rule maturity guidance	Tracing policiesTracing policies with event selection and actions	Express one relevant scenario and a benign look-alike
Response	External toolingAssess the specific external response tooling you would deploy; do not label it universally incapable	Signals · overridesSupports return-value overrides and signal actions	Verify whether the operation is prevented and how the application handles it
Investigation	Output fieldsInspect fields emitted by the selected event source and rules	JSON eventsInspect fields emitted by the selected tracing policy	Can responders identify workload and observed sequence?
Performance impact	Measure itScales with event volume, rule count, and driver; drops events under pressure	Measure itScales with the hooks selected; in-kernel filtering reduces volume	Measure CPU, memory, and event loss on one representative node per class
System stability impact	Userspace engineUserspace engine; never blocks a workload; kernel module carries more risk than eBPF probes	In-kernel enforcementIn-kernel enforcement can fail an operation the application did not expect	Roll out any enforcement in observe or audit form first; test the failure path
Operations	You operate itMaintain rules, exceptions, and output plumbing	You operate itMaintain tracing policies and kernel compatibility	Validate change rollout and rollback

Chips describe status and scope, not a score. Performance and stability rows are things to measure in your environment, not vendor figures.

05

When Falco fits

Falco is a candidate when the team wants a rule-driven detection workflow and is prepared to maintain the surrounding pipeline: the ruleset and its exceptions, the alert routing, and whatever response tooling the team chooses. The default ruleset gives a broad starting point, and the rule language is readable by analysts who do not work in the kernel.

Expect to spend the early weeks tuning. The published style guide and exceptions mechanism exist because tuning is part of operating Falco, not a sign that something is wrong.

06

When Tetragon fits

Tetragon is a candidate when kernel-level observability and policy-controlled enforcement are central requirements: when the team needs to see specific kernel functions with their arguments, filter at the source to control event volume, or deny an operation in the kernel rather than react after the fact.

Expect the policy authoring to require kernel knowledge. Selecting the right hook, understanding its arguments, and confirming that an override is safe on your kernel version are engineering tasks, and each policy should be tested for both detection and enforcement behavior.

07

What your SOC still needs to investigate

Neither project closes an investigation on its own. Both produce events with process and container identity; both leave the join to a request, the workload's owner, the image's vulnerability status, and the outcome of an attempted operation to the responder or to other systems.

Whichever you choose, plan for the questions that follow an alert: which service is this, which request caused it, did the attempted action succeed, what happened next, and what evidence might be missing. If those answers live in five tools, the sensor choice is only part of the design.

• Workload ownership and image version: from your container runtime, deployment and CI metadata; add pod and namespace identity when using Kubernetes.
• Request context: from application tracing or access logs, where instrumented.
• Outcome of an attempted operation: from the event's return value where captured, otherwise from network or file-system logs.
• Related events in order: joined by process tree and time, not by alert title.

08

A reproducible evaluation checklist

Run the same checklist against both projects on the same Linux hosts or Kubernetes cluster and the same workloads. Record versions, kernel, and dates so the comparison can be repeated after an upgrade.

• Pin versions: project release, kernel version, driver or BTF availability, container runtime, and Kubernetes version when applicable.
• Pick three scenarios that matter to you (for example a shell from a web process, a sensitive file read, an unexpected outbound connection) and one benign look-alike for each.
• Write the rule or policy for each scenario; note how long it took and what knowledge it needed.
• Run the attack case and the benign case; record fire / no-fire for each.
• If you need enforcement, verify the operation is prevented and observe how the application behaves when it receives the error.
• Measure CPU, memory, and event volume on a representative node before and during the test; do not extrapolate to the whole fleet from one node.
• Send the output to your responders and ask them to identify the workload and the sequence without help.
• Change one rule or policy and roll it out; confirm the change took effect where expected and nowhere else.