Digital trust is the infrastructure problem of our era.
The organisations that will define the next decade — in finance, healthcare, critical infrastructure, and the public sector — will be distinguished by how deeply they have built security into their foundations. Not bolted on. Not purchased as an afterthought. Architected from day one.
What is broken in the current security landscape.
The enterprise security market has spent two decades selling the same philosophy repackaged: add another layer, deploy another product, buy another dashboard. The result is security stacks of sixty-plus tools that cannot interoperate, generate alert fatigue at industrial scale, and still fail to catch the breach that actually matters. Security Operations Centre analysts spend the majority of their working day triaging alerts from systems that have no shared context. The problem is not that the tools don't work. It is that they were never designed to work together.
AI has changed the threat environment — but not in the way most enterprise security buyers have internalised. Threat actors now automate reconnaissance at scale, generate polymorphic malware on demand, and chain vulnerabilities faster than any human analyst cadence can track. The mean time between a vulnerability's disclosure and active exploitation in the wild has collapsed. The asymmetry between attacker and defender has never been wider. And yet the majority of security investment still flows toward detection and response after the breach has already occurred.
"The breach you haven't seen yet already exists somewhere in your supply chain."
Identity has become the actual perimeter — and most enterprises have not finished processing that shift. Network perimeters no longer describe how organisations operate. The modern enterprise runs on SaaS platforms, public cloud workloads, remote workforces, and third-party API integrations. Every one of those connections is an identity relationship. Access tokens, service account credentials, OAuth grants, and API keys now constitute the boundary between your data and an adversary who has obtained one. Most enterprises cannot tell you, in real time, how many non-human identities have access to production systems. That is the perimeter problem.
The developer workflow is the new attack surface, and security has been institutionally separated from it. The conventional model — security as a compliance gate at the end of the release cycle — produces exactly the outcome you would expect: vulnerabilities discovered in production, where the cost to remediate is an order of magnitude higher than at code review. Supply chain attacks targeting open-source dependencies, secrets committed to version control, and container images shipped with known CVEs are not edge cases. They are the routine consequences of treating security as a final check rather than a continuous property of the build process.
How we invest.
We back AI-native security companies at Seed to Series A. Initial cheques range from €1M to €4M; we have led follow-on rounds and participate alongside specialist co-investors at subsequent stages. Our primary focus is European companies — or global companies with strong European regulatory relevance and meaningful operational presence. We have made thirteen investments across three funds since 2018. Fund III is currently deploying.
We do not lead with a term sheet. We lead with the diligence conversation. Willem and Martijn both built and broke security systems in their prior careers. The first substantive meeting is a technical discussion about the threat model the company is addressing. We want to understand precisely what the product prevents, how it detects what traditional tooling misses, why the architecture is defensible at scale, and what the adversary would have to do to route around it.
NIS2, GDPR, and DORA are not compliance burdens for European security companies — they are structural moats. Regulation that mandates a security upgrade creates a deployment requirement that does not depend on a buyer's internal security culture. We back founders who have designed for this regulatory environment from the first commit, not founders who are planning to add compliance documentation after product-market fit.
We are not generalist investors who have added a cybersecurity vertical. We do not invest in enterprise SaaS with security features, or in consumer products that sit adjacent to privacy. Every investment Stroom has made has been in companies where security or digital trust is the entire product.
What we look for in founders.
-
Deep technical convictionFounders who can describe the threat model they are solving in precise terms. Not "we use AI to improve security" but "we detect lateral movement in east-west traffic within 200ms of anomalous authentication by correlating identity graphs with network telemetry." The specificity of the threat model tells us whether the founder has spent time inside the problem or has built a solution in search of one.
-
European-first thinkingThe NIS2 directive, GDPR Article 32 security obligations, and DORA's ICT risk management requirements for financial entities create a specific regulatory design environment. Founders who have built these requirements into their product architecture from the beginning — rather than planning to layer compliance on top — have a structural advantage in European enterprise sales that is difficult for US-origin products to replicate quickly. We back founders who treat the European regulatory landscape as an architectural input, not a go-to-market obstacle.
-
AI-native architectureNot AI as a feature appended to a product that existed before the model. AI as the core architecture — the reason the detection capability, the verification accuracy, or the compliance proof is technically achievable when it was not before. We distinguish between companies that are AI-native and companies that have fine-tuned an LLM on top of an existing data pipeline and called it AI. The test: remove the model, and does the core product value collapse?
-
Operator background preferredWe back founders who have shipped security software in production — who have written the incident response playbook, run the post-mortem, and understand the operational constraints that shape how security tools actually get deployed and used. This is a preference, not a requirement. But when a founder has seen the problem from the inside, their product decisions tend to reflect a different set of trade-offs: they know which friction points kill adoption, which false positive rates are tolerable, and which security features are bought by the CISO but never used by the team.
Building the security infrastructure of the European digital economy?
If you are building AI-native security or digital trust infrastructure — threat detection, identity, developer security, compliance tooling, or data protection — and you have a genuine technical point of view on the problem, we want to hear from you. Fund III is actively deploying. Initial conversations are technical, not commercial.