NetSenX: plans and set-up

Every plan, Free included, detects beaconing, scanning, lateral movement and unusual outbound volume, explains each alert in plain language and keeps a network map; higher plans add reports, integrations and specialised monitoring. Free costs €0 for up to 3 devices with 30 days of alert history, plus NIS2 deadline tracking, an audit log and two-factor sign-in. Free and Solo cover the computers the agent is installed on; a network sensor on a SPAN or TAP port starts with Starter. Starter, at €49 per month for up to 10 devices, adds PDF reports, manual response actions, team management and TLS fingerprinting where the agent captures packets. Solo, at €19 per month, has Starter's detection, reports and response actions for exactly one computer, the one the agent is installed on, and one user, without team management or a device add-on. Pro, at €99 for up to 25 devices, adds Shadow AI visibility, passive OT protocol monitoring, the API, Slack and webhooks, and the NQCI crypto inventory, which needs packet capture on Linux or a SPAN or TAP sensor. Business, at €249 for up to 100 devices, adds SIEM export and breach and attack simulation. Enterprise, from €999, adds unlimited devices, custom detection policies, white label, on-premises deployment and single sign-on. Prices are per month and exclude VAT. Reports: Free: No reports (AI Act instructions for use included). Solo and Starter: Operational reports (NIS2 incident, GDPR, monthly, MITRE); audit pack with annual billing. Pro, Business and Enterprise: All reports including the audit pack.

You choose: connect one agent to a SPAN or TAP port to watch a whole network segment, or install the agent on the hosts you want to monitor. The agent runs as a system service on Linux and macOS; on Linux the installer accepts only a package signed with the NetSenX release key, and macOS agents are set up together with NetSenX support. The dashboard is a service hosted in the EU; an on-premises option is available on the Enterprise plan.

You choose the deployment: a single SPAN/TAP port on your switch watches a whole network segment and counts as one device, or install the NetSenX agent on the specific hosts you choose. Both are documented; no kernel modules. On Linux the installer only installs a package whose signature matches the NetSenX release key, and refuses anything else; macOS agents are set up together with NetSenX support.

The NetSenX agent runs on Linux and macOS, and a single agent on a SPAN or TAP port watches every device on that segment, whatever operating system those devices use. On Linux, the agent installs as a system service with a one-line command from the dashboard, and the installer accepts only a package signed with the NetSenX release key. On macOS it installs from a signed package and runs as a background service; macOS agents are set up together with NetSenX support. If your company also has computers with other operating systems, or printers, cameras, phones and machines that cannot run any agent, put one agent on a host connected to a mirror port: it sees their traffic without anything installed on them. That is usually the simplest way to cover a mixed office. What the agent does not see is traffic on segments you do not mirror and activity inside a computer that never touches the network.

It is designed not to, and the safest way to avoid any load on a server is not to install it there at all: one agent on a host connected to a mirror port watches the whole segment without touching the servers on it. A mirror port copies traffic inside the switch, so the monitored servers do not process anything extra, and the network path itself is not changed: the sensor only receives a copy. When you do install the agent on a server, it reads connection metadata and a few protocol fields, such as timing, volume, destinations, DNS answers and, where packets are captured, the TLS handshake. It never decrypts traffic and does not proxy or block connections. As with any new software on a busy server, watch its resource use for the first days, and pilot on a less critical host first. Ask NetSenX support before deploying on very high-traffic links.

The basic mode sees connections, timing and volumes; packet capture also reads the unencrypted fields of the TLS handshake, which some features need. On macOS, the agent runs in a basic mode that observes the connections of the Mac it is installed on. That is enough for the core detections, such as beaconing, scanning, lateral movement and unusual outbound volume. Packet capture means the agent copies the packets themselves to read a few protocol fields, still without decrypting anything. It is available where the agent runs on Linux, or as a sensor on a SPAN or TAP port. Two features depend on it: TLS fingerprinting, from the Starter plan, which recognises known malware clients by their handshake, and the NQCI crypto inventory, active from the Pro plan, which reports quantum-vulnerable and hybrid key exchange. If you need either, plan a Linux agent or a mirror-port sensor.

