The Researcher Portal

Why It Matters

Researchers are far more likely to submit through a transparent, structured portal than a blind security@ inbox. A clear submission flow with built-in status tracking shows researchers you take their work seriously, which attracts higher-quality reports and builds long-term trust with the security community.

Kit’s researcher portal uses magic-link authentication — no passwords to manage, no accounts to create. This eliminates friction for one-time researchers while maintaining accountability and a secure communication channel for every report.

What Researchers See

The researcher portal lives at a separate URL from your staff dashboard:

/security/{program-slug}/

This is a public-facing portal — distinct from the Kit admin interface your team uses. The experience is designed around three principles:

Custom Domain (VDP Add-on)

With the VDP Add-on you can serve your security portal on your own domain — for example security.yourcompany.com — instead of the default Kit subdomain path. Point a DNS CNAME record at Kit and add the domain under Account Settings > Custom Domains. Once the domain is verified and active, all portal URLs (/policy, /report, /hall-of-fame, /.well-known/security.txt) are served directly from your domain with no path prefix.

Custom security portal domains require the VDP Add-on ($49/mo).

• Low barrier to entry — No login required to submit a report. Researchers only need an email address.
• Transparency after submission — Once a report is submitted, the researcher receives a magic link via email to access their portal. From there they can see their submitted reports, each report’s current status, the message thread with your team, and a timeline of events.
• Strict isolation — Researchers cannot see internal staff notes, other researchers’ reports, or any details beyond their own submissions.

Submitting a Report

The public submission form is available at /security/{program-slug}/report. No account is required — the researcher provides an email address and Kit handles the rest.

Required Fields

Field	Description
Title	A short summary of the vulnerability
Vulnerability Type	OWASP category selected from a dropdown (SQL Injection, XSS, Broken Auth, IDOR, SSRF, RCE, etc.)
Affected Endpoint	The URL or system component where the vulnerability exists
Description	Full details of the vulnerability, with Markdown support
Reproduction Steps	Step-by-step instructions to reproduce the issue
Severity (Self-Assessed)	The researcher’s own estimate — not binding on your team’s final assessment
Email Address	Used for magic-link portal access and all notifications

Researchers can also attach files — screenshots, proof-of-concept code, or video recordings. These are optional but encouraged for complex vulnerabilities.

A CAPTCHA challenge is presented on submission, and the endpoint is throttled per IP address, to keep automated spam out of your triage queue. Beyond that, Kit tracks each submitting email address and IP and blocks a burst — more reports than your configured threshold inside a short window. A researcher working steadily over days or months never trips it; the counter resets every time a window closes.

After Submission

Once a report is submitted, two things happen immediately:

1. The report appears in your team’s triage queue (see Triaging Reports)
2. The researcher receives a confirmation email with a magic link to their portal

The magic link grants access to the researcher portal without any password. Every subsequent email notification also includes a fresh portal link via the {{ portal_link }} template variable.

Magic-Link Authentication

The portal uses email-based magic links instead of passwords. Here is how it works:

1. Researcher visits /security/{program-slug}/ and enters their email address
2. Kit sends a one-time login link to that address
3. Clicking the link authenticates the researcher and opens their portal
4. The session persists until the browser is closed or the link expires

If a researcher does not have an existing session, they can request a new magic link at any time from the portal login page. A “Submit a new report” link is also available on the login page for first-time visitors.

Viewing Report Status

From the portal, researchers see a list of all reports they have submitted. Each report card shows:

Element	Details
Report ID	Unique prefixed identifier (e.g., RPT-abc123)
Title	The vulnerability title from the submission
Severity	Displayed once your team has completed their assessment
Status	Current status in plain language (e.g., “Validated”, “In Progress”, “Resolved”)
Bounty	Amount and status, if a bounty has been approved. An internal bounty proposal your team is still discussing never appears here, and never triggers an email.
Payout prompt	A nudge to add payout details when an approved bounty is waiting on them. A payment that later bounced is not flagged on the card — that appears once they open the report, and by email (see When a Payment Fails)
Submitted Date	When the report was originally filed

Clicking into a report shows the full detail view: the original submission content, the current status with an explanation, the message thread (external messages only — internal staff notes are hidden), and a timeline of all transitions.

Researchers cannot edit report details after submission. They can communicate with your team by sending messages in the report thread, which is the primary channel for clarification requests and status updates. See Communicating with Researchers for how your team manages these conversations.

Appeals

When your team dismisses a report, the researcher has the option to appeal the decision directly from the portal.

How Appeals Work

1. The researcher opens the dismissed report in their portal
2. They click Appeal and provide a written justification (minimum 10 characters)
3. The appeal is submitted; Kit alerts your on-call responder and posts a reply in the report’s Slack thread (if Slack is connected), each linking straight to the appeal panel on the report. The researcher is emailed a confirmation that their appeal was received.
4. Your team reviews the appeal from the report detail view and either accepts or rejects it:
   • Accept — your team agrees with the researcher. If the report was dismissed, accepting reopens it and returns it to triage. The researcher is emailed that the appeal was accepted.
   • Reject — your team upholds the original decision. The researcher is emailed that the decision stands.

