Using Threat Telemetry Data in Published Security Reports

Same threat, three different numbers, all three true. That's what this piece is about: security reports built on telemetry earn trust by showing their work, and most skip that step.

Telemetry is just the stream of security events a system logs while it runs: endpoint activity, network traffic, cloud metrics, identity logs, application traces. Every vendor claims to have it, but almost none of them are watching the same thing.

ESET pulls from its installed customer base. Trend Micro layers platform data with its Vision One XDR feed. Nokia blends managed-service findings with input from telecom security leads. Verizon's DBIR runs on incident response cases and contributed records from law enforcement, forensic firms, and insurers. CrowdStrike's OverWatch team hunts threats directly, tracking more than 280 named adversary groups through 2025. Five collection setups, five cameras pointed at five different corners of the same building, and the setup decides what a report can see before any analysis begins. So the first question worth asking, every time a report lands in an inbox, is simple: what machine made these numbers, and what is that machine built to miss?

Why the numbers in major reports diverge so sharply on the same threat

Take ClickFix, the social-engineering trick that gets users to paste malicious commands into their own machines. The 2026 DBIR puts it at 2.7% of browser-level detections. CrowdStrike clocked a 563% jump in ClickFix lures over roughly the same window. Microsoft named it the single most common way attackers got in, at 47% of observed intrusions. Read that again, because none of those three numbers is wrong.

Each one is an honest readout from a different instrument pointed at a different slice of the same attack surface. DBIR counts confirmed breach data pulled from incident response cases and contributed records. CrowdStrike counts what its hunters see live, inside its own customer telemetry. Microsoft counts what shows up across its own large but bounded install base. Stack them side by side and they triangulate each other. The gap is a visibility problem. A report that presents its slice as the whole pie turns it into a credibility problem. Most reports do exactly that: they present one camera's footage as the full building, and that framing is worth calling out plainly.

Dwell time tells the same story from another angle. M-Trends 2026 found a global median dwell time of 14 days, the stretch between an attacker getting in and getting caught. Narrow the lens to espionage campaigns and North Korean IT worker schemes, though, and that median jumps to 122 days. An endpoint-only telemetry feed would never catch that gap, because the attackers in question are built to look like normal remote employees, not malware.

The lesson for anyone reading three reports on the same topic: ask what each one was built to see, then read the disagreement itself as the data.

The structural biases baked into vendor telemetry before analysis begins

Product telemetry has a built-in flattery problem. It logs what got detected and blocked, so it over-counts failed attacks relative to successful ones, because antivirus dashboards record only the threats they stopped. The DBIR runs the opposite risk: it can only report incidents that contributors choose to hand over, so anything covered up, settled quietly, or undisclosed to a forensic firm is absent from the dataset.

Threat hunting has its own version of tunnel vision. Logs only capture what a device was configured to monitor in the first place, and an attacker working outside that configured scope is invisible by design. The gap is baked into the setup before the hunt even starts.

Trend Micro's 2026 report says this part out loud: its figures reflect patterns across Trend Micro's own customer base, not a statistically representative slice of any industry or region. That's an honest label on the jar, offering directional signal rather than ground truth, and readers who treat it as ground truth misread its purpose.

Then there's the volume problem. Attacks generate telemetry faster than analysts, or the machine-learning systems standing in for them, can process it. Static, heuristics-based models trained on old attack patterns tend to choke on anything genuinely new, because they were trained exclusively on prior examples. A few vendors have started borrowing NATO or Admiralty-style confidence coding, the kind used to mark intelligence as assessed versus confirmed. Most skip that step, and the gap separates a report worth trusting from one that merely sounds confident.

Coverage gaps are shrinking, unevenly. The 2026 DBIR found multi-domain System Intrusion patterns, attacks that cross multiple domains in a single campaign, in 61% of breaches, up from 53% the year before. Single-domain telemetry is running out of road.

What responsible methodology disclosure looks like in practice

The DBIR's methodology section is worth studying, not skimming past to get to the charts. It names its contributor types and describes how records were collected and validated. The 2025 edition documented its scope plainly, over 22,000 incidents and 12,000 confirmed breaches, and it names its own blind spots inside the report rather than relegating them to a footnote.

