Compliance Theater vs. Threat Mitigation

One of our recent security scans flagged an issue that, on the surface, seemed straightforward:

A self-signed certificate was being served from direct IP access.

The recommendation was predictable: replace it with a publicly trusted TLS certificate.

Normally, that makes sense. Public-facing services should absolutely use valid certificates. But in this particular case, the recommendation felt backwards.

The service was never intended to be accessed directly via IP address. It is only meant to be accessed through its domain name. And that distinction matters.

Traditionally, services like Let's Encrypt issue certificates for domain names, not raw IP addresses. One possible "fix" would be to simply serve the domain's valid certificate when someone connects directly to the IP.

But that introduces a different problem.

If an attacker is scanning IP ranges and stumbles across that endpoint, the TLS handshake now reveals the hostname of the application. A previously unknown domain has just been exposed during reconnaissance.

Instead, I would rather:

  • serve a generic self-signed certificate
  • avoid exposing the real hostname
  • return a default 404 response for direct IP requests
  • only serve the real application when the correct host header is supplied

In other words, reduce discoverability instead of optimizing for a green checkmark in a scanner report.

This is where I think modern security practices sometimes drift into compliance theater.

Security scanners are incredibly useful, but they operate without context. They see:

  • self-signed cert = bad
  • publicly trusted cert = good

Reality is more nuanced.

Threat mitigation is about understanding intent, exposure, and attack surface. Sometimes the technically "correct" configuration leaks more information than the supposedly incorrect one.

Not every warning deserves blind remediation.

Sometimes the right answer is:

"Yes, the scanner is technically correct. No, changing it would not improve security."

Good security engineering requires threat modeling, not just checklist completion.