Nearly all modern software trusts public certificate authorities, which is why the eMudhra compromise is big news. Private keys for eight intermediate certificates from the certificate authority were compromised, and nearly every browser and operating system trusts that CA. In plain terms, whoever holds those keys can mint a valid-looking certificate for any domain they want. That's everything an attacker needs for a convincing impersonation or man-in-the-middle attack, and it affects anything that trusts public CAs, which is almost everything.

So, the question we know you're asking: is Twingate affected? Not directly. None of the affected certificates are part of how Twingate operates, and we've seen no sign that anyone has used this against Twingate or our customers. But "not directly" doesn't mean "nothing to do," so here's what we're working on and what we'd suggest you check.

What happened

All eight compromised certificates are P-384 intermediates under eMudhra's G3 ECC hierarchy, and their private keys were weak enough for outsiders to recover. Six are TLS intermediates trusted by Chrome, Mozilla, Microsoft and Apple. The other two are used for code signing.

eMudhra revoked all eight on October 18. None of them ever issued a legitimate customer certificate, so a certificate chaining to them shouldn’t be trusted. That gives attackers two openings: TLS certificates for domains they don't own, and code that looks like it was signed by a trusted publisher. There's a knock-on effect too: the G3 root itself is being distrusted, so about 30,000 legitimate certificates issued under it will need to be reissued.

What we're doing

Like almost every modern software stack, ours depends on libraries, base images, and runtimes that ship their own trust stores. Some of those dependencies still trust the compromised intermediates. Nothing points to an active risk to Twingate, but leaving distrusted CAs in our stack isn't acceptable to us.

We're updating these dependencies across the system now:

• Shared trust stores and base images: We're updating common components, then rebuilding and redeploying the services that use them.

• Services that authenticate remote endpoints: Anything that relies on public certificates to verify who it's talking to is first in line.

• Bundled or custom trust stores: We're assessing and updating these one by one, because they don't pick up OS-level fixes automatically.

What you should do

For Twingate itself, you don't need to take any action right now. If a future Client or Connector release includes trust store updates, we'll note it in our changelog.

This is a good moment to check your own environment. A few pointers:

• Patch your own dependencies. Go, Python's certifi, and the ca-certificates packages for Debian, Ubuntu and Fedora have all shipped fixes. Your OS, runtimes, container base images and HTTP libraries may carry their own trust stores too, and Mozilla's crowdsourced list of patched packages is worth a look.

• Patch, don't rely on revocation. Browsers and operating systems already block the affected intermediates, but many non-browser clients never check revocation.

• Look for misuse. The revoked certificates and their revocation times are published as JSON, so you can check your logs against them.

• Check the entire verification path. A browser test or a quick curl doesn't prove that background services or apps using a different verifier are protected.

• Don't disable certificate verification to make post-patch errors go away. That removes the very protection the patches restore.

• Review mutual TLS configurations and any internal systems that pin or bundle CA lists.

The bigger picture

Incidents like this show why trust shouldn't come from network position alone, or from a single certificate check. A forged certificate can get an attacker into the middle of a connection, but it doesn't give them a verified identity, a healthy device, or permission under your access policies. Layered, identity-based access is what keeps one broken link in the chain from turning into a breach.