The five trust signals: how LightEDR scores endpoint trustworthiness

Most security models ask a binary question: is this device on the network? If yes, it is trusted. That framing was always flawed, and ransomware operators spent the last decade proving it.

NIST SP 800-207 describes a better model. Instead of granting access based on network location, a Policy Decision Point (PDP) continuously evaluates signals about the device and decides what access level it deserves - right now, not just at login. LightEDR implements this as a weighted five-signal trust score, reassessed on every connection.

The five signals and what each one measures

Every endpoint is scored across five dimensions. The weights reflect how reliably each signal predicts compromise.

Certificate identity (35%) - The highest-weighted signal. Each agent enrols with a certificate generated from a Certificate Signing Request (CSR): the private key is created on the device and never transmitted to the server. The PDP verifies this certificate on every mTLS connection, which makes impersonation extremely difficult without physical access to the endpoint. A valid certificate is strong evidence the device is exactly who it claims to be.

Behavioural telemetry (30%) - Real-time process execution, file activity, and network behaviour collected by the lightweight agent. Anomalies - unexpected parent-child process chains, lateral movement patterns, execution from unusual paths - reduce the score. This is the signal that catches the attacker who has already obtained valid credentials, because valid credentials cannot hide anomalous execution.

Network context (15%) - Where is the device connecting from? Recognised subnets, consistent geolocation, and expected ingress paths score positively. A workstation usually seen on the corporate LAN, suddenly connecting from a residential IP in a different country at 03:00, does not.

Session state (10%) - How long has this session been active? Has it seen mid-session privilege escalation, unusual authentication attempts, or replay patterns? Session signals catch attacks that start legitimately and then pivot after the initial foothold.

Posture assessment (10%) - Is the operating system patched? Is disk encryption enabled? Are known-vulnerable software versions present? Posture is a slower-moving signal - it will not catch an active intrusion in real time - but an unpatched device with no encryption is a higher baseline risk regardless of its current behaviour.

These five signals combine into a composite score. A device with a perfectly valid certificate but suspicious process behaviour will score lower than one with both healthy identity and clean telemetry. The combination is what makes the model robust: compromising one signal is not sufficient to appear fully trusted.

From score to action: the four trust levels

A raw score is only useful if it drives a decision. LightEDR maps the composite score to four discrete trust levels, and the Policy Enforcement Point (PEP) acts on whichever level the device currently holds.

Trust level	What it means	Practical effect
FULL	All signals healthy	Complete access to permitted resources
REDUCED	Minor anomalies or posture drift	Narrowed access; high-sensitivity resources blocked
QUARANTINE	Significant behaviour or identity anomaly	Network restricted to security tooling only
DENIED	Certificate invalid or critical signal failure	Connection refused; device flagged for investigation

Trust level transitions fire in real time. When a device’s composite score drops - say, because the behavioural engine detected a suspicious process spawn - the PEP immediately applies the new level without waiting for an analyst to review an alert.

When a trust level change occurs, an event is emitted immediately. Analysts and integrated tooling see something like this:

{
  "event": "trust_level_changed",
  "device_id": "wkstn-144",
  "previous_level": "FULL",
  "new_level": "QUARANTINE",
  "trigger_signal": "behaviour",
  "reason": "cmd.exe spawned by WINWORD.EXE (T1204.002)",
  "timestamp": "2026-08-11T09:17:32Z"
}

The event identifies which signal triggered the change and maps it to a MITRE ATT&CK technique where applicable. SOC teams get the context they need without digging through raw telemetry.

Why continuous scoring is not just periodic re-authentication

Most enterprise tools implement a “check at login” model. Once a device authenticates, it is trusted for the duration of the session - sometimes for hours or days. That is not continuous verification; it is deferred trust.

The problem is that the most dangerous phase of an attack often begins after a legitimate login. A threat actor who obtains valid credentials will use them to authenticate cleanly, then move laterally or escalate privileges from what looks like a known-good session.

Because LightEDR re-evaluates the composite score on every connection rather than once per session, a device that was FULL trust five minutes ago can shift to QUARANTINE in response to a single suspicious process event. The trust level reflects the device’s current behaviour, not just its identity at first contact.

The system also fails closed. If the trust scoring engine cannot reach the policy database, the PEP defaults to DENIED. An endpoint with no assessable trust level does not receive the benefit of the doubt.

---

If you are planning a Zero Trust rollout and want to understand how continuous endpoint scoring fits your architecture, get in touch.