Germany: §202c and the Berlin question

Section 202c of the German criminal code criminalizes producing, procuring, selling, or "otherwise making accessible" software whose purpose is unauthorized computer access — and it has not been amended since 2015, despite a 2025 coalition-agreement pledge to fix it. That is the single fact a Berlin founder building anything offensive-capable cannot skip. It does not make Berlin a legal trap. It does mean the company's entity structure and publishing policy need to be built around an unresolved statute, not a solved one.

#§202a/b/c StGB, explained precisely

Three adjacent provisions of the Strafgesetzbuch (German criminal code) govern computer intrusion, and only the third is the real landmine.

§202a — Ausspähen von Daten (data espionage). Criminalizes obtaining data not intended for the offender, specially protected against unauthorized access, by circumventing that protection — up to 3 years imprisonment or a fine.

§202b — Abfangen von Daten (data interception). Criminalizes unauthorized interception of non-public data transmission or electromagnetic emissions from a data-processing system using technical means — up to 2 years or a fine.

§202c — Vorbereiten des Ausspähens und Abfangens von Daten, the "Hackerparagraf." This is the preparation offense, and it is what makes the other two dangerous for a tooling company rather than just an individual attacker. It criminalizes preparing a §202a or §202b offense by producing, procuring for oneself or another, selling, transferring, distributing, or otherwise making accessible: (1) passwords or other security codes enabling data access, or (2) software whose purpose is the commission of such an offense — up to 2 years or a fine (dejure.org, §202c StGB).

That second clause is the one every German security researcher, red team, and pentest-tool vendor has been nervous about since it was introduced in 2007 to implement the Council of Europe Cybercrime Convention. The legislative intent was to target malicious tool trafficking, not legitimate security research, and prosecutors have generally exercised restraint — but there is no dedicated statutory safe harbor for authorized penetration testing or security research, in the way DMCA §1201(j) at least attempts to provide in the US (see The US picture). Legality has rested on prosecutorial discretion and the absence of test cases against reputable vendors, not on a codified defense a company can point to in a contract or a press release. A constitutional complaint against §202c was rejected by the Federal Constitutional Court in May 2009, leaving the statute in force essentially as written for 17+ years.

#What this concretely means

Publishing an offensive benchmark containing exploit code. A public repository of working exploits, distributed from Germany or by a German entity, sits inside §202c's "otherwise making accessible" language if the software's purpose can be characterized as enabling unauthorized access — plausible for a benchmark full of working PoCs regardless of stated research intent. AIxCC's approach — open-sourcing all seven finalist systems only after the competitive and disclosure window closed — is the model worth following, not a public exploit-benchmark release timed to a launch. See AIxCC: the closest thing to a proof and Cyber benchmarks and evals.

Open-sourcing an agent that exploits systems. The same clause applies with more force to an agent whose entire function is generating and executing exploit code. Releasing weights, or an easily-fine-tuned checkpoint, that reliably produces working exploits is a materially different act than releasing a paper describing the technique — and it is the release, not the underlying research, that §202c's "producing... or otherwise making accessible" language targets.

Running an autonomous pentest product from a German entity. Least legally exposed of the four, but not exposure-free. A pentest product operating strictly within signed, scoped authorization is squarely the kind of legitimate activity §202c's 2007 intent was never meant to catch — but an autonomous agent that drifts outside its scope (a live risk with no German or US case law resolving it cleanly — see Dual-use risk and what it costs you and The US picture) removes the "authorized" characterization the whole defense rests on. Hard technical scope-fencing matters more here than anywhere else in the business.

Hiring security researchers in Germany. Recruiting is the least legally fraught of the four in practice — CISPA, TU Darmstadt, and Ruhr-Universität Bochum (HGI) produce genuinely excellent, cost-competitive security-research talent, and none of them treat §202c as a reason to avoid the field. The practical friction is compensation, not law: the hybrid "security research + ML post-training" skill set commands SF/London premiums that a Berlin-based standalone lab struggles to match [unsourced — directional comp benchmarks, not a freshly sourced survey]. See Talent: the actual constraint.

