Threat detection
Deep inspection of live traffic, with proprietary rules mapped to MITRE ATT&CK.
Defensio Sensor
passive network sensor for agentless, continuous network monitoring
An appliance that sits beside your network, sees a copy of the traffic and turns the inside of your infrastructure into something you can actually watch. No agents on endpoints, no added latency, nothing in the path of production traffic.
What it is. Defensio Sensor is the on-premise component of the Defensio ecosystem. It runs real-time threat detection on network traffic, internal and external vulnerability assessment, attack surface management, port and service mapping, network share discovery and unauthorised SMB access checks, traffic flow analysis and credential leak monitoring. It observes a mirrored copy of the traffic, so it is safe to deploy alongside industrial OT and SCADA systems, and it satisfies the continuous monitoring obligations of NIS2.
Sixteen analysis engines in one appliance
Specialised engines run in parallel inside a single appliance and update themselves. None of them needs software installed on your endpoints.
Vulnerability assessment
Priority follows the exploits actually circulating, not the theoretical severity score.
Deception
Decoy services that imitate the real ones: any single touch is a near-certain alert.
Network inventory
Every device that appears on the network gets recorded, including the uninventoried ones.
Devices and applications
Device type, make and model; the applications in use identified by name.
Shares and passwords
Reachable shares and weak credentials: the routes ransomware genuinely takes.
Post-access checks
Deeper enumeration of shares and domain settings once authentication has happened.
Web application testing
OWASP Top 10 categories against internal and internet-facing web applications.
Digital identity
Company credentials surfacing in breach databases, with early warning before use.
Attack surface
Subdomains, DNS configuration and certificates: the perimeter as outsiders see it.
Data transfers
Outbound transfers and unauthorised remote access tools, watched continuously.
Image and container CVEs
The application layer that conventional network scanning does not reach at all.
Software bill of materials
What each installed component actually contains, dependency by dependency.
Exposed secrets
Credentials and keys left behind in repositories and on file systems.
Cloud posture
Configuration audit against the recognised benchmarks for cloud environments.
Reporting
Executive, technical and compliance reports, built on real data and included.
How much it covers
Capability is something you describe; coverage is something you count. These are measured on the appliance, not estimated, and they grow on their own as content updates land.
224,000+
active checks — the total of what the Sensor verifies across your estate.
115,000+
detection rules applied to network traffic as it happens.
95,000+
vulnerability tests against systems and the services they expose.
12,900+
targeted templates — the fast answer when a new flaw is published.
640+
cloud posture checks against the recognised configuration benchmarks.
900,000+
known vulnerabilities in the reference database used for supply chain work.
The count includes network scanning scripts, web application rules and post-access verification modules. Of the known vulnerabilities in that database, more than 1,600 are recorded as actively exploited — those are the ones that weigh most in prioritisation.
What it actually sees on the network
Applications by name, through encrypted traffic
Knowing that a device “speaks HTTPS on 443” helps nobody. The Sensor resolves encrypted traffic into real application names — video, social, cloud storage, software updates, remote access tools — from data it already captures, without adding a single probe. Across a day, roughly 90% of encrypted connections are attributed to a named application, against a catalogue of more than 6,000 signatures covering over 200 applications. The rest stays honestly marked as unknown: modern traffic is designed to hide its destination, and anyone promising 100% is not measuring.
Who is on the network, without asking them
Every device that appears is recorded without agents and without being interrogated: addresses, manufacturer, exposed services, habitual behaviour. Recognition reaches device type, make and model — printer, camera, PLC, phone, company laptop — derived only from signals already present in the traffic. Sending no packet to the device means no risk to a PLC on a production line. Each client has its own record and its own timeline: when it appeared, what it contacted, how it normally behaves. This is the inventory NIS2 requires and that most networks either lack or last updated two years ago.
From findings to the list you act on
A scan that returns three thousand “critical” items is not a result — it is another way of not knowing where to start. Every finding is enriched with the institutional catalogue of actively exploited vulnerabilities and with the observed probability of exploitation, then cross-checked against what that device really is and how exposed it is. “Critical on paper” is one thing; a flaw with an exploit circulating today, on a reachable service, is another. Web applications are tested by two independent engines and the results deduplicated, so the same issue is never counted twice. For every newly published vulnerability we develop the test that detects it in house.
The routes that actually lead to a ransom
A ransom does not arrive through an exotic exploit. It arrives through a share open to everyone, a weak password reused somewhere, a remote access tool someone installed and nobody removed. That is exactly what the Sensor looks for. It finds exposed shares and genuinely verifies how solid the credentials are, with a controlled test that is safe against account lockout: one password at a time across all users, never all the passwords against one user, so no account is ever locked. It recognises unauthorised remote access tools and watches outbound data transfers — the moment a compromise becomes a breach you have to notify.
The software supply chain
Vulnerabilities do not live only in operating systems. They live inside the images and containers modern applications are assembled from — a layer conventional network scanning does not reach at all. The Sensor runs a scheduled daily scan across images and containers, produces the software bill of materials — what each component actually contains — and looks for credentials and secrets exposed in repositories and on file systems, which is the fastest route an attacker takes from outside to inside. For cloud environments, posture auditing against the recognised benchmarks is added on top.
We apply it to ourselves first. The platform analyses its own images by the same standard it applies to yours.
An appliance that looks after itself
A sensor that needs somebody sitting in front of the machine is not a product, it is a commitment. The Sensor runs as real server software with no graphical desktop: the engines are supervised system services, they restart on their own, and nobody can stop them by closing a window. Disks are encrypted at rest, and if the machine restarts overnight it stays down and safe until the volumes are unlocked. An operator sees the state and the logs of every engine from a browser, from anywhere, without console access. Detection content updates itself without maintenance windows and without interrupting traffic capture.
How it connects, and how you run it
Connecting it
The Sensor is deployed as a dedicated appliance — physical or virtual — inside your network, connected through a SPAN port, a passive TAP or a mirror port on the core switch. It adds no latency. Traffic is analysed as a copy: nothing is inline, and production traffic is never touched. Within the first 48 hours the picture usually already includes unknown devices, open shares, forgotten services and traffic nobody was watching.
You always have access to your own instance
Fidem handles configuration and platform administration, but you have direct, independent access to your instance — the same full platform, not a reduced view: dashboards, live alerts, asset inventory, scan and assessment results, traffic flows, reports and module status. There is no black box.
Standalone
Your team runs the Sensor on its own. Fidem supplies the platform, the content updates and technical support, while triage and response stay in house. It suits an organisation with a structured IT team that wants full visibility without outsourcing alert handling.
Connected to the SOC
The Sensor becomes part of Fidem’s managed monitoring. Telemetry reaches the operations centre over an encrypted channel with per-customer isolation, where triage, escalation and incident response are handled for you. You keep complete access and visibility over your own instance throughout.
Defensio Sensor and NIS2
For organisations in scope of the directive, the Sensor covers the technical obligations of Article 21 directly.
- Continuous network monitoring — Art. 21 §2(b): ongoing detection of anomalies and incidents.
- Vulnerability management — automated assessment with scoring and a documented remediation plan for the evidence pack.
- Current asset inventory — automatic mapping of the infrastructure, the baseline the directive assumes you already have.
- Supply chain security — Art. 21 §2(d): visibility over traffic to and from suppliers connected to your network.
- OT safety — fully passive operation: no interference with industrial OT and SCADA protocols.
- Early warning through deception — decoys reveal lateral movement and internal reconnaissance before they reach real assets.
- Exfiltration and unauthorised remote access — data transfer analytics and remote tool detection surface abnormal outbound channels.
Fidem runs the full NIS2 compliance programme in Italy: NIS2 compliance with Fidem.
Common questions
Do we have to install software on our PCs and servers?
No. The Sensor observes a copy of the traffic from the mirror port: no agents, no changes to endpoints, no performance impact.
Can the Sensor block traffic or cause an outage?
No, by design. It is passive detection, never inline. It detects and reports; enforcement remains your team’s decision, or the SOC’s with guided escalation.
What does it see that our firewall does not?
Internal traffic. Lateral movement, unregistered devices, open shares, weak passwords that are genuinely exploitable, data leaving through legitimate channels. A firewall watches the boundary; the Sensor watches inside the house.
Does it work without Fidem’s SOC?
Yes. In standalone mode your team gets the complete platform and automatic updates. Connecting it to the SOC adds cross-sensor correlation, deeper analysis and managed response, and can be switched on later.
Is it safe on an industrial network?
Yes. It never sends a packet to a monitored device: everything comes from observing a mirrored copy of the traffic. That is why it can sit alongside PLCs and OT systems that do not tolerate active scanning.
Start with a look at your network
Every deployment starts with a topology review that identifies the right observation point — SPAN, TAP or mirror port — and sizes the appliance to your infrastructure.
Explore the ecosystem: All products · Defensio SOC · Defensio XT · Defensio SECaaS · Identity Shield