Hi, I have worked on security teams, been on both sides of supplier assessments and built infrastructure / deployed vendor agents. Both of these options (assum

Hi, I have worked on security teams, been on both sides of supplier assessments and built infrastructure / deployed vendor agents. Both of these options (assuming best practice configuration) would be acceptable to any security team I've worked on based on the fundamentals. But the limitations of corporate environments and processes mean that one is much easier than the other. Practically speaking, supplier assessment forms usually have standard questions for TLS, endpoints, settings / ciphers etc. The paperwork is more complicated for WireGuard because there are no "boxes" for it, you have to write out lengthy explanations into spreadsheet cells / forms. Often the people filling out the forms are the project team who are not networking experts and they have trouble figuring out what to put where. It produces a small feeling of discomfort for people filling out and reviewing the form because it does not look "completely standard". Since WireGuard is a tunnel, an "alert" person might also ask "oh, what protocols are going over that tunnel and to where? How are THEY secured?" which is possibly a whole other set of questions that never seem to come up with TLS. With my deployer hat on - TLS is the happy path. As a deployer, you often don't "own" the network, that's a separate team. These teams (and their equipment) very greatly in their capability, sometimes they are excellent, sometimes they are dysfunctional. There is usually a standard process or form for "TLS egress to XYZ" - but anything that is NOT this will trigger a complicated workflow requiring actual meetings and people looking at architectures and diagrams etc. You will basically find it "impossible" to deploy into some customer environments if you don't go with TLS, that is the bitter reason why everyone uses it despite other things being "better" along certain dimensions. Even mTLS or non-public CAs won't work "out of the box" if there is a middlebox that does inspection by terminating and re-establishing the TLS connection. There is usually a ticket / standard process to request a bypass for this this - but some customers will need hand-holding through that. That (plus the practical difficulties of terminating it in cloud on the SaaS end, which are mostly solved in 2025 fortunately) is a reason even mTLS is not more widely used. Imagine that the person deploying a pod into k8s, the team managing the cluster, the 2 or 3 teams managing the cloud environment, the team doing the supplier assessment and the team managing the network are all different, don't understand each other's "layers" or job functions well, and often fail to communicate with each other. The interface between some teams might mainly be a ticketing system. Making the deployment work at all in these situations is a challenge, and anything "non-standard" is something that needs to be communicated seamlessly across all these layers.