On the SEP client, I would like to see a cleaner mechanism for replacing/propigating the certificates used by the SEP client to authenticate their SEPM servers. Currently this occurs automatically and only supports one certificate per server. This creates the situation where replacing/upgrading certs requires you to either disable certificate validation in the environment or stage the replacement over multiple weeks/months if redundant SEPM servers are used so the connection to one server will fail and the updated certificate will be downloaded through a different SEPM from its backend database. A policy mechanism to control which certificates are accepted by the SEP client would allow for cleaner migrations to new certs, popssibly based on a trusted CA to issue for the domain instead of just the fingerprint for the one particular certificate. Operating a SEP environment with a PKI cert would become more viable if the process to upgrade the certificate was less cumbersome.
On SEPM, I would like to see the certificate used for HTML/Java management traffic on 8443/9090 separated from the certificate used for SEP client traffic. Decoupling this would allow environments to continue to auth SEP clients to SEPM with 10yr self-signed certs while administrative users in the management console would no longer need to see errors about self-signed certificates.