Either way the decision, the reviewer, and the timestamp are recorded on the report. See Triaging Reports for the team side of this flow.

Appeal Limits

Each report has a configurable maximum number of appeals. The default is 3 appeals per report. You can adjust this limit in your program’s Triage Settings. The portal displays how many appeals have been used (e.g., “Appeals used: 1 of 3”) so researchers know where they stand.

NDA / Agreement

You can optionally require researchers to accept a program agreement before a bounty is disbursed. This is useful for non-disclosure agreements or coordinated disclosure terms.

• Configure the agreement text in Program Settings using the rich text editor
• When a bounty is approved, the researcher sees an Accept Agreement prompt in their portal
• The researcher accepts electronically with a single click — there is no file to sign or upload
• Acceptance is recorded with the exact agreement text in force, a timestamp, and the researcher’s IP address

Agreement acceptance is a prerequisite for payout — if enabled, the disbursement pipeline will not proceed until the researcher has accepted.

Payout Setup (VDP Add-on)

After your team approves a bounty, the researcher is prompted in their portal to provide payout information. This section is only available with the VDP Add-on ($49/mo).

Supported payout methods depend on what you have configured in Program Settings:

• Bank Transfer — Researcher provides their bank name, account number, and routing number
• PayPal — Researcher provides their PayPal email address

Payout information is encrypted at rest. It is shown back only to the signed-in researcher, on their own payout page, so they can check and correct what is on file — which is what a failed payment usually requires. Your team never sees the full details. Staff screens show a masked handle only (••••4321 for a bank account, j•••@example.com for PayPal). The full account number and routing number appear in exactly one place: the one-time, 90-day confirmation link sent to your finance inbox, which is the secure channel the person scheduling the transfer actually needs. See Bounties and Payouts for the full disbursement workflow.

When a Payment Fails

If a bounty payment bounces, the report’s detail page shows a banner — Your $X bounty needs new payout details — explaining that the payment could not be delivered and that the full amount is still reserved for them. Its Update payout details button opens the payout page.

The bounty badge on that page tracks the loop in two steps. Needs payout details means the payment bounced and Kit is waiting on them. Resending payout means they have supplied new details and your team can now re-queue the payout.

On the payout page an inline callout names the rail that failed, by its masked handle, and asks them to enter a different account or fix that one with their provider first. The field that bounced carries a matching hint with the date.

Kit also emails the researcher directly, with a magic link that lands them on the payout page in one click. That email names the reason in plain language but never quotes anything your team or your finance contact typed.

Retry is a staff action. Once the researcher saves new details their badge sits at Resending payout until someone on your team clicks Retry — the portal tells them so rather than implying the money is already moving.

Tax Documents (VDP Add-on)

For programs that require tax documentation before disbursement, researchers upload their forms directly through the portal. This section is only available with the VDP Add-on ($49/mo).

Document	Who Needs It	Purpose
W-9	US-based researchers	Required by the IRS for domestic payments exceeding $600/year
W-8BEN	Non-US researchers	Certifies foreign status and claims treaty benefits to reduce withholding

Upload flow:

1. After a bounty is approved, the researcher sees a prompt in their portal to upload the appropriate tax document
2. The researcher selects the document type (W-9 or W-8BEN) and uploads the file
3. Your team reviews and marks the document as verified or rejected from the Tax Documents queue in the staff dashboard
4. If rejected, the researcher is notified and can upload a corrected version

A recurring background job monitors document expiration dates and sends reminders to researchers when their documents are approaching expiry. Tax document verification is a prerequisite for disbursement when this requirement is enabled in your program settings.

Invite-Only Access Control

By default, your security portal is publicly accessible to anyone with the URL. You can switch to invite-only mode to restrict who can submit reports — useful for private programs, early access betas, or programs limited to a curated researcher list.

To enable it, go to VDP > Security Portal Settings and set Access Control to Invite Only. Kit automatically generates a secret access token. Share the resulting invite URL directly with trusted researchers — it includes the token and grants a persistent browser session on click.

Access Request Form

When a visitor lands on your locked portal without a valid token, instead of a dead end they see a short Request Access form. They can enter their email and an optional message explaining their interest. You are not obligated to approve every request, and submitting the form does not tell the visitor whether their email was already pending — preventing enumeration.

When a request comes in:

1. A notification email is sent to your security.txt contact email (or account billing email as fallback)
2. The Access Requests item appears in the VDP sidebar under Configuration, with a badge showing the pending count
3. Open VDP > Access Requests to review pending requests — email address, optional message, and submission date are shown
4. Click Approve & Send Invite to send the requester their personal invite link in one step

