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}/reports/new. No account is required — the researcher provides an email address and Kit handles the rest.

Required Fields

Field	Description
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
Severity (Self-Assessed)	The researcher’s own estimate — not binding on your team’s final assessment
Description	Full details of the vulnerability, with Markdown support
Reproduction Steps	Step-by-step instructions to reproduce the issue
Impact	What data or functionality is at risk if the vulnerability is exploited
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 rate limiting applies per IP address to prevent automated spam from reaching your triage queue.

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
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 and your team is notified via the appeal_received email template and a Slack notification (if configured)
4. Your team reviews the appeal from the report detail view and can either uphold or overturn the original dismissal

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
• Acceptance is recorded with a timestamp
• The researcher can optionally upload a signed copy of the document

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 bank account details
• PayPal — Researcher provides their PayPal email address
• Crypto — Researcher provides a wallet address

Payout information is encrypted at rest. Once submitted, the full details are never displayed again in the portal — the researcher sees only a confirmation that their information is on file. Your team uses this information solely to execute the transfer. See Bounties and Payouts for the full disbursement workflow.

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

Researchers can opt in to your program’s public Hall of Fame from their portal profile. This is entirely voluntary — no researcher is listed without their explicit consent.

How it works:

• In the portal profile page, the researcher toggles Show my handle publicly
• Only their handle is displayed on the public leaderboard — never their real name or email address
• Your team can feature specific researchers from the Hall of Fame management page in the staff dashboard (featured researchers appear first)
• The public Hall of Fame is accessible 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}/reports/new) 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