Nokia's approach earns credit for a different reason. Its hybrid model names each ingredient separately, mixing operational data, managed security findings, and direct input from telecom security leads. A reader can trace exactly which layer produces which claim.

The minimum standard for a report worth a practitioner's time is straightforward: name the data sources, specify the collection period, describe the customer base honestly, disclose coverage gaps, and separate what was assessed from what was confirmed. That last one matters more than it sounds, since a phrase like "our data suggests" carries different weight than "we observed," and vendors who conflate the two erode their credibility fastest, often inside a single paragraph.

A methodology section earns the reader's permission to believe everything that follows it. Reports that treat it as a legal disclaimer bolted on to dodge liability earn the same dismissal.

How practitioners actually read — and discard — vendor security reports

Security leaders trust their peers over vendor marketing, by a wide margin. Research from ISSA and ESG puts peer recommendations as the most trusted source of vendor information for 79% of respondents. Peer testimony ties back to a specific deployment and a measurable outcome, grounded in real experience rather than marketing materials.

CISOs report trusting industry peers at a 64% rate, and the audience walks in skeptical of vendor numbers by default. A report earns its credibility line by line, starting from the first page.

Buying committees span multiple stakeholders, and each one reads for something different. The CISO wants strategic framing. The security engineer wants technical depth, the kind with protocol names and specific TTPs. Procurement checks for compliance alignment, and the CFO wants the number translated into dollars of exposure. A report tuned to only one of those readers loses the other six before they finish the executive summary.

Practitioners spot a shallow report fast, usually within the first page. A headline statistic with no source behind it reads as an ad, while the same statistic, wrapped in a sentence explaining the collection model that produced it, reads as research. The line between those two is sharp.

And the discard threshold sits low. A technically sharp reader who catches one unsupported claim tends to write off the entire document. Reports succeed or fail whole, and pretending otherwise is wishful thinking dressed up as strategy.

The specific ways telemetry transparency lifts a report's practitioner standing

Original threat research, published with a methodology section that actually holds up, brings in inbound interest from prospects who cite the findings back in their own sales conversations. A well-built annual research report can keep generating pipeline, press mentions, and analyst attention well after the launch news cycle fades.

Transparency works as an edge because most vendor content reads identically. A report that names its own blind spots earns more trust, because practitioners assume the blind spots exist and naming them confirms the report's authors understand their instrument.

Closing the credibility gap between vendor and practitioner runs on substance: publishing reports that show a real grasp of how threat data behaves, limits included. Reports that triangulate across multiple sources demonstrate analytical maturity that readers recognize immediately. The DBIR's use of contributed data from multiple external partners is a structural argument for credibility before a single chart appears.

Consistency compounds, too. Part of the DBIR's authority comes from running a consistent methodology year over year, which lets practitioners compare this year's cohort against last year's without adjusting for a moved goalpost. The instrument holds its shape, so the readings mean something across time.

Translating telemetry responsibly into report findings that hold up

Lead with what the data actually supports, saving the flashy headline for when the data earns it. The 2026 DBIR reported that vulnerability exploitation overtook stolen credentials as the top breach entry point, at 31%. That finding lands hard precisely because it's bounded: a defined dataset, a defined time period, no hand-waving about the wider world beyond it.

Scope every claim to the instrument that produced it. Phrases like "among our customer deployments" or "across observed incidents" are the exact language that makes a finding trustworthy, because they tell the reader where the edge of the data sits.

Use more than one telemetry source when it's available, and say plainly where they agree and where they don't. The ClickFix numbers across DBIR, CrowdStrike, and Microsoft teach more sitting next to each other than any single one of them would alone.

Trend and anomaly are distinct, and reports that blur them mislead by omission. CrowdStrike's finding that average eCrime breakout time dropped to 29 minutes, a 65% jump in attacker speed compared to the year before, with the fastest observed case clocking in at 27 seconds, only means something next to that prior baseline. Present the comparison alongside the current number.

Confidence language belongs in the body of the report, visible to every reader rather than relegated to a methodology appendix. "The data suggests," "the data shows," and "assessed with high confidence" are three distinct claims, and practitioners read the gap between them as a signal of how honest the rest of the document is likely to be.

The whole job here is making the data legible to an audience that will test every sentence against what they already know. Precision applied consistently beats polish applied once, and reports built that way get cited while others get closed after page one.