What Are Time-Boxed Contests and How Do They Work?

Every March, a small group of exploit developers gathers at Pwn2Own and spends three days trying to break fully patched browsers, operating systems, and virtualization software live, on stage, in front of judges holding a stopwatch. A working exploit chain against a target like Chrome or Windows can pay out well into six figures, but only if it lands inside the window. Walk in a day late with the same exploit and it is worth nothing. That single constraint, a hard deadline instead of an open-ended engagement, is what defines a time-boxed contest, and it produces a completely different kind of security testing than either a bug bounty or a pentest.

What a time-boxed contest actually is

A time-boxed contest is a security testing exercise with a fixed start time, a fixed end time, and a defined scope, run as a competition rather than an ongoing program. Researchers are not paid a flat engagement fee like a pentest, and they are not submitting whenever they happen to find something like a standing bug bounty. They are competing against a clock and, usually, against each other, for a prize pool that gets distributed based on the severity and order of what they find.

The compression is the point. A bug bounty rewards patient, long-horizon research. A time-boxed contest rewards intense, focused effort against a narrow target during a window everyone knows in advance. That difference changes researcher behavior completely. People who would never commit to an open-ended engagement will clear their calendar for a weekend if the prize pool and the target are interesting enough, and the live leaderboard turns what would otherwise be solitary research into something closer to a sport.

Where the format comes from

Capture the flag competitions predate the commercial bug bounty industry by years. DEF CON CTF, first run in 1996, is generally considered the origin of the modern format: teams compete to find and exploit vulnerabilities in purpose-built challenge systems within a fixed conference window, and it remains one of the most prestigious events in the field almost three decades later. Pwn2Own followed in 2007 at the CanSecWest conference, and it did something CTF competitions had not done at that scale: it pointed the same time-boxed, competitive format directly at real, shipping, fully patched software, with cash prizes that eventually grew into the hundreds of thousands of dollars for a single working exploit chain.

The corporate world adapted the format soon after. HackerOne began running in-person "h1" live hacking events around 2017, flying researchers to a physical location for 24 to 48 hours to hammer on a client's systems together, with real-time triage happening on-site so a finding could be confirmed and paid within hours instead of weeks. The Pentagon, after the success of Hack the Pentagon in 2016, ran several more time-boxed programs against specific systems rather than leaving every engagement open-ended. The lesson every one of these programs converged on independently is the same: a deadline concentrates attention in a way that open-ended access never quite does.

How a time-boxed contest actually runs

Defining the window and scope. The organizing team picks a start and end time, usually somewhere between 24 hours and a week depending on target complexity, and locks down exactly what is fair game. Scope tends to be narrower and more specific than a standing bug bounty, often a single new product launch, a major version upgrade, or a system going through a migration, because the whole point is concentrated coverage of something specific rather than broad, continuous coverage of everything.

Structuring the incentives. This is where contest design earns its keep. A flat reward table does not create urgency, so most contests layer in tiered prizes by severity, a leaderboard that is visible to every participant in real time, and "first blood" bonuses that pay extra to whoever reports a given class of bug first. That last mechanic matters more than it sounds. It is what stops ten researchers from quietly sitting on the same finding for two days each hoping to be the one who reports it, and instead pushes everyone to report fast and move to the next target.

Running the live window. Triage cannot be a five-day queue during a 48-hour contest. Programs that run these well staff live triage for the entire window, confirming or rejecting submissions within minutes so the leaderboard stays accurate and researchers can see in real time whether a given area is already claimed. This is the single hardest operational piece to get right, and it is usually the difference between a contest that researchers rave about afterward and one they quietly avoid next time.

Closing and judging. When the clock runs out, submissions stop being accepted, and any borderline calls on severity or duplication get resolved by a judging panel rather than the live triage team alone, since the final standings are now permanent and public.

Payout and recognition. Winners get paid, usually faster than a standard bounty program would pay out the same finding, because the entire premise of the event was speed. Recognition matters as much as the money for a lot of top researchers. Public leaderboards, conference talks referencing the contest, and case studies of the winning exploit chains are what turn a good contest into one researchers actively watch for next year.

What gets tested, across every layer of the stack

Because the window is short and the scope is narrow, contest organizers tend to pick a specific slice of their stack rather than everything at once, but every layer shows up somewhere in the contest circuit.

