Security.txt Adoption Across DENOG17: Where Does Your Organization Stand?

Published on 11/10/2025

Security.txt Adoption Across DENOG17: Where Does Your Organization Stand?

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:

  1. Single point of contact for vulnerability reports
  2. Encryption for authenticity through PGP signatures
  3. Expiration dates to ensure information stays current (within one year)
  4. 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