EU regulation as a demand engine
A cluster of EU laws with hard dates turns vulnerability management into a mandatory, budgeted, recurring purchase.
The EU did not pass a law that says "buy AI security tooling." It passed five that make continuous vulnerability handling, SBOM maintenance, incident reporting on an hours-to-days clock, and recurring adversarial testing into legal obligations with fines and personal management liability attached. Read together, they are the closest thing this market has to a guaranteed demand curve, and most of the relevant clocks are already running. The one genuinely open question for this founder is not whether the EU creates budget — it does — but whether a company that post-trains and releases a cyber-capable model becomes a regulated subject itself.
#The forcing-function table
| Instrument | Key date | Who must act | What they must buy | Penalty |
|---|---|---|---|---|
| Cyber Resilience Act (Reg. 2024/2847) | Art. 14 reporting live 11 Sept 2026; full application 11 Dec 2027 | Manufacturers of "products with digital elements" sold into the EU | Automated SBOM generation, continuous vuln/exploit-intel matching, incident-triage pipeline | Up to €15M / 2.5% turnover cited in secondary sources [unverified — primary Article 64 text not confirmed] |
| NIS2 (Dir. 2022/2555) | EU transposition deadline 17 Oct 2024; Germany's NIS2UmsuCG in force 6 Dec 2025 [unverified — see Germany: §202c and the Berlin question] | ~18 sectors, essential + important entities (≥50 staff / €10M turnover) | Risk-management policy, incident handling, supply-chain security assessment of vendors | Fines (specific caps not confirmed in sourced notes) plus personal liability and temporary management bans for essential-entity leadership |
| DORA (Reg. 2022/2554) | Applying since 17 Jan 2025 (EIOPA) | ~20 categories of financial entities + their "critical" ICT third-party providers | Recurring threat-led penetration testing (TLPT) on a roughly 3-year TIBER-EU cycle, ICT risk-management contracts | Direct examination/sanction of Critical ICT Third-Party Providers by an EU "Lead Overseer" [figure unverified] |
| CER Directive (Reg. 2022/2557) | Transposition deadline 17 Oct 2024 | Critical-infrastructure operators (physical + cyber) | Resilience plans overlapping NIS2's essential-entity population | Not specified in sourced notes [unverified] |
| Cybersecurity Act / EUCC (Reg. 2019/881; Impl. Reg. 2024/482) | EUCC scheme adopted, in force Feb 2024 | ICT product/component vendors (voluntary) | Common Criteria-based certification recognized EU-wide | N/A — voluntary scheme |
- CRA Article 14 reporting: live 11 September 2026 — European Commission, Cyber Resilience Act
- CRA full application: 11 December 2027 — same source
- DORA applying since 17 January 2025 — EIOPA
- AI Act GPAI obligations live since 2 August 2025 — Digital Strategy — Regulatory framework for AI
- Digital Europe Programme: >€8.1 billion, 2021–2027 — Digital Europe Programme
- NATO Innovation Fund: ~€1 billion, ~24 Allied nations as LPs [unsourced — not independently re-fetched]
#The CRA deep-dive: why this is the strongest structural driver
The Cyber Resilience Act covers almost anything that ships with a network stack, an API, or firmware — Article 3's "product with digital elements" definition is deliberately broad, catching both a SaaS scanning product and an on-prem appliance. Non-commercial open-source is out of scope by default, and the Act creates a lighter-touch "open-source software steward" category for foundations and marketplaces, but a commercial vendor gets none of that shelter.
Two obligations do the real work. Article 13 requires manufacturers to run a cybersecurity risk assessment across the product lifecycle, patch vulnerabilities without delay through updates separable from feature updates, run a coordinated vulnerability disclosure process, and — the line item that matters most for tooling demand — produce and maintain a Software Bill of Materials, available to market-surveillance authorities on request. Article 14 then requires manufacturers to notify, simultaneously through a single reporting platform, both the coordinating CSIRT and ENISA of any actively exploited vulnerability or severe incident. The exact sub-deadlines (industry expectation is a 24-hour early warning, 72-hour full notification, 14-day final report, modeled on GDPR/NIS2) could not be confirmed against the live consolidated Article 14 text in the underlying research pass — treat the hour counts as indicative, not contractual, until checked directly.
Knowing your own SBOM continuously and reporting an exploited vulnerability within hours is operationally impossible to do by hand above a handful of products. That gap — not marketing, not thought leadership — is what a vendor sells into: automated SBOM generation wired into CI/CD, continuous vuln/exploit-intelligence matching against that SBOM, and an incident-triage pipeline that can produce an ENISA/CSIRT-ready report inside the statutory window.
Annex I's "state of the art" secure-development requirement is the second lever: at 2026–2027 audit standards, demonstrating state-of-the-art secure development increasingly means AI-assisted static/dynamic analysis and fuzzing in the pipeline, not a quarterly manual review. A vendor building for CRA compliance should target: (1) SBOM generation that plugs into existing CI/CD without a rewrite, (2) continuous matching of that SBOM against exploit intelligence, not just CVE existence, (3) a reporting workflow pre-shaped to the CSIRT/ENISA platform's format, and (4) audit-trail evidence that satisfies a market-surveillance authority, not just a security team. This is discussed further from the buyer side in Who buys, and what they pay, as a company-building thesis in AI code security companies, and as an open gap in current tooling coverage in Where the gaps actually are.
Penalty figures for Article 64 breaches — commonly cited in secondary sources as up to €15 million or 2.5% of worldwide turnover — could not be confirmed against the primary Article 64 text in the underlying fact-check pass. Treat that number as [unverified] until checked directly against EUR-Lex; do not put it in an investor deck as confirmed.
#NIS2, DORA, and the rest of the stack
NIS2's headline lever is not the fine schedule — the specific caps were not confirmed in the sourced notes — it is personal management liability: essential-entity leadership can face temporary bans from managerial functions for non-compliance. That is a sharper escalation than prior EU cyber law and a direct driver of board-approved tooling budget, because a board member with personal exposure wants defensible, continuously monitored controls, not an annual pentest PDF. Germany's implementation is covered in full in Germany: §202c and the Berlin question.
DORA is narrower in scope but the cleanest recurring-revenue forcing function on this table: threat-led penetration testing (TLPT), based on the TIBER-EU framework, runs on a roughly three-year cycle for the largest, most systemically important EU financial entities — a budgeted, repeat-purchase line item for automated adversarial testing tooling, not a one-off audit. DORA also reaches past the regulated financial entity into its ICT third-party providers, including a direct EU "Lead Overseer" oversight regime for providers designated "critical" — an unusual extension of financial regulation into vendor territory that a security vendor selling into EU banks needs to understand before signing a contract.
CER and the Cybersecurity Act/EUCC matter less as direct demand drivers and more as compliance-mapping and certification surface: CER's physical-resilience obligations overlap NIS2's essential-entity population, and EUCC gives a certifiable path for a hardware/software component sold into regulated sectors. Current EUCC uptake figures were not independently re-checked and are [unverified].
#The AI Act: GPAI obligations, the omnibus, and what actually changed
The AI Act's prohibited-practices and AI-literacy obligations (Articles 4–5) became applicable 2 February 2025. GPAI obligations (Chapter V, Articles 51–56) became effective 2 August 2025 and remain on that schedule — this is the part every "the AI Act was gutted" take from 2025–2026 commentary gets wrong. What actually moved is the high-risk system deadline, via the AI Omnibus simplification package: Annex III high-risk use cases (biometrics, critical infrastructure, employment, credit, law enforcement, migration, justice) now apply from 2 December 2027, and high-risk systems embedded as safety components in already-regulated products (medical devices, machinery, toys, lifts) apply from 2 August 2028 — both roughly 16 months later than originally scheduled.
The omnibus's own in-force date (27 July 2026) and the two new high-risk deadlines were confirmed against the European Commission's digital-strategy site. The package's adoption date (reported as November 2025) and the full legislative history behind it were not independently pinned down in the underlying fact-check pass — treat the adoption timeline as [unverified] even though the resulting dates check out.
Article 15 requires high-risk AI systems to be accurate, robust, and resilient against unauthorized third parties exploiting vulnerabilities to alter outputs — naming data poisoning, model poisoning/backdoors, adversarial examples, and confidentiality attacks (model/data extraction) explicitly. This is close to a textual specification for an AI red-teaming and adversarial-robustness testing product category, one of the more direct regulatory hooks anywhere for "you must test your model like an attacker would." See Cyber benchmarks and evals for what that testing looks like in practice today.
#The question that actually matters for this founder
What obligations fall on a company that post-trains and releases a cyber-capable model?
Start with whether it is a GPAI model at all. Article 51(2) sets a rebuttable presumption of systemic risk at 10^25 FLOPs of training compute — a compute threshold, not a capability test. A company fine-tuning an existing frontier open-weight base (Llama- or Qwen-class, itself trained past that threshold) is unlikely to trigger the presumption purely through its own post-training compute spend — but the Commission also holds a discretionary designation power to deem a model systemic-risk on capability/reach grounds even below the compute threshold, and a model that is unusually effective at autonomous exploitation or vulnerability discovery is a plausible target for exactly that kind of case-by-case designation, given the AI Office's stated interest in high-impact capabilities. Whoever places the resulting model on the market under their own name can also inherit Chapter V provider obligations in some circumstances — this is contested legal territory and needs EU counsel before a public release, not a confident assumption either way.
Does the open-source exemption apply? Article 53(2) exempts GPAI models released under a genuine free/open-source license — public weights, architecture, and model information, a license permitting access, use, modification, and redistribution — from the Chapter V transparency obligations in Articles 53(1)(a) and (b). That carve-out is explicitly disapplied the moment the model is treated as carrying systemic risk under Article 51. This is not an edge case or an oversight — it is the provision working as designed, specifically to stop a systemic-risk lab from using "we open-sourced it" as a compliance shortcut.
Open-weighting a cyber-offense-capable model does not by itself avoid Article 55's obligations — model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident tracking and reporting to the AI Office, and cybersecurity protection of the model and its infrastructure — if the Commission or the compute presumption treats the model as systemic-risk. Do not build a release plan on the assumption that open-sourcing is a compliance exit. See Dual-use risk and what it costs you for the operational and legal-exposure side of the same problem, and The open-source stack for the licensing mechanics.
Walking through it concretely for a Berlin-founded lab: (1) confirm whether the base model you post-train already crossed 10^25 FLOPs — if yes, get counsel on whether Chapter V provider obligations attach to your release, not just the original developer's; (2) assume the Commission's discretionary designation power is a live risk if your model demonstrably crosses a meaningful autonomous-exploitation capability bar, regardless of compute spent on your side; (3) do not treat an open-weight release as a way around Article 55 — build the adversarial-testing and incident-reporting infrastructure Article 55 requires before you need it for a systemic-risk determination, not after; (4) document your GPAI Code of Practice posture either way — the Code (finalized 10 July 2025, applying alongside the GPAI obligations from 2 August 2025) creates a presumption of conformity with Articles 53 and 55 and is the lower-friction compliance path if you sign it.
#EU money: where the non-dilutive capital actually is
- Digital Europe Programme (DIGITAL), 2021–2027 — confirmed overall budget >€8.1 billion, cybersecurity as a named capacity-building strand alongside supercomputing, AI, and digital skills (Digital Europe Programme). A specific cybersecurity-strand envelope in the ~€1.6B range is widely reported but not independently confirmed here — [unverified].
- European Cybersecurity Competence Centre (ECCC) — established by Reg. 2021/887, Bucharest-based, running a National Coordination Centre network (Germany's NCC-DE sits at BSI). Pools Digital Europe and Horizon Europe cyber R&D funding and runs SME/consortium calls — the natural first port of call for an EU-incorporated entity chasing non-dilutive cyber R&D money.
- Horizon Europe — the EU's ~€95.5bn 2021–2027 research framework; funds cybersecurity and secure-AI research through Cluster 4, typically via ECCC-coordinated, multi-partner consortium calls — slower and more academic than Digital Europe's path, but real money.
- EU Cyber Solidarity Act (Reg. 2025/38) — in force early 2025, funds a Cybersecurity Emergency Mechanism (via Digital Europe) that pays pre-vetted "trusted providers" for incident-response services during major incidents — a genuine procurement channel, not a grant, worth pursuing once the company has an incident-response track record. Reserve size [unverified].
- European Defence Fund (EDF) — ~€8 billion, 2021–2027, co-funded defense R&D including cyber-defense topics; requires multi-member-state defense-industrial partners and moves slower than DIU-style US contracting (see The US picture).
- NATO DIANA and the NATO Innovation Fund (NIF) — DIANA runs accelerator/test-centre programs across NATO states including Germany for dual-use deep tech, cyber and AI explicitly in scope. NIF is a roughly €1 billion, ~24-nation multi-sovereign venture fund making direct equity investments, typically pre-seed to Series A, into dual-use startups — one of the very few funding vehicles genuinely built for this exact founder profile: EU-based, dual-use, defense-adjacent. Cross-reference Who funds this and at what price for the full non-dilutive landscape including SPRIND and Cyberagentur, which sit on the German side of this picture and are covered in Germany: §202c and the Berlin question.
#What this means for us
- CRA Article 14 (11 Sept 2026) and CRA full application (11 Dec 2027) are the two hardest, nearest-term dates in this whole document — build the product roadmap around being CRA-audit-ready before Dec 2027, not after.
- Do not put the CRA €15M/2.5% penalty figure into anything investor-facing without re-verifying it against Article 64 directly — the sourced notes could not confirm it.
- DORA's TLPT cycle is the cleanest recurring-revenue forcing function in the EU stack; a product that plugs into a TIBER-EU-aligned testing cadence has a natural three-year repeat-purchase rhythm.
- The AI Act question is existential, not academic: before any public release of a cyber-capable post-trained model, get a real answer — not an assumption — on systemic-risk designation and whether the open-source exemption actually applies. See Dual-use risk and what it costs you and Is frontier-lab gating a real wedge?.
- The digital omnibus did not touch GPAI — don't let "the AI Act got delayed" commentary bleed into complacency about Article 55 obligations that are already live.
- ECCC/NCC-DE, Horizon Europe, and NIF are the most realistic non-dilutive paths for an EU-incorporated entity; see Who funds this and at what price and Germany: §202c and the Berlin question for the German-specific instruments (Cyberagentur, SPRIND) that stack on top of these.