Kaspersky was fine. Until it wasn't. The geopolitical risk hidden in your security stack.
In June 2024, the United States government banned Kaspersky antivirus software for all American consumers & businesses. Not deprecated it. Not advised against it. Banned it, with a 30-day window for organisations to find an alternative.
For organisations that had been running Kaspersky as their primary endpoint security solution, this wasn't a minor inconvenience. It was an emergency migration of critical security infrastructure, under time pressure, with no clean transition path.
The question European organisations should be asking themselves is not whether this will happen to them. It's whether they're prepared if it does.
The Kaspersky Timeline
The Kaspersky story unfolded over years, but the end came suddenly:
-
2017 The US Department of Homeland Security banned Kaspersky products from all federal government systems, citing concerns about the company's ties to Russian intelligence.
-
2022 Germany's BSI (Federal Office for Information Security) issued a warning against using Kaspersky products, recommending organisations replace them.
-
2024 The US Commerce Department banned Kaspersky software nationwide for all consumers and businesses, effective July 2024. Kaspersky subsequently shut down its US operations entirely.
Each step happened faster than the previous one. And each time, organisations that had built their security infrastructure around Kaspersky found themselves scrambling.
Why this matters for European organisations
-
Regulatory risk
If the EU were to introduce restrictions on non-EU security vendors, whether in response; organisations dependent on US-based security SaaS would face the same emergency migration scenario that US organisations faced with Kaspersky.
-
Supply chain risk
ISO 27001 Annex A explicitly requires supply chain risk assessments. A security vendor with privileged access to your entire IT infrastructure; monitoring every endpoint, every network connection, every process execution; is arguably the highest-risk supplier in your supply chain.
If that vendor is subject to foreign government influence, that's a risk that needs to be assessed & documented.
-
Data sovereignty risk
Security tools collect highly sensitive data: vulnerability information, network topology, user behaviour, incident history. Under GDPR and NIS2, organisations have obligations around where this data is processed and stored. A security SaaS that processes this data on US infrastructure may create compliance exposure that hasn't been fully assessed.
-
Operational risk
SaaS-based security means your operational security depends on a vendor's portal being available. If the portal goes down, for any reason, your visibility goes down with it.
The NIS2 supply chain dimension
NIS2, which came into force across EU member states in 2024, explicitly addresses supply chain security. Article 21 requires organisations to implement measures addressing
supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.
For a CISO or IT manager assessing compliance, this creates a clear obligation: your security vendors; the companies with the deepest access to your infrastructure; need to be assessed as supply chain risks.
The questions that assessment should answer:
- Where is this vendor headquartered & under which jurisdiction does it operate?
- Where is our security data processed and stored?
- What government access obligations does this vendor operate under?
- How quickly could we replace this vendor if required to do so?
- What is our exit plan if this vendor is restricted, acquired or discontinued?
For many organisations, honest answers to these questions reveal a dependency on US-based security infrastructure that hasn't been fully thought through.
What sovereign security looks like in practice
-
Runs in your environment
Open source tools run in your own datacenter or cloud. Your security data never leaves your infrastructure. You're not dependent on a vendor's SaaS portal being available.
-
Transparent and auditable
Open source code can be inspected, audited & verified. You're not trusting a vendor's claims about what their software does; you can check. This is increasingly important for supply chain risk assessments under ISO 27001 and NIS2.
-
No vendor lock-in
Open source tools don't have end-of-life dates driven by commercial decisions. They don't get acquired & discontinued. They don't get geopolitically restricted. As long as the community maintains the software, it remains available.
A practical example
Kangasec's reference security architecture is built on Elasticsearch (or OpenSearch as a fully open alternative), Falco, Zeek, Suricata, CrowdSec, MISP & OpenBao. Every component runs in the customer's own environment. Every component is open source. Every component can be audited, modified ànd replaced without vendor permission.
This isn't idealism, it's risk management.
The transition question
For organisations currently running US-based commercial security tools, the question isn't whether to maintain the status quo. The status quo carries geopolitical, regulatory & operational risks that are growing, not shrinking.
The question is how to transition to a more sovereign security architecture in a structured, planned way; rather than in an emergency, under time pressure, as US organisations had to do with Kaspersky.
A structured transition typically involves:
- Assessment
Understanding what security tools you currently run, what data they access & where that data goes - Risk mapping
Identifying which tools create the highest sovereignty risk - Architecture design
Defining a target architecture based on open source tools running in your own environment - Phased migration
Replacing tools incrementally, starting with the highest-risk components - Validation
Verifying that the new architecture provides equivalent or better detection coverage
This is work that takes time. Which is exactly why it's better to start now, while you have time to plan, than to wait until you're forced to act.
Conclusion
Kaspersky's ban was not a unique event. It was a preview of what can happen when geopolitical tensions intersect with dependency on foreign technology.
European organisations that want to be resilient; not just secure, but genuinely resilient, need to take digital sovereignty seriously in their security architecture. That means choosing tools that run in their own environment, that can be audited & verified, and that don't depend on the commercial or political decisions of foreign governments.
Open source security isn't just a philosophical choice. For organisations that take NIS2, ISO 27001 and supply chain risk seriously, it's increasingly the only responsible choice.
Related news items