#Practical mitigations founders actually use

None of the following is legal advice, and none of it makes §202c go away — they are the structural choices that let German security companies operate today under exactly this uncertainty.

• Entity structure. A common pattern: a German GmbH for EU sales, EU-funding eligibility (ECCC/NCC-DE, Cyberagentur, SPRIND — see below), and defensive/compliance-tooling R&D, paired with a separate entity — often US-domiciled — holding IP and go-to-market for any product line that touches offensive capability. This is not purely a tax or fundraising decision; it puts the exploit-generation surface area under a jurisdiction with a codified research safe harbor (see The US picture) rather than an unreformed one.
• Where the offensive capability lives. Keep exploit-generation and execution capability inside a tightly access-controlled, contractually authorized product surface (an enterprise pentest engagement with a signed scope-of-work) rather than a broadly distributed model or open dataset. The legal risk profile of "we generate an exploit for a customer under signed authorization" is categorically different from "we shipped a model that generates exploits for anyone."
• Contract-side authorization. Treat the signed scope-of-work as the operative legal document, not a formality — it is the closest thing German law offers to the codified authorization defenses that exist elsewhere. Build technical enforcement (network allowlisting, target-scoping at the infrastructure layer) around the contract, not just prompt-level instructions to the agent.
• Publishing policy. Default to coordinated disclosure timelines before any public release involving working exploit code, and route model or benchmark releases with offensive capability through the same systemic-risk lens the EU AI Act already requires for GPAI models (see EU regulation as a demand engine) — even where the AI Act doesn't strictly apply, the underlying vulnerability-equities reasoning does.

#NIS2UmsuCG: what it makes German companies buy

Germany transposed NIS2 via the NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), amending the BSI-Gesetz (BSIG) to introduce the NIS2 categories of "besonders wichtige Einrichtungen" (essential) and "wichtige Einrichtungen" (important) entities.

Whatever the exact date, the law is live now, and it brought an estimated 15,000–30,000 German mid-market and public-sector entities into scope for the first time [unsourced — BSI-cited estimate range, not independently re-confirmed], with the same personal management liability that NIS2 attaches EU-wide (see EU regulation as a demand engine). It mandates risk-analysis and information-security policies, incident handling, business-continuity planning, supply-chain security including vendor assessment, vulnerability handling and disclosure, and cryptography use. The supply-chain clause is the one that matters commercially: it is the channel through which an AI code-security vendor becomes a required line item in a customer's own compliance evidence, not an optional upgrade. Mid-market German companies that ran security as a part-time IT function are now first-time buyers of continuous, automated tooling — see Who buys, and what they pay and Go to market.

#BSI, the national strategy, Cyberagentur, SPRIND

BSI (Bundesamt für Sicherheit in der Informationstechnik) is Germany's federal cybersecurity authority. Its powers were expanded first by IT-Sicherheitsgesetz 2.0 (in force since 28 May 2021) and again by the NIS2UmsuCG amendments to BSIG — new entity categories, expanded registration and reporting duties owed to BSI, and BSI acting as the national coordinator feeding into the CRA's Article 14 reporting pipeline and ENISA (see EU regulation as a demand engine). BSI also hosts Germany's National Coordination Centre (NCC-DE) under the ECCC network. Germany's most recently published national cyber strategy is the Cybersicherheitsstrategie für Deutschland 2021; whether a successor document has been formally published under the current coalition government was not confirmed and is [unverified].

BSI functions as both regulator and buyer — it is a plausible direct customer and procurement partner, not purely an enforcement risk.

