A managed threat intelligence provider should be able to tell you, this week, which of your internet-facing assets carries the vulnerability they just alerted on, which employee's credentials are sitting in a stealer log that is still live, and what has been done about the lookalike domain registered against your brand on Tuesday. Plenty of services charge a retainer and deliver none of that. They deliver a dashboard, a feed and a monthly PDF counting alerts.

This article is written as an accountability standard rather than a category explainer. If you already pay for a service, use it to audit what you are getting. If you are buying, use it to write your questions.

What managed threat intelligence actually buys you (and what it does not)

The honest definition: external specialists collecting, analysing and prioritising threat data about your organisation specifically, then telling you what to do about it. Not a licence to somebody else's indicator feed with your logo on the login page.

There is a real difference between tactical data and researched intelligence. Tactical data is indicators of compromise, CVE notifications, malicious IP lists and hashes. Useful, cheap, and largely commoditised. Researched intelligence is a human analyst establishing that your finance director's personal email appears in a fresh infostealer dump, that a Telegram channel is advertising access to a UK organisation matching your sector and headcount, or that a subdomain nobody on your IT team claims is running an unpatched content management system.

Where it sits next to MDR, SOC and EASM

Managed detection and response watches your endpoints and logs for activity inside the estate. A SOC, internal or outsourced, triages those detections. External attack surface management maps what the internet can see of you. Managed threat intelligence should sit across the outside view, telling you what adversaries are discussing, trading and preparing, and tying it back to named assets and named people.

Buyers confuse these constantly and end up paying twice for the same indicator feed, once inside the MDR contract and once in the intelligence retainer, while nobody owns the external footprint at all. Draw the boundaries on paper before you sign anything.

The question that exposes a reseller

Ask which findings in the last month were produced by a human analyst, and ask to see two of them. A provider with a genuine in-house research team will walk you through the source, the reasoning and the recommendation. A reseller will show you a filtered feed and talk about machine learning. The gap becomes obvious inside five minutes.

Deliverable one: intelligence tied to a mapped external attack surface

An alert about a critical vulnerability means nothing until somebody can tell you which of your public-facing hosts runs the affected software. A provider that reports the CVE and stops there has handed you homework, not intelligence. Your team then spends two days establishing whether it applies, which is exactly the work you outsourced.

So the mapping comes first. Domains, subdomains, IP ranges, cloud services, APIs, exposed admin interfaces, certificates, mail infrastructure. The valuable part is what turns up outside the asset register: the staging subdomain from a marketing campaign three years ago that still resolves, still runs an old CMS, and appears on no internal CMDB because the agency that built it was paid and offboarded. Shadow IT and forgotten infrastructure are where incidents start, and internal inventories fall behind faster than most teams expect.

Three things to hold the provider to here:

  • Change detection with a short clock. A new exposure should surface in days, with an alert, not appear in a quarterly review deck.
  • Risk prioritisation that reflects context. An exposed login portal on an unmanaged host outranks a missing security header on the careers page, every time.
  • Dual scanning with deduplication. Infrastructure scanning and web application scanning cover different ground, and running them separately produces the same underlying issue twice under two different names. Teams lose credibility when a Jira board fills with repeats. Ask how findings are deduplicated and whether fixed items auto-resolve. That matters more to your workload than raw detection volume.

Deliverable two: dark web and Telegram coverage you can verify

Every provider claims dark web monitoring. Few will show you what sits behind the claim.

Credible coverage means crawled marketplace and forum content, a maintained leaked-credential database, and, above all, stealer log analysis rather than raw dumps dropped into a portal. Infostealer output is where providers either prove themselves or embarrass themselves. Raw collections are stuffed with years-old passwords, recycled breach data and duplicates of duplicates. The number of credentials found is a vanity metric. The questions that matter are whether the credential is current, whether it is tied to an active identity in your directory, and whether it opens something you actually expose to the internet. If you are working through a dump now, our 48-hour stealer log triage approach sets out the sequence.

Telegram moves faster than the forums

A large share of activity that once lived on closed forums now runs through Telegram: ransomware leak announcements, combolist sharing, initial access brokering, hacktivist coordination. Channels appear, get reported, migrate and reappear under new names within days. Automated collection alone captures text and misses meaning. A human analyst reading the chatter is what connects a dumped credential to a named employee and a live asset, and what recognises when an access advert describes your infrastructure without naming you.

The timing advantage is real. A ransomware group will often post a victim countdown to its channel hours before the entry appears on its leak site. If that victim is one of your suppliers, those hours let you check your integrations, rotate shared credentials and brief your service desk. An indicator feed would never have told you. How these channels are structured and policed explains why coverage needs constant re-acquisition rather than a static source list.

The verification test

For any dark web or Telegram finding, the provider should be able to state the source type, the channel or marketplace, the date of collection, the date the data appears to originate from, and whether the credential has been validated as still live. No provenance, no finding. Apply that rule and a surprising volume of reported exposure disappears, which is the point.

Deliverable three: people, executives and suppliers, not just servers

Infrastructure exposure is scored by severity. People exposure is not, and treating them the same produces bad decisions. An executive's reused personal credential sitting in a current stealer log, or a guarded profile appearing in a combolist, can carry more practical risk than a medium-severity finding on a marketing microsite. One leads to a convincing business email compromise attempt; the other leads to a ticket.

A serious service should give you dedicated executive and VIP profiles, classification of identities as internal or external, per-person risk scoring, and monitoring of personal as well as corporate identifiers where the individual consents. Social media and employee intelligence belongs here too, because a LinkedIn update announcing a new finance hire is a phishing pretext within the week. Our field guide to executive monitoring goes further into how those profiles are built and maintained.

