Currently, all encrypted transport between Zabbix Server/Proxy and Zabbix Agents requires explicit authentication configuration: either pre-shared keys (PSK paired with PSKIdentity) or mutual PKI certificates (cert with full CA validation).
While this provides strong MITM (Man-in-the-Middle) protection, it introduces significant deployment friction in scenarios where:

• Users want basic privacy/confidentiality over the wire against passive sniffing without running an internal PKI or distributing symmetric keys.
• Ephemeral, large-scale cloud environments (containers, dynamic VMs) are spun up, and managing PSK secrets across templates adds operational overhead.
• Users want a graduated security model: Phase 1 (Transport encryption on by default)
• Phase 2 (Add PSK or strict CA validation later when identity pinning is required).

Currently, if an Zabbix user does not want to manage keys upfront, their only choice is plaintext transmission (unencrypted), exposing all metric payloads and system metadata to passive eavesdropping.

Expected Benefits

• Zero-touch security baseline: Enables encrypt-by-default out of the box.
• Lower barrier to entry: Eliminates manual steps in host/template creation for users who simply need encrypted transit.
• Parity with standard network tools: Aligns with standard practices seen in modern databases, mail protocols (opportunistic STARTTLS), and web services.

Components/expectations:

• Server to Agent (Active/Passive);
• Server to Proxy (Active/Passive);
• Frontend to Server (encryption done under ZBXNEXT-8698 is too complicated);
• Server is supplied with self-signed certificates (generated during first start), like MySQL, or other software, which are enough  for base TLS encryption between the components; 

Regards,

Edgar