NQCI is visible on every plan as a preview, active from the Pro plan, and it needs the packet-capture sensor, which is off by default. To use it, you need two things. First, a Pro, Business or Enterprise plan. Second, an agent that captures packets: either a Linux agent with packet capture switched on, or an agent on a host connected to a SPAN or TAP port. The basic macOS mode does not see TLS handshakes, so it cannot feed the inventory. Once it runs, NQCI shows which connections crossing the monitored segment use quantum-vulnerable key exchange and which already use hybrid post-quantum key exchange, plus the SSH server versions it sees. It is still in preview. It does not see cryptography inside applications or on disk, it does not migrate anything, and it does not do your compliance work for you; it gives you a starting inventory from the network.

Yes, alerts and the device inventory start as soon as traffic flows, but comparisons with each host's normal behaviour get better as NetSenX learns your network. On day one you will see devices appear on the network map and clear patterns such as scanning or regular call-outs raise alerts. What takes longer is the part that depends on history: knowing that the finance server never talks to a certain host, or that a large transfer at 02:00 is unusual for this machine but normal for the backup server. Expect the first weeks to need more of your attention, as you confirm and mark normal activity. There is no ready-made model that knows your network on day zero. The false-positive bound, part of the NetSenX Math Guarantee, is shown only once your own labelled data supports it; until then the dashboard says so instead of showing a number.

It is a live inventory of the devices NetSenX sees on your monitored segments, with who talks to whom, and it is included on every plan, Free included. For each device it shows the name it announces on the network, its address, when it was first and last seen, and its connections to other devices and to outside destinations. Cloud and hosting destinations go into a review queue, so you can decide whether a server talking to a freshly rented cloud machine is expected. The map is built passively from traffic: NetSenX never scans or probes devices, which is safe for printers, cameras and industrial equipment. The flip side is that a device that never sends traffic, or sits on a segment you do not mirror, does not appear. Many customers use the map in the first week to find forgotten servers, unknown devices and equipment that should not be there.

On every plan, alerts appear in the dashboard and are sent by e-mail; from the Pro plan they can also go to Slack, a webhook or your own systems through the API, and from the Business plan to your SIEM. E-mail suits a small team: send alerts to a shared mailbox or to two people, so someone sees them when the administrator is away. A webhook lets you forward alerts to a ticketing system, a chat tool or an on-call service your IT provider already uses. SIEM export puts network detections next to your log data. Whatever the channel, each alert carries the same plain-language explanation of what happened, on which host and why it was raised. Decide in advance who reads alerts at night and at weekends: NetSenX detects at any hour, but it does not run a staffed service that phones you.

It depends on the plan: the Free plan keeps 30 days of alert history, each higher plan keeps longer, and Enterprise has no time limit; the pricing table shows the exact period for each plan. Alert history matters more than it seems. When an incident is found, investigators and insurers ask when it started, and the answer often lies weeks back; if your history is shorter than the attacker's time inside, the evidence is gone. The audit log, which records who changed what and what was done about each alert, is kept separately with its own default period per plan. Choose the plan with the incident in mind, not only the device count: a company that must report under NIS2 or answer an insurer's questions may need more history than its size suggests. If you cancel a paid plan, the account continues on the Free plan with its retention periods.

Yes. DNS tunnelling alerts are included on every plan, Free and Starter included. DNS tunnelling hides data or commands inside DNS lookups, usually as long, random-looking names sent to one domain. NetSenX alerts on that pattern. Other DNS-related detections are still being measured and do not raise alerts yet, so NetSenX does not claim to detect other kinds of DNS abuse. Independently of NetSenX, you can reduce the risk by sending all DNS through your own resolvers, blocking direct DNS to the internet from workstations, and keeping resolver logs. Remember that encrypted DNS sent over HTTPS to an outside provider is not visible as DNS to any network sensor.

