Anyone working in IT security in Germany eventually runs into Section 202c of the German Criminal Code (StGB) — the so-called “hacker paragraph.” It's tricky because it doesn't just punish unauthorized access itself; it reaches one step earlier, at the tools. And those tools — exploit frameworks, password crackers, custom proof-of-concept code — are also the everyday toolkit of a legitimate penetration test.

Two Statutes, One Core Problem

To understand the legal situation, it helps to look at two closely related but distinct provisions.

§ 202a StGB — the Gatekeeper

Section 202a StGB criminalizes “data espionage”: deliberately bypassing an access control to gain access to someone else's data. That's essentially what happens, technically, during a penetration test — and without anything further, it would be unlawful regardless of intent. The only difference between a penetration tester and an attacker is the explicit authorization of the system owner.

§ 202c StGB — the Real Problem for Security Professionals

This is where it gets uncomfortable for the industry. Section 202c StGB already criminalizes producing, procuring, selling, supplying, disseminating, or otherwise making accessible passwords, access codes, or software “whose purpose is the commission of such an offense.” In theory, that describes the standard toolkit of a penetration test almost exactly: scanners, exploit code, password-attack tools.

When the provision was introduced in 2007, lawmakers explicitly did not intend to criminalize legitimate security research — the target was trafficking in attack tools for criminal purposes.

Why Consent “Cleanses” the Tool

Legally, § 202c is what's known as a preparatory offense. It punishes preparing an unlawful main offense under §§ 202a or 202b StGB. But if that main offense isn't unlawful in the first place — because of valid consent from the system owner — the necessary element is simply missing, and with it the punishable preparatory act. The use of the tool effectively inherits the lawfulness of the authorized main act.

This isn't a creative interpretation on my part — it's the prevailing view in case law and legal literature, and it matches the legislature's intent when the provision was introduced.

What This Means in Practice

That said, this protection isn't a blank check. It only applies if the authorization visibly covers not just the systems being tested, but also the methods and tool categories used. A vague statement like “you may test our website” leaves it open whether exploit code was actually covered. A legally sound scope document should therefore explicitly define:

  • Which systems, domains, and IP ranges may be tested
  • Which methods are explicitly excluded
  • Which categories of security tools may be used — not just a blanket reference to “testing”
  • The approved time window for active testing
  • Who is notified in an emergency

Conclusion

Section 202c StGB isn't a reason to shy away from penetration testing — not as a client, and not as a tester. It's a reason to take the scope document seriously and explicitly name the tools involved, not just the systems. That's why every engagement I take on includes a separate, signed authorization statement with an explicit tool-use clause — independent of the underlying contract.