mTLS vs API key auth: the security case for certificate-based access

API keys are everywhere. They’re simple to generate, simple to pass in a header, and simple to revoke in theory. They’re also one of the most common sources of credential exposure in real incidents. This post walks through why mTLS is a fundamentally different - and stronger - authentication model, particularly for workloads like EDR agents that need to talk to a control plane continuously.

What API key auth actually gives you

An API key is a shared secret. When an agent or service presents a key, the server checks it against a stored value. If they match, the request is authenticated.

That sounds fine until you look at the failure modes.

Static secrets are hard to rotate. Most API key implementations don’t enforce rotation. If a key is valid today, it’s often valid 18 months later. A key captured in an old log, a leaked .env file, or a misconfigured CI pipeline stays exploitable until someone notices.

The key doesn’t prove identity. A valid API key tells you the request was made by someone who has that key - not which specific machine or service sent it. In a compromised environment, an attacker who extracts the key from memory or disk has everything they need to impersonate the legitimate client.

No transport-layer binding. The key travels in the request. TLS encrypts it in transit, but TLS termination happens before your application layer. A key validated at the app layer is decoupled from the connection that carried it.

Here’s what a typical API key exchange looks like:

GET /api/v1/alerts HTTP/1.1
Host: triage.example.com
Authorization: Bearer sk_live_abc123xyz

Nothing in that request cryptographically proves which machine sent it. The bearer token is the identity.

What mTLS changes

Mutual TLS (mTLS) extends the standard TLS handshake so that both sides present certificates. The server presents its certificate as normal, and the client does the same. Both parties verify each other’s certificate chain before any application data flows.

The key properties this gives you:

Private keys never transit. During enrolment, the agent generates a key pair locally and sends only the CSR (Certificate Signing Request) to the server. The private key never leaves the machine. Compare this to API key auth, where the secret must be known to both sides from the start.

Identity is cryptographically bound to the connection. A certificate ties the client’s identity to a specific key pair. An attacker who extracts an API key can replay it from any host, at any time. An attacker who wants to impersonate an mTLS client also needs the private key - and if that key lives in a TPM or hardware security module, it cannot be extracted at all.

Revocation is fast and auditable. A certificate authority can revoke a compromised certificate. Your control plane checks revocation status on each connection and rejects certs that have been invalidated. With API keys, “revocation” means the key must be explicitly deleted from your system - and that requires first knowing the key was compromised.

Property	API key	mTLS
Private secret transits on enrolment	Yes (key is issued to client)	No (CSR only)
Cryptographic proof of client identity	No	Yes
Replay attack resistant	No (key is reusable)	Yes (cert binding + nonce)
Rotation enforcement	Manual, often skipped	CA-managed, auditable
Compromised credential scope	All holders of that key	One certificate, one endpoint

Where this matters most for EDR

An EDR agent is a persistent process running on every endpoint in your environment. It generates a continuous stream of telemetry - process events, network connections, file activity - and authenticates every message it sends to the control plane.

If that auth channel is API-key-based, every agent in your fleet shares the same credential class. A single extraction gives an attacker the ability to inject false telemetry, suppress real alerts, or exfiltrate telemetry data at scale - without triggering anything that looks like a credential compromise.

With mTLS, each agent has its own certificate. A compromised agent’s certificate is revoked without touching any other endpoint. The control plane can also use the certificate as an active trust signal - combining transport-layer identity with behavioural and network signals to produce a composite trust score per endpoint.

LightEDR builds on this with nonce-based replay protection on top of the mTLS session. Even if an attacker intercepts a connection, they cannot replay earlier messages to the triage service. Agent certificates feed directly into the endpoint’s trust score - making the TLS channel part of the continuous Zero Trust verification loop rather than a one-time gate at connection time.

The operational trade-off

mTLS is more complex to operate than API key auth. You need a CA, a certificate lifecycle management process, and tooling to handle enrolment, renewal, and revocation. For managed products, the vendor absorbs most of this - you deploy the agent and the certificate lifecycle is handled for you.

If you’re evaluating the trade-off for a bespoke agent-server architecture, the question is whether you’d rather manage secret rotation or certificate rotation. Both require discipline. But certificate rotation gives you cryptographic guarantees that secret rotation never can - and the blast radius of a single compromised credential is bounded to one endpoint, not the whole fleet.

To learn more about how LightEDR handles mTLS certificate issuance and revocation across your agent fleet, get in touch.