CVD Portal
← All tools
Free Tool

security.txt Generator

Generate a standards-compliant security.txt file (RFC 9116) for your product or website. Required by the EU Cyber Resilience Act to make your vulnerability reporting contact discoverable.

Last updated 29 August 2026

Key takeaways

  1. RFC 9116 standardises the security.txt format to publish discoverable security contact information for websites and digital products.
  2. CRA Article 13 requires manufacturers to maintain a publicly accessible single point of contact for vulnerability reporting.
  3. RFC 9116 places the file at /.well-known/security.txt, where researchers and automated tools look for it.
  4. RFC 9116 mandates an Expires field so security researchers and automated tools can verify the file is current.

Required. Primary email for vulnerability reports.

A web form or portal URL as an additional Contact.

Link to your public coordinated vulnerability disclosure policy.

RFC 9116 requires an expiry date. Update annually.

Link to your PGP public key for encrypted reports.

Link to your CSAF 2.0 advisory feed. Increasingly expected under CRA Annex I.

/.well-known/security.txt
# security.txt — https://securitytxt.org

Contact: mailto:security@example.com
Preferred-Languages: en
Expires: 2027-09-04T17:23:36+00:00

Upload this file to /.well-known/security.txt on your web server. CVD Portal generates and hosts your security.txt automatically.

Copy this file from your browser. Email security gateways rewrite links, so a copy taken from an email points at the gateway instead of your domain.

Frequently asked

What is security.txt?+

security.txt is a proposed standard (RFC 9116) that defines a file format for websites and products to communicate their security contact information. It is placed at /.well-known/security.txt and tells security researchers how to report vulnerabilities.

Is security.txt required by the CRA?+

The CRA requires a publicly accessible single point of contact for vulnerability reporting (Article 13). A security.txt file is the most widely-adopted way to publish this contact - it is discoverable by researchers, automated scanners, and CVD platforms.

Where do I publish the security.txt file?+

Place the file at /.well-known/security.txt on your website. For products without a web presence, link to the security.txt from your product documentation or CVD policy page.

Does the Expires field matter?+

Yes - RFC 9116 requires an Expires field. Researchers and tools use it to verify the file is current. Set it 1 year ahead and update annually. CVD Portal updates your security.txt automatically.

Other free CRA tools

CVD Policy GeneratorBuild a complete, publication-ready CVD policy document using a guided five-step wizard. Configure your response timelines, CRA Article 13 and 14 obligations, and product scope, then export a finished Markdown policy you can publish immediately.Article 14 Deadline CalculatorEnter the date and time you became aware of an actively exploited vulnerability or severe security incident. Get your exact Article 14 notification deadlines for ENISA reporting.CRA Vulnerability Disclosure Readiness CheckA 20-question check of your readiness to handle and report vulnerabilities under CRA Articles 13 and 14. Focused on coordinated disclosure, acknowledgment turnaround, ENISA reporting and advisories. For a whole-programme view across all five CRA domains, use the CRA Maturity Assessment.CSAF 2.0 Advisory ValidatorPaste your CSAF 2.0 JSON advisory and instantly validate the structure against the OASIS CSAF 2.0 schema. Identifies missing mandatory fields, invalid values, and flags common issues that would cause rejection by automated consumers and ENISA tooling.SBOM Exposure SnapshotUpload or paste a CycloneDX, SPDX JSON document or dependency manifest to scan all declared components against the OSV.dev open vulnerability database. The scanner identifies known CVEs and security advisories with precise version matching, returning an immediate severity breakdown across Critical, High, Medium, and Low vulnerabilities alongside top exposed components. The live interactive scanner is available at /sbom-exposure with no registration required. The tool operates in-request and does not store your SBOM data on our servers. For continuous vulnerability monitoring and full CRA Annex I Part II(1) due diligence, CVD Portal integrates SBOM ingestion with automated alerting and CSAF 2.0 advisory generation.SBOM Validator (BSI TR-03183-2 and CISA 2026 Minimum Elements)Upload or paste a CycloneDX or SPDX JSON SBOM and check it against BSI TR-03183-2 v2.1.0, the German federal guideline that concretises the CRA SBOM requirement. The validator verifies the minimum specification version of CycloneDX 1.6 or SPDX 3.0.1. It checks every required data field for the SBOM and for each component, including creator, timestamp, dependencies, licences, and hashes. Validation runs entirely in your browser. The same document is also assessed against the 2026 Minimum Elements for a Software Bill of Materials, version 2.1. CISA published this specification with seventeen partner agencies, including seven EU national cybersecurity authorities. That document replaced the 2021 NTIA minimum elements and expanded the field count from seven to seventeen. It is not EU law and creates no CRA obligation, but it is increasingly what procurement asks for. The two verdicts are reported separately and never blended because the frameworks disagree on key requirements. TR-03183-2 sets minimum format versions that the 2026 elements do not. In addition, the 2026 elements require transitive dependency coverage that CRA Annex I Part II(1) does not.

Ready to automate your CVD programme?

CVD Portal integrates all these tools and handles your Article 13 and 14 obligations automatically.

Start your free portal →