Publishing your security.txt

security.txt is a plain-text file that tells security researchers how to report a vulnerability to your organisation. Publish it at https://yourcompany.com/.well-known/security.txt so people and automated scanners can find your reporting channel.

The Cyber Resilience Act requires manufacturers to provide an accessible vulnerability-reporting channel. security.txt is the recognised machine-readable way to publish that channel.

CVD Portal generates an RFC 9116-compliant file from your workspace settings. It can include your security contact email, portal submission link, CVD policy, PGP public key, acknowledgments page, CSAF metadata, supported languages, expiry date, and product support periods.

Change the public security contact

Use Public Security Contact when you need to replace the email shown to researchers. This is separate from the account email that you use to sign in.

1. Sign in to CVD Portal as an administrator.
2. Open Settings → Company Profile.
3. Enter the shared inbox in Public Security Contact. For example: [email protected].
4. Select Save Changes.

Leave the field blank only if you want CVD Portal to use your login email as the public contact.

The saved address is used in all public researcher-facing locations:

• The Contact: mailto: line in generated security.txt files.
• The contact information in the default public CVD policy.
• The follow-up address in report-received and report-acknowledgement emails.

This setting is available on every plan.

If you use a custom policy

When you save a new public security contact, CVD Portal updates an unmodified default policy automatically. It does not overwrite policy text that your team has edited.

For a custom policy, update the email address in Settings → Policy & Security yourself. You can instead select Reset to latest template there if you want to discard your changes and restore the current default policy.

Generate a replacement file

Changing the contact saves the setting. You must still replace the file on your own website.

1. Open Settings → September 2026 → Publish Your Reporting Channel.
2. Enter the domain where you publish your company website, such as yourcompany.com.
3. Select Verify my website.
4. If CVD Portal cannot find a valid file, it displays the exact replacement security.txt.
5. Select Download security.txt or copy the displayed text.
6. Upload the file to /.well-known/security.txt on that domain.
7. Select Verify my website again to confirm that the new file is public.

Copy the file from your browser

Do not send the file to yourself or to a colleague by email. Email security gateways such as Microsoft Defender Safe Links, Mimecast, and Proofpoint URL Defense rewrite every link in a message. A file copied out of an email carries the rewritten links, so Canonical, Policy, Contact, and CSAF all point at the gateway instead of your domain. The file looks correct but researchers cannot use it. Always copy or download the file from the browser.

If your existing file is already valid, keep the generated file as your reference and update your deployment through your website or CI/CD process. The portal does not write files to your company web server.

Publish it on your website

The required public address is:

https://yourcompany.com/.well-known/security.txt

Serve the file over HTTPS as plain text. Do not publish it only at /security.txt; CVD Portal and many scanners check /.well-known/security.txt first.

After deployment, open the URL in a private browser window and confirm that it contains the new Contact: mailto:[email protected] line. Then run the verification step in CVD Portal again.

Your portal serves its own security.txt

Your portal publishes a valid RFC 9116 file at https://<your-slug>.cvdportal.com/.well-known/security.txt with no setup on your part. If you serve your portal on a verified custom domain, the file is served there instead and every link inside it uses your own hostname. The legacy /security.txt path and a /security-policy alias of your policy page are served too, because some third-party checkers only look there.

The file lists your portal submission URL and policy page, your PGP key when you have uploaded one, your CSAF provider metadata on Pro, and your per-product CRA support periods (Article 13(8)). Its Expires field is refreshed automatically, so it never lapses.

This covers the portal host only. It does not put a security.txt on your own company domain, and that is what researchers, EU buyers, and scanners actually check. You still need to publish the generated file at https://yourcompany.com/.well-known/security.txt yourself.

Scanning a domain that already has a portal

The CRA Exposure Scanner recognises a domain that already points at a CVD Portal portal, and links you to your portal and dashboard instead of offering to create a second account.

Detection uses public evidence only: the domain is a portal host, or a verified custom domain we serve, or its own published security.txt points at one. A scan never reveals whether an unrelated domain belongs to a customer.

A recognised domain can still score NON_COMPLIANT, and that verdict is correct. It means your portal is live but your own domain does not yet advertise it, so publishing the generated file is the remaining step.

Troubleshooting

The old email still appears in the file. Confirm that you saved Public Security Contact, then generate a new file. A file already uploaded to your website does not update by itself.

The old email still appears on the policy page. Your team may have customised the policy. Edit the email in Settings → Policy & Security, or reset the policy to the latest template.

Verification cannot find the file. Check the exact /.well-known/security.txt URL over HTTPS, confirm that your web server does not redirect it to a login page, and make sure a CDN has not retained an older copy.

The portal subdomain and company domain show different files. This is expected. CVD Portal serves one file for your portal host, while your website must host its own copy on the company domain.

The scanner reports that a link was rewritten by an email security gateway. Your published file contains URLs on a host such as mimecastprotect.com, safelinks.protection.outlook.com, or urldefense.com. The file passed through email before you published it. Generate the file again, copy it from the browser, and upload the new copy.

The scanner reports that Canonical does not match the file location. RFC 9116 defines Canonical as the authoritative address of the file itself. The value must name the host and path that serves the file. If you publish at https://yourcompany.com/.well-known/security.txt, the line must read Canonical: https://yourcompany.com/.well-known/security.txt. A value that names a different host tells researchers the copy they are reading is not the trusted one.