Signal requirements enable a program to set a signal threshold that hackers must reach to submit reports to the program. If a hacker falls below the threshold, they will be limited to a small number of trial reports, shared across all programs whose requirements they don't meet. This will improve the quality of reports programs can expect to receive from hackers.
The signal used for signal requirements is calculated based on a rolling 365-day window. This means that a hacker’s signal is based on their activity from the last 365 days.
Setting your Signal Requirement
Go to Security page > Hacker Management > Submission, then set your signal requirement in the Signal Requirements section. You can choose any value from −1.0 to 7.0, or turn signal requirements off entirely.
Choosing a Value
Setting | What it means in practice |
Off | Any researcher can submit regardless of signal. Best for veteran programs that want maximum participation. |
−1.0 | Excludes only researchers with a consistently negative recent record. Maximises participation. |
0.0 | The long-standing default, for most programs. Excludes researchers with a recent net negative record. |
1.0 | Previously called Strict. Restricts submissions to researchers with a demonstrable record of success. A good starting point for new programs or teams that want lower volume. |
Above 1.0, up to 3.0 | Tighter again. Appropriate if you're receiving high submission volume and want to reduce it materially. Expect a noticeable reduction in the number of researchers who can submit freely. |
Above 3.0 | Very restrictive. A minority of active researchers achieve a signal this high, which effectively limits your program to a narrow set of proven researchers. Worth reviewing the effect on your inbound volume after a few weeks. |
Raising your requirement doesn't completely shut anyone out; researchers below it can still submit using their trial reports, as described below. It does mean more researchers will be drawing on trial reports when they submit to you.
Changing your requirement doesn't affect reports already submitted.
Note: a lower requirement, or turning signal requirements off, suits teams that value having the maximum number of researchers looking for issues.
Trial Reports
Every user has a 3 trial report limit. Trial reports are counted when a participant does not meet the program's signal requirements. Every submission to a program that a Hacker does not currently qualify for uses one. A Hacker’s trial report limit can be refilled in three ways:
Any report of theirs is marked as Triaged or closed with a Resolved returns their trial report limit to 3. It does not need to be a trial report and can be a VDP or BBP report; or
One of their trial reports is closed as a Duplicate of a report marked as Triaged or Resolved where the first-filed report was not disclosed prior to their submission. This returns 1 trial report, up to a total of 3; or
They use all 3 trial reports and wait out a pause of 90 days. The pause starts on the date they submit the third trial report, and ends early if any of their reports are marked Triaged or closed as Resolved.
Trial reports exist to give researchers below a program's requirement a chance to build a track record. Tying them to resolved reports keeps that opportunity open while reducing low-quality reports reaching your queue. A resolved report also raises a researcher's signal, so people finding real issues can continue to submit high-quality reports that will help them move toward meeting your requirements outright.
Setting Per-Program Trial Report Limits
If you want to limit how many trial reports a single researcher can have open to your program at once, speak to your CSM. You can set a per-program requirement from the default of three trial reports to 2 or 1. This requirement restricts the number of open trial reports an individual Hacker can have on your program at any one time.