The eMudhra CA compromise: what small businesses need to check before October 27

A certificate warning can become a business outage

Imagine your customer portal works on Friday but starts showing a trust warning after a browser update. Your certificate has not expired. The problem is that a certificate authority in its chain is no longer trusted.

That is why the October 2026 eMudhra incident deserves a check even in a business with no security department. There are two separate jobs: update the software that decides what to trust, and determine whether any certificate your business serves depends on an affected hierarchy.

This article reflects public statements checked on October 23. Recheck the linked vendor notices before scheduling changes because the response is still developing.

What the vendors have confirmed

Mozilla's incident notice says it received a report on October 17 that keys for eight eMudhra intermediate certificates were compromised. Mozilla blocked the certificates through OneCRL and issued browser and trust-store updates for other configurations. Its October 21 update also identifies an additional Android fix.

Google's response explains that weak keys could enable forged HTTPS certificates against clients that still trust them. Google also describes protection from Certificate Transparency enforcement; that protection must not be assumed for every application.

For website operators, Google announced removal of emSign ECC Root CA - G3 from the Chrome Root Store for October 27, 2026, with earlier availability on prerelease channels. It directs affected operators to move to another trusted PKI hierarchy. A legitimate certificate under that root can be affected even if it was not issued by a compromised intermediate.

In its incident statement, eMudhra says it revoked the eight intermediates and that the incident did not involve compromise of its root private keys. Treat the provider's investigation statements as attributed findings, not proof that every downstream customer is unaffected.

First ask your website provider about the served chain

Send your host or MSP a list of your public domains, including customer portals and API endpoints. Ask whether the certificate chain served for each hostname reaches emSign ECC Root CA - G3 or an affected intermediate.

The brand on an invoice is not enough to answer this. Neither is the expiry date in a monitoring dashboard. Ask for the actual chain, the relevant fingerprints or issuer identifiers, and the vendor's assessment.

If a chain needs replacement, agree who obtains the new certificate, who controls domain validation, and who can deploy it across all endpoints. Check that renewal automation will not later restore the old hierarchy. Keep private keys in the approved certificate-management system; nobody needs to email them to a consultant.

After deployment, have the operator verify the expected hostname and chain from outside the hosting environment. Test the actual customer login or transaction, not just the certificate file stored on a server.

Then check what your business software trusts

An updated browser is useful evidence about that browser. It is not evidence about the accounting integration, a server-side API client, or an old appliance.

Ask the MSP to list the important outbound connections: payments, payroll, document exchange, backups, and software updates. For each application, identify who supplies its trust store and how that trust data is updated. Some applications use the operating system's certificates; others ship their own bundle.

Prioritize services that handle money, credentials, or sensitive records. Request a vendor-supported update or mitigation and a result from the application itself. Do not ask staff to visit suspicious sites to test whether protection works.

For an unsupported device, the decision may be to restrict its connectivity while the vendor provides guidance or the business replaces it. Document the limitation rather than marking it patched because the employee's laptop is current.

Keep a certificate failure from becoming an unsafe workaround

Tell staff where to report a warning and what to do while IT investigates. The instruction should not be to click through, disable certificate checking, or install a certificate someone sent in a support message.

Consider a hypothetical payroll integration that fails after a trust-store update. The owner should confirm the destination and chain with the payroll provider, then use an approved fallback if the deadline is close. Disabling verification can make the connection appear repaired while removing the check that distinguishes the intended provider from an impostor.

Put an owner and expiry on any temporary exception. If a supplier suggests bypassing validation, ask for an alternative that preserves authentication and escalate the decision to the business owner.

What to tell leadership and customers

Separate three statements: a public CA incident occurred; a company service depends on an affected chain or trust store; and evidence shows an attacker accessed company information. One does not automatically establish the next.

Leadership needs the affected services, the operator for each, the time required to replace or update them, and the continuity plan. Customer communication should describe verified service impact without claiming a breach or guaranteeing that no compromise occurred.

Keep the vendor replies, change records, and test results together. The executive incident briefing template can help separate confirmed facts from open questions. The immediate goal is simple: customers can reach the right service, and your applications still verify who they are connecting to.