# Nozomi Arc Endpoint Sensor — Host Context & OT Blind Spots Solved

Source: https://ai.techclick.in/blog_nozomi_arc_endpoint_sensor
Markdown: https://ai.techclick.in/blog_nozomi_arc_endpoint_sensor.md
Publisher: Techclick Infosec Pvt Ltd

Learn how Nozomi Arc, a lightweight OT endpoint sensor, adds host context — users, processes, USB, local sessions — reaching segments a passive Guardian network sensor cannot see, without network changes.

Nozomi Arc Endpoint Sensor — Host Context &amp;amp; OT Blind Spots Solved student learning map
                     A visual study map for Nozomi Arc Endpoint Sensor — Host Context &amp;amp; OT Blind Spots Solved showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Nozomi Arc Endpoint Sensor — Host Context &amp;amp; OT...
                     Nozomi · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   🎯 By the end you will be able to

   2. Understand
   Pick where you want to start

   3. Prove
   ① Why passive network sensing...

   4. Practice
   ② Nozomi Arc — the lightweight...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

             Most engineers think…

             Most OT security engineers assume that once you have a Guardian sensor watching the network, you have full visibility. That assumption fails in production — and in interviews.

 A passive network sensor can only see  what crosses the wire it is mirroring . It cannot see a USB stick plugged into a historian, a new process spawned locally, an RDP session opened to a jump host, or anything happening in a segment with no SPAN or TAP point.  Nozomi Arc  is the host-based sensor that fills those structural blind spots — without requiring a single network change. Understanding when to deploy Arc alongside Guardian is what separates a complete OT security design from one that leaves host-level threats invisible.

## ① Why passive network sensing leaves host-level blind spots

 Guardian, Nozomi's core network sensor, does its job by mirroring traffic from a  SPAN port  or  TAP  and running deep packet inspection. This means Guardian can discover assets, detect anomalous OT protocol traffic, and spot network-borne threats — all without touching any device. But that model has hard structural limits.

 A passive network sensor only sees  what crosses the network . Three categories of events are invisible to it. First,  host-internal actions : a USB stick being inserted, a new process executing, a user logging in — none of these generate network traffic. Second,  isolated or heavily segmented zones : if no SPAN or TAP covers a subnet, Guardian simply cannot see it. Third,  local sessions : an RDP or VNC session that stays within the same subnet never leaves to a mirror port.

 These are not theoretical risks. In OT environments, historians, engineering workstations and jump hosts are exactly the machines with human access — the machines most likely to see USB-based exfiltration, insider misuse, or a lateral-movement pivot. Missing that layer means a real threat category goes undetected.

  Legend    Guardian sensor / Nozomi component (royal)    pipeline stage (DPI, detect, enrich)    diagram heading    diagram background panel    supporting label / OT detail

  Figure 1 — Guardian passive monitoring loop
   Guardian mirrors network traffic and classifies it — but the loop never touches host internals.
- Guardian passive monitoring loop SPAN / TAP mirrors all packets DPI engine parses OT protocols Detect anomaly or signature Alert sent to Vantage / CMC Blind spot USB, process, user Guardian mirrors network traffic and classifies it — but the loop never touches host internals. Quick check · Q1 of 10 · Understand Why can't Guardian detect a USB stick being inserted into a historian server? a) USB events are host-level actions that produce no network traffic, so they never appear on the SPAN/TAP mirror Guardian uses b) Guardian only works on Windows hosts c) Guardian can detect USB events if configured correctly d) SPAN ports block USB signals Correct: a. Guardian is a passive network sensor — it only sees what crosses the mirrored network port. A USB insertion is a local host event with no network packet, so it is structurally invisible to Guardian. 👉 So far: Passive network sensors see only what crosses the wire — USB events, processes, users and isolated segments are structurally invisible to a SPAN/TAP-based sensor like Guardian. ## ② Nozomi Arc — the lightweight host sensor and what it collects Nozomi Arc is a lightweight software agent that installs on the host operating system of an OT or IT asset — a Windows or Linux historian server, engineering workstation, DMZ jump host, or any endpoint where host-level visibility matters. It reports telemetry directly to Vantage (the cloud-native SaaS management platform) or the CMC (on-prem Central Management Console), appearing in the same asset inventory and alert views as Guardian data. ### Four host-context categories Arc collects Users — who is currently logged in, new or unexpected accounts, privilege changes, and remote-session logins.
- Processes — what software is running, newly spawned processes, and executables that don't match the known-good baseline for that asset.
- USB / removable media — device attach and detach events, device identifiers, and timing — the key signal for physical exfiltration risk.
- Local sessions — RDP, VNC, local console, and other session types that may never appear on the network mirror.  These four streams feed the same hybrid detection engine that processes Guardian's network data. An anomalous process or an unexpected USB insert triggers an alert in Vantage or CMC just as an anomalous OT protocol sequence would.

  Figure 2 — Four host-context categories Arc collects
   Arc reports all four layers of host telemetry — none of which appear in network traffic.
