Frequently asked questions

DENIS (Device Enumeration & Network Inventory Security) is self-hosted network visibility and security monitoring for small businesses and industrial networks. It runs on a machine you control, finds the devices on the networks it can see, keeps an asset inventory current, learns what is normal for each device and tells you in plain words when something changes. When you choose, it can also contain a device through the switches and firewalls you already own. A free Community edition is available for personal, non-commercial use on up to 100 devices.

No. DENIS is built for organisations that have no such platform and little security staff: it gives practical visibility, detection and investigation in one self-hosted program. It does not collect logs like a SIEM, does not look inside computers like an EDR, does not authenticate devices with 802.1X like a NAC server and has not been run on live traffic at an industrial site yet. It can feed a SIEM and work next to the tools you have.

No. No product makes an organisation NIS2 compliant. NIS2 asks for cybersecurity risk-management measures, incident handling and reporting, which are organisational duties. DENIS can contribute evidence and capabilities to some of them, such as an inventory of networked devices, network monitoring and support for investigating incidents. See the NIS2 page for what it contributes and what it does not.

Devices and their traffic: which devices are present (from ARP, DHCP, mDNS, SSDP, LLDP/CDP, PROFINET and optional active discovery), what they are, which addresses and ports they use, how much data they move, when they are active, and, on industrial networks, which devices read from, write to or send control commands to controllers.

No. DENIS is an out-of-band network visibility and monitoring layer. It does not collect logs from other systems. It can send its own alerts, findings and audit events to a SIEM (CEF, LEEF or JSON over syslog, or ECS documents to Elasticsearch/OpenSearch). It is also not an EDR, a firewall, an inline blocking appliance or a vulnerability scanner.

DENIS provides NDR-style detection; it is not a full enterprise NDR platform. Detection is the core: passive network monitoring, device fingerprinting, per-device baselines and explainable, scored alerts when behaviour changes. The response half is optional and off by default: an administrator can block a device or a connection, quarantine a device, switch a port off or end its sessions through equipment you already own, and can choose to let marked policies (and, separately, Autopilot) act by themselves. Automation and Autopilot are experimental. By default DENIS notifies your team and exports to a SIEM or ticketing system, so a person (or another tool) decides.

DENIS provides NAC-style response; it is not a full NAC product. DENIS controls access by asking equipment you already own to act: a switch (disable the port or move it to a quarantine VLAN you built), a firewall or router (an address group or list that your own rule uses, or one deny rule), a controller or a cloud platform. It does not authenticate devices with 802.1X and does not replace your RADIUS or policy server. Every action is shown in full before it runs, needs an administrator, has a time limit and a release, and goes through one path with a kill switch and an hourly limit. Verified with Cisco Catalyst switches, Palo Alto PAN-OS, FortiGate FortiOS, MikroTik RouterOS and UniFi OS; the other integrations are experimental. Setup guides are in the documentation.

Yes. Every device that appears on the network is discovered and placed in a review queue, whether or not anyone told DENIS about it in advance. Rogue DHCP servers, ARP/gateway hijacks and devices sending unexpected traffic are flagged as specific alert types, not just lumped in as "new device".

No. DENIS observes the network, so nothing is installed on the devices it monitors. For multiple sites you can run a DENIS collector (denis agent) at each remote site, which reports to one central console. That is one collector per network, not software on endpoints. An agent installs with one command (install.sh --agent, prepared by the Add agent dialog on the Sites page, or Docker) and can be updated from the console.

By default, DENIS combines passive listening with polite active discovery on ordinary IT devices: an ARP sweep, ping and a light scan of 73 common ports. --passive-only turns all active probing off, and the OT profile is listen-only. Since 4.2 the port scan and the ping can also be switched off on their own, for all networks or for one monitored network (Settings > Capture), and a documentation page lists exactly what DENIS sends, so you can allow it in an intrusion detection or endpoint product that reports it as a port scan. Devices identified as industrial are never pinged or port-scanned in any mode, and you can exclude any address range from probing.

Yes. For OT/ICS security, DENIS passively decodes Modbus/TCP, S7comm, S7comm-plus, EtherNet/IP-CIP, DNP3, BACnet/IP, OPC UA, IEC 60870-5-104, IEC 61850 (MMS and ICCP, GOOSE, Sampled Values), PROFINET IO, Omron FINS, MQTT and CoAP, identifies HART-IP, KNXnet/IP and CODESYS, and builds a communications matrix of reads, writes and control commands. It needs a mirror/SPAN port or network tap. The decoders are checked against real captures of each protocol. DENIS has not yet been run against live traffic on a real industrial network, so plan a representative trial period.

No, it does not decrypt anything. For encrypted traffic it still sees who talks to whom, on which port, how much, and when. For TLS handshakes it records the TLS version, the requested server name (SNI) and JA3/JA3S fingerprints.

In one SQLite database file on the machine where you run DENIS. There is no DENIS cloud service. The database as a whole is not encrypted at rest, so protect it with file permissions and disk encryption. Integration credentials and, since 4.2, the secrets of authenticator apps are stored sealed inside it, with a key kept in a separate file.

No. DENIS has no telemetry and no usage reporting: nothing tells anyone how you use it. A default installation makes five kinds of outbound request on its own, and each can be switched off. Four carry nothing about your network: the update check (one request to GitHub every six hours; with automatic security updates on, also the release list and the download of an eligible release), a fallback to usedenis.com that is used only when GitHub cannot be reached, is on by default and sees your address and the version asked for, a monthly GeoIP database download, and weekly end-of-support and known-exploited vulnerability data. The fifth, reverse-DNS lookups of public addresses, goes to a configurable resolver (1.1.1.1 by default) and includes the address being looked up; you can switch it off or use your own resolver. Since 4.2 a signed security update of the same minor line is installed automatically unless you switch that off. Anything else, such as notifications, exports or an AI provider, is only contacted if you configure it.

Yes. DENIS is a single binary that runs on your own Linux server or Mac. The console is served by DENIS itself, over HTTPS by default.

Pre-built releases exist for Linux (x86-64 and ARM64) and macOS (Intel and Apple silicon), and a Docker image is published as ghcr.io/stefanmesaros/denis. Since 4.1.1 each release also has a static Linux build (x86-64 and ARM64) with everything built in, which runs on Alpine Linux and on systems without the usual packet capture library (libpcap). The Linux installer sets DENIS up as a systemd service (Ubuntu, Debian, Raspberry Pi OS, RHEL-family and others) or as an OpenRC service on Alpine, and --no-service installs it without a service for your own supervisor. OpenRC has so far been tried in a container, not on a booted Alpine machine. There is no Windows release yet. A packaged Windows collector is on the roadmap.

Through passive device fingerprinting. The manufacturer comes from the IEEE OUI registry built into DENIS. Device type and operating system come from weighted evidence: DHCP request fingerprints, mDNS and SSDP announcements, LLDP/CDP, TCP/IP stack characteristics, open ports and names. Product and version come from service banners where a service reveals them. Each device shows the rules behind its classification, and a manual correction always takes precedence.

After a learning period (24 hours by default), DENIS compares each device with its own baseline: destinations, ports, traffic volume and active hours. It also runs rules for events such as new devices, rogue DHCP servers, ARP conflicts, internal scans and contact with known-bad addresses. Each alert gets a 0–100 score built from named reasons, and related alerts are grouped into incidents. Detection is rule-based. AI is not involved.

Yes. Each release is published as an image, ghcr.io/stefanmesaros/denis, and the repository includes a Docker Compose file with a demo service, a monitoring service and a remote agent. See the Docker guide. Monitoring a real network from a container needs host networking and two Linux capabilities. Real packet capture from inside a container has not yet been verified.

Yes. denis demo --db demo.db load followed by denis serve --db demo.db --insecure-no-auth loads a fictional company and serves the console on this machine only, without capturing any traffic. You can also run a packet capture file through DENIS with denis replay.

Response and access control through Cisco Catalyst switches, Palo Alto PAN-OS, FortiGate FortiOS, MikroTik RouterOS and UniFi OS (the next question gives the versions). Experimental connectors: D-Link switches, OPNsense, SonicWall, Check Point, Juniper SRX, WatchGuard, Cisco ASA, Cisco Secure Firewall (FTD), Cisco Meraki, RADIUS Disconnect and CoA, VMware NSX-T, AWS, Azure, Hyper-V and Proxmox VE. Notifications to Slack, Microsoft Teams, Discord, PagerDuty, Pushover, ntfy, e-mail, Jira, ServiceNow and signed webhooks. Export to SIEMs (syslog CEF/LEEF/JSON), Elasticsearch/OpenSearch, OpenObserve and Prometheus, plus a REST API. Read-only context import from Microsoft Entra ID, Intune, Active Directory, Jamf Pro, Azure, AWS, Google Cloud and Nessus/Tenable.io. Sign-in with OpenID Connect, passkeys and authenticator apps.

Optionally. With your own API key for Claude, ChatGPT, Gemini or Grok, or a local OpenAI-compatible model (such as Ollama), DENIS can explain and triage alerts, summarise the dashboard and reports, draft rules and answer questions through "Ask DENIS". Every AI feature is off by default, and AI is never part of detection.

DENIS Community is free for personal, non-commercial use on a single installation monitoring up to 100 devices, and is distributed as signed, pre-built binaries under the DENIS Community License. An organisation may use the Community edition free for 30 days from its first installation, on up to 100 devices, to evaluate and demonstrate DENIS; it is evaluation only, not for running the organisation’s operations. After that, and for any other use by or for a business, non-profit or other organisation, a separate commercial license from the author is needed; licenses are issued individually and there is no self-service purchase. Commercial licenses come in the tiers DENIS 500, DENIS 5000 and DENIS 20000, by the number of devices counted; above 20,000 devices a license is arranged individually. A device counts while it has been seen in the last 30 days, and the list is cut to the licensed number only past the cap: detection, alerting and protection never stop. Every license can also act as an MSP license: there is no separate MSP edition. DENIS is not sold yet: licenses are issued individually and there is no self-service purchase. DENIS does not count the 30 days or switch itself off. See the license for the exact terms.

Yes. Under clause 2A of the license an organisation may use the Community edition free of charge for 30 days, counted from the first installation by or for that organisation, on up to 100 devices, to evaluate and demonstrate it. Installing again on another machine does not start a new period. After the 30 days, stop using DENIS or get a commercial license. The built-in demo, which captures nothing, can be run at any time.

On a Linux server, download and run the installer from the latest GitHub release. It verifies the signature, sets up a systemd service (or an OpenRC service on Alpine) and prints the address and a one-time admin password. On any supported machine you can also download the binary and run denis run. See the Quick start.

Yes, if you switch it on. Traffic between two of your own devices (a laptop and the file server, an HMI and a PLC) is not recorded by default, because it shows internal behaviour. Turn on east-west recording under Settings → Network interfaces (it needs traffic accounting with --flows or a mirror port), and DENIS keeps which device talked to which, over which protocol and port, first and last seen, and whether it saw who opened the connection or only guessed from the ports. Each alert then has an Investigate section showing the device’s other events around that time, what was recorded between the device and the other party, and which other devices contacted that same party. The API answers “what does this device talk to” and “who has contacted this address”. Nothing alerts on east-west traffic by itself yet.

“Top exposures today”, on the Dashboard and on each device’s panel, lists only devices with at least one serious standing fact: a known-exploited vulnerability (CISA KEV), a critical or high scanner result, unsupported software, an open incident or another high-severity finding. They are ranked with fixed, documented points plus what is at stake on the device (an industrial controller, a device rated critical), and every point is listed with where it came from. It is an ordering, not a black-box score, and it does not yet consider whether an attacker could reach the device.

DENIS keeps an asset register — owners, locations, serial numbers, warranties, criticality — so it covers IT asset management for what it can see on the network. It is not a full CMDB (it does not track software licenses, contracts or assets with no network presence), but it can cross-reference a CMDB/MDM you already have (Entra ID, Intune, Active Directory, Jamf, Azure, AWS, GCP) and show that context on each device.

DENIS surfaces findings — known-exploited vulnerabilities (CISA KEV) with an EPSS score, and end-of-support software — matched against what a device’s banner actually reveals, plus CVEs from an imported Nessus/Tenable.io scan. It is not a vulnerability scanner itself and does not probe for vulnerabilities; it is read-only context for prioritising attack-surface reduction, with an Accept this risk / Check again workflow.

Yes. A one-click, 10-20 second test measures packet loss, jitter and latency over two legs at once — your browser’s connection to DENIS, and DENIS’s own connection to your gateway or the internet — and rates the result separately for browsing, a video call, and 1080p/4K streaming. It also checks whether DENIS’s own recent network activity overlapped the test and made things measurably worse, had no effect, or was not running at all, so you get evidence instead of a guess.

Yes. A single installation can host several tenants, each with its own database, detector, users, branding, settings and audit log — nothing of one tenant is reachable from another. Managed service providers get technician accounts that work across customers without a separate login in each one, and a customer’s data can be exported or imported as a standalone file. A plain installation with no tenant added behaves exactly as before. Since 4.1, an MSP can also open a customer’s own DENIS installation from its console: the customer pairs, chooses what the MSP may do, sees a banner while it is in use and can disconnect with one click, and every MSP operator needs a second factor.

Verified with Cisco Catalyst switches, Palo Alto PAN-OS, FortiGate FortiOS, MikroTik RouterOS, UniFi OS and the TP-Link Omada controller: Cisco IOS 15.2(7)E4, PAN-OS 10.1.14-h9, FortiOS 7.2.3, RouterOS 7.21.4, UniFi Network 10.6.106 and Omada Controller 5.15. Also verified, in test environments and not on real equipment: the Cisco Secure Firewall FDM and FMC block, in the Cisco DevNet sandbox on virtual devices (29 October 2026), and AWS security groups, in a lab AWS account (3 November 2026). The other integrations in the list are experimental: they are built and tested, and we would be glad if you tried them and reported any problems. Verifying hardware takes a long time and we cannot own every device, so your reports help us improve DENIS. Step-by-step setup guides are in the documentation.

Yes, when an administrator switches it on. Enforcement is off by default. DENIS can block a device or one connection, quarantine a device, switch a switch port off or end its sessions through the switches, firewalls, controllers and cloud platforms you already own. Every action is shown in full before it runs, needs the administrator’s password, goes through one path with a kill switch and an hourly limit, and can be released. By default a person decides every action. Letting policies you mark block by themselves, and letting Autopilot block, are separate switches, experimental and off by default; their actions are always time-limited, and automation never acts on DENIS itself, the gateway or industrial devices. Since 4.2 the Respond menu shows where the device is, offers a switch port or a firewall only when DENIS is sure it is on the device’s path, and says why an action is unavailable. Through Palo Alto a block uses a dynamic address group, so it takes effect in seconds without a commit, and UniFi is reached with an API key and a firewall policy. Verified with Cisco Catalyst switches, Palo Alto PAN-OS, FortiGate FortiOS, MikroTik RouterOS and UniFi OS. The other integrations are experimental and need two lab switches before they act.

Ask DENIS can draft a change — a new detection rule, an exception for a noisy device, or a parameter edit on an existing rule — from a plain-language follow-up to its own analysis, such as “add an exception for that”. It never applies anything by itself: an administrator always reviews the exact change and applies it with one click. When asked to do something it cannot (such as blocking a device, which only an administrator can do through the enforcement dialog), it says so plainly instead of answering a different question.

Yes. Group devices into zones — by subnet, device type, tag, or by hand — and write policies on top: explicit allow-lists, and a default for whether traffic may cross a zone boundary at all. DENIS judges every flow it already sees against your policies and raises an alert when one crosses without permission. A zone × zone matrix shows what has actually been checked, and says plainly when it has not (such as traffic recording being off for a site) instead of showing a false all-clear. A new policy starts in a quiet, record-only mode until you switch it on, and "freeze this device’s behaviour" turns a device’s own observed traffic into a ready-to-review starting policy that is only saved once you confirm it.

Yes. The Coverage page compares your devices with what your directory, device-management, vulnerability-scanning and endpoint-protection tools report. For each device it says whether it is managed, scanned or protected, and it says "no match" or "not managed" separately: a device DENIS could not find in a tool is not the same as a device that is genuinely unmanaged. Coverage is tracked over time against goals you set, so you can see whether it is improving.

An alert is one detection. An incident groups related alerts into one thing to look at, with a priority. A finding is a standing problem to fix, such as an outdated service or a missing owner. Each has the same clear lifecycle: acknowledge, resolve or reopen, with every decision written to a log. Acknowledging or resolving an incident also updates the alerts that belong to it, and each change is written to the log. An incident never changes a finding on its own; a finding is tracked to a fix separately, with an owner and a due date.

Optionally. In a PostgreSQL-backed deployment, two DENIS nodes share one PostgreSQL database, and the standing node is tracked with a database lock; if it goes down, the other takes over automatically. Experimental in 4.4, tested on PostgreSQL 16 in containers and in a local fault lab, not yet on a managed service. A write fence refuses writes from an old leader. A data key per tenant. Tenants on PostgreSQL are Experimental until measured. A standard single-node installation uses SQLite and has no second node to fail over to.

Each account picks its own language, which follows that person to any device they sign into. Each browser separately picks a look — Triage (the default), Scope or Clipboard, each available in light or dark — independent of who is signed in.

Yes. The Devices table has its own 0–100 risk score column, built from exposure, device type and unacknowledged alerts, so you can sort or scan the whole inventory by risk without opening each device. Acknowledging a device’s alerts lowers it; every device panel lists the reasons behind its own score.

Autopilot (experimental, off by default) reads the alerts DENIS raises, sorts them into the few that need attention now and the many that can wait, explains each in plain language and asks one specific question at a time, in the console or on a phone through Telegram, ntfy or web push. It starts in shadow mode, where it only records what it would have done. By default it blocks nothing; letting it block is a separate, highly experimental switch with its own conditions and limits. It can miss real threats. Not yet verified: a shadow week on a real network, real phone round trips and an external review.

Yes, with traffic accounting on (--flows). When an address on the internet completes a connection to one of your devices, for example a solar inverter or a camera behind a port forward, DENIS raises one alert with the source, its country and network when known, the port and service, and whether other devices were reached. A port can be marked as expected for a device.

4.2 is about acting on the right thing, and about trust. The Respond menu knows where a device is and which firewall is on its path, and every plan says exactly what it covers. A router or firewall seen under several hardware addresses is one device, and DENIS says why. The network map and a new Equipment page show the cables between switches, firewalls and access points, each marked confirmed, best guess or set by hand. A notification bell lists what you should know, and messages name the device. You can block through UniFi and, without a commit, through Palo Alto. Your own rules can prepare a block for you to approve, or block by themselves after a 7-day trial (experimental). The port scan and the ping can be switched off, for all networks or for one. Security updates install automatically unless you switch that off. Authenticator-app secrets are stored sealed. The release process attaches software bills of materials, and the documentation has an architecture guide, an API reference and a Cyber Resilience Act readiness document. The full list is in the changelog.

