Standard TLS authenticates the server to the client through the server's public certificate. The client validates that certificate against its configured trusted certificate authorities. Mutual TLS extends this process by requiring the client to present its own certificate so that the server can authenticate the client's identity as well.
MuleSoft describes a TLS-enabled server as exposing its public certificate while retaining its private key, and states that TLS clients validate the server certificate against their trusted certificates. For two-way TLS, both keystore and truststore material are configured so that the server can additionally validate certificates presented by clients.
Accordingly, server identity authentication is part of the TLS handshake before completion of the mutual client-authentication exchange. This makes option C the valid statement in the context of the question.
mTLS does not inherently increase the symmetric encryption strength; cipher-suite strength is independent of whether one-way or two-way authentication is used. A hardware security module can be useful for protecting keys but is not mandatory for mTLS. Finally, mTLS authenticates certificate-bearing client identities, not necessarily individual application end users or their business authorization.
Reference topics: TLS; mutual TLS; two-way authentication; keystore; truststore; client certificate authentication.
Official documentation: https://docs.mulesoft.com/mule-runtime/4.3/tls-configuration
===============================================================
