Zero Trust EDR - what it means and why it matters

What is Zero Trust in the context of endpoint security?

Zero Trust is an architectural model, not a product. The term originates in NIST Special Publication 800-207, which defines it as a set of design principles where no implicit trust is granted to any asset, user, or connection based purely on network location or prior authentication.

The core principle: never trust, always verify. Every request for access - regardless of where it originates - must be authenticated, authorised, and continuously validated.

For most enterprise security, Zero Trust has been applied at the network and identity layer: microsegmentation, identity-aware proxies, conditional access policies. Endpoint security platforms have been slower to catch up. Most EDRs issue an enrolment credential and then trust the agent indefinitely - exactly the kind of implicit, location-based trust that Zero Trust architecture is designed to eliminate.

A Zero Trust EDR applies the same "never trust, always verify" principle to the EDR agent connection itself. Not just at enrolment - but continuously, throughout the agent's lifetime.

How most EDRs handle trust (and why that is a problem)

The standard EDR enrolment flow works roughly like this:

1. An administrator installs the agent on an endpoint
2. The agent registers with the management server and receives an API key, enrolment token, or certificate
3. From that point forward, any connection carrying that credential is trusted - indefinitely

This creates a significant blind spot. If an attacker compromises an endpoint and gains control of the agent process, they inherit a trusted connection to your security platform. The agent can report selectively, suppress alerts, or go silent - and the platform has no way to distinguish that from a healthy agent.

The problem compounds with token lifetime. Many enterprise deployments use certificates with multi-year validity periods. Revocation is a manual process that depends on an analyst noticing the anomaly first - which is precisely what the attacker is trying to prevent.

There is also no mechanism to detect that the private key has been copied off the device. Once a credential is issued, the platform has no way to prove that the credential is still on the original hardware.

How LightEDR implements Zero Trust for endpoints

LightEDR's trust engine is built on the Policy Decision Point / Policy Enforcement Point (PDP/PEP) architecture defined in NIST SP 800-207, applied to every active agent connection.

Enrolment: private key never transits the network

Instead of issuing an API key, LightEDR uses a certificate signing request (CSR) enrolment flow. The endpoint generates a key pair locally, sends only the public key to the triage server, and receives a signed certificate in return. The private key is generated on the endpoint, stored at chmod 600, and never sent anywhere. This means a compromise of the server-side credential store cannot expose agent credentials.

Five continuous trust signals

Every active connection is scored in real time across five independent signals:

The five signals combine into a weighted composite trust score between 0 and 1. This score is recalculated continuously as events arrive and challenges are answered.

Four trust levels

The composite score maps to one of four trust levels, each with automatic consequences:

Challenge-response every 5 minutes

Every 5 minutes, the triage server sends each active agent a random nonce. The agent must sign the nonce with its local private key and return the signed response within the timeout window. This proves that the private key is still present on the original device - not copied to an attacker's system.

An agent that has been cloned or whose private key has been extracted will fail this challenge within 5 minutes. The trust score drops, the session moves toward QUARANTINE or DENIED, and your console receives an alert - automatically, without any analyst needing to notice the anomaly first.

Mutual TLS on every connection

Every WebSocket connection between agent and triage server uses mutual TLS. Both sides present certificates. Every authentication frame carries a unique nonce that is validated server-side to prevent replay attacks - a captured authentication frame cannot be reused.

Instant revocation

When you revoke a certificate - from the console or via the API - the agent's active WebSocket connection closes immediately via a pub/sub signal. There is no polling window, no grace period. The session terminates the moment revocation is issued. An attacker cannot continue exfiltrating while revocation propagates.

Fail-closed design

If the trust engine cannot reach its backing store to validate a connection, it does not allow the connection to continue as trusted. LightEDR fails closed. A network partition does not create a window where compromised agents continue operating unchallenged.

Tamper-evident audit trail

Every trust event is hash-chained - each record stores a SHA-256 hash of the previous entry. A background job walks the chain and alerts on any gap or modification. Deleting or altering a trust event is detectable.

What this means for your SOC

Lateral movement becomes detectable at the EDR layer

When an attacker moves laterally to a host running LightEDR, the network signal detects the unusual source IP. If they attempt to reuse captured authentication frames, nonce validation blocks them. If they copy the agent binary without the private key, challenge-response fails within 5 minutes. Each of these paths triggers a trust score drop and an alert - before the attacker has established a persistent foothold.

Compromised agents stop hiding

Legacy EDR platforms have no mechanism to detect an agent that has been tampered with. It either goes silent (which may not trigger an alert for hours) or continues reporting selectively. With continuous behaviour scoring, an agent whose process activity, network connections, or event patterns deviate from its learned baseline will see its trust score drop - even before an analyst reviews the alert stream.

Automatic containment without manual triage

When the trust score drops below QUARANTINE threshold, network access is restricted automatically. Your analysts are notified after the containment is in place - not before. This is the difference between detecting a compromise and responding to it on the same shift, versus discovering it during a post-incident review the next morning.

Frequently asked questions