A software shouldn’t use passwords for tls, just like before you use submit your bank password your network connection to the site has been validated and encrypted by the public key your client is using to talk to the bank server, and the bank private key to decrypt it.
The rest of the hygiene is still up for grabs for sure, IT security is built on layers. Even if one is broken it shouldn’t lead to a failure overall. If it does, go add more layers.
To answer about something like a WiFi pineapple: those man in the middle attacks are thwarted by TLS. The moment an invalid certificate is offered, since the man in the middle should and can not know the private key (something that isn’t used as whimsically as a password, and is validated by a trusted root authority).
If an attacker has a private key, your systems already have failed. You should immediately revoke it. You publish your revokation. Invalidating it. But even that would be egregious. You’ve already let someone into the vault, they already have the crown jewels. The POS system doesn’t even need to be accessed.
So no matter what, the WiFi is irrelevant in a setup.
Being suspicious because of it though, I could understand. It’s not a smoking gun, but you’d maybe look deeper out if suspicion.
Note I’m not security operations, I’m solutions and systems administrations. A Sec Ops would probably agree more with you than I do.
I consider things from a Swiss cheese model, and rely on 4+ layers of protection against most understood threat vendors. A failure of any one is minor non-compliance in my mind, a deep priority 3. Into the queue, but there’s no rush. And given a public WiFi is basically the same as a compromised WiFi, or a 5g carrier network, a POS solution should be built with strengths to handle that by default. And then security layered on top (mfa, conditional access policies, PKI/TLS, Mdm, endpoint health policies, TPM and validation++++)