- Four host-context categories Arc collects Users & sessions logins, RDP/VNC, account changes Processes running software, new executables USB / removable media attach / detach events and device IDs Arc reports all four layers of host telemetry — none of which appear in network traffic. 🔌 Nozomi Arc tap to flip Lightweight software agent on the host OS — reports users, processes, USB events and local sessions to Vantage or CMC. No network changes needed. 📡 Guardian sensor tap to flip Passive network sensor (SPAN/TAP) doing deep packet inspection — sees OT protocol traffic, network anomalies and asset communications, but not host internals. 🏭 Historian server tap to flip A high-value OT asset that aggregates process data from PLCs. A prime candidate for Arc because it has human access and USB risk, and may not be fully covered by a Guardian SPAN. ☁️ Vantage tap to flip Nozomi's cloud-native SaaS management platform that aggregates Guardian sensor and Arc endpoint data into a single asset inventory, alert queue and dashboard. Name the two sensor types In an interview, be explicit: Guardian = passive network sensor (SPAN/TAP, DPI, protocol-level); Arc = host sensor (agent, OS-level). Both feed the same Vantage or CMC console. Saying 'Nozomi uses network sensors' without mentioning Arc misses half the architecture. Quick check · Q2 of 10 · Remember Which of the following is NOT one of the four host-context categories collected by Nozomi Arc? a) Users and logins b) Running processes c) OT network protocol traffic d) USB device attach events Correct: c. Arc collects host-level context: users, processes, USB events, and local sessions. OT network protocol traffic (Modbus, S7, etc.) is the domain of Guardian, not Arc. 👉 So far: Nozomi Arc installs as a software agent on the host and reports four host-context categories: users, processes, USB events, and local sessions — to Vantage or CMC with no network changes. ## ③ Arc in action — filling the gaps Guardian cannot reach The deployment story for Arc is deliberately simple: install a software agent, point it at Vantage or CMC, and you have host visibility immediately. There is no SPAN port to configure, no TAP to order, and no maintenance window needed for a network change. This matters enormously in OT environments where even a minor network change requires a formal change-control process and a maintenance window. Three OT scenarios where Arc is the right answer: (1) Isolated or micro-segmented zones — where a Guardian sensor cannot be placed and no TAP is available. Arc installs on each host in the zone and phones home. (2) Historian and SCADA servers — these machines aggregate data from many PLCs and are high-value targets; Arc gives you process, user, and USB telemetry from the most sensitive boxes in the plant. (3) DMZ and jump hosts — the crossing point between IT and OT networks, exactly where lateral movement from an IT compromise would pivot into OT; Arc's session and process visibility catches that pivot. USB-based attacks are a special case. A threat actor — or an unknowing contractor — inserting a USB drive into a historian produces no network traffic . Guardian is silent. Arc logs the event instantly and Vantage raises an alert, giving the analyst a chance to intervene before any malware executes or data copies complete. Figure 3 — Arc reaches where Guardian cannot Arc deploys on hosts in segments, DMZs and isolated zones where no SPAN port exists. Arc reaches where Guardian cannot Nozomi Arc host agent Historian server Engineering WS DMZ jump host Isolated segment SCADA workstation Arc deploys on hosts in segments, DMZs and isolated zones where no SPAN port exists. Figure 4 — Arc vs Guardian — two sensors, one platform The two sensors cover different visibility layers and deploy in completely different ways. Arc vs Guardian — two sensors, one platform Guardian (network) Passive SPAN/TAP-based Sees all OT network traffic DPI of OT protocols Needs mirror port or TAP Best at aggregation switches Arc (host) Software agent on the host Sees users, processes, USB No network changes needed Reaches isolated segments Best on historians & jump The two sensors cover different visibility layers and deploy in completely different ways. Priya Nair, OT security analyst at Bharat Steel Works in Raipur, faces this A contractor connects an unauthorised USB stick to the plant historian during a maintenance window. The Guardian sensor on the OT network fires no alerts — no suspicious network traffic is observed. Likely cause USB insertion is a host event. Guardian only monitors network traffic from the SPAN port; it has no visibility into local device events on the historian. Diagnosis Check Vantage: Arc is installed on the historian and logs the USB attach event (device ID, timestamp) plus a new process that started immediately after. The alert is waiting in the Vantage queue. Vantage ▸ Alerts ▸ Host Events ▸ Historian asset Fix Isolate the historian, revoke the contractor's access, and investigate the process that ran. Arc's USB event log and process timeline give Priya the full forensic picture without needing network traffic. Verify Arc continues to monitor the historian; Guardian monitors network traffic. Future USB events on any Arc-covered host trigger an alert in Vantage immediately, regardless of network activity. 'Guardian covers everything' is wrong Passive network sensors structurally cannot see USB events, running processes, logged-in users, or activity in zones with no mirror port. Never claim full OT visibility from a network sensor alone — always add Arc for host context on high-value assets. ### ▶ Watch Arc catch a USB threat Guardian missed A USB device is inserted on a historian during a quiet maintenance window. Press Play for the Arc detection path, then Break it to see what happens without Arc. ① USB inserted A contractor plugs an unauthorised USB stick into the historian server during a maintenance window. No OT network traffic changes. ▼ ② Arc detects Arc, installed on the historian, logs the USB attach event (device ID, timestamp) and immediately reports it to Vantage. ▼ ③ Process alert Arc also logs a new process spawned seconds after USB insertion — a double signal for the analyst. ▼ ④ Vantage alert Vantage raises a host-context alert on the historian asset. Analyst sees USB event + process launch with full forensic detail. Press Play to step through the Arc detection path. Then press Break it to see the gap without Arc. ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply An OT zone has no available SPAN port and a formal change-window is weeks away. You need security visibility on the historian server today. What do you deploy? a) Wait for the change-window and install a TAP b) Deploy a second Guardian sensor on the subnet c) Use Vantage IQ to infer host activity from network flows d) Deploy Nozomi Arc on the historian server — it installs as a software agent with no network changes Correct: d. Arc deploys as a software agent with zero network infrastructure changes. No SPAN port, no TAP, no switch access required — making it the right answer when network changes are impractical. 👉 So far: Arc is the right choice for historian servers, engineering workstations, DMZ jump hosts and any segment with no available SPAN or TAP — deploy as an agent, gain visibility immediately. ## ④ Arc + Guardian together — unified visibility in Vantage Arc and Guardian are complementary, not competing . Guardian owns the network layer: passive DPI, OT protocol analysis, network-based asset discovery, and network anomaly detection. Arc owns the host layer: users, processes, USB, and sessions on individual machines. Together, they close the visibility gap in both dimensions. Both streams flow into the same Vantage or CMC console — no separate tool, no data silo. An asset discovered by Guardian over the network is enriched by Arc's process and user telemetry in the same inventory record. An analyst sees one asset card with both network-behaviour data and host-context data side by side. The decision rule is straightforward: deploy Arc wherever host context matters and a SPAN/TAP is impractical. For most OT estates that means historian servers, engineering workstations, DMZ hosts, and any host in a segment without a network tap. Guardian covers the network at aggregation points; Arc covers the hosts that matter most. The combination, managed from Vantage or CMC, gives the complete OT security picture that either sensor alone cannot. Figure 5 — Arc + Guardian unified in Vantage Both streams enrich the same asset record and alert queue — no separate tool needed. Arc + Guardian unified in Vantage Guardian network events Arc host events Vantage / CMC unified console Asset inventory enriched record Alerts network + host combined Both streams enrich the same asset record and alert queue — no separate tool needed. Check the asset record, not just the alert When investigating an OT incident, open the asset record in Vantage — it shows both Guardian network data and Arc host data in one view. If Arc is installed, you will see the process list, user history and USB events alongside network-behaviour data, giving a complete picture without switching tools. Quick check · Q4 of 10 · Analyze An analyst sees an alert in Vantage for an unexpected process on a historian and, separately, anomalous Modbus traffic on the same asset. Which sensors generated each alert? a) Both came from Guardian via SPAN mirroring b) Both came from Arc installed on the historian c) The process alert came from Arc; the Modbus traffic alert came from Guardian d) The process alert came from Guardian; the Modbus traffic alert came from Arc Correct: c. Arc owns host-level telemetry (processes, users, USB, sessions); Guardian owns network-level telemetry (OT protocol traffic). Both feed Vantage, so both alerts appear in the same console — but from different sensors. 👉 So far: Arc and Guardian are complementary: Guardian owns the network layer, Arc owns the host layer. Both feed the same Vantage or CMC console — one asset record, complete visibility. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is Nozomi Arc? What are the four host-context categories Arc collects? How does Arc deploy compared to Guardian? When should you deploy Arc instead of (or alongside) Guardian? Does Arc replace Guardian? How does Arc data appear in the Nozomi platform? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which Nozomi component is a lightweight software agent installed on a host OS? a) Guardian Air b) Nozomi Arc c) Vantage IQ d) CMC Correct: b. Nozomi Arc is the lightweight host-based (endpoint) sensor that installs directly on the asset OS. Guardian is the passive network sensor; Vantage IQ is the AI analytics add-on; CMC is the on-prem management console. Q6 · Understand Why does a USB stick insertion on a historian produce no Guardian alert? a) USB insertion is a local host event with no network traffic — invisible to a SPAN/TAP-based sensor b) Guardian is not configured for USB events by default c) The historian is not added to the Guardian inventory d) Guardian only monitors wireless traffic Correct: a. Guardian mirrors network traffic via SPAN or TAP. A USB insertion is a local OS event that generates no network packets — it is structurally outside what any passive network sensor can see. Q7 · Apply An OT segment has no available SPAN port and network changes require a 4-week change-window. To get visibility on a critical SCADA workstation today, you should: a) Request the change-window and wait b) Install a Guardian virtual appliance on the segment switch c) Deploy Nozomi Arc on the SCADA workstation — agent install, no network changes d) Enable passive mode on the existing firewall Correct: c. Arc deploys as a software agent with zero network infrastructure changes. It is exactly the tool for situations where a SPAN or TAP is unavailable or impractical to deploy quickly. Q8 · Analyze A Vantage alert shows an unexpected process on a DMZ jump host. The Guardian sensor covering the DMZ shows normal traffic. What is the most likely explanation? a) The Guardian sensor is misconfigured b) Vantage is generating a false positive c) The process was launched over the network and Guardian missed it d) Arc on the jump host detected a host-level process event that produced no anomalous network traffic Correct: d. Arc captures host-level events (processes, users, USB, sessions) that may never appear as anomalous network traffic. A process launched locally or via RDP on the jump host is exactly what Arc detects and Guardian does not. Q9 · Understand Where does Arc telemetry appear in the Nozomi platform? a) Alongside Guardian data in the same Vantage or CMC asset inventory and alert queue b) In a separate Arc-only console, not Vantage c) Only in Vantage IQ after AI processing d) In a raw log file on the host Correct: a. Arc data flows into the same Vantage (SaaS) or CMC (on-prem) console as Guardian data. Both enrich the same asset record and appear in the same alert queue — no separate tool is needed. Q10 · Evaluate An OT architect says 'We have Guardian sensors at all aggregation switches, so we have full visibility.' What is the strongest counter-argument? a) Guardian uses too much bandwidth b) Guardian requires cloud connectivity to work c) Guardian only supports physical appliances d) Guardian network sensors cannot see host-level events — USB inserts, running processes, local user sessions — and cannot reach segments with no SPAN or TAP. Arc fills those gaps. Correct: d. Network sensor coverage at aggregation switches leaves host-level and segment-level blind spots. Arc fills those gaps by providing host context (users, processes, USB, sessions) and reaching isolated segments without network changes. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what can Nozomi Arc see that Guardian cannot, and why? Then compare with the expert version. Compare with expert answer Expert version: Arc sees host-level events — USB device inserts, running processes, logged-in users, and local sessions (RDP/VNC) — that generate no network traffic and are therefore structurally invisible to Guardian's SPAN/TAP-based passive sensor. Guardian watches what crosses the wire; Arc watches what happens inside the machine. The two sensors are complementary: Guardian owns the network layer, Arc owns the host layer, and both feed the same Vantage or CMC console. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Nozomi Networks at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Nozomi Arc Lightweight software agent installed on a host OS to collect host context (users, processes, USB events, local sessions) for Vantage or CMC. Guardian Nozomi's passive network sensor (SPAN/TAP-based DPI) for OT asset discovery, protocol analysis and network anomaly detection. Vantage Nozomi's cloud-native SaaS management platform that aggregates Guardian sensor and Arc endpoint data into a single console. CMC (Central Management Console) On-prem alternative to Vantage for multi-site estates that cannot use SaaS; aggregates Guardian and Arc data centrally. Host context OS-level telemetry about what is happening on a machine: active users, running processes, USB events and session activity. SPAN port / TAP Network infrastructure that copies traffic to a passive sensor port — required for Guardian, not required for Arc. Passive monitoring Observing copies of network traffic without sending packets or touching devices — Guardian's zero-impact approach. Vantage IQ AI/analytics add-on to Vantage that accelerates alert triage, correlation and root-cause analysis. #### 📚 Sources Nozomi Networks — Arc endpoint sensor: host visibility for OT & IoT . nozomi.com/products/arc
- Nozomi Networks — Guardian sensor: passive OT network monitoring & DPI . nozomi.com/products/guardian
- Nozomi Networks — Vantage: cloud-native SaaS OT/IoT security platform . nozomi.com/products/vantage
- Nozomi Networks — Platform overview: Guardian, Vantage, CMC & Arc . nozomi.com
- Nozomi Networks Labs — Threat Intelligence & Asset Intelligence subscription feeds . nozomi.com/labs
- Techclick — Nozomi Networks OT/IoT Security course ground-truth reference . techclick.in

### What's next?

             Got Arc? Next, explore how Nozomi Guardian's passive deep packet inspection discovers assets and detects threats on the network side — the other half of the Arc + Guardian pairing.

                 Next · All interview lessons →
                 Practice on exam.techclick.in →

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt
