Prove the device on port 47 is the same device it was, or changed legitimately. Every polling cycle.
"Continuous inventory" is easy to claim. Most tools that claim it are running a polling loop against a switch's CDP table once an hour and calling it continuous. This page is the part where I tell you what validation actually means at Layer 1, what the cycle time really is, and what the inventory looks like the day you turn it on versus 30 days in.
What validation means in this tool, specifically
Most security tools use "validation" to mean: the device's certificate verified, or 802.1X authentication succeeded, or the EDR agent checked in. Those are claims the device makes about itself. The CISO's question lands directly on the gap between "the device claims to be X" and "the device is X." We close that gap by not asking the device anything.
The validation cycle, step by step
- Observe. The External Scan Engine listens on the wire. A structured signal set per device, refreshed every polling cycle. The specific signals are proprietary; what matters architecturally is that they're switch-derived (not from packet capture), bounded (fixed schema), and resolve to a deterministic identity through the 750M+ reference database. Nothing is asked of the device; everything is read off what the device is already doing.
- Hash. The collected signals get hashed and matched against the 750M+ reference database; the pair becomes the Device DNA signature. Deterministic, reproducible, no model in the path.
- Compare. The new signature is compared against the device's prior signature on that port. Similarity is Jaccard distance over the signal set.
- Decide. Similarity above the threshold (default 0.65) means same device. Below means a substitution event fires. A small drift in the 0.85 to 0.95 range is consistent with a firmware update; logged but no page.
- Emit. The result ships to your SIEM via the configured channel (syslog or REST API). The full validation history is queryable from the dashboard.
The cycle runs every 30 seconds per switch by default (tunable). A swap detection lands within one polling cycle, sub-minute end-to-end.
Why this works at Layer 1 when it doesn't at Layer 2 and above
Every claim at Layer 2 and above is forgeable in software. A device with the right firmware can present any MAC, claim any vendor ID, pass any 802.1X handshake with the right certificate, and answer any EDR ping with the right agent ID. Those layers were designed for interoperability, not for surviving an attacker who controls the device.
Layer 1 wasn't designed for either. Switch-side signals about how a device presents on the wire are byproducts of the actual silicon and firmware running. They don't transmit upward. They don't pass through software emulation cleanly. A malicious-twin device that's been swapped in produces detectably different Layer 1 behavior even when every higher-layer claim matches.
This is a property of how Ethernet works, not a property of our product. What we built is the engineering to collect those signals from the switches, resolve them through the reference database deterministically, and run the comparison continuously without injecting anything into your network.
What "continuous" actually means here
I've sat through enough vendor demos to know that "continuous" can mean anything from "real-time" to "we run a cron job at 3am." The specific cycle times in this product are below.
| Activity | Cycle time | What that means in practice |
|---|---|---|
| Read-only switch polling | Always-on, no polling | The External Scan Engine (ESE) polls the switch management plane in read-only mode. Signal set updates land on each polling cycle. |
| Device DNA recomputation | 30 seconds (default, per switch) | The signature is re-derived from the latest signal set on every 30-second polling cycle. |
| Similarity check and event emission | Same cycle as recomputation | If the new signature reads below the substitution threshold against the prior, a device-substituted event fires within that same polling cycle. |
| SIEM delivery | Sub-second after event emission | Syslog ships in under a second. REST API endpoints return the same event the moment it's persisted. |
| Inventory API freshness | Last-seen timestamp 30s old or newer | An API query at any moment returns the inventory as of the most recent validation cycle. |
There is no "daily refresh." There is no "Monday morning batch." The inventory is the live state of the wire, exposed to you over an API and an event stream.
What "polling-cycle current" looks like when a swap actually happens
A concrete sequence. A device gets physically swapped on port 47 at 14:08:33 UTC. Here's the timeline I'd watch on a screen-share during a red-team exercise.
// T+00:00, device physically replaced (attacker action) // existing device unplugged, malicious-twin plugged in // the malicious twin presents the same MAC, same VLAN tag // every higher-layer security tool sees no change // T+00:00 to T+00:30, first validation cycle // Switch reports an updated signal set; // the database lookup resolves to a different device record. MAC matches but the rest doesn't. // T+00:30, Device DNA recomputed { "event": "device-substituted", "timestamp": "2026-05-10T14:09:03Z", "port": "sw-bldg-3-fl-2/port-47", "previous_dna": "dna:7a4f-1c91-...", "current_dna": "dna:5b8e-2a4f-...", "similarity": 0.31, "threshold": 0.65, "mitre": ["T1200", "T1556"] } // T+00:30.5 syslog ships to SIEM // T+00:31 SIEM ingest complete, correlation rule fires // T+00:32 SOAR playbook quarantines the port via the NAC API // T+00:32 Slack alert to on-call SOC analyst with full context // total time from swap to quarantine: sub-minute.
In planned red-team exercises across customer environments, the gap between physical swap and SOC analyst page lands under a minute, before the attacker has finished plugging the device in.
What you can query right now
The inventory is a queryable record. The API surface is small. Each of these returns the live state as of the most recent validation cycle. Full reference and authentication details on the API page.
GET /api/v1/inventory
Every port with a current Device DNA. Filterable by site, building, floor, port type, vendor hint, last-seen timestamp. Cursor-paginated for large fleets.
GET /api/v1/inventory/{port_id}
A single port's current device, its DNA, its similarity to previous, its vendor hint, its observation history.
GET /api/v1/inventory/{port_id}/history?since=...
Time series of every DNA observed on that port. The forensics endpoint, "what was actually plugged in here on Tuesday at 2pm?"
GET /api/v1/events?type=...&since=...
Drift event stream. Filter by event type, MITRE technique, severity, framework control, port, or time window.
GET /api/v1/evidence/{framework}/{control}
Pre-mapped evidence for a specific framework control (e.g., PCI-4.0/12.5.1, SOC2/CC6.1). The auditor's actual question, with a queryable answer.
What about the stuff that's supposed to change?
Real environments have firmware updates, MAC randomization on guest VLANs, device moves between ports, and lab and dev VLANs where churn is the steady state. The validation logic has to account for all of that, otherwise the alert volume crushes the SOC. Here's the handling per case.
| Normal change | How it looks in DNA | How CybrIQ handles it |
|---|---|---|
| Firmware update | Similarity lands in 0.85 to 0.95 (within firmware-shift tolerance) | No substitution event. device-firmware-shift logged. Cross-reference with the change ticket auto-suppresses. |
| Device moved to a different port | Same DNA appears on a new port; original port goes silent | device-departed on the old port plus device-appeared on the new one. Reported as a port-move, not a swap. |
| MAC randomization on guest VLAN | Each randomized MAC produces a distinct DNA | Tag the guest VLAN as randomization-tolerant; events suppress. Or keep it on, your policy call. |
| Approved change-management work | DNA shifts inside the change window | If the CR API is wired, events that overlap with an approved CR auto-suppress within a 24-hour lookback. |
| Lab and dev VLAN churn | Many devices appear and depart | Tag the VLAN as high-churn; severity downgrades; events still logged for audit but don't page. |
The pattern across all of these: legitimate change should not page the SOC, but the audit trail should still record that the change happened. That's what the suppression logic preserves.
How accurate is "validated"?
A reasonable security engineer asks this question in the first five minutes of every evaluation call I've been on. The numbers below come from the reference customer set; specific results depend on your environment and how you tune the thresholds.
True positive rate
At least 99% of intentional swap tests fire device-substituted within one polling cycle at the default similarity threshold of 0.65.
False positive rate
Roughly one event per 100 ports per week at default thresholds in stable production. Higher in lab and dev environments. Tunable per VLAN tag so the lab churn doesn't drown the production noise floor.
Device coverage
Anything that draws a wired link. PoE devices have a fifth marker (power) so identification is more granular for them. Wireless-only devices are out of scope; there's no wire to observe.
Vendor identification confidence
Around 78% of devices in a typical enterprise come in at or above 0.85 confidence on the vendor inference. Devices below that show as "unknown vendor" in the inventory; the signature is still validated, you just don't get a vendor label on the row.
See validation fire against your own environment.
30-day pilot, no fee. We deploy the External Scan Engine, ingest 30 days of Layer 1 observations, run validation cycles against your devices, and ship the inventory and drift report regardless of whether you go forward.
Start a pilot