The State of Security.txt Adoption: An Analysis of 240 Million Domains in 2026

Five years of data reveals a standard struggling to gain traction, propped up by platform automation rather than organic adoption.

Introduction

In April 2022, the IETF published RFC 9116, formalizing security.txt as an official standard for vulnerability disclosure.(1) The concept is simple: place a text file at /.well-known/security.txt containing contact information for security researchers who discover vulnerabilities. Major security agencies including CISA,(2) the UK's NCSC,(3) and government bodies across Europe have endorsed the standard.

But has the industry adopted it?

To find out, we analyzed security.txt adoption each year since 2021 across 826 million total domain scans year after year until 2026. The data reveals a standard that, despite growing 7x in absolute terms, remains adopted by less than a quarter of one percent of all domains. More concerning: the majority of that adoption appears driven by platform automation rather than deliberate security decisions.

The Numbers

The growth trajectory is real: from 82,000 domains in 2021 to 573,000 in 2026 represents a 7x increase. Year-over-year growth rates of 123% (2021-2024), 112% (2024-2025), and 47% (2025-2026) suggest a standard gaining momentum.

At 0.24%, security.txt adoption lags far behind other security standards. HTTPS, with browser enforcement mechanisms, sits at 87.6%.(4) SPF email authentication, enforced by delivery failures, reaches 95.7%.(5) Even DMARC enforcement, which is fully voluntary, achieves 4-5% adoption(6)—still 20x higher than security.txt.

Perhaps security standards without enforcement mechanisms will struggle for adoption. Security.txt has no browser warnings, no delivery failures, no regulatory requirements. Adoption depends entirely on organizational initiative.

The Platform Effect

The most significant finding in our analysis is the role of hosting platforms and website builders in driving adoption. When we analyzed contact information in 2026 security.txt:

60.3% of all domains with security.txt in 2026 point to contacts from identifiable platforms. Only 39.7% appear to be organic, self-implemented deployments.

This represents a form of "checkbox compliance" where the platform, not the domain owner, made the decision to implement security.txt. The domain owner may not even know they have a vulnerability disclosure policy, let alone be prepared to receive security reports.

Webador, a Dutch website builder with over 120,000 customers, accounts for nearly 21% of all security.txt deployments in 2026. Hostpoint, Switzerland's largest hosting provider managing 1.2 million domains,(7) contributes another 10.5%. Neither company publicly documents this auto-provisioning behavior—we discovered it through data analysis.

This raises questions about the meaning of "adoption." Is a security.txt file meaningful if it routes to a platform's generic security contact rather than someone who can actually remediate vulnerabilities in the specific website?

The Bug Bounty Platform Landscape

Bug bounty platforms represent a different category of third-party contacts: organizations that deliberately chose to implement a vulnerability disclosure program. Our data reveals significant market shifts.

HackerOne dominated in 2021, appearing in 78% of bug bounty program security.txt files. By 2026, that share dropped to 80% (of the bug bounty segment) as Bugcrowd and Intigriti gained ground.

This shift aligns with industry reports. HackerOne maintains market leadership with 38.3% mindshare but has declined from 40.3% year-over-year.(8) Bugcrowd, growing at 73% annually with $152M in 2024 funding, has increased mindshare from 25.5% to 32.4%.(9) Intigriti, "Europe's #1 ethical hacking platform," has built a community of 125,000+ security researchers.(10)

In absolute terms, all platforms grew. The overall bug bounty market is projected to expand from $1.52B (2024) to $5.7B (2033) at 15.8% CAGR.(11) But the competitive landscape is fragmenting, and our security.txt data captures this shift in real-time.

The Google Paradox

Google's presence in security.txt data represented they were an early adopter based on their market share comparatively.

These are domains whose security.txt contains Google's Vulnerability Reward Program contacts—either https://g.co/vulnz or mailto:security@google.com. This typically indicates Google-owned properties, domains hosted on Google platforms (Blogger, Firebase, Google Sites), or in some cases, domains that incorrectly copied a security.txt template containing Google's contact information.

Google's absolute numbers grew 31%, but their market share collapsed by 81% as the overall market expanded around them.

RFC Compliance Improves

One positive trend: compliance with RFC 9116 requirements has improved dramatically.

The Expires field, mandatory under the RFC to ensure security.txt files don't become stale, saw adoption rise from 1.78% (2021) to 88.61% (2026). This suggests that newer implementations follow the standard more closely, likely due to better generator tools and clearer documentation.

However, 7.3% of security.txt files in 2026 had already expired, indicating ongoing maintenance challenges. An expired security.txt arguably signals worse security hygiene than having no file at all—it suggests a vulnerability disclosure program that was set up and then abandoned.

Contact Patterns

The type of contact information has shifted:

Early adopters favored URLs pointing to web forms or security pages. Current implementations overwhelmingly use email addresses.

This shift likely reflects the rise of platform-provisioned security.txt files, which default to email contacts. It may also indicate that maintaining web-based vulnerability reporting portals requires more effort than simply providing an email address.

Notably, 93% of domains with security.txt list only a single contact. Multi-contact implementations remain rare, suggesting most organizations haven't invested in redundancy or escalation paths for security reports.

