From FULL to QUARANTINE: what happens when an endpoint's trust drops

Zero Trust architectures talk a lot about “never trust, always verify” - but that phrase papers over the messy, real-time decisions that happen when a previously trusted endpoint starts behaving badly. What actually happens between the moment an anomaly is detected and the moment an endpoint loses access? That transition is where Zero Trust either works or falls apart.

Here is how trust level changes work in practice, and what your SOC needs to know before they matter.

The four trust levels and what they mean

LightEDR follows the NIST SP 800-207 Policy Decision Point / Policy Enforcement Point model. Each endpoint carries one of four trust levels at any given moment:

Level	Network access	Typical state
FULL	Unrestricted	Normal, healthy endpoint
REDUCED	Read-only or subset access	Early anomaly signal, under watch
QUARANTINE	Blocked except management channel	Active investigation underway
DENIED	All connections rejected	Confirmed threat or unrecoverable posture

The transition between levels is not binary - it is continuous. Trust is scored in real time from five signals: certificate validity (35%), behavioural patterns (30%), network behaviour (15%), session characteristics (10%), and posture checks (10%). When the weighted total drops below a threshold, the Policy Decision Point re-evaluates the endpoint’s level.

What triggers a trust downgrade

Consider a Windows workstation that has been at FULL trust for three months. Then:

1. The certificate is valid and the session is stable - no change there.
2. A process spawns an unexpected child: winword.exe → cmd.exe → powershell.exe -enc <base64>. Behavioural score drops.
3. Outbound connections begin to a domain registered 72 hours ago. Network score drops.
4. Combined score crosses the REDUCED threshold.

At this point the Policy Decision Point issues a trust level change. The Policy Enforcement Point - the LightEDR agent running on the endpoint - receives the updated policy via the management WebSocket channel and begins enforcing it. The endpoint’s user may notice nothing yet; REDUCED typically restricts egress to known-safe destinations rather than dropping all connectivity.

If the behaviour continues, the posture check runs again at next interval and the session score degrades further. When the combined score drops into QUARANTINE range, the enforcement is immediate and visible: the agent isolates the endpoint’s network interfaces, retaining only the encrypted management channel back to the triage server. The endpoint is now contained - but the SOC still has full telemetry, can pull process trees, query 90-day history, and push remediation commands.

DENIED is reserved for either a confirmed, active threat where QUARANTINE is not sufficient, or a case where the endpoint’s certificate has been revoked and no valid identity can be established.

What the SOC sees during a transition

Every trust level change generates a trust_level_changed event that lands in the alert stream:

{
  "event_type": "trust_level_changed",
  "agent_id": "ws-049",
  "hostname": "LAPTOP-FINANCE-04",
  "previous_level": "FULL",
  "new_level": "QUARANTINE",
  "trigger_signals": ["behaviour", "network"],
  "timestamp": "2026-09-15T09:14:23Z"
}

The alert surfaces in the triage queue with context: which signals fired, the process tree at the moment of detection, and the outbound connection log. If you have AI triage enabled, the alert arrives with an LLM-generated explanation summarising what the behavioural and network anomalies look like and suggesting next steps.

One common confusion: trust level changes are distinct from manual containment. If a SOC analyst clicks “isolate endpoint” on a FULL-trust machine, that is a manual QUARANTINE override - the trust score does not change, but the enforcement state does. The system tracks both independently. This distinction matters when releasing an endpoint after investigation: you need to manually unisolate it, and if the underlying trust score is still degraded, you should expect automatic re-quarantine until the root cause is resolved.

Fail-closed is not optional

One design principle worth calling out: if the Policy Decision Point is unreachable - say, a network partition or a triage server restart - the agent does not fall back to permissive mode. It holds the last known enforcement state. If the endpoint was QUARANTINE when the connection dropped, it stays QUARANTINE.

This frustrates users during planned maintenance windows, which is a real operational cost. The alternative - fail-open, where a connectivity loss means unrestricted access - is not an acceptable trade-off in a Zero Trust model. An attacker who can cut the management channel should not automatically gain full network access.

The practical recommendation: build your maintenance runbook around trust levels. Before a planned triage server restart, elevate any endpoints under active investigation to DENIED (so they cannot act) or restore them to FULL (so they do not lose access). Do not assume that agents will “just reconnect” and resume normal operation without checking their enforced state.

When to intervene manually versus waiting for automation

Automated trust degradation is fast but not omniscient. There are scenarios where manual intervention is faster and more appropriate:

• Active incident: do not wait for score thresholds. Manually quarantine the endpoint now, then let the investigation inform whether to move to DENIED or release.
• False positive: if a trust degradation was triggered by a legitimate script deployment or unusual-but-approved software, restore the endpoint manually and note the exception. Review whether the scoring weights need tuning for your environment.
• Posture drift: an endpoint that has been sitting at REDUCED for days without any active threat signal probably has a configuration issue - missing patch, disabled AV, stale certificate. Treat it as a maintenance problem, not a security incident.

The automation handles the speed problem. The SOC analyst handles the context problem. Neither works well alone.

---

If you want to see trust level transitions in your own environment, get in touch - we can walk through how the scoring and enforcement would map to your fleet.