Service

Zero-Trust Segmentation & Automated Quarantine

Making the endpoint layer and the network layer act on each other's findings, automatically, in the seconds that matter.

Home Services Zero-trust segmentation

  • Micro-segmentation
  • Automated quarantine
  • Policy sync
  • Default deny

In plain terms

Most networks let any computer reach any other computer, so one infected laptop can reach everything. We divide the network into compartments and control what may cross between them — then connect it to your security software, so a machine that starts behaving badly is moved into an isolated compartment automatically, in seconds, without waiting for a person.

The single highest-value integration in most estates is also the one most often skipped: when the EDR agent on a laptop sees a breach, the router should move that device into a quarantine VLAN without waiting for a human.

The gap this closes

In most organizations the endpoint platform and the network team are separate purchases, separate consoles and separate people. Detection happens on the endpoint; containment happens on the network; and the handoff between them is a human reading an alert.

That handoff is where dwell time is spent. Ransomware does not wait for the ticket to be assigned. If an EDR agent on a laptop — or on an IoT camera — detects a breach, it must be able to tell the router to segment that device into a quarantined VLAN on its own authority.

The sequence, end to end

Automated endpoint-to-network quarantine flowAn EDR detection passes through a policy engine to the network control layer, which moves the device into a quarantine VLAN. Guardrails constrain each step and the analyst is notified afterwards.EndpointEDR agent detectscredential dumpingsignalPolicy engineconfidence thresholdasset-class exclusionsverdictNetwork controlNAC / router APIdevice identity resolvedenforceQuarantine VLANremediation services onlyGUARDRAILSNever-isolate classesManual overrideTested release pathseconds, with no human in the pathanalyst is notified after containment, not before
The handoff that usually costs minutes of dwell time, automated — with the guardrails that keep it from causing its own outage.

How we wire it

  • Shared identity. One authoritative answer to "what is this device" across the endpoint platform, the network access control layer and the asset inventory. Without it the quarantine action has nothing reliable to target.
  • Policy sync. Endpoint posture becomes a network attribute, so segmentation policy can be written against posture rather than subnet.
  • Automated containment. Defined triggers move a device to an isolated VLAN, with an explicit and tested release path. A quarantine you cannot reverse quickly will be switched off within a month.
  • Blast-radius design. Segment boundaries drawn where they limit damage, rather than where the existing VLANs happen to sit.

Guardrails

Automated containment on a production line or a clinical network can cause the outage it was meant to prevent. Every deployment defines asset classes that are never auto-isolated, a confidence threshold that must be met before action, and a manual override that works when the management plane is degraded. We rehearse the release path before enforcement is enabled.

Where to start

Segmentation projects stall when they begin as a full estate re-architecture. We start at one boundary that measurably reduces blast radius — usually the one between general corporate access and whatever the crown jewels are — prove the automation there, then extend.

Getting from flat to segmented without breaking the business

Segmentation migration pathFlat network, then a monitoring phase that derives the allow-list from observed flows, then default-deny enforcement.Today: flatone broadcast domainany host reaches any hostlateral movement is freeobserveStep 1: monitormap every flow that occursbuild the allow-list fromobserved realityenforceStep 2: enforcedeny by defaultexceptions are loggedand reviewednever write the policy first — write it from what the network actually doesTHE FAILURE MODE THIS AVOIDSPolicies authored from an architecture diagram block traffic nobody knew existed, break a business process on day one,and the segmentation project is cancelled by week three. Observation first makes the first enforcement boring.
The observation phase is not optional. It is what converts a risky cutover into a non-event.

The universal failure is authoring policy from an architecture diagram. Diagrams describe intent; networks carry reality. We run an observation phase that records every flow that actually occurs over a full business cycle, derive the allow-list from that, and only then enforce. First enforcement should be uneventful — if it is dramatic, the observation phase was too short.

How long the observation phase needs to be

