Threat Intelligence Platform: Where a Feed Ends and a Case Begins

Threat intelligence platforms are subscribed to. Investigations are opened, worked and closed. That structural difference decides which one answers the question in front of you, and buying the wrong shape is expensive in a way that only becomes obvious at renewal.

This page is written for a security leader who already has a feed, or is being asked why one is not enough.

See pricing

Scope recorded before collection.
Passive collection only.
Evidence a reviewer can re-run.
Built to clear procurement.

Two products, two questions, one procurement cycle.

Both are legitimate. Neither substitutes for the other, and a trial that does not test the shape will not reveal the mismatch.

	Threat intelligence platform	Investigation platform
The question	What is happening out there that could affect us?	What is true about this specific entity, and can I prove it?
Unit of work	An indicator, a campaign, an actor, a feed	A scoped case about a named subject
Time model	Continuous stream	Point in time, timestamped, re-runnable for a diff
Primary output	Detections, blocklists, analyst reporting	A dossier a decision maker acts on
Who consumes it	SOC, detection engineering, CTI	Risk, legal, procurement, corp dev, investigations
Integration surface	SIEM, SOAR, TIP, firewall	The case file, the vendor record, the deal room
Commercial anchor	Commonly $50k or more a year, annual contract	Per seat, mid-market, from $149 a month

The question

Threat intelligence platform: What is happening out there that could affect us?
Investigation platform: What is true about this specific entity, and can I prove it?

Unit of work

Threat intelligence platform: An indicator, a campaign, an actor, a feed
Investigation platform: A scoped case about a named subject

Time model

Threat intelligence platform: Continuous stream
Investigation platform: Point in time, timestamped, re-runnable for a diff

Primary output

Threat intelligence platform: Detections, blocklists, analyst reporting
Investigation platform: A dossier a decision maker acts on

Who consumes it

Threat intelligence platform: SOC, detection engineering, CTI
Investigation platform: Risk, legal, procurement, corp dev, investigations

Integration surface

Threat intelligence platform: SIEM, SOAR, TIP, firewall
Investigation platform: The case file, the vendor record, the deal room

Commercial anchor

Threat intelligence platform: Commonly $50k or more a year, annual contract
Investigation platform: Per seat, mid-market, from $149 a month

The gap a feed cannot close.

A feed is optimized for coverage across the whole internet. That optimization is exactly what makes it a poor fit for a named-entity question, because the answer to "tell me about this one company" is not a subset of a global stream. It is a collection you have to go and perform.

Three requests surface this gap in almost every security organization:

"Procurement wants a security view on this vendor by Thursday."

The feed can tell you whether the vendor has been in the news. It cannot produce a per-vendor artifact with the collection dated and the scope recorded, which is what the vendor file actually needs. The team goes back to browser tabs and a spreadsheet.

"Corp dev is buying this company. What are we inheriting?"

Registration age, hosting concentration, mail posture, certificate surface, all cited and dated. This is a case, and it has a deadline set by a deal timetable rather than by a threat.

"Somebody is phishing our brand. What exists out there?"

The feed found the campaign. Enumerating lookalike registrations of your own brand, with the registration evidence attached in a form a registrar complaint can use, is entity work.

None of that is a criticism of the feed. It is the wrong shape for the request, and no amount of feed quality fixes it.

How the two work together in a mature team.

Step 1

The feed finds the weather

Global visibility tells you a campaign is targeting your sector, or that a technology in your stack is under active exploitation. This is what a threat intelligence platform is excellent at and you should keep it.
Step 2

The case asks the entity question

Which lookalikes of our brand exist, who registered them and when, where does their mail point, and what does the registration record say. Scoped, passive, and dated.
Step 3

The findings come back sourced

Each with the raw record, the endpoint and the UTC retrieval time, which is what makes a registrar complaint or a UDRP filing go somewhere rather than stall.
Step 4

The artifact and the indicators split

The document goes to legal and to the brand team. The indicators go back into detection. Two outputs, one collection, and neither team is waiting on the other.

Run the entity question and see the artifact.

Declare the scope, pick the modules, run a domain you are authorized to assess. What comes back is the shape of the case output: severity, claim, raw record, source endpoint, UTC retrieval time.

It runs in your browser. Queries go to public DNS and RDAP endpoints, not through us.
Nothing reaches the subject. The domain you enter is never contacted, probed or scanned.
A domain, never a person. There is no input on this panel that accepts an individual.
Findings carry their evidence. Raw record, source endpoint and the UTC moment of retrieval.

Domain footprint sweep

passive collection only

1. Declare the scope stamped on the report

I am authorized to assess this domain, and I am collecting only from public sources.

2. Subject domain

Samples:

Every finding will carry four things

1 Severity. What the record means for the decision in front of you.
2 The raw record. Exactly as the source returned it, unedited.
3 The source endpoint. The request that produced it, so it can be re-run.
4 The UTC retrieval time. Records change. Without this it is an assertion.

Reads dns.google and rdap.org from your browser. Nothing is sent to the domain you enter.

Tick the authorization box, then run the sweep. Enter the domain you are authorized to assess, then run the sweep. Run the sweep. The report lands here.

What a security procurement review asks for.

These are the line items that decide whether a tool clears review, and their absence is the usual reason an analyst tool never gets bought. They are listed here rather than hidden behind a call.

SSO and SAML

Okta, Entra ID or any SAML 2.0 provider

SCIM provisioning

Joiners and leavers handled by your directory

Roles and permissions

Who may open a case, who may sign one off

Audit log

Every case, every export, every scope declaration

Data residency

Choose where case data is stored

SLA

Written availability and support commitments

DPA

Signed data processing agreement

Invoicing and PO

Annual invoice, purchase order, net terms

If you can only fund one this year.

Fund the shape that matches the decisions you are actually asked to make.

If your week is detection and response, the feed pays for itself and an investigation tool will sit unused. If your week is filled with "should we sign this", "what are we buying", "is this counterparty real", the case tool pays for itself in write-up time alone and the feed will not touch that work.

Read the split at more length in OSINT versus threat intelligence, or look at attack surface management if the estate rather than the counterparty is the pressing question.

More for security and risk teams

New to the category? Start with open source intelligence, then see how a scoped case runs or read the analyst notes on the blog.

Run one scoped sweep and see what a sourced finding looks like.

The demo is free, it takes a domain and never a person, and it produces the same evidence chain the paid report does.

See how a case runs

Passive collection only, from public sources.
A domain, never a person. There is no input for one.
Your case data stays yours. No card required.