NetProbe is currently in development and validation at ST-LINE on a proprietary network simulator. There are no external deployments yet; the first pilot is planned for the third quarter of 2026. This post is not sales material — it’s a status update on the product and the architectural choices that shaped it.
From a set of tools to a product
NetProbe wasn’t born out of market analysis. It came from grouping together proprietary tools we used internally for security audits on our clients’ networks. Asset discovery, vulnerability scanning, firewall log parsing, TLS audits: each was a script or a small dedicated tool. The friction was in stitching them together and producing coherent evidence for an ISO 27001 or NIS2 audit every time a client asked.
Across the Italian SME clients we worked with, we kept seeing the same pattern. Asset inventories in spreadsheets that were always out of date. Firewall logs producing large volumes of events that nobody analysed. Incidents detected late. Enterprise tools — Darktrace, Vectra, Claroty — evaluated but out of scale, both in budget and in team. The Italian SME doesn’t have a SOC, it has an IT manager who is also doing four other things.
Consolidating those tools into an integrated product meant solving the problem once instead of every time. It became NetProbe.
Why passive
The founding architectural choice is that NetProbe’s observation plane is passive.
This needs saying immediately, because otherwise the word “passive” covers more than it should: among the features developed there is also a port scan with CVE matching, and a port scan is active probing. The two planes are distinct and must be treated as such — passive observation always available, active assessment off by default and enabled only on explicit authorisation, within an agreed window. Presenting the whole as “a passive probe” would be unfair to whoever has to grant that authorisation. It receives traffic in copy from a mirror port, or telemetry that already exists like NetFlow and firewall syslog. It doesn’t authenticate to any appliance, it doesn’t write to anything, it doesn’t block traffic.
Two concrete reasons. The first is operational: the client’s approval is faster. A probe that only observes has a far simpler operational risk profile to evaluate — not a null one, since the load on the mirror port, the management of the appliance and the handling of the collected data all remain, but conversations with IT and security teams are shorter. An active or agent-based probe needs weeks of evaluation, staging tests, formal change approval. The difference between “installed in days” and “deployed in months” mostly lives there.
The second reason is coverage. In the mixed IT/OT environments we see in real clients — manufacturing, healthcare, energy — many devices won’t accept agents. PLCs, HMIs, IP cameras, MQTT brokers, BACnet devices: legacy or industrial systems where an agent isn’t a technical option. A passive probe sees them all from the same vantage point, without having to touch any of them.
Why on-premise (and local AI)
NetProbe runs entirely on the client’s premises: capture, analysis, AI, archival, reporting. Cloud is optional, never required.
In regulated sectors this is a constraint, not a preference. Moving network data to a cloud vendor opens a chapter that Italian SMEs don’t have time for: extra-EU transfers, sub-processors, Art. 30 GDPR records. If the analysis runs on the client’s appliance, the transfer chapter never opens. Do not stretch that too far, though: staying on-premise removes the transfer, not the obligations. The Art. 30 record concerns processing activities, not whether the data leaves the company — and an appliance capturing network traffic processes personal data regardless, with its own legal basis, notice and retention period. It also works in air-gapped environments, where some industrial and healthcare clients require it as a condition of acceptance.
Local AI follows the same constraint. NetProbe uses open-weight Llama models executed locally; cloud providers (Claude, Gemini, OpenAI) are optional and require pseudonymisation of IPs, MACs and hostnames before any outbound call. Pseudonymisation is an architectural invariant rather than a setting: it sits in the data path, not in a checkbox.
That said, two clarifications matter more than the phrase. The first is legal: pseudonymising IPs, MACs and hostnames does not anonymise. If re-identification is possible with additional information — and on an inventoried network it is, because the reverse mapping is the inventory itself — the data remains personal under the GDPR, with everything that follows. Pseudonymisation is a security measure, not an exit from scope. The second is methodological: “not bypassable” is a security claim, and as such needs publishable tests and code review behind it, not an assertion. Until that material exists, the correct wording is that the path is designed not to be bypassable.
Calibrated for the Italian SME also means concrete things: syslog parsers for the firewalls actually deployed here (WatchGuard, Sophos, Fortinet, pfSense, OPNsense), support for on-premise Active Directory Windows Event Logs, Italian interface and reports by default. Italian NIS2, Italian GDPR, Italian auditor.
What NetProbe deliberately doesn’t do
NetProbe doesn’t replace a firewall, an EDR, a SIEM or a SOC. It doesn’t block traffic, it doesn’t write to appliances. It doesn’t guarantee zero false positives on any detector — that would be mathematically false, and the auditor knows it. It doesn’t make an organisation 100% compliant with any framework: compliance is an attribute of the organisation, not of a single tool installed on the network.
What it does, it does with verifiable evidence: it surfaces known patterns on a network the client couldn’t see before, it automates the collection of evidence for compliance audits, it delivers a technical dossier that the security manager, DPO or auditor can use without having to rewrite it. The list of things it doesn’t do is central: anyone selling a product that promises to solve everything has already lost the client at the first contact with reality.
Current state
Developed and exercised on our own cases in the internal lab — not yet validated on a customer pilot, and without a publishable evidence package: passive capture with protocol recognition, live asset inventory, port scan with CVE matching against NVD, offline SSL/TLS audit, correlation engine with statistical baseline and MITRE ATT&CK mapping, local Llama conversational AI, invariant pseudonymisation, immutable audit log, ROPA, IoT/OT analyser, SIEM export, multi-format reports with AI-generated narrative.
In delivery for 2026: proactive AI Watcher, unified detection plane between deterministic rules and AI, locally fine-tuned models, simplified UX. First pilot on a real client: third quarter 2026.
What a tool can and cannot do
Local AI isn’t a feature, it’s the entry condition. In regulated sectors, if the AI runs in the cloud, there’s no product to sell — there’s just one more chapter the client has to write in their records of processing. Italian SMEs don’t have the time to write that chapter, and their auditors don’t have the patience to read it. NetProbe starts from this constraint and makes it the architectural foundation, not a compromise.
NetProbe is in development. If you work in an Italian SME subject to NIS2, ISO 27001 or IEC 62443, or you’re a consultant running periodic security audits on clients, and you’d like to be among the first pilot organisations in 2026, get in touch.