Suppliers deserve the same continuous treatment. Annual questionnaires measure a moment. If a supplier lets its ISO 27001 certification lapse in March and your review cycle lands in November, nothing in your process notices for eight months. Continuous supplier threat scoring and accreditation tracking closes that window, and it gives procurement something defensible when a contract renewal is contested.

Deliverable four: action, not just alerting

Detection without takedown capability leaves you worse off, because now you know and still cannot fix it.

Start with DNS surveillance: newly registered lookalike domains, available permutations of your brand that an attacker could register, certificate issuance against unfamiliar names, mail records configured on domains you do not own. Catching a spoof domain while it is parked, before a login clone goes live, is the cheapest intervention available. The five signals that separate a genuine spoof from noise are worth reading before you judge a provider's alerts.

Then ask the provider to describe the takedown process step by step rather than quoting a success rate. You want to hear about evidence collection, the abuse routes they use with registrars, hosts and platforms, how they escalate when the first request is ignored, who chases, and how a case is tracked to closure. Relationships and persistence do this work. Percentages on a slide do not.

Finally, look at how findings reach the people who fix them. Related risks grouped into a project with an owner and a finish line beat a flat list of alerts. Integration into Slack, Microsoft Teams, Jira, your SIEM or your ticketing tool, plus API access so your own tooling can pull findings, decides whether intelligence turns into remediation or into an inbox folder.

Deliverable five: reporting leadership will actually read

Three reporting layers earn their place: a weekly summary of what changed, a management report that explains posture in business terms, and VIP reports for named individuals. On screen, as a PDF, or scheduled by email to the people who need them. If a provider can only produce a monthly count of alerts raised, you are paying for an activity log.

Translation is the skill. A board wants to know which exposures could stop trading, cost money or trigger a notifiable incident. An insurer wants evidence of continuous monitoring and remediation discipline. Procurement wants supplier assurance that is more current than a questionnaire. The same finding should be expressible in all three registers.

Keep the evidence trail in mind as regulation tightens. UK GDPR requires notification to the ICO within 72 hours of becoming aware of a reportable personal data breach, and being able to show when exposure was detected and what was done matters at that moment. Organisations with EU operations sit under NIS 2, which member states were required to transpose by 17 October 2024. The UK's Cyber Security and Resilience Bill, progressing through Parliament at the time of writing, points in the same direction on supplier oversight and incident reporting. Ask any managed threat intelligence provider how their reporting supports those obligations, and whether you can export the underlying data rather than only the PDF.

How to choose and hold a managed threat intelligence provider to account

Questions to ask on the call

  • How many analysts do you employ, and will we have a named one?
  • Walk us through a takedown you handled last quarter, start to finish.
  • Which source types do you cover directly, and which do you buy in?
  • How are false positives handled, and who closes them?
  • How long until we see our first mapped attack surface, not our first alert?

Contract terms worth negotiating

Named analyst access and a response route for urgent questions. Report cadence written down rather than assumed. A defined escalation path for critical findings outside working hours. API access and full data export rights, so your findings leave with you if the relationship ends. Clarity on whether takedowns are included or billed per case.

Red flags

No external asset mapping. No takedown capability. Reporting built around volume rather than change. Findings with no named source or date. An inability to say what a human looked at last month. Any of those on their own is a conversation; two together is a reseller.

A reasonable 30, 60 and 90 day expectation

In the first 30 days, expect discovery and a mapped external footprint, including assets your team did not know about, plus an initial exposure baseline and the first credential findings. By 60 days, scanning should be running across infrastructure and web applications with duplicates collapsed, executive and supplier profiles should be live, and alerting should flow into your own tooling. By 90 days, you should be judging change rather than backlog: new exposure detected and closed, takedowns completed, a board-ready report you did not have to rewrite.

Most organisations do not have a complete view of their external attack surface, which is precisely why intelligence has to be anchored to one. If you want to see what your own footprint looks like from the attacker's side before committing to any retainer, start with the DarkInvader platform and work outwards from what it finds.

Frequently Asked Questions

What does a managed threat intelligence provider actually do?

A managed threat intelligence provider collects, analyses and prioritises threat data about your organisation specifically, then tells you what action to take. That covers mapping your internet-facing assets, monitoring dark web marketplaces and Telegram channels for leaked credentials and brand abuse, tracking executive and supplier exposure, running takedowns, and reporting findings in a form your leadership can act on.

How is managed threat intelligence different from MDR or a SOC?

MDR and a SOC focus inward, detecting and responding to activity on your endpoints, networks and logs. Managed threat intelligence looks outward at what attackers can see, discuss and trade about you before any intrusion happens. The two are complementary, and the common buying mistake is paying for the same indicator feed inside both contracts while nobody owns the external footprint.

Should threat intelligence be linked to external attack surface management?

Yes, and this is the dividing line between useful and unusable. A vulnerability alert is only actionable once the provider can name which of your public-facing hosts is affected, including shadow IT and forgotten infrastructure that never reached your CMDB. Intelligence that floats free of your asset inventory becomes work for your team rather than work taken off them.

How do you check whether dark web and Telegram findings are genuine?

Ask for provenance on every finding: the source type, the channel or marketplace, the collection date, the apparent origin date of the data, and whether the credential has been validated as still live. Recycled breach data and years-old passwords are common in raw stealer log dumps. A provider that cannot evidence those five points is reporting noise.

What should a managed threat intelligence service deliver in the first 90 days?

Expect a mapped external attack surface and an exposure baseline within the first month, scanning with deduplicated findings and live executive and supplier profiles by around 60 days, and demonstrable change by 90 days: exposures closed, takedowns completed and reporting that reaches the board without being rewritten. If the service is still producing unprioritised alert lists at the three-month mark, raise it in the review.