What are the key advantages of Kaspersky Industrial CyberSecurity for Networks Additional Sensor?
Central management – Managed entirely from the KICS for Networks Server.
Passive monitoring – Analyses mirrored traffic without touching the production network.
Protocol inspection – Reads industrial control commands inside network packets.
Asset visibility – Lists devices and their communications per monitored segment.
Local preprocessing – Keeps traffic analysis load off the central Server.
Important note – Requires an existing KICS for Networks base licence.
Additional sensor node – One more traffic analysis node for an existing deployment.
Monitoring points – Network interfaces on the sensor that receive mirrored industrial traffic.
Deep packet inspection – Reads process parameters and system commands out of traffic.
Detection rule engine – Intrusion, integrity and anomaly rules run on the sensor itself.
Certificate based link – Sensor to Server traffic is authenticated using certificates.
Important – Active Polling and Security Audit modules are licensed separately.
This is an add-on that extends an existing Kaspersky Industrial CyberSecurity for Networks installation with one further sensor node, and it cannot be operated on its own. All sensors are managed centrally by the KICS for Networks Server, which also hosts the web interface where their findings are reviewed.
Fewer blind spots – Covers plant segments the central Server cannot physically reach.
Lower server load – Sensor preprocesses traffic before sending results to the Server.
No process impact –Monitoring stays passive and never writes to controllers.
Single event view – Sensor findings appear in the existing Server web interface.
Faster incident scoping – Local asset records show which devices communicated and when.
Site by site rollout – Add sensors as further plants or lines come online.
Company size matters less here than plant topology. The decisive question is whether your OT network has segments whose traffic cannot be mirrored back to the existing KICS for Networks Server, for example a second production hall, a remote substation or a pumping station on its own switch fabric. Organisations with a single switched cell rarely need a second sensor at all.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | By sector | By sector | Often applies |
| NIS 2 in the European Union | Rarely | By sector | ✓ |
| Security questionnaire from large customers | Occasionally | ✓ | ✓ |
| OT segments the Server cannot mirror | ✕ | Sometimes | ✓ |
| This product fits | Rarely | Partial | ✓ |
The revised Information Security Act obliges operators of critical infrastructure, among them energy and drinking water suppliers, transport companies, listed hospitals, data centre operators and cantonal and municipal administrations, to report cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery. An additional sensor supports that obligation in one narrow but useful way: it produces timestamped, protocol-level records of device communications in a segment that was previously unmonitored, which is often what turns an unclear plant disturbance into a reportable finding within the deadline. It does not decide whether your organisation is in scope, does not classify an incident as reportable, and does not submit anything to BACS, so the reporting process itself remains manual. It also covers only the segments where mirrored traffic actually reaches the sensor, meaning any cell without a mirror port stays invisible regardless of how many sensors you licence. This text is informational and does not constitute legal advice; whether your organisation falls under the reporting obligation should be clarified with your own legal counsel.
No product creates NIS 2 compliance, because the directive addresses organisational risk management rather than any single tool. NIS 2 requires measures in categories including risk analysis, incident handling, business continuity and crisis management, supply chain security, network and information system security, and policies to assess whether those measures actually work. An additional sensor contributes to two of these: network and information system security, by extending traffic analysis into a further segment, and incident handling, by delivering event and asset data that shortens the detection and scoping phase. It contributes nothing to business continuity, crisis management, supply chain security, access control, cryptography, or staff training, and it produces no policy documentation of the kind auditors ask for. Treat it as one detection input inside a wider programme, not as a measure that closes a category on its own.
Two official positions are relevant and both are still in force. On 20 June 2024 the US Department of Commerce Bureau of Industry and Security issued a Final Determination prohibiting Kaspersky from supplying cybersecurity and anti-virus products and services to US persons, with new agreements barred from 20 July 2024 and update provision ending on 29 September 2024; the resale or integration of Kaspersky software by US persons is covered by the same determination. Germany's Federal Office for Information Security has warned against the use of Kaspersky anti-virus software since 15 March 2022, a warning it has maintained into 2026 and which now sits under Section 13 of the amended BSI Act following the German NIS 2 implementation act that entered into force on 6 December 2025. Kaspersky rejects both assessments, states that the concerns are geopolitical and hypothetical rather than evidence-based, points to its data processing in Switzerland, and has said it offered independent third-party verification of its products. Independent technical testing is a separate matter and has continued: in 2026 AV-Comparatives awarded its Operational Technology certification to KICS for Nodes, the endpoint component of the same platform, after it blocked all offline post-breach execution scenarios without false positives. Practically, this affects buyers with US market exposure, public sector contracts, or customers who impose vendor-origin clauses through supply chain questionnaires; for a purely Swiss or EU private-sector industrial operator with no such clauses, it is a documented risk to record in a vendor assessment rather than a legal barrier.
Partly, and only for the network monitoring items. It answers questions about OT asset inventory, whether industrial network traffic is monitored, whether unauthorised device-to-device communication is detected, whether industrial protocol commands are inspected, and whether detection events are forwarded to a SIEM, since the KICS for Networks Server exports to external systems through connectors. It answers nothing about endpoint anti-malware, application allowlisting, patch status, vulnerability remediation, encryption, multi-factor authentication, privileged access, backup and restore testing, or security awareness training, and it produces no policy or process evidence. It also cannot answer the vendor-origin question that increasingly appears in questionnaires from customers with US exposure. The cheaper route to closing the technical gaps is usually to stay inside the same platform, adding KICS for Nodes for endpoint protection and the separately licensed Security Audit module for vulnerability and configuration evidence, rather than introducing a second vendor's console alongside the existing Server.
The single decisive difference is that the Server is a complete, self-sufficient installation and the Additional Sensor is not. The Server carries the web interface, stores device and event data, manages every sensor, and contains its own built-in sensor, so a Server on its own already delivers the full feature set for the segments it can see. An Additional Sensor adds analysis capacity and physical reach only: it inspects traffic at its own monitoring points and relays results upstream, but has no console, no data store and no independent existence. You buy sensors when traffic cannot be brought to the Server, not when you want more features.
| Capability | Server licence | Additional Sensor |
|---|---|---|
| Web interface and central management | ✓ | ✕ |
| Traffic analysis at own monitoring points | ✓ | ✓ |
| Event storage and device database | ✓ | ✕ |
| Runs without another licence | ✓ | ✕ |
| Active Polling and Security Audit | Licensed separately | Licensed separately |
The clearest regional limitation is that Kaspersky products may not be supplied to US persons following the 2024 Commerce Department prohibition, so this add-on is not an option for organisations with US entities in scope, and resale or integration by US persons is covered by the same determination. Technically, a sensor sees only what is physically mirrored to its monitoring points, so a segment without a mirror port or tap stays dark no matter how many sensors are licensed, and a sensor needs its own dedicated computer separate from the Server. Monitoring is passive by design: the sensor detects and reports but does not block, and enforcement at device level requires the endpoint component KICS for Nodes. The Active Polling and Security Audit modules, which most buyers assume are included when they read about asset discovery and vulnerability scanning, must be purchased and licensed separately. Finally, the link between sensor and Server needs enough headroom above the volume of traffic the sensor is analysing, which is the limitation most often discovered after installation on a remote site with a thin WAN connection.
No. Sensor monitoring is passive and cannot affect the monitored system, which is deliberate in environments where a false positive on a controller link would be more damaging than the threat. Blocking unauthorised communication happens at endpoint device level through the KICS for Nodes component, not through the network sensor.
In some cases yes. KICS for Networks documents deployment across a data diode for one-way isolated segments and can also receive industrial network traffic from Kaspersky SD-WAN components. Both are architectural decisions that should be settled before you buy the sensor, not afterwards.
The sensor continues analysing traffic at its monitoring points locally, because detection rules run on the sensor itself rather than on the Server. What stops is the upstream flow of events and asset data into the central web interface, so findings from that segment become visible again only once the certificate-secured link is restored.