Mark that exact job as expected, rather than switching off the detection: the backup server, its destination and its time window, nothing broader. A nightly backup moves a lot of data, often to an outside storage provider, which looks like data theft to any tool that watches volumes. The first time it alerts, confirm it is the backup: check the host, the destination and the schedule against your backup software. Then mark that alert as a false positive in NetSenX, so similar alerts from that job are recognised. Keep the detection on for every other host: the same transfer from a workstation, or from the backup server to a new destination, should still raise an alert, because attackers also copy data out at night. Write down the decision and review it when the backup setup changes. NetSenX keeps each decision in the audit log, so you can show later why an alert was closed.

It is a statement that, among the alerts the tool surfaces, the share of false alarms stays below a stated level, at a stated confidence, measured on your own network. For a small team it answers the practical question: how much of my alert time will be wasted? NetSenX derives such a bound with a split-conformal method from benign traffic your team has labelled in your own tenant. The catch is honest: a bound is only as good as the data behind it. With few labelled alerts, the method cannot support a tight bound, so the dashboard says that no bound is supported yet and what would close the gap, instead of showing a reassuring number. As you mark alerts over the first weeks and months, the bound becomes possible. It is a property of your data, not a fixed rate NetSenX promises, and it is included on every plan as part of the NetSenX Math Guarantee.

It is a verifiable false-positive bound among engine-surfaced alerts, derived with split-conformal prediction from benign traffic your analysts have labelled on your own network, at a confidence level you set. The dashboard shows the bound only once your calibration data supports it; until then it says so instead of showing a number. It describes a method and what your data currently supports, not a fixed rate. It is included on every plan.

It guarantees a method, applied to your data, and full visibility into what that method currently supports. A split-conformal layer derives a false-positive bound on the alerts the engine surfaces, at a configurable confidence level, from analyst-labelled benign traffic in your own tenant. A finite calibration set can only resolve a bound so tight, so the dashboard shows the bound your data supports — and states that it supports none yet, together with what would close the gap, rather than displaying a figure we cannot back. The methodology is documented in our Trust Center and is independently reviewable.

No. NetSenX detects and alerts at any hour, but it is software: nobody at NetSenX watches your alerts around the clock or responds for you. The difference matters when you describe your security to an insurer, an auditor or a customer. Saying detection runs around the clock is true; saying someone responds around the clock is only true if you arrange it. Options that work for small and mid-sized companies: send alerts by e-mail to two people instead of one; use a webhook, from the Pro plan, to reach an on-call service your IT provider runs; agree with an MSP or MSSP that they receive and act on alerts outside office hours; and keep an incident-response firm's number ready. If you need people watching around the clock, a managed detection and response (MDR) provider offers that, and NetSenX alerts can be passed to them.

It does not block traffic, decrypt sessions, protect endpoints, filter e-mail, manage identities, back up data or run a staffed security service. NetSenX watches network behaviour and explains alerts. It never reads the content of encrypted sessions, so it cannot tell you what was in an uploaded file or what someone typed into an AI tool. It does not see what happens inside a computer without touching the network, devices that stay silent, or segments you do not mirror. It does not see sign-ins in your VPN, directory or cloud services, so a valid stolen password used normally may look like normal work. It does not decide whether an incident is reportable or submit reports to authorities. For those gaps you need endpoint protection or EDR, e-mail security, multi-factor authentication and identity logs, tested backups, and people who can respond. NetSenX works alongside them.

Enterprise customers receive evidence mapped to SOC 2 Type I (in progress), ISO 42001 (AI management), and ISO 27001. Each control includes timestamped artifacts, sub-processor attestations, and an exportable auditor view, refreshed on a real-time cadence.

Yes. The Business and Enterprise onboarding includes a structured cut-over: parallel running for two weeks, alert taxonomy mapping, and analyst playbook migration.