When “Secure” Is Just a Gut Feeling
mTLS enabled everywhere, dashboards green - and nobody can say what actually runs encrypted.
- Date
- Topic
- Accountability
- Reading time
- 2 min
- Version
- Translation
A familiar scene in Istio audits: mTLS enabled everywhere, dashboards green, compliance boxes ticked.
Figure as text
Two-column comparison of "feels secure", an assumption marked with checkmarks, and "provably secure", evidence marked with question marks. The bottom line: without proof, you are certifying technical debt.
Three hours later, it’s clear: nobody on the team can reliably say which services actually communicate over encrypted connections. The setup is “secure” - by gut feeling.
Not an isolated case. That’s the pattern.
Istio gets adopted to increase security and stability. In practice, I regularly see the opposite. Istio isn’t the problem. The rollout is: approached as a technical exercise, with no structural thinking behind it.
What that costs:
An engineer quits, and the knowledge of how incidents in the mesh even get analyzed leaves with them. Bus factor of 1 as a business risk that shows up in no risk register.
An auditor asks which traffic policies apply where. The answer takes two days and still isn’t conclusive.
In a production incident, time-to-recovery depends on whether “that one person” happens to be reachable.
The actual problem is rarely the configuration. It’s the lack of clarity about who really owns the network behavior in the cluster, which rules are binding (and not merely documented), and whether an incident can be analyzed reproducibly or depends on individual people.
Without these foundations, Istio becomes riskier with every new service instead of safer.
The question is not whether Istio is configured correctly. The question is whether the system behind it was designed to scale - or whether you are certifying technical debt right now.
Which of these symptoms do you recognize in your setup? I’ll turn your answers into the topics for the coming weeks.
