What are the key advantages of Kaspersky Threat Data Feeds IP Reputation?
Feed delivery – No console, consumed by your existing systems.
Threat scoring – Each IP scored from 50 to 100.
Rich context – Category, geolocation, whois and related file hashes.
Anonymiser detection – Flags Tor nodes, proxies and VPN hosts.
Broad integration – JSON via HTTPS, or STIX via TAXII.
Important note – No protection agent, no blocking without your tools.
IP Reputation Data Feed – IP addresses of malicious and suspicious hosts.
Dynamic threat score – Value from 50 to 100, records sorted by score.
Threat categories – Spam, botnet C&C, phishing, proxy, VPN, Tor nodes.
Contextual fields – First seen, last seen, popularity, geolocation and whois.
Related file hashes – Up to ten malicious file hashes per address.
Important – No console, no agent and no blocking function included.
Kaspersky Threat Data Feeds IP Reputation is a subscription to one machine-readable indicator feed from the Kaspersky Threat Intelligence Data Feeds portfolio, documented by the vendor as IP Reputation Data Feed. It has no console and no agent, because the data is pulled by your own SIEM, next-generation firewall or threat intelligence platform, and older documentation and listings still carry the earlier vendor name Kaspersky Lab.
Prioritised blocking – Block at 75 and above, review 50 to 74.
Fewer stale entries – Addresses scoring below 50 are removed from the feed.
Faster alert triage – Context answers who and where without a second lookup.
Format flexibility – JSON for enterprises, with conversion to STIX, CSV, Snort.
Two delivery paths – HTTPS with a client certificate, or TAXII with token.
Anonymiser visibility – Separate categories for Tor nodes, proxies and VPN hosts.
The decisive question is not headcount but whether you already run a system that can ingest indicators. Without a SIEM, a next-generation firewall with external list support, or a threat intelligence platform, the feed has nowhere to go and delivers nothing.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | By sector | By sector | By sector |
| NIS 2 in the European Union | Rarely | By sector | Usually |
| Security questionnaire from large customers | Sometimes | Often | Standard |
| SIEM, NGFW or TIP already in place | ✕ | Partial | ✓ |
| This product fits | ✕ | Limited | ✓ |
The revised Information Security Act obliges operators of critical infrastructure, including energy and water utilities, transport operators, listed hospitals, data centres and cantonal and municipal administrations, to report cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery. Meeting that deadline depends on noticing the attack in the first place, and this is where an indicator feed contributes: a match on a botnet command-and-control address in firewall or proxy logs gives you a timestamp, a category and a threat score you can put straight into the initial report. The feed does not detect anything by itself, does not raise an alert, does not produce a report and does not track the 14-day window for completing an initial notification, so all of that has to come from your SIEM, your logging retention and your written incident process. It also covers only one indicator type, which means an attack that arrives by phishing attachment or a compromised credential will not appear in it at all. This is not legal advice, and you should have your own reporting obligations assessed by qualified counsel.
No product makes an organisation compliant with the NIS 2 Directive, because the directive addresses governance, risk management and processes rather than software features. NIS 2 requires measure categories including risk analysis, incident handling, business continuity, supply chain security, network and information system security, and the assessment of the effectiveness of the measures taken. This feed contributes to two of them: network and information system security, by feeding scored blocklists into perimeter controls, and incident handling, by supplying category and context data that shortens the identification step. It contributes nothing to business continuity, backup, access control, cryptography, staff training, or supplier risk management, and it produces no evidence artefact that an auditor could review. Treat it as one input into a detection capability, not as a measure in its own right.
Two official measures are relevant and both remain in force. The German Federal Office for Information Security (BSI) has warned against the use of Kaspersky antivirus software since 15 March 2022, and the BSI states explicitly that the warning covers the antivirus portfolio and that no statement has been made about other Kaspersky products. The US Department of Commerce issued a Final Determination on 20 June 2024 that prohibited new agreements with US persons from 20 July 2024 and signature and codebase updates from 29 September 2024; that determination expressly does not apply to Kaspersky threat intelligence products and services, which are treated as informational. Kaspersky rejects the BSI warning, stating that it was not based on an objective technical analysis of the risks of using its software. In practice this matters most for public sector contracts, for buyers whose customers apply supply chain requirements, and for anyone whose procurement policy excludes vendors under an official warning regardless of the specific product; it matters less for a private-sector SOC that ingests the data into its own systems. The scope distinction is worth documenting, because a questionnaire reviewer who knows only the headline may not know the carve-out exists.
Partly, and only for a narrow band of questions. It answers whether you subscribe to a commercial threat intelligence source, whether you enrich perimeter logs with external indicators, whether you block known malicious infrastructure at the network edge, and whether you can detect connections from anonymising infrastructure such as Tor exit nodes and public proxies. It does not answer questions on endpoint protection, EDR coverage, patch management, disk encryption, multi-factor authentication, backup and restore testing, log retention periods, privileged access management, or your documented incident response and escalation process. It also produces no report you can attach as evidence, so any answer you give has to be supported by output from your SIEM or firewall rather than from the feed. To close the indicator-side gaps, adding further feeds from the same Kaspersky family, such as the Malicious URL, Malicious Hash or Botnet C&C feeds, is usually cheaper and less work than introducing a second intelligence vendor with a different schema. Expect at least one questionnaire to ask about the vendor country of origin, so prepare that answer alongside the technical ones.
The decisive difference is detection rate: the demo feed carries a deliberately reduced set of indicators and is intended for evaluation, not for production blocking. The demo version is feed ID 87 and the commercial version is feed ID 68, and Kaspersky CyberTrace uses the demo feeds by default when no licence key is installed. Running the commercial feed through CyberTrace requires a CyberTrace licence key, which is a separate item to plan for. If your SIEM can ingest JSON or STIX directly, you can use the commercial feed without CyberTrace at all.
| Property | Demo IP Reputation Data Feed | IP Reputation Data Feed |
|---|---|---|
| Feed ID | 87 | 68 |
| Detection rate | Lower | Full |
| Default in CyberTrace Community Edition | ✓ | ✕ |
| CyberTrace licence key required | ✕ | ✓ |
| Suitable for production blocking | Evaluation only | ✓ |
This is data, not software: it installs nothing, protects nothing on its own, and produces no value until a system you already own is configured to consume and act on it. The feed carries IP addresses only, so malicious URLs, phishing pages, file hashes, botnet command-and-control URLs and vulnerable software are covered by separate feeds in the same family and are a common follow-up purchase. On the regional side, the US prohibition on Kaspersky products explicitly excludes threat intelligence products and services, and the German BSI warning is scoped to antivirus software with no statement on other products, but procurement policies at your customers may not draw that distinction, so check before you commit. One practical planning point that regularly surprises buyers: firewalls and gateways cap how many entries an external dynamic list can hold, so filtering the feed by threat score before you push it to the device is usually necessary rather than optional. Finally, running the commercial feed through Kaspersky CyberTrace needs a CyberTrace licence key, because the free Community Edition is limited to the demo feeds.
Kaspersky designs the feed for integration into SIEM systems, next-generation firewalls, secure mail and web gateways, and network traffic analysis tools, either as a dynamically updated blocklist or as an enrichment source. Delivery is by HTTPS download with a Kaspersky client certificate, and the most widely used feeds are also available over TAXII with token-based authentication.
No. Kaspersky states that its Threat Data Feeds can also be handled by a SIEM using the SIEM's own built-in capabilities, without CyberTrace. CyberTrace is useful when you want matching and triage to happen before events reach the SIEM, but using it with commercial feeds requires a licence key rather than the free Community Edition.
Kaspersky aggregates the feeds from the Kaspersky Security Network, its own web crawlers, round-the-clock botnet monitoring, spam traps, internal research teams and partners. The aggregated data is then filtered through statistical criteria, sandboxes and heuristics engines, analyst validation and allowlisting checks before it is published.