Self-Hosted vs. Third-Party

Who actually receives vulnerability reports?

83% of security.txt implementations route reports to a domain other than the one hosting the file. This reinforces the platform-driven adoption narrative: most security.txt files exist because a hosting provider or website builder added them, not because the domain owner set up a vulnerability disclosure program.

The 15% of domains with self-hosted contacts represent the organic adoption—organizations that deliberately implemented security.txt with their own security team's contact information.

What This Means

Security.txt is a voluntary standard in a world where voluntary security practices rarely achieve scale.

The 7x growth from 2021 to 2026 sounds impressive until you realize 60% of it comes from a handful of hosting platforms auto-provisioning files for their customers. Strip out platform-driven adoption, and organic growth is perhaps 3-4x—meaningful, but not transformative.

The comparison to other security standards is instructive:

• HTTPS reached 87% adoption because browsers display warnings
• SPF reached 95% adoption because emails fail delivery without it
• DMARC enforcement sits at 4-5%, similar to security.txt, because it's purely voluntary

For security.txt to reach meaningful adoption, something needs to change. Possibilities include:

• Browser integration: Display security.txt information when users attempt to report issues
• Regulatory requirements: Mandate vulnerability disclosure policies for certain industries
• Platform defaults: More hosting providers auto-provisioning files (though this raises questions about quality)
• Search engine signals: Include security.txt presence as a ranking factor

Without external pressure, security.txt will likely remain a niche practice—implemented by security-conscious organizations and platforms seeking competitive differentiation, but ignored by the broader web.

Methodology

This analysis is based on scans of gTLD zone file domains for the presence and contents of /.well-known/security.txt files. Scans were conducted in 2021, 2022, 2023, 2024, 2025, and 2026, covering 151M to 241M domains per scan in the year it was performed.

Data was analyzed using DuckDB for efficient processing of the 68GB JSONL dataset. Contact domains were extracted from mailto: addresses and https: URLs to identify organizational patterns.

Limitations:

• Dataset covers gTLD zone files only; ccTLDs are not included
• Scans capture a point-in-time snapshot; domains may have added or removed security.txt between scans. The domain lists were accurate as of the day of the year they were scanned.
• Platform attribution is based on contact domain analysis and may miss some platform-provisioned files using custom contacts

Conclusion

Security.txt adoption has grown significantly since RFC 9116's publication in 2022, but remains below 0.25% of all domains. The majority of adoption is driven by hosting platforms and website builders auto-provisioning files, rather than deliberate organizational security decisions.

The bug bounty platform landscape is fragmenting, with HackerOne's dominance challenged by Bugcrowd and Intigriti. RFC compliance has improved substantially, with the Expires field now present in 89% of implementations.

For security researchers, the practical implication is clear: security.txt remains unreliable as a primary method for finding vulnerability disclosure contacts. When a file does exist, there's a 60% chance it points to a platform's generic security contact rather than someone who can remediate the specific vulnerability.

For organizations considering security.txt implementation: do it deliberately. Create your own file with your own security team's contact information, set an appropriate expiration date, and monitor the email address for incoming reports. The standard works—when it's actually implemented rather than auto-generated.

References

• (1) Foudil, E. and Shafranovich, Y. "A File Format to Aid in Security Vulnerability Disclosure." RFC 9116, IETF, April 2022. https://www.rfc-editor.org/rfc/rfc9116.html
• (2) CISA. "security.txt - A Simple File, Big Value." Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/news-events/news/securitytxt-simple-file-big-value
• (3) NCSC. "Vulnerability Disclosure Toolkit." UK National Cyber Security Centre. https://www.ncsc.gov.uk/information/vulnerability-disclosure-toolkit
• (4) "SSL Certificates Statistics 2025." SSL Insights. https://sslinsights.com/ssl-certificates-statistics/
• (5) "PowerDMARC United States DMARC & MTA-STS Adoption Report 2026." PowerDMARC. https://powerdmarc.com/email-phishing-dmarc-statistics/
• (6) "Red Sift's Guide to Global DMARC Adoption." Red Sift. https://redsift.com/guides/red-sifts-guide-to-global-dmarc-adoption
• (7) Hostpoint AG is Switzerland's largest web hosting provider, managing over 1.2 million domains. https://www.hostpoint.ch
• (8) "HackerOne Closes Record Q2 as Pentesting and AI Red Teaming Business Grows 200%." HackerOne, 2024. https://www.hackerone.com/press-release/hackerone-closes-record-q2-pentesting-and-ai-red-teaming-business-grows-200
• (9) "Bugcrowd Announces Record Growth, Secures $102M in Series E Funding." Bugcrowd, 2024. https://www.bugcrowd.com/press-release/bugcrowd-announces-record-growth-secures-30-million-in-series-d-funding/
• (10) "Intigriti 2024 - A Year in Review." Intigriti. https://www.intigriti.com/blog/news/intigriti-2024-a-year-in-review
• (11) "Bug Bounty Platforms Market Size, Share | Global Research 2033." Global Growth Insights. https://www.globalgrowthinsights.com/market-reports/bug-bounty-platforms-market-116066