Cyberagentur (Agentur für Innovation in der Cybersicherheit), founded 2018/2020 and based in the Halle/Leipzig area, funds high-risk, high-payoff cybersecurity and AI-security research on a challenge/prize and long-horizon-contract model explicitly modeled on DARPA. Confirmed 2026 research budget: €109 million, structured around four programme areas including Key Technologies (quantum/ML/autonomous systems) [source: cyberagentur.de]. This is closer to DARPA than to a startup accelerator — a 10–15-year-horizon research mandate, not seed capital, but a genuine funding and credibility channel for defense-relevant AI-security research.

SPRIND (Bundesagentur für Sprunginnovationen) is Germany's federal deep-tech "moonshot" agency, running challenge-based funding with public deadlines rather than rolling applications. No dedicated cybersecurity/AI-security challenge track was visible as of this research pass, though its "Next Frontier AI" track explicitly funds European AI teams — check sizes not independently confirmed [unverified].

Together with the ECCC/NCC-DE and NATO Innovation Fund access covered in EU regulation as a demand engine, Cyberagentur and SPRIND round out a genuinely strong German non-dilutive funding base — see Who funds this and at what price for the full picture including EIC Accelerator and High-Tech Gründerfonds.

#The verdict: base, trap, or manageable constraint?

Manageable constraint with the right structure — not a trap, and not a non-issue.

The case for Berlin as a base is real and not just sentimental: NIS2 is already in force with personal management liability attached, DORA has been live for financial entities and their vendors since January 2025, CRA Article 14 reporting starts within weeks of this writing, BSI is both regulator and potential customer, Cyberagentur and SPRIND provide real non-dilutive capital, and CISPA/TU Darmstadt/Bochum are a genuinely excellent, cost-competitive security-research talent pipeline. The compliance-driven demand signal in Germany is not hypothetical the way much of the equivalent US signal currently is — see The US picture for the CMMC suspension that undercuts the comparable American forcing function.

The counter-argument worth taking seriously: European buyers — especially public-sector and defense-adjacent ones — increasingly write "sovereignty" preferences into procurement, favoring an EU-domiciled vendor over a US one on data-residency and strategic-autonomy grounds. That preference is a genuine tailwind for a Berlin-headquartered company selling into the EU market it is already best positioned to sell into, and it partially offsets the §202c friction: a company that keeps its core defensive/compliance product EU-domiciled captures that sovereignty preference while routing only the specific offensive-capability surface through a structure with a codified research safe harbor.

The reason it is not simply "Berlin is fine" is that §202c is unreformed, has no statutory safe harbor, and the coalition's reform pledge has produced no confirmed legislative action as of August 2026. A founder who builds the offensive product line as if the reform has already happened is making a bet on a specific piece of pending legislation passing, with no confirmed timeline. The right read is: build the defensive/compliance business in Germany now, where the regulatory tailwind and funding access are strongest, and keep the exploit-generation surface area structurally separated — a different entity, tighter authorization gating, or both — until §202c reform is confirmed rather than pledged. Revisit this page when that changes; see Open questions and the research backlog and Verification ledger for what to check next.

#What this means for us

• Treat §202c as unreformed and in force until you can point to a primary source saying otherwise — not the coalition agreement, an actual Bundestag vote.
• Any product surface that generates or executes exploit code should sit behind signed contractual authorization and hard technical scope-fencing, not prompt-level instructions.
• Structure the offensive-capability product line under a jurisdiction with a codified research safe harbor (see The US picture) while keeping the defensive/compliance business German-domiciled to capture NIS2/CRA/DORA demand and the sovereignty-buyer preference.
• BSI, Cyberagentur, and NCC-DE are simultaneously regulators and plausible funders/customers — engage them as both.
• Do not time a public benchmark or model release with working exploit code to a launch; follow the AIxCC pattern of releasing only after the competitive/disclosure window closes.
• Revisit this page's confidence rating when a BMJ draft or Bundestag vote on §202c reform is actually confirmed — the whole "manageable constraint" verdict is contingent on that not changing the calculus in the other direction.