MAY 2026
From HTTPS to machine trust: the rise of mTLS client certificates
In recent years, we have seen something interesting happen: the digital certificate, which many associated only with HTTPS, is becoming increasingly central in modern architectures. This is because it is undeniable that machines communicate more than humans do. And when they communicate with each other—via APIs, microservices, cloud integrations, or exchanges between trusted platforms—the question is no longer just “is the channel encrypted?”, but above all: who is making the call? what is its identity?
This is where mutual TLS, or mTLS, comes into play. In “standard” TLS, the server presents its certificate, and the client trusts it (if everything checks out). With mTLS, an additional step is introduced: the client also authenticates itself using an X.509 certificate. So both parties prove their cryptographic identity. The result? We are no longer just protecting a communication: we are building a verifiable trust relationship.
For greater clarity: this is a technical and regulatory direction that is becoming structural.
Why client certificates matter more and more
The point is simple: API keys and tokens are not identities, they are shared secrets. They work until they end up in the wrong place: a poorly copied configuration file, incorrectly executed exchange procedures, overly verbose logs, a public repository “for testing”. And once a key is stolen, the attacker becomes indistinguishable from the legitimate client.
With client certificates, the story changes. Every application, container, workload, or API gateway has a strong identity, anchored to a private key. We are no longer saying “I know the password”, but “I am this entity and I can prove it”. Moreover, this identity is:
- non-clonable (without the private key you can do nothing);
- traceable and auditable (trust chain, attributes, revocation);
- governable via policy (who can call what, based on CN/SAN/EKU and CA).
In other words, mTLS is the natural way to implement zero trust between machines.
Naturally, the client certificate performs best when it is part of proper identity and key management. Its strength is based on protecting the private key: in machine-to-machine environments, storing it in a secure keystore, vault, or HSM raises authentication to a truly robust level, drastically reducing the risk of misuse even in the presence of misconfigurations or overly broad permissions. In practice, with the right tools, the client certificate becomes one of the most reliable defenses available.
Likewise, it is true that a certificate expires—but this is not a limitation, it is a security and control mechanism. When rotation is managed in a centralized and automated way, expiration stops being an operational burden and becomes an opportunity: it ensures continuity, regularly updates keys, and keeps the infrastructure current and governed. Of course, you can also choose longer durations (we offer certificates up to 3 years) to further reduce effort, but it is automation that closes the loop and makes the certificate lifecycle finally simple, secure, and predictable.
Moreover, a certificate expires, and expiration is notoriously an operational hassle: if not managed centrally and automatically, it can disrupt critical services at the worst possible time. You can always opt for long-lived certificates (we offer certificates with durations up to 3 years), but automation is what truly solves the issue.
That said, as an authentication method it remains among the most robust: a stolen private key is an isolated and revocable incident, whereas a compromised API token is infinitely replicable and indistinguishable from the original. In other words: the risk exists, but it is manageable—and above all, it does not force you to blindly trust static secrets scattered across your infrastructure.
Client certificates are essential for both engineers and regulators
In the European “trusted services” ecosystem, for example, this requirement is already clearly defined. REM (Registered Electronic Mail) services under eIDAS/eIDAS 2.0 focus on interoperability and end-to-end trust. ETSI standards for REM and the use of qualified certificates indicate the adoption of TLS channels with mutual authentication when both parties have appropriate authentication certificates (QWAC/QCert): therefore, with client certificates.
Translated: if you are building ecosystems where trust is part of the service, the identity of the calling machine cannot be optional.
The same applies to regulated cloud environments. The ACN qualification path for cloud services intended for public administration requires strict controls on identity, data protection in transit, and access traceability. In particular, system identities are managed using digital certificates. Even when you do not explicitly see the word “mTLS”, the set of requirements leads in that direction as a coherent and auditable solution.
And then there is the most evident precedent: open banking and payment APIs. There, mutual authentication with certificates (often qualified) has been part of the standard security model for years. Because if you want to trust a client that moves money, you do not ask “do you have a token?”, you ask “show me who you really are”.
What this means
For us, this evolution is almost natural, because we are not just talking about “issuing certificates”, but about giving reliable identities to machines. And mTLS is the language through which these identities exchange trust.
In practice, client certificates enable increasingly strategic use cases:
- strong authentication for internal and external APIs;
- identity for cloud-native workloads (Kubernetes, service mesh, microservices);
- machine-to-machine integrations in regulated environments (REM, trusted services, public administration, healthcare, finance);
- automation of onboarding, rotation, and revocation at scale.
This also reduces operational risk: fewer static secrets scattered around, more centralized control, and greater peace of mind when the auditor arrives with a checklist.
The next step: crypto-agility and quantum-resistant algorithms
While the market accelerates on mTLS, another requirement is emerging that we cannot ignore. The certificates we use today (RSA, ECC) are secure against classical computers but will not be against sufficiently powerful quantum computers. Institutions and international standards are preparing for the post-quantum transition, and in 2024 NIST standardized the first PQC algorithms (ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures).
This means that anyone providing PKI must immediately start designing crypto-agile systems: CAs, certificate profiles, and TLS stacks ready to integrate quantum-resistant or hybrid algorithms.
Because the migration will not be a switch overnight: it will be a long phase in which classical and post-quantum will coexist, and those who are prepared—with centralization and automation that make the transition agile—will have a huge advantage. Not only technical but also competitive.
For more information, see our dedicated page.
Conclusion
Mutual TLS has become the most direct and robust way to ensure that machines communicating with each other are truly who they claim to be. It is a requirement driven by cloud-native technology, but now reinforced by regulations and qualifications for trusted services and regulated cloud environments.
And since the near future also calls for post-quantum algorithms, the real challenge is managing identity and trust in the long term.
How to prepare
If you are designing (or reviewing) API integrations, service meshes, machine-to-machine flows in regulated environments, or qualified cloud services, as a CA and PKI provider, we can help you to:
- define certificate profiles suitable for mTLS;
- automate issuance/rotation/revocation at scale;
- integrate mTLS into your stack (gateway, mesh, workload identity);
- set up a crypto-agile and post-quantum-ready path from the start;
- use certificates with durations up to 3 years to reduce operational complexity and incidents related to expiration.
We help your machines communicate in a secure and verifiable way, without leaving keys scattered around.