What are the core benefits of Kaspersky Threat Data Feeds Whitelisting?
No console – No management console; your own tools consume it.
Trusted data – Continuously updated records of legitimate software.
False positives – Filters known-good objects out of alert queues.
Open formats – JSON, CSV, OpenIoC and STIX over HTTPS.
SIEM integration – Works with QRadar, ArcSight, Splunk and others.
Important note – No protection component; matching runs on your side.
Download: Kaspersky Threat Data Feeds Whitelisting
Whitelisting Data Feed – Systematic, continuously updated knowledge of legitimate software.
Machine-readable formats – Delivered as JSON, CSV, OpenIoC or STIX files.
HTTPS and TAXII delivery – Pulled by your own systems on a schedule.
SIEM and TIP support – QRadar, ArcSight, Splunk, MISP and other platforms supported.
Vetted source data – Aggregated from Kaspersky Security Network and research teams.
Important – No console, no agent and no blocking function included.
Kaspersky Threat Data Feeds Whitelisting is a subscription to one feed within the Kaspersky Threat Intelligence family, and it delivers data about known-legitimate software rather than software itself. There is no management console: the feed is downloaded by your own SIEM, threat intelligence platform or Kaspersky CyberTrace, and the matching happens there.
Fewer false positives – Known-good objects are filtered before analysts see them.
Faster alert triage – Analysts stop re-analysing files already proven non-malicious.
Lower SIEM workload – Fewer events reach the correlation and storage layer.
Text-only delivery – No executable code runs inside your infrastructure.
Vendor-neutral integration – Usable without any Kaspersky endpoint product installed.
Supports application control – Feeds allowlist decisions in third-party solutions and services.
This is a security operations product, not a small-business product. It only pays off if someone in your organisation already runs a system that ingests indicator data and matches it against events. A company without a SIEM or threat intelligence platform has nothing to feed it into.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | Rarely | By sector | ✓ |
| NIS 2 in the European Union | ✕ | By sector | ✓ |
| Security questionnaire from large customers | Sometimes | ✓ | ✓ |
| Own SIEM or threat intelligence platform | ✕ | Sometimes | ✓ |
| This product fits | ✕ | Limited | ✓ |
No single security product meets the requirements of the revised Information Security Act (ISG) on its own. Since 1 April 2025, operators of critical infrastructure in Switzerland must report qualifying cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery, with a further 14 days to complete a first report that was necessarily incomplete. The 24-hour deadline is a triage problem before it is a reporting problem, and this is where the feed contributes: removing files already proven legitimate from the alert queue shortens the time analysts need to decide whether an event is a reportable incident. What the feed does not do is detect the attack, generate the report, record who discovered what and at which time, or retain evidence for the follow-up submission — those come from your monitoring platform, your endpoint protection and your documented incident process. This text is general product information and not legal advice; whether your organisation falls under the reporting obligation should be clarified with qualified legal counsel.
No product creates NIS 2 compliance, and any vendor claiming otherwise is describing a marketing position rather than the directive. The NIS 2 Directive requires essential and important entities to implement risk-management measures covering incident handling, network and information system security, supply chain security, business continuity, and the reporting of significant incidents. This feed touches one narrow part of that: it improves the signal-to-noise ratio in security monitoring, so that events worth escalating are easier to separate from routine activity. It contributes nothing to incident handling workflows, access control, encryption, continuity planning, staff training or supplier risk assessment, and it generates no audit trail by itself. Treat it as an input that improves a detection capability you already operate, not as a measure you can present on its own.
In Switzerland, the Federal Office for Cybersecurity (BACS) does not issue recommendations for or against individual products and has published no warning concerning Kaspersky; it has stated that it would inform the public if it received confirmed evidence of misuse. In Germany, the Federal Office for Information Security (BSI) has warned against the use of Kaspersky virus protection software since 15 March 2022. That warning is still in force in 2026, it relates specifically to antivirus software rather than to Kaspersky's full portfolio, and Kaspersky has publicly disputed it, pointing to its Swiss data storage, its transparency centres and the absence of any confirmed incident, and signalling legal steps in early 2026 if the warning is not withdrawn. In the United States, the Department of Commerce issued a Final Determination on 20 June 2024 prohibiting Kaspersky from supplying antivirus software and cybersecurity products to US persons, with resale, integration and licensing prohibited from 29 September 2024. One detail in that determination matters directly here: it explicitly does not apply to Kaspersky Threat Intelligence products and services that are purely informational in nature, which is the category this feed belongs to. In practice this affects three groups of buyers — organisations with US entities or US-person contractual obligations, German public sector bodies and organisations that follow BSI guidance, and any supplier whose large customers screen vendor country of origin in procurement. Independent detection tests from the AV laboratories cover Kaspersky's endpoint engines and say nothing about a text data feed, so they are not a useful signal for this product either way. The decision is yours to make against your own contractual and sector requirements.
Partly, and only in one section of a typical questionnaire. It gives you a concrete answer to items asking whether you use external threat intelligence sources, whether your monitoring uses reputation data from a source outside your own environment, and whether you take active steps to reduce alert fatigue in triage. It answers nothing else. Questions about endpoint protection coverage, patch status, encryption of mobile devices, backup and restore testing, multi-factor authentication, access reviews, log retention periods, incident response times and staff awareness training are all untouched, and so is any question asking you to produce evidence or reports, because this product generates none. There is also a question type where the feed can work against you: some questionnaires ask you to declare the country of origin of your security suppliers, and a Russian-headquartered vendor will require an explanation regardless of how the product is delivered. If the gaps are what you actually need to close, a broader Kaspersky Threat Intelligence subscription covering malicious indicator feeds and reporting will usually cost less and cause fewer integration problems than assembling equivalent coverage from several vendors.
The decisive difference is direction: the Whitelisting Data Feed tells your systems what is known to be safe, while the malicious feeds tell them what is known to be dangerous. That means the whitelisting feed cannot detect anything on its own — it can only suppress noise generated by something else. Buyers who purchase it expecting detection coverage have bought the wrong feed. Both are delivered in the same machine-readable formats and both require a matching engine on your side, so the integration work is the same either way.
| Property | Whitelisting Data Feed | Malicious indicator feeds |
|---|---|---|
| What the records describe | Legitimate software | Malicious objects |
| Primary purpose | Suppress false positives | Raise detections |
| Usable alone as a detection source | ✕ | ✓ |
| Delivery formats | JSON, CSV, STIX | JSON, CSV, STIX |
| Requires your own matching engine | ✓ | ✓ |
The most common follow-up purchase is the matching layer itself: the feed is text data, and something has to compare it against your event stream, which in practice means an existing SIEM, a threat intelligence platform, or Kaspersky CyberTrace as a separate component. The second is scope — this feed reduces noise but adds no detection, so a security operations centre buying it in isolation still needs the malicious indicator feeds to gain coverage. On regional availability, the US Final Determination against Kaspersky expressly excludes purely informational threat intelligence products, but a US entity in your group should still confirm its own position before you deploy, and organisations following German BSI guidance will need an internal justification even though that warning addresses antivirus software rather than data feeds. Finally, Kaspersky's current public feed overview promotes a different subset of its 25-plus feeds and does not list the whitelisting feed by name, so confirm the exact current package with your distributor before you plan an integration around it.
No. Application control software enforces a policy on an endpoint and blocks what is not permitted. This feed supplies reference data about legitimate software that such a system, or a third-party service, can consult when making that decision. The enforcement component remains something you buy and operate separately.
Nothing is blocked, because the feed does not block. An unlisted file simply receives no known-good confirmation, so it stays in the queue and is handled by your normal analysis process. In-house applications, custom scripts and freshly compiled binaries will routinely fall into this category, which is worth accounting for when you estimate how much triage volume the feed will actually remove.