At DENOG17, Sascha Heinemann presented our findings on security.txt adoption across the German network operator community. What started as a simple question "who else follows the official recommendations?" turned into an analysis that reveals both progress and significant room for improvement in our industry.
Test Your Security.txt
Check if domains have implemented a valid security.txt following RFC 9116. Use our free checker:
Why This Research Matters
At EdgeOps, we develop, among other solutions, whitelabel data center portals with digitized processes for access requests and cross-connect orders. Our development is community-driven, shaped by real feedback from network operators like those at DENOG. When we decided to implement security.txt following official recommendations, curiosity led us to investigate: how many organizations in our community have done the same?
What is Security.txt?
For those unfamiliar, security.txt (RFC 9116) is a standardized way for organizations to publish security contact information. Think of it as providing a clear emergency exit for security researchers and responsible disclosure.
The standard defines four main guidelines:
- Single point of contact for vulnerability reports
- Encryption for authenticity through PGP signatures
- Expiration dates to ensure information stays current (within one year)
- Clear policies that set expectations for security researchers
The implementation is straightforward: a simple text file at /.well-known/security.txt with defined fields like Contact and Expires, formatted to be machine-readable.
Both the U.S. CISA (2019) and German BSI (2024) officially recommend this standard.
The Sobering Reality: Our Findings
We analyzed 239 organizations from various industries represented at DENOG17. Here's what we found:
- Only 25% (60 organizations) have implemented security.txt at all
- Of those 60, only 25% (15 organizations) have a valid security.txt
- When looking at implementation including PGP signatures and proper expiration dates only 7 organizations meet all criteria
Let that sink in: out of 239 organizations, only 7 implement this security best practice correctly.
Industry Breakdown
The adoption rates vary significantly across sectors:
| Industry | Total | With security.txt | Adoption Rate | Valid implementation | Validity Rate |
|---|---|---|---|---|---|
| Public Authority | 3 | 2 | 67% | 0 | 0% |
| Education & Research | 20 | 8 | 40% | 3 | 15% |
| Internet Exchange | 7 | 3 | 43% | 0 | 0% |
| Hosting & Cloud Services | 42 | 13 | 31% | 2 | 5% |
| Datacenter & Colocation | 16 | 4 | 25% | 0 | 0% |
| Consulting & Services | 70 | 15 | 21% | 5 | 7% |
| Carrier | 48 | 8 | 17% | 4 | 8% |
| Hardware | 18 | 3 | 17% | 0 | 0% |
| Other | 15 | 4 | 27% | 1 | 7% |
We'd particularly like to call out hardware manufacturers. Having a standardized way to report vulnerabilities is beneficial for everyone in the ecosystem. With only 17% adoption, there's a lot of room for improvement.
Honorable Mentions
Our research uncovered some interesting edge cases:
Heise.de: www.heise.de has a security.txt, but heise.de (without www) does not. The solution? Route all traffic to the canonical URL to ensure consistent access to security information.
BSI: The German Federal Office for Information Security's security.txt expires in 2099, meaning it will remain valid for 74 years, longer than the BSI has existed! While creative, this violates the RFC's requirement for expiration within one year.
DE-CIX: Proves that security.txt doesn't have to be boring. Unfortunately using special characters breaks the machine readability test.
Why Security.txt Matters for Network Operators
We interpret the scope of security.txt not just as "we found a vulnerability on your website," but as a central source of contact for all security matters related to a provider's services.
A network operator without a clear security contact is like a building without an emergency exit.
When security researchers discover vulnerabilities, they need a reliable, standardized way to report them. Security.txt provides exactly that: a machine-readable, easily discoverable contact method that works across the entire internet.
Test Your Own Security.txt
Use our interactive checker to verify your own security.txt implementation:
Looking Forward
This research represents a snapshot of our community at DENOG17. We'd love to revisit this topic next year to see if adoption has increased. Our hope is that by highlighting both the champions and the gaps, we can encourage broader adoption of this simple but crucial security standard.
Will your organization be among the leaders next year?
Special thanks to the DENOG community for the inspiration and to all organizations already implementing security.txt
security.txt Checker
Enter your domain to validate its security.txt setup. The checker follows RFC 9116 and only requests /.well-known/security.txt over HTTPS/HTTP