Bug Bounty

Poland’s CERT launches state-run bug bounty with 1m zloty pool

CERT Polska’s hack.cert.pl pays up to 20,000 PLN for flaws in public systems, run in-house. One council quit after its site went down.

Illustration of a bug icon over a network, headlined Poland pays hackers to test government systems

Poland’s national CERT has opened its own bug bounty platform, paying researchers from a 1 million zloty pool to find flaws in public-sector systems, with no commercial platform in between. Within a day, one participating council’s website buckled under test traffic and the council pulled out, which is a useful lesson for any UK body thinking of following suit.

What happened

On 3 November 2026 CERT Polska, the incident response team that sits within the research institute NASK, launched hack.cert.pl. The platform carries a state-funded bug bounty for government systems. The total prize pool is 1 million PLN, and individual payouts run from a few hundred zloty to a maximum of 20,000 PLN per confirmed vulnerability, depending on severity.

There were five programmes at launch: the GOV.PL portal, the government’s mSzyfr messenger, services run by the seaside municipality of Władysławowo, and CERT Polska’s and NASK’s own websites. Deputy Prime Minister and Minister of Digital Affairs Krzysztof Gawkowski presented it alongside NASK director Radosław Nielek and CERT Polska head Marcin Dudek, according to regional outlet Puls Gdańska.

The notable detail is that CERT Polska built and runs the platform itself: reports are submitted, triaged and passed on entirely inside its own infrastructure, with no commercial intermediary. NASK claims it is one of the first state-run public-sector bug bounty platforms anywhere.

The launch did not go entirely smoothly. On 4 November Puls Gdańska reported that Władysławowo’s Public Information Bulletin had been briefly taken offline by a surge of testing traffic tied to the bounty. The municipality told the outlet it is no longer taking part.

The detail

The rules show a programme designed to keep control tight. Polish security news sites Niebezpiecznik and Zaufana Trzecia Strona both report that researchers must verify their identity through the government’s Login.gov.pl service. CERT Polska’s announcement lists the other eligibility conditions: participants must be at least 18, hold a PESEL national identification number, be tax resident in Poland and supply a Polish bank account. Allowing 16 to 18 year olds to take part with a guardian’s consent is planned for later.

Each programme is run as a contest with its own regulations, which CERT Polska says spares winners from settling income tax on prizes themselves. Zaufana Trzecia Strona suggests the residency rule also filters out the low-quality reports that global programmes now receive.

According to Niebezpiecznik, payouts for CERT’s own services cover 20 vulnerability categories tied to CVSS 4.0 severity tiers, and informational findings earn nothing. Automated tools are allowed but capped at five requests per second, and three invalid or out-of-scope submissions can get an account blocked.

Every report first goes to CERT Polska analysts, then to the owner of the affected system for fixing. Nielek’s message, as reported by dobreprogramy and Puls Gdańska, was that knowing about a flaw achieves nothing unless it is fixed quickly. NASK cited a rising workload: more than 105,000 new vulnerabilities worldwide between January and September 2026, against roughly 71,000 in all of 2025. Rankings, badges and more public bodies are planned.

Timeline of the launch of CERT Polska's hack.cert.pl bug bounty, from the 3 November launch to Władysławowo's withdrawal on 4 November

Why it matters for UK organisations

The UK has no direct equivalent. Public bodies here generally run vulnerability disclosure policies, often hosted on commercial platforms, and these usually offer thanks rather than cash. Poland’s approach tests three ideas that UK policymakers and security leaders should watch.

The first is sovereignty over vulnerability data. A queue of unpatched government flaws is about as sensitive as data gets, and keeping it on national infrastructure answers a question UK departments rarely ask in public: who else can see our open bugs?

The second is paying for public-sector findings. Money attracts skilled researchers but also noise, and Poland’s identity checks, rate limits and account blocking are an attempt to get the first without the second.

The third is legal certainty. Polish researchers taking part now have written rules, a named scope and a state sponsor. In the UK the position is still unsettled. The government told the Lords in September that the Home Office proposes a defence under section 1 of the Computer Misuse Act 1990 for accredited researchers, to be delivered through separate national security legislation. As one legal briefing pointed out at the time, no accreditation scheme has yet been described. Until something is in place, a well-scoped programme with explicit authorisation remains the clearest protection a UK researcher can get.

Expert view

I like this programme, and I like the Władysławowo episode even more, because it shows exactly what bug bounties do. A bounty does not test your website. It tests your organisation: your hosting capacity, your monitoring, your change process and your nerve. A small council’s information site going down under researcher traffic was not a security failure. It was a resilience finding, and arguably the most useful one the programme has produced so far. The pity is that the response was to leave rather than fix the capacity problem.

In my experience, many organisations that want a bounty are not ready for one. Before a penetration test we agree scope, timing, rate limits and emergency contacts. A public bounty brings dozens of testers at once with none of that coordination, and five requests per second sounds modest until you multiply it by every participant against one small server.

The eligibility rules are a trade-off. National identity verification will deter some excellent researchers, including anyone wary of tying their name to findings, a worry raised by readers commenting on Niebezpiecznik. In return CERT Polska gains accountability and a lever against AI-generated report spam, which some programmes have cited when pausing or narrowing rewards.

Building the platform in-house is the bolder decision, because it means taking on triage and payments that commercial platforms normally handle. The real test will be how quickly reported flaws are fixed.

What to do now

  1. Publish a vulnerability disclosure policy and a security.txt file if you have neither. The NCSC’s Vulnerability Disclosure Toolkit is the right starting point, and this is the minimum before considering any paid scheme.
  2. Load-test before you invite testers. Model concurrent automated traffic against in-scope assets and set explicit rate limits in your programme rules. Weak hosting is a resilience risk regardless of any bounty.
  3. Prove you can remediate. Measure how long it currently takes to fix reported issues. A bounty that produces findings faster than you can patch them simply creates a backlog of known exposures. Tie this to the Cyber Essentials security update management control.
  4. Write scope and safe harbour wording carefully. Until the Computer Misuse Act defence exists, clear written authorisation is what protects researchers acting in good faith, and what protects you from arguments about whether they were.
  5. Plan for AI-generated noise. Set out quality requirements, reproduction standards and consequences for invalid reports from the start.

Bottom line

Poland has done something the UK has not: funded a national bug bounty for public systems and kept the whole pipeline in-house. The rules are strict and the start has been messy, but the council outage is a valuable lesson. If UK public bodies want the benefits of crowdsourced testing, they need to be ready for the traffic, the findings and the fixes, and UK researchers still need a law that clearly protects them.

Sources

Related Posts