The invite link sent on approval is the same token-based URL you would share manually. Once a researcher clicks it, they have a persistent session and can submit reports normally.

Hall of Fame

Your program’s public Hall of Fame credits researchers who reported valid vulnerabilities. Listing is consent-based: no researcher is published without choosing it (or without your team recording a consent they gave you directly).

Recognition preferences. In the portal profile, each researcher picks one of three options; until they answer, their state is “not asked”:

• Named — credited publicly by handle (or name, if they have no handle). Their email address is never shown.
• Anonymous — credited as a Private Researcher row that keeps its rank and report count, but shows no name.
• Not listed — published nowhere. This is a hard refusal: your team cannot override it.
• Not asked — the researcher never answered. Your team can ask them (see below), or credit them by recording a consent obtained elsewhere.

Asking for consent. You do not have to wait for a researcher to answer on their own. Open their profile in the staff dashboard and click Ask for consent — Kit emails them a link, good for 30 days, that opens without a login and offers the same three choices. Whatever they pick becomes their recognition preference everywhere, exactly as if they had set it in their portal, and whoever sent the ask is notified of the answer.

The Credit me by name choice carries a name field, prefilled with the name Kit already has for them and editable before they answer — nobody should consent to a credit they were never shown. Whatever they enter becomes their public credit name everywhere, not only on your Hall of Fame, and a researcher with no name on file has to supply one before that choice will save.

The option appears only for a researcher who has never answered and who has at least one valid report on your program. A researcher who chose Not listed can never be asked — that refusal stands. Otherwise one ask can be outstanding at a time, a reminder can follow after seven days, and once someone has answered you cannot ask them again for 30 days.

A “yes” still publishes nobody. Your team adds the Hall of Fame entry by hand as always, choosing the year, display name and link. What changes is that the consent is now yours first-hand, so the entry records the researcher’s own answer and the date they gave it instead of an attestation from your team.

Curation. The Hall of Fame management page in the staff dashboard lets your team:

• Add researchers who have at least one valid report on the program (dismissed-only reporters are not addable). If someone to be credited by name has no name on file, the form asks you for a display name — without one the entry would publish them as a Private Researcher, the opposite of what they agreed to
• Publish a “not asked” researcher by attesting a consent given in the report thread or by email — Kit stores who recorded it, when, and where the consent came from. A researcher who answered a consent request needs no attestation
• Credit someone else: a manual entry for an off-platform reporter (an email-only submission, or a fix from before the program existed) with a display name, an optional link and a short public note
• Edit any entry’s display name, note, link, and credited date
• Feature entries — featured researchers genuinely sort first on the public page
• See each row’s publication state at a glance (Published / Private / Not listed / Manual)

Who to credit next. The management page’s Recommended tab lists researchers who have filed valid reports on your program but are not credited publicly yet, most deserving first. The order weighs how severe their findings were — a critical counts for far more than a low — how many valid reports they filed, and whether those reports were paid out; spam and low-quality submissions on their record count against them. A report nobody has assessed yet still counts, only slightly: unranked is not the same as trivial. Bounty amounts are shown for context but never move the ranking, because programs pay in different currencies. Each row shows the evidence as chips rather than a score, so you can always see why someone is where they are.

The action on a row follows their consent. A researcher who has already told you how they want to be credited can be added to the Hall of Fame from there; one who has not is offered Ask for consent instead, because Kit never publishes a name nobody agreed to. A third tab tracks who has been asked and not yet answered. Anyone who chose Not listed never appears in any of them.

The public page. Entries are grouped by the year they were credited, newest first, and each entry has its own permalink at /security/{program-slug}/hall-of-fame/{entry-id} with the credit, report count, note, and moderated link. Report counts refresh automatically when a report’s status changes. The list is available at /security/{program-slug}/hall-of-fame.

The Hall of Fame is a low-cost incentive that works especially well for recognition-only programs (no monetary bounties). Enable it in Program Settings to give researchers a reason to opt in.

Quick Checklist

• Verify your submission form URL (/security/{program-slug}/report) and share it in your security.txt and website footer
• (VDP Add-on) Set up a custom domain (e.g. security.yourcompany.com) under Account Settings > Custom Domains for a branded researcher experience
• Test the magic-link flow by submitting a test report with a personal email
• Customize the Report Acknowledged email template so researchers know what to expect after submitting
• Configure the appeal limit in Triage Settings (default: 3 per report)
• Set up an NDA/agreement if your program requires one before payout
• Enable the Hall of Fame in Program Settings to incentivize researcher participation
• If running a private program, enable invite-only access control in Security Portal Settings and share the invite URL with trusted researchers
• If using the VDP Add-on, verify the payout methods and tax document requirements are configured correctly

Next Steps

• Bounties and Payouts — the full disbursement pipeline, tax documents, and financial ledger
• Communicating with Researchers — message threads and email templates
• Submission Limits and Spam Blocks — why a submission can be refused, and how to unblock a researcher