EnvironmentMinimumWhy
Corporate IT30 daysMonth-end batch, payroll, reporting cycles
Manufacturing1 full production cycleProduct changeovers alter traffic completely
Healthcare45 daysClinical rotas and on-call patterns vary weekly
Finance1 quarterQuarter-end close generates flows seen nowhere else
Utilities1 seasonal cycleDemand peaks change control behavior

Testing that segmentation actually holds

A segmentation design that has never been tested from inside each zone is an assumption. Testing is also a PCI DSS requirement where a cardholder data environment is in scope, so it carries commercial weight beyond the engineering.

  1. Enumerate the matrixEvery source zone against every destination zone, with the expected verdict for each pair recorded in advance.
  2. Test from insideA host placed in each source zone attempts the traffic. Testing from a central jump host proves nothing — it has different policy applied.
  3. Verify the deny is loggedA silent drop and an enforced deny look identical from the client. If it is not logged, you cannot prove enforcement to an assessor.
  4. Test the reverse directionAsymmetric rules are common and routinely missed.
  5. Re-test after every changeSegmentation decays. Each firewall change is an opportunity to reopen a path, and nobody notices until an assessment or an incident.

Worked example — 4,000-seat manufacturer, flat /16

Starting position: a single flat network carrying corporate, the plant floor, guest wifi and a subsidiary acquired two years earlier. Any host could reach any host. A ransomware incident at a peer company had made the board receptive.

  1. Observation, 60 daysFull flow capture. 41 million distinct flows collapsed to 2,300 unique service relationships. That reduction is typical — networks look chaotic and are actually repetitive.
  2. Zone designSeven zones: corporate, plant supervisory, plant cell, engineering, guest, subsidiary, and a management VRF. Drawn where they limited blast radius, not where the existing VLANs sat.
  3. The hard findingThe subsidiary had a flat route to the plant floor for a reporting integration nobody could explain. It had been in place since acquisition and was the single largest lateral-movement path in the estate.
  4. Monitor mode, 30 daysPolicy deployed in log-only. 11 legitimate flows had been missed; all 11 surfaced in week one and were added before any traffic was blocked.
  5. EnforcementZone by zone over six weeks, lowest-risk first. Guest and subsidiary first, plant cell last.
  6. Automated quarantineEnabled only after enforcement was stable, with plant safety systems registered as never-isolate before the first rule went live.
  7. Measured outcomeReachable-host count from a compromised corporate workstation fell from approximately 3,900 to 47.

That last number is the only segmentation metric worth reporting to a board. "Seven zones deployed" describes activity; "a compromised laptop now reaches 47 hosts instead of 3,900" describes risk.

Automated containment — the parameters we set

ParameterConservative startAfter 90 days
Confidence threshold to auto-isolateHigh onlyHigh + corroborated medium
Hours of operationBusiness hours, staffed24/7
Asset classes in scopeCorporate workstations only+ servers, excluding domain controllers
Never-isolateSafety systems, clinical, plant control, DCsUnchanged — this list never relaxes
Auto-releaseNever — manual onlyManual only

Common questions

What is network segmentation?

Network segmentation divides a network into smaller zones so that traffic between them must pass a policy check. The security value is blast radius: a compromise in one zone does not automatically reach the others. Modern practice goes further into micro-segmentation, where policy is enforced per workload or per device rather than per subnet.

How do you test network segmentation?

By attempting the traffic that policy says should fail, from inside each zone, and confirming it is actually blocked rather than merely undocumented. We test from a host in each segment against every other segment, verify the deny is logged, and re-test after every firewall or VLAN change. A segmentation design that has never been tested from inside is an assumption, not a control.

How does network segmentation protect cardholder data?

Segmentation reduces PCI DSS scope. Systems that cannot reach the cardholder data environment are out of assessment scope, so isolating the CDE cuts both risk and the cost of every future assessment. PCI DSS requires segmentation to be validated by penetration testing, which is why the testing point above matters commercially as well as technically.

Scope your endpoint and network architecture

Bring us the estate you actually have — mixed OS fleets, ageing routers, unmanaged IoT — and we will tell you what can be unified under one agent and what needs custom work.

Request a FREE consultation