A bonus-calculation service receives data from the HR system. Until now, an internal network address was enough to accept the request. Test applications and a contractor now share that network. The address says less and less about who actually sent the information.
Mutual TLS lets both endpoints authenticate using certificates: payroll should recognise HR, and HR should recognise the real calculation service. Recognising an endpoint still leaves a separate question about permission to change a payment. A network setting cannot decide that business rule.
Presenting a certificate is not the same as proving possession
With ordinary HTTPS, the client verifies the server. Mutual authentication also verifies the client. A certificate associates a public key with an identity; the endpoint proves possession of the corresponding private key. Copying somebody's public certificate is not enough. TLS 1.3 specifies this proof.
TLS already protects the connection. The additional client certificate provides reciprocal authentication, not “double encryption”. The server must actually require an authenticated client: installing certificates does not, by itself, prove that requests without them are rejected.
A valid certificate may belong to the wrong application
Validation involves more than an expiry date. The issuer must be trusted, the certificate must be suitable for its purpose, and the peer must match the expected identity. Another application with a certificate from the same authority must not automatically inherit HR's permissions.
Service identity should survive replacement of a machine. For example, SPIFFE X.509-SVID places an identity in a certificate's URI SAN field. This is one concrete design, not a requirement to adopt SPIFFE for every integration.
Issuance needs its own controls. If a test process can obtain the production HR identity, later certificate validation will faithfully confirm an incorrectly issued credential. Separate environments, restrict registration and record why each identity was granted. A certificate inventory alone does not establish that issuance was legitimate.
Authorisation follows authentication. HR might submit approved adjustments without permission to change bank details. Where an employee initiates an operation, their authority still matters. A machine certificate does not establish the employee's right to perform that particular action.
If an attacker compromises the application holding the legitimate key, mTLS may correctly authenticate it. Restricted permissions and application protection remain necessary. A valid identity is not proof of good behaviour.
Where does the authenticated connection end?
Certificates can be checked in the application, at a gateway or by a network proxy. That choice changes the trust boundary. When mTLS terminates at a gateway, the connection from gateway to application is another hop. The application needs a trustworthy account of the verified caller.
Some integrations pass that identity in a request header. Arbitrary clients must not be able to supply an authoritative version of it, and direct access must not bypass verification. Envoy's handling of X-Forwarded-Client-Cert illustrates why sanitising and forwarding identity are explicit configuration choices.
A service mesh can automate certificates and connections, but one integration does not necessarily justify an entire platform. Trace the real request path first: who checks identity on each hop, and who enforces permission?
The first successful handshake is the easy part
Certificates expire. Renewal must issue fresh credentials, deliver them and ensure that running processes use them. A new file on disk is insufficient if an application still holds the old certificate in memory. Testing only an established connection may miss the problem.
Changing a trusted authority is more involved than renewing one application's certificate. Recipients may need a bounded transition period accepting both old and new issuers. Test the sequence through removal of the old trust. Keeping every past authority forever is not a completed migration.
Operations needs evidence of successful renewal and remaining validity, rather than an alert on the final day. Istio's security architecture automates issuance and renewal. Teams still need to test new workloads, trust changes and delivery failures.
What actually stops after a compromise?
Replacing a certificate and removing the old authority to connect are different actions. A stolen key may remain usable while recipients still trust its certificate. Revocation behaviour depends on the deployed infrastructure; an administrator's decision does not automatically reach every participant.
Existing connections and resumed sessions need their own treatment. Refusing a new connection does not necessarily terminate an established one. An important integration needs an agreed place to disable an identity, a connection-termination procedure and a way to demonstrate that access has ended.
An issuance outage may initially leave running instances unaffected while preventing new ones from starting or existing ones from renewing. Those are separate test cases. Remaining certificate validity buys little protection when nobody notices that renewal has stopped.
Accept the integration on its failures as well as its successes
For HR and payroll, test a permitted transfer, a client without a certificate, another application's certificate and an operation outside the caller's permissions. Then renew credentials on a live instance, replace the instance and disable a test identity. Use an authorised test environment without real payments.
Support should distinguish an untrusted issuer, expiry, an authorisation denial and a network failure. Private keys must not appear in diagnostic output. These exercises show which duties the company can sustain and which missing control it has actually gained. That is a more useful basis for choosing mTLS than a count of connections labelled secure.