Meet CybrIQ at InfoComm 2026 · Booth C5052 · June 13–19 · Las Vegas · Pre-book a working session →
Article · Claim Discipline

Real-time threat detection is a marketing phrase.

Every security platform claims it. Most of them mean "we have a streaming detection engine that ingests events with sub-second latency and emits alerts to a SIEM." Some of them mean it. None of them are quite what the buyer thinks they are getting. CybrIQ does not claim real-time threat detection. This is the article that explains why.

By the CybrIQ team · 6 minute read

What the phrase actually means inside vendor marketing.

"Real-time threat detection" lives in the headline because it is what buyers are scanning for. Underneath the headline, the same vendors are usually doing one of three things: streaming events from a sensor pipeline into a SIEM (which is event delivery, not detection); running ML classifiers over those events to label some of them as suspicious (which is inference at speed, not response); or orchestrating a SOAR playbook off a triggered alert (which is response, but not necessarily fast and not the vendor's classifier doing the deciding). Each of these is useful. None of them is what the phrase suggests, which is a system that watches and stops bad things from happening.

The difference between identity detection and threat detection.

CybrIQ identifies devices. A new device appears on a port; CybrIQ surfaces the new device with a fingerprint and a timestamp. A device's fingerprint shifts unexpectedly; CybrIQ surfaces a substitution event. A previously-known port develops an extra hop; CybrIQ surfaces a topology change. None of those events is a threat by itself. They are inputs to a threat decision that the security team and the rest of the security stack make.

The distinction matters because the threat decision depends on context CybrIQ does not have. The new device on the radiology VLAN might be a scheduled vendor service-engineer laptop or the first stage of a breach. The substituted device on Gi1/0/14 might be a firmware update or a physical swap. The topology change might be IT installing a small switch the change-management ticket forgot, or an attacker bridging an unauthorized BYOD device onto a corporate VLAN. CybrIQ surfaces the change with enough fidelity that the decision can be made; CybrIQ does not make the decision.

What CybrIQ does, in present tense.

Polls managed switches every 30 seconds. Resolves observed devices against a 750-million-device reference database. Emits identity events via syslog and REST. Logs changes with timestamped switchport context. That is the whole feature surface.

What CybrIQ does not do.

Triage. Correlation across data sources. SOAR orchestration. EDR-style endpoint isolation. NDR-style traffic analysis. Threat intelligence overlays. Risk scoring beyond the deterministic device-identity confidence value. Each of these is a real capability that someone in the customer's stack does, and several vendors do them well; the CybrIQ output feeds those vendors, not replaces them.

Why the narrow claim is defensible under audit.

An assessor's first job is to validate that the product does what the customer's program says it does. The narrower the claim, the easier the validation. "CybrIQ identifies devices on the network at switch-derived signal sets, emits identity events, and feeds the change record into our audit-controls evidence" is a methodology paragraph an assessor can verify in an afternoon. The vendor-marketing-copy version, by contrast — "Our continuous-evidence platform provides AI-driven real-time threat detection across the enterprise attack surface" — is a paragraph that requires a Master's-level conversation about every term in it.

The latter style of marketing copy creates audit liability the customer carries forever. The former does not. The customer is who pays the price for vendor language that overpromises; the vendor is who gets the deal, and then leaves.

Where the threat decision actually lives.

It lives in your SIEM, your NDR, your EDR, your XDR, your SOAR runbook, and the human analyst on call. CybrIQ provides the identity input the rest of that stack needs to make better decisions. The order is: identity first, threat second, response third. Skipping the identity step is why so many SOC alerts arrive without enough context to act on. CybrIQ supplies the missing first step.

The honest scope of what CybrIQ does is at cybriq.io/technology and the integration shape (syslog, REST, the existing tools that consume the identity feed) is at cybriq.io/integrations. If you want to see how the narrow claim survives a compare-page treatment against vendors with broader claims, the comparisons are at cybriq.io/compare.