--- title: secnostic sensor canonical: https://www.secnostic.com/en/products/sensor language: en dateModified: 2026-08-12 alternate-de: https://www.secnostic.com/de/products/sensor --- # secnostic sensor - URL: https://www.secnostic.com/en/products/sensor - Positioning: Sensing and reality check secnostic sensor inspects endpoints and networks directly, finds assets and their connections, and reports what is actually there. Instead of trusting your lists, secnostic sensor checks the real IT and OT environment and fills the gaps nobody maintains by hand. **What is really running, not what the list says** Spreadsheets go stale the moment someone plugs in or rewires something. secnostic sensor checks for itself: on Windows and Linux, in Active Directory, on the network, read-only and gentle in OT, plus Microsoft 365, Intune, and Sophos Central. Every finding arrives with its source and a confidence level and is handed to secnostic inventory directly or through a Fleet Manager. So you see what is really there, what changed since the last run, and where a blind spot still remains. **Capabilities** - Observe endpoints, networks, services, and technical state - Surface communication relationships and unknown systems - Cross-check inventory data against the real environment and uncover quality gaps - Adapt passive or controlled discovery to sensitive OT environments **Outcomes** - Current asset data without maintaining spreadsheets by hand - A clear view of what really talks to what in IT and OT - A data basis that inventory, security, and audit can trust **Modules of secnostic sensor** - **Dashboard** - Overview: Sensor health at a glance, with counts of assets, connections and findings, plus upload status. - **Hosts** - Inventory: Every discovered asset with its IP, vendor and detected protocols, seen actively or passively. - **Network graph** - Model (core module): The heart of it: who talks to whom as one connected model of nodes, edges and traffic with identity hints per asset, not a flat list. - **Connections** - Paths: Every path of communication with endpoints, protocol, volume and service. - **Findings** - Findings: Detected devices and security facts such as a Siemens S7 identity, with category and reported version. - **Collectors** - Sources: Specialized collectors grouped by how gently they read: passive network, local endpoints, a scoped Active Directory read, opt-in OT, and cloud. - **Safe by default** - Safety: Read-only, opt-in and plan-only for OT, with a fail-closed scheduler and a per-protocol allow-list. **From many observations to one reliable inventory** Specialized collectors gather evidence from IT, OT, identity, and cloud, grouped by how gently each is read. The sensor normalizes every finding with source and confidence into one stream and hands it to secnostic inventory directly or, in scaled environments, through a Fleet Manager. - Passive: Network, Flow records - Read-only: Endpoints, Active Directory, Active & OT - Cloud: Microsoft 365, Sophos Central **Protocols, practice, and a safe scope** Which protocols the sensor reads, how that looks in practice, and the explicitly approved scope active discovery runs in. - OT & industry: Modbus, Siemens S7, PROFINET, EtherNet/IP, OPC UA, BACnet, DNP3, EtherCAT - Network: TLS, HTTP, DNS, SMB, RDP, SSH, NetFlow, IPFIX - Identity & cloud: Active Directory, Microsoft 365, Intune, Sophos Central, SNMP _Scope & safety._ Active and OT discovery is not a free scan. An explicit, fail-closed scope and a policy per probe decide what is probed at all, gently and read-only. - **Target scope**: Allow and block lists for hosts, networks, and ranges. With no entry, nothing is probed. - **Planning**: Candidates come from allowed ranges and optionally from passive sightings, always inside the scope. - **Plan-only**: On request the probe computes only the plan and sends no packet at all. A true dry run. - **Approval & pacing**: Every probe family can be toggled individually. Concurrency, timeouts, and delays bound the load. - **Read-only**: Approved probes only read and return identity and posture facts with evidence attached. In practice: - **See what's on the network**: An operations team wants to know which devices are active and talking to each other, without touching anything. (Listen in -> Spot devices -> See relationships -> No intrusion) - **Inventory software and devices**: An IT team needs a current list of every system and its installed software, without installing anything on each machine. (Read sources -> Software & versions -> Gaps surface -> Into inventory) - **Merge the data**: The same device is often seen more than once. The sensor merges this evidence into one reliable entry. (Many sources -> Match safely -> Merge -> With provenance) **A look inside the sensor** Dashboard, hosts, graph, connections, and findings stay separate by task and share one observation stream. - Dashboard: assets, connections, findings, and the upload queue at a glance, with the sensor's identity, version, and health. - Hosts: every discovered asset with its IP, vendor, protocols, and source, seen actively or passively. - Network graph: who talks to whom, with nodes, edges, traffic, and identity hints per asset. - Connections: every path of communication with endpoints, protocol, volume, and service, as proof instead of a guess. - Findings: detected devices and facts, such as a Siemens S7 identity, with category and reported version. **FAQ** - Q: Does the sensor write to the devices it discovers? A: No. The sensor is a pure collection probe. Passive network visibility sends no packet, and every active or OT probe only reads, is opt-in, and runs solely against an explicit allow-list. It even reports passively observed writes from other systems as a security fact. - Q: Is it safe to run in OT environments? A: Gentle probing is the sensor's job. The production baseline is plan-only, the target planner is fail-closed, concurrency can be limited to a single host, and every protocol family is approved individually. The shipped lab profile must be replaced with the safe baseline before touching a real network. - Q: Where does the data go if the inventory is unreachable? A: Each run is spooled locally first. A single sensor can deliberately send directly to the Inventory API over HTTPS; in distributed or segmented environments, the optional Fleet Manager merges the changes and initiates an mTLS sync. If inventory is unreachable, data stays local and the transfer retries with growing back-off. Nothing leaves the host until synchronization is configured. - Q: How sensitive is the data, and how is it protected? A: Observations can reveal hosts, users, services, certificates, and communication paths, so they are treated as sensitive. Normalization is data-minimizing: usernames, principals, and secrets are hashed rather than stored, raw DNS and OT payloads are dropped, and raw evidence is off by default. The local diagnostics view is read-only and reachable only over loopback. **Getting started.** Together we clarify which sources can be used with low risk and which observations matter first for inventory, operations, and security.