From physical wire to SIEM event in eight steps. Here's what each one actually does.

Stand up the ESE on a small on-prem server

The External Scan Engine is CybrIQ software you run on a small Linux or Windows server in your environment. Lightweight enough that the server spec isn't a planning concern. The ESE needs read-only management access to the switches it should reach (one ESE handles up to 500 switches), and an outbound mTLS path to the control plane (or no outbound at all in air-gapped mode).

No SPAN, no mirror, no inline insertion, no traffic injection. The inventory path doesn't require any endpoint agent (separate USB-threat agent is described in step 8). In a new environment, the longest part of the install is usually waiting for the network team to grant the read-only management credentials. The install itself is 30 minutes.

• A small Linux or Windows server to host the ESE software (lightweight; specific hardware spec isn't a planning concern)
• Read-only management access from the ESE to the switches in scope (one ESE handles up to 500 switches)
• Outbound mTLS to the control plane (or air-gapped, no outbound required)

• No endpoint agent for inventory or Device DNA (the switch-derived signal set is enough). Separate USB-threat agent is optional, workstation-only, and described separately.
• No SPAN port, no mirror port, no inline tap (the ESE doesn't read traffic)
• No network access for CybrIQ staff (the customer or partner installs and operates)
• No certificate trust, no AD/identity integration, no service account beyond switch-management read-only

Typical install: 30 minutes once credentials and connectivity land. First Device DNA records arrive within minutes of the ESE starting up.

Arista · Aruba · Cisco · HP · Huawei · Juniper · Meraki · Rockwell Automation · Ruijie Networks. If your environment includes a switch family not on this list, send the model and platform version through the working-session form for a clean yes/no.

The ESE polls each managed switch on a continuous cycle

The ESE reads a structured signal set per device from each switch in scope, on an ongoing cycle. The specific signals collected are proprietary; the architectural shape is what your evaluation needs.

• Switch-derived. Read from the managed switches themselves, not from packet capture or any wire-tap. No SPAN, no mirror, nothing inline.
• Structured and bounded. A fixed schema per device, sized so the database lookup in the next step is unambiguous.
• Cross-vendor. Works across the major enterprise switch vendors. The collection abstracts vendor differences.
• Continuous. Each switch is polled every 30 seconds by default (tunable). Device change on a port surfaces in the next poll, not on a nightly batch.
• Read-only. Nothing the ESE does modifies switch state or alters traffic. Worst-case behavior is "stops polling"; blast radius is "we go blind on that switch," not "we caused an outage."

Per-ESE capacity is 500 switches. Larger environments scale horizontally by adding ESE instances; the control plane aggregates the records.

Resolve the signal set to a device identity via the 750M-device reference database

Each cycle, the collected signal set gets matched against CybrIQ's reference database of 750 million-plus device fingerprints. The match resolves the device's identity (vendor, model, NDAA status, firmware lineage). The signal set is hashed; the matched identity is hashed; the pair gets combined into the final Device DNA. Deterministic end-to-end: same signals plus same database snapshot produce the same signature, every time.

signal_hash    = sha256(canonical_serialize(collected_signals))
identity_hash  = sha256(canonical_serialize(database_lookup(collected_signals)))

device_dna     = "dna:" + base32(sha256(signal_hash || identity_hash))[:16]

An auditor will accept "the signature is the SHA of these five observations." An auditor will not accept "the model thought it looked like a Crestron." That difference is why the signature is a hash and not an ML output. The side effect is that the detection path has no AI-attack surface; the AI threats page goes deeper on why that turned out to matter more than we expected when we designed it this way.

Persist per-port, per-device inventory

Every signature gets associated with the port it was observed on and persisted. Per-port history is retained for whatever window you configure (default 90 days, longer on request). This is the surface the audit team queries against; it's also the surface a forensics investigator goes to when they're asking "what was actually plugged in here on Tuesday at 2pm?"

{
  "port":        "sw-bldg-3-fl-2/port-47",
  "device_dna":  "dna:7a4f-1c91-...",
  "first_seen":  "2026-02-12T14:08:33Z",
  "last_seen":   "2026-05-10T17:01:00Z",
  "vendor_hint": "Crestron DM-MD8x8 · confidence 0.92",
  "signals":     { /* the collected signal set */ },
  "controls":    ["PCI-4.0/12.5.1", "SOC2/CC6.1"]
}

Cloud control plane (US/EU/APAC tenant, your choice), on-prem (customer-hosted control plane), or air-gapped (records stay on the ESE). Customer-controlled data residency in all three modes. CybrIQ staff never have access to customer records.

Compare each new signature to the prior, continuously

Every 30 seconds (per switch, tunable), the platform re-derives the signature from the freshest signal set and compares it to the prior signature for that port. The comparison produces a similarity score via Jaccard distance over the signal set. This is the loop that catches a swap in near-real-time.

Thresholds are configurable per environment. Most customers run defaults.

When drift crosses a threshold, emit a structured event

When the similarity score crosses a threshold, or when topology, vendor-hint, or device-class indicators change, the platform emits a typed event. Each event carries the timestamp, the port, the prior and current signatures, the similarity score, MITRE ATT&CK technique IDs, and the framework-control tags the affected port satisfies. The shape of this payload is what your SIEM and SOAR will live with, so I've tried to make it the same shape my own playbooks would want.

device-appeared · device-departed · device-substituted · port-topology-changed · device-firmware-shift · ndaa-prohibited-detected · device-class-mismatch · device-silent-extended · unenrolled-flagged · vendor-hint-confidence-changed · port-orphaned · compliance-control-drift

{
  "event":        "device-substituted",
  "timestamp":    "2026-05-10T17:08:12Z",
  "port":         "sw-bldg-3-fl-2/port-47",
  "previous_dna": "dna:7a4f-1c91-…",
  "current_dna":  "dna:5b8e-2a4f-…",
  "similarity":   0.31,
  "mitre":        ["T1200", "T1556"],
  "controls":     ["PCI-4.0/12.5.1", "SOC2/CC6.1"]
}

Approved change-management tickets inside the lookback window auto-suppress. Lab and dev VLANs can have severity downgraded so they don't drown out production. Whitelisted DNA shifts (known firmware updates, MAC randomization on guest VLANs) are recognized as legitimate. The suppression logic exists because alert fatigue kills SOC tools. Losing an occasional alert is a better failure mode than losing the team's attention.

Ship the event to your SIEM and the rest of your stack

The event ships through the configured channel inside one second of emission. The platform supports four output paths in parallel; pick whichever ones fit the way your pipeline is already wired. You're not going to redesign your SIEM for this product, so the goal is to land cleanly in what you already have.

• Syslog (RFC 5424). TCP+TLS recommended; UDP and plain TCP also supported. Carries every event as it happens. The push surface for SIEM ingest.
• REST API. Cursor-paginated GET endpoints for events, inventory, devices, drift history, and compliance evidence. The pull surface for SIEMs, SOAR, and any tool that prefers to query.

Splunk SPL templates, Sentinel KQL queries, Chronicle UDM parsers, Elastic ingest pipelines, ServiceNow workflow blueprints. See integrations.

Query the inventory and export evidence on demand

The output isn't just events. The full inventory is queryable through the REST API or the web dashboard at any time. For audit cycles, the platform produces a pre-mapped evidence pack tied to the framework controls each device satisfies. The combination of "queryable now" and "evidence pack on demand" is what collapses an audit prep that used to take six weeks into a 30-second download.

• Current state, every port with its current Device DNA, vendor hint, last-seen, confidence
• Per-port history, every DNA observed on a given port over the retention window
• Drift event stream, every event by type, MITRE technique, control, severity, time
• Framework evidence, per-framework, per-control export (PCI 4.0 12.5.1, SOC 2 CC6.1, HIPAA 164.312(b), etc.)

Auditor asks for inventory for a specific control → security team queries GET /api/v1/evidence/{framework}/{control} → exports the device-row record with timestamps, observations, and signature history → auditor reviews. No reconstruction project required.