4.4 is about where a device is plugged in, rules of your own, and running without losing messages. DENIS shows what a device hangs on (access points and switches under their controller, virtual machines under their host), and has new connectors for TP-Link Omada, MikroTik Wi-Fi and the Cisco Catalyst 9800 wireless controller; TP-Link Omada has since been tried on a real controller and is no longer Experimental (4.4.2), the other two are Experimental. One Respond dialog names the few responses that can work for a device. The same address in two routing domains is no longer taken for one network. Twelve new detections arrive switched off; rules can run in a trial mode and expire, and you can write your own rules and try them first. An MSP can send you rules, and you decide what happens to them. Alerts go through a durable queue, every customer has its own data key that can be rotated, and two servers on one PostgreSQL database and customers in PostgreSQL are Experimental, tested in containers and a local fault lab, not on a managed service. AWS security groups were verified in a lab account. Back up the database and the file secrets.key before you update: the first start of 4.4 changes how stored passwords and keys are kept, and 4.3 cannot read it.

4.3 is about seeing more and trusting what you see. A new Network section has a map with zoom, search, groups and cable drawing, and Equipment, Response and Setup pages. More than 40 new detections cover industrial networks (program uploads, several masters, a changed device identity, commands outside working hours and more) and office networks (brute force from outside, DNS threat domains, mining pools, VPN and remote-access tools, a rogue DHCPv6 server and more). A page shows what DENIS cannot see, duplicate packets from SPAN or TAP copies can be counted or removed, a Not managed view lists unmanaged devices, each device has a timeline, and any alert can be marked This is normal. Any managed switch with standard SNMP can be read; port actions on such switches are Experimental and tested only on simulators. API tokens have scopes and expiry, and site administrators manage only their sites. UniFi and Meraki can show their clients on the map (Meraki Experimental). The new PostgreSQL code of 4.3 has not yet been run against a live PostgreSQL database. The full list is in the changelog.

Since 4.2 each rule has a response setting: only notify (the default), prepare a block for an administrator to approve with one click, or block automatically. Automatic blocking is experimental and off by default. A rule set to block starts with a trial of at least 7 days in which it only records what it would have done, and after that it acts under the same safety checks, time limits and hourly limit as every other action. It never acts on DENIS itself, the gateway or industrial devices.

That is expected: to find devices and their open services DENIS sends an ARP sweep, a ping and a light TCP scan, which an intrusion detection or endpoint product can read as reconnaissance. The documentation page “Security tools that may flag DENIS” lists exactly what is sent and when, and how to allow the DENIS server for that detection only. Since 4.2 you can also switch the port scan and the ping off, for all networks or for one, in Settings > Capture. Devices identified as industrial are never scanned or pinged.

Since 4.2, for new installations, yes by default and with an opt-out: a signed, stable release of the minor line you run is installed automatically, with the same signature and checksum checks, a backup and automatic rollback as a manual update, and never while an enforcement action is running. New minor or major versions wait for an administrator. One setting in Settings > System switches it off, and the console then shows a standing advisory. An installation that existed before 4.2 keeps its behaviour and is asked once.

DENIS is developed in the European Union (Slovakia) and is designed to align with the requirements of the EU Cyber Resilience Act. It is being prepared for conformity assessment. It is not yet assessed, certified or CE marked, and DENIS makes no claim of compliance. Already in place: signed releases, software bills of materials (CycloneDX and SPDX) attached to releases by the release process, a daily check of dependencies for known vulnerabilities, a published vulnerability disclosure policy and contact, an audit log, a secure update mechanism with automatic security updates on by default for new installations, five years of security support per major version, and security fixes that are always free. Still to come: an independent penetration test and the formal conformity assessment before DENIS is sold.