Web applications. Authentication and session handling bugs are disproportionately common in contest settings because they are fast to find and exploit under time pressure, which matters when the clock is running. A classic example is JWT algorithm confusion, where a token verification library trusts the algorithm specified in the token header itself:

APIs. Rate limit bypass and business logic chaining are contest favorites because they reward creativity under a deadline more than raw technical depth. A researcher who chains three "low severity on their own" API quirks into one high-impact exploit within an hour will consistently beat a researcher who spends the whole window on one deep but narrow bug.

Cloud infrastructure. Server-side request forgery against a cloud provider's internal metadata endpoint is one of the most consequential single bugs a contest can turn up, because it can hand an attacker temporary cloud credentials directly. This exact technique, SSRF against the AWS instance metadata service, was the root cause behind the widely documented 2019 Capital One breach, where a misconfigured web application firewall allowed an attacker to reach the metadata endpoint and pull IAM credentials with access to customer data.

Mobile applications. Contest scopes involving mobile apps tend to focus on the newest build, since that is exactly the moment a regression is most likely to have slipped past review, whether that is a reintroduced hardcoded key, a certificate pinning bypass, or a broken deep link handler.

Networks. Segmentation testing fits the time-boxed format naturally, since the question "can a researcher pivot from a low-trust zone to a high-trust one within the window" is inherently a race against the clock, which is exactly what a live contest measures.

Web3 and blockchain. Smart contract contests, sometimes run as standalone events before a major protocol launch, focus intensely on economic exploits like flash loan manipulation and oracle price manipulation, where an attacker temporarily distorts a price feed within a single transaction to drain a lending pool. The time-boxed format suits this domain especially well because a contract audit contest run right before mainnet deployment can catch a catastrophic bug in the exact window where catching it still matters.

IoT and embedded devices. Hardware-focused contests, the kind you see at conferences with a literal table of physical devices, are almost always time-boxed by necessity, since physical access to hardware for extended periods is expensive and hard to scale the way a purely digital scope is.

Why organizations run them

A time-boxed contest solves a problem a standing bug bounty program does not solve well: concentrated attention at exactly the moment it matters most. Launching a major new product, migrating to a new cloud provider, or shipping a significant version upgrade all create a short window where the attack surface has changed faster than your internal team's understanding of it has. A contest throws a large, motivated group of researchers at that exact window instead of waiting for a standing program to slowly get around to the new surface over the following months.

Budget predictability is a real, underrated advantage too. A contest has a fixed prize pool and a fixed date, which makes it far easier to plan and justify internally than the open-ended, variable cost of a standing bounty program, even though the two are complementary rather than competing approaches. Many organizations run both: a standing bug bounty for continuous coverage, and periodic time-boxed contests around major launches for concentrated coverage exactly when the risk is highest.

There is also a team-building and marketing dimension that should not be underestimated. A well-run contest generates a leaderboard, war stories, and often a public writeup of the winning exploit chain, all of which signal to customers and the researcher community that an organization takes security seriously enough to invite the best researchers to actively try to break it, in public, on a deadline.

What it takes to run one well

The contests researchers remember for the right reasons share a few traits. Triage capacity is staffed for the entire live window, not scaled down overnight, because a contest that goes quiet for eight hours loses momentum it never fully recovers. The scope is narrow enough to be genuinely tested in the time available rather than an ambitious wishlist that guarantees shallow coverage. The prize structure rewards speed and severity clearly enough that researchers know what a given class of bug is worth before they commit their weekend to it. And the results, at least the high-level ones, get shared afterward, because a contest that pays out in silence never builds the reputation that makes the next one worth clearing a calendar for.

This is precisely the model behind HackerSavanna's own time-based contests, covered in more depth on the platform page, built for the exact moment a new launch or migration needs concentrated attention rather than open-ended coverage. If you have a launch window coming up and want a live leaderboard, tiered prizes and real-time triage running against it, onboard your organization to get a contest scoped. Not sure yet what shape of contest fits your timeline? Get in touch and the team will help you work it out.

Done right, a time-boxed contest is not a smaller version of a bug bounty program. It is a different instrument entirely, built for the specific moments when an organization needs its most motivated researchers looking at its newest, least-tested surface, all at once, before the deadline runs out.