Every network carries equipment its security team cannot fully account for, like medical devices, controllers on a plant floor, or contractor equipment on a segment nobody has audited in years. Some of it is too old to send logs. Some of it will never accept monitoring software installed on it. If your security tools rely only on logs, those devices can be invisible. This leaves gaps where you cannot protect or report on activity you have never seen.
A sensor changes that. It listens to the segments you attach it to, and anything that talks on the network surfaces, whether or not it writes a log.
Today, we release a new version of Guardsix Network Detection and Response (NDR) that improves that listening capability in three places: what the sensor detects, where the sensor runs, and how quickly you can bring one online.
Version 2.33 does four things:
It does all of that on infrastructure you own, under your own jurisdiction, at a price that tracks the sensors you choose to deploy rather than the volume of traffic they carry.
Two new detections ship in Guardsix NDR 2.33, both medium severity.
Find systems exposing sensitive login data. Some servers still check staff usernames and passwords over the network without encrypting them, so anyone watching that segment can simply read them. Guardsix NDR now flags those unencrypted directory logins, which usually turn out to be a legacy system or a misconfiguration nobody knew was there.
Catch files being gathered before they are stolen. An attacker who has taken over one workstation rarely sends files straight out of the building. They copy large volumes onto a single machine first, then move everything in one go. Guardsix NDR now flags an internal computer transferring an unusually large file, or an unusual total volume, to another internal computer over Windows file sharing. That is the gathering step, and it happens before anything leaves.
Both appear in the product as medium severity detections:
Cleartext protocol LDAP flags LDAP binds sent unencrypted over TCP port 389, excluding sessions upgraded through StartTLS. LDAP is the directory protocol most Windows estates use to check staff credentials, and an unencrypted bind exposes both those credentials and directory metadata to anything else on the segment.
SMB internal data staging flags an internal host transferring an unusually large file, or an unusually large aggregate volume, to another internal host over SMB. SMB is the Windows file-sharing protocol, and internal-to-internal transfers at that scale are the pattern used to stage data before exfiltration.
Each one states its condition: a protocol, a port, an exclusion, a direction of travel. An analyst can reason about that, tune it against the estate, and map it to an ATT&CK technique. That is markedly different from the way typical behavioural scores work. They arrive with a number attached and a model behind it that nobody other than the vendor can interrogate. The first question of the investigation becomes why the alert fired, rather than what the attacker did next.
A single detection rarely tells the whole story on its own. Each one is a link in a chain that runs through your logs as well as your traffic.
When someone tries thousands of passwords against an account, the number of attempts in the alert signifies how serious it is. That number also ends up in the incident record and the audit trail behind it.
Guardsix NDR counts only the login attempts it can confirm in the network traffic itself. Traffic it cannot tie to a real attempt does not add to the total. This applies to NTLM, an older Windows login method still in wide use across most estates.
The reason it matters is what a wrong number costs. A count that overstates the activity sends a small team chasing noise for an entire afternoon. After a few months of repeatedly doing that, it teaches them to ignore the alert whenever it appears. Tuning cannot fix either outcome.
The same principle runs through all Guardsix releases. A detection is only as useful as the evidence an analyst can stand behind when they act on it.
Guardsix NDR sensors run as virtual machines, on the same software that hosts the rest of your virtual machines. Version 2.33 adds Nutanix AHV to the existing VMware and KVM options, configured so the sensor receives a full copy of the network traffic passing through it.
In practice, that means an organisation standardised on Nutanix no longer needs separate hardware or a second platform to get network monitoring. The sensor goes on the infrastructure your team already runs and already knows how to support.
That matters more than one more box on a compatibility sheet. Each sensor also works on its own. If the connection between two of your sites goes down, the sensors at both sites carry on monitoring their own segments and keep their evidence. Nothing goes blind waiting for a central system to come back.
A satellite-style design that leans on a master node for coverage creates a single point-of-failure where a network disruption takes visibility down with it. A standalone sensor keeps watching its segment through that disruption, because it never needed the master node to do its job in the first place.
Put the two together and the result is consistent: coverage that scales with your hypervisors, on infrastructure that keeps working even when a link between sites does not.
Coverage that lands on the right hypervisor still needs a licence before it does any work. In earlier releases, that step required manual coordination before a new sensor could go live.
A new License tab in Admin Settings brings that step inside the product. An organisation admin submits a licence request through a guided form. Approval stays with higher-privileged roles, so the person who can ask is not always the person who can grant. Once approved, licence transactions, storage, and issuance run end to end in the background, and every step leaves a record in the audit trail.
For a single site, that shortens a task. For a multi-site rollout or an MSSP bringing tenants online one after another, it changes the workflow entirely. Someone junior can raise the request; someone senior approves it from wherever they are; a sensor goes live without a ticket sitting in a queue between them.
The cost story lines up with it. A sensor you licence is a sensor you decided to deploy, at a cost that scales with the infrastructure you run rather than the traffic it happens to see. Deployment and rollout stay a partner's own operation, run at a partner's own pace, on terms a partner can plan around a quarter ahead.
This release just one part of a bigger picture. Knowing where your NDR sensor lives, who can see inside it, and who decides what it costs to run is as important as the capabilities it enables.
Guardsix NDR runs on infrastructure you control, under European jurisdiction, rather than routing traffic analysis through a hyperscaler cloud. Cost tracks the sensors and infrastructure you deploy, not the volume of traffic they happen to carry in a given quarter, so a spike in activity does not become a spike in the bill. And the roadmap keeps investing in on-prem and hybrid deployment, at a moment when several major vendors have moved theirs to the cloud instead.
That is not the right answer for everyone. An organisation already committed to a single hyperscaler, with the budget to absorb licensing that scales with data volume, has a reasonable case for staying there. Guardsix NDR is built for the lean team that needs coverage across a converged IT and OT estate, on infrastructure it runs and a budget it can plan a year ahead.
Version 2.33 is available now. If your estate runs on Nutanix, the new deployment path is worth consideration on its own. If cleartext LDAP or internal data staging are gaps in your current coverage, the two new detections close them without waiting for a broader upgrade.
See how Guardsix NDR fits alongside your SIEM, or book a demo to walk through a converged estate with your own segments in mind.