The questions I get on every evaluation call, answered the way I'd want them answered.

No. The External Scan Engine is CybrIQ software you run on a small Linux or Windows server in your environment. The External Scan Engine (ESE) polls the customer's managed switches in read-only mode. No service account on endpoints, no certificate trust, no traffic injection, no SPAN, no mirror, no inline anything. The handoff is one-way: your ESE sends signed records to your control plane (cloud, on-prem, or air-gapped, your call).

The first thing most network teams ask after I describe this is "wait, you're not running anything on our endpoints, and you're not sniffing traffic?" Correct on both. The ESE talks to switches over the management plane and reads what the switch already knows.

No. The whole point of the switch-derived approach is that you don't have to touch the device. Codecs, controllers, biomed equipment, OT, BYOD, IoT, anything that can't run an agent (or that won't tolerate one without a vendor support escalation) is still seen.

When agent-based asset tools land in procurement alongside CybrIQ, the agent project usually stalls because the device-owning teams won't allow software on their gear. The ESE keeps running through that whole conversation; the politics don't reach it.

One, and it's narrow. The inventory and Device DNA path is entirely switch-derived; no agent is involved. There is an optional small agent for USB-threat detection that runs on Windows and Linux workstations. It catches Rubber Ducky, Flipper Zero, O.MG cables, BadUSB-class HID-spoofers, and rogue USB mass-storage plugged into a corporate endpoint. That class of attack rides a switch port that already has a legitimate workstation on it, so it's invisible to the switch-side view. The agent fills that one gap.

It's opt-in per host and typically scoped to the high-risk groups (privileged users, executive workstations, R&D, finance) rather than the whole fleet. The full detection writeup is on the Detection page.

A small Linux or Windows server for the ESE software (lightweight; the 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). That's the list.

Typical install in a new environment: 30 minutes once the management credentials and connectivity are in place. The longest part of the install is usually waiting for the network team to approve the read-only role.

Yes. Records stay on the ESE; the dashboard runs locally; nothing crosses the air gap unless your operator physically carries it across. The ESE still reaches its in-scope switches over the management plane, which is internal-network reachability, not internet reachability. Software updates ship signed and offline. We work with several federal customers who run this mode; if you're in that profile, plan an extra week for the operations briefing.

Customer's choice across three options. Cloud control plane with US, EU, or APAC tenant. On-prem in your environment. Air-gapped ESE-local. Data residency stays in customer control across all three modes. CybrIQ staff never have access to your Layer 1 records. That's not a policy, it's a deployment property: there's no path from our office to your records that doesn't require you to grant it.

The ESE polls switches across the major enterprise platforms:

• 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 and we'll come back with a clean yes/no plus timing if it's on the roadmap.

As long as you want them, bounded only by storage. The platform doesn't enforce a fixed retention window; the default-deployed window matches the customer's audit and forensics requirements, and the customer chooses how far back history persists. For air-gapped and on-prem deployments, the customer manages the storage directly; for cloud-tenant deployments, retention is part of the tenant configuration.

The practical effect is that the inventory and drift-event history are usable for multi-year forensics if you size the storage that way, and they shrink back to the audit window if you'd rather keep the footprint small.

Inside one polling cycle, end to end. The ESE polls each switch every 30 seconds by default; a device change on a port surfaces in the next poll and propagates to your SIEM in near-real-time. End-to-end from physical swap to NAC quarantine, the typical number is sub-minute.

The phrase I usually use on calls is "before the attacker is done plugging the device in." If your threat model includes someone walking up to a wall jack with a packet-injection device, sub-minute detection is the difference between "we caught it" and "we didn't."

About one event per 100 ports per week at default thresholds in a stable production environment. Higher in lab and dev environments where things genuinely change all the time. Tunable per VLAN tag, so the lab VLANs don't drown out the production noise floor.

The number that matters more than the raw FP rate is the false-positive ratio after change-management correlation. With a SOAR playbook that auto-checks for matching change tickets, the rate I've watched customers achieve is roughly one true investigation per port per quarter. That's a number a SOC can actually act on.

At least 99% of intentional swap-tests fire device-substituted within one validation cycle, at the default similarity threshold of 0.65. The 1% that doesn't fire is almost always the test where the new device is the same model with a fresh firmware version, where similarity legitimately reads above the substitution threshold. That's the case our customers want it to behave that way.

In theory, yes, by an attacker who can engineer a device whose switch-derived signal set matches the legitimate device's so closely that the reference-database lookup resolves to the same identity. In practice this is a research-grade attack. It requires hardware fabrication plus intimate knowledge of how the legitimate device presents to the switch.

What you're really asking is "how does this compare to spoofing higher-layer claims?" Several orders of magnitude harder. MAC addresses, DHCP fingerprints, and TLS attributes can all be impersonated in software with public tools. The Device DNA can't be.

The similarity score also surfaces near-matches as low-confidence signals, so a partially successful spoof shows up as anomalous rather than a clean pass.

No. The detection path is deterministic. Device DNA is a SHA-256 of the switch-derived signal set combined with the reference-database identity record. Similarity is Jaccard distance over the signal set. No model, no training data, no LLM anywhere in the decision path.

This isn't an anti-AI stance; it's a property of the problem space. The signals are stable enough that you don't need a model to recognize them; you can hash them and look them up. The full argument is on the AI threats page, including why this happens to be the right answer for adversarial-ML resistance.

Firmware updates land in the 0.85 to 0.95 similarity range, below the substitution threshold but well above the noise floor. They're logged as device-firmware-shift events and don't fire P1 alerts. MAC randomization is handled by tagging the VLAN as randomization-tolerant, which suppresses the false signal from guest networks. The threshold and the per-VLAN behavior are both tunable; see validation for the operational detail.

Twice a week. The reference database receives a curated update on a regular cadence; new device fingerprints land after human review and are pushed to all tenants as part of the standard release flow.

Mark the device through the dashboard's vendor-hint dispute flow. The dispute lands in the engineering queue for the reference-database team; a confirmed mismatch produces a curated database update in the next semi-weekly cycle. The disputed device gets a confidence-score override in your tenant in the meantime so it stops generating noise.

If the dispute reveals a pattern (a vendor whose new firmware drifted enough to change its switch-side presentation, an OEM that quietly relabeled a model), the fix lands for every tenant. Disputes are anonymized before they reach the database team.

Splunk, Microsoft Sentinel, Google Chronicle, Elastic, IBM QRadar, all via syslog (RFC 5424). For pull-style integration, the REST API surfaces the same data for SIEMs and other tools that prefer to query. Pre-built integration templates are on integrations; the syslog and API reference are on Syslog & API. We do not ship webhooks or STIX/TAXII feeds.

Yes. Splunk SOAR, Cortex XSOAR, Tines, Sentinel Logic Apps, n8n. The event payload includes structured fields (severity, similarity, MITRE techniques, framework controls, change-window status) that drive automated branches. The on-call playbook has the field reference; the SOAR action endpoints are in the API reference.

Two-way. CybrIQ consumes 802.1X session data from Cisco ISE (or your NAC of choice) for context enrichment. The NAC consumes CybrIQ events to trigger quarantine on substitution or topology change. The end-to-end loop is sub-minute. We're not the enforcement tool; we're the detection that drives your enforcement tool.

Roughly half an event per port per week at default thresholds in stable production. Most are routine: a port goes empty, a device appears on a new install. Drift events that actually require a human look are 1 to 5 per 100 ports per week, before SOAR correlation. After change-management correlation, the human-attention number drops by another order of magnitude.

Yes, for the inventory-and-identity-drift controls. The evidence pack is pre-mapped to the asset-management and detection controls across PCI 4.0 (12.5.1), SOC 2 Type II (CC7.1, CC7.2), HIPAA Security Rule (164.308 inventory), NIST 800-171 (3.4.1 inventories half), CMMC L2 (CM.L2-3.4.1 inventories half, SI.L2-3.14.6), and NIST CSF 2.0 (ID.AM, DE.CM). Each export is signed at the control plane with a SHA-256 hash. Configuration-baseline and config-settings-enforcement controls (e.g., PCI 11.5.1 file integrity, CM.L2-3.4.2) are out of scope and need complementary FIM and config-management tooling.

The acceptance test I quote is from a customer audit cycle I sat through: the auditor opened the dashboard during the walk-through, ran their own query against a control she cared about, and exported the PDF herself. She kept the PDF. She didn't ask for anything else. That's the bar we built to.

Unauthorized device plug-in. Device substitution (the swap attack). Unauthorized switch insertion. NDAA Section 889 prohibited components. Firmware tampering surfaced through L1 marker shift. BYOD on a production VLAN. The full list with MITRE technique mapping is on the Detection page.

The honest list. Application-layer attacks (use a WAF). Endpoint malware (EDR). Phishing (SEG). Encrypted-traffic exfiltration (NDR). Identity attacks (IAM and the SaaS-side controls). Cloud and SaaS misconfiguration (CSPM). Insider threats acting through legitimate credentials and legitimate hardware.

CybrIQ is one specific tool in your stack, not a replacement for any of the above. If a vendor on your evaluation list is claiming single-product coverage across that list, run away. The full scope is on the threat model page.

The ESE runs as CybrIQ software inside your normal server-hardening envelope. Whatever physical-security and host-integrity baseline you already apply to security-relevant servers (locked rack, host-based IDS, integrity monitoring, signed-software-only policy) applies here. The ESE binary is signed; the reproducible-build path lets you verify the running version's SHA matches the one in our artifact registry. If the ESE goes offline, the control plane logs the loss within 60 seconds and fires a critical alert. A compromised ESE host can't be silent for long.

The ESE buffers DNA records locally for up to 14 days. On reconnect, the backlog ships at full rate. Detection is delayed during the outage but events are not lost. The customer I think of for this question is the one whose WAN went down for nine days during a hurricane; their backlog re-shipped cleanly when the link came back.

RoomIQ is per-room, recurring. SpacesIQ is per-deployment, recurring, sized by total port count. Pilot has no fee. Specific pricing is scope-dependent and lives in the working-session conversation. We don't publish a per-port number because the right answer depends on environment size and the integration shape; the conversation takes 15 minutes once we have the inputs.

No fee. No procurement-process commitment to keep talking after. You supply the small server the ESE software runs on, grant read-only switch-management access, and at the end of 30 days we hand over the inventory, the drift report, and the framework-mapped evidence pack as deliverables. You keep them whether you buy or not.

The reason this is the pilot shape: the deliverables have standalone value for you even if we never see each other again. That's the bar I want a pilot to clear before I ask a security team to spend a quarter evaluating us.

Yes, continuous controls. Report available under MNDA. Audit firm and reporting period available on request.

Coordinated disclosure at cybriq.io/security/disclosure. PGP-signed advisories. SLA: acknowledgment within 24 business hours, status update within 5 business days, public disclosure coordinated with patch availability. We've never had to invoke the process publicly, which means the SLA is theoretical for now, but the runbook is real.

For the install and physical-operations path, yes. The integrator stands up the ESE on the small server and configures the read-only management access to the in-scope switches. For the data and policy, no, the security team owns that. CybrIQ never has physical or network access; the integrator does the install but the data and the decisions stay with you. This split confuses procurement on the first call and then makes sense by the second.