eMudhra Incident FAQ for Indian Banks, Fintechs and Government Bodies

The eMudhra incident hit its Global TLS business: eight intermediate CA keys were generated so weakly that anyone could compute them. eMudhra, CERT-In and MeitY all say Indian DSC and eSign services are unaffected. Indian banks, fintechs, insurers and government bodies should replace G3-chained certificates, update trust stores, check partners and brief customers calmly.

This is the India-specific companion to our technical explainer on the eMudhra key compromise, which covers how the weak keys worked and which runtimes have fixes. Nothing here is legal advice; we link every regulatory source so your compliance team can read it.

The short version

Three things matter most for Indian organisations:

1. It is not a data breach. eMudhra told PSU Watch the incident "did not involve unauthorised access to its infrastructure or any breach of customer data."
2. DSC and eSign are reported as unaffected. eMudhra, CERT-In and MeitY all say so.
3. There is still work to do. Sites chaining to the emSign ECC Root CA G3 will fail in Chrome once the root is removed, and servers, containers, Java runtimes and appliances with their own CA bundle may still trust the bad intermediates.

What CERT-In's advisory says

CERT-In published CIAD-2026-0050 on 21 October. It states no severity rating. In summary:

The advisory's recommendations, grouped by who they are for:

• Everyone running systems: update browsers, operating systems and trust stores; find and replace certificates chaining to the affected intermediates or the G3 ECC root, including cross-signed chains; watch Certificate Transparency (CT) logs; review runtimes, container images, appliances and embedded systems that keep their own CA bundles.
• Software vendors: review code-signing chains and add integrity and provenance checks.
• Certification authorities: use approved random number generators, proper HSM controls and independent maker and checker verification of generated keys.
• Users: do not bypass certificate warnings or disable verification.

Some headlines framed the advisory as a warning about fake websites. It warns about what forged certificates could enable, such as a fake payment page with a valid looking padlock; it does not report that such sites were found. Reporting duties come from the separate 2022 directions, covered below and in our guide to CERT-In directions.

Global TLS intermediates vs Indian DSC and eSign

eMudhra runs two very different certificate businesses, and internal briefings this week often mix them up.

What this means in practice:

• DSC-signed documents and eSign workflows are outside this incident according to every official statement so far. Nothing in them suggests re-signing or reissuing.
• An eMudhra website certificate is a different product. If your net banking portal, API gateway or citizen portal uses one, check whether it chains to the G3 ECC root. Other emSign roots are not part of the current removal.
• This rests on statements. The separation claim comes from eMudhra, repeated by CERT-In and MeitY; MeitY says more details will follow its investigation.

MeitY's own summary is that the impact on Indian websites and applications was "very limited and for a very short interval," according to Business Today.

Who in India needs to act

The middle rows matter most in financial services. Outbound integrations often run on Java application servers or older middleware with their own cacerts files, which get no browser-style revocation pushes.

CERT-In's six hour reporting direction

CERT-In's directions of 28 April 2022, issued under section 70B(6) of the IT Act, require body corporates, service providers, data centres and government organisations, among others, to report the cyber incidents listed in its Annexure I "within 6 hours of noticing such incidents or being brought to notice about such incidents." Reports go to incident@cert-in.org.in or the phone and fax lines listed there.

The same directions require:

• Clocks synced to NIC or NPL NTP servers, or a source traceable to them.
• Logs of all ICT systems kept for a rolling 180 days, within Indian jurisdiction per the directions. CERT-In's own May 2022 FAQ (Q35) later said logs may be stored outside India as long as they can be produced to CERT-In in reasonable time.
• A designated Point of Contact registered with CERT-In.

Does the eMudhra incident itself trigger a report?

Our reading, which your legal team should confirm: the revocation is an event at a certificate authority, not an incident on your systems, and updating trust stores is routine maintenance. The duty changes if you notice something on your side, for example:

• A certificate for your domain from an affected intermediate in CT logs (Annexure I item vii, spoofing and phishing).
• Evidence of interception with a forged certificate (item iii, unauthorised access).
• Software signed through an affected code-signing intermediate (item v, malicious code).

From CERT-In's FAQ: you may report what you know within six hours and add details later (Q30); any entity that notices an incident on a partner's systems must report, and the duty cannot be contracted away (Q13); and the duty overrides confidentiality clauses (Q22).

RBI context for banks and NBFCs

RBI-regulated entities have a parallel clock. RBI's Commercial Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 (31 July 2026) say at paragraph 182 that a bank "shall report cyber incidents within six hours of detection on DAKSH platform" and shall also proactively notify CERT-In. The NBFC version has the same six hour window at paragraph 141.

They do not mention eMudhra, but several provisions bear on the clean-up:

• Inventory. Paragraph 47 of the bank directions requires an up-to-date inventory of information assets. Certificates and trust stores belong in it.
• Supply chain. Banks must manage supply chain risks (paragraph 126(6)) and conduct due diligence and oversight of third-party vendors (paragraph 129).
• DSC use. The NBFC directions (paragraph 31) tell NBFCs to use Digital Signature Certificates to authenticate identity and protect online transactions. So the DSC versus TLS distinction matters to NBFC risk teams.

We did not find an RBI, SEBI or IRDAI circular about this incident as of 21 October. SEBI and IRDAI entities should check their own regulator's reporting rules.

Checks to run on internal systems

The technical explainer covers runtime checks in depth; this list focuses on what Indian enterprises usually run.

1. List every public hostname you own, including net banking, payment callback endpoints, partner API gateways and citizen portals, then check each issuer.

# hosts.txt: one hostname per line
while read -r h; do
  echo "== $h"
  openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null \
    | grep -E " s:| i:" | grep -i -E "emsign|emudhra" && echo "   ^ eMudhra in chain"
done < hosts.txt

If a flagged chain ends at the emSign ECC Root CA G3, replace it from another hierarchy before 27 October, as Google advises.

2. Search CT logs for your domains. You are looking for certificates you did not request, especially any from an eMudhra issuer.

curl -s "https://crt.sh/?q=%25.example.in&output=json" \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' \
  | grep -i emsign

An empty result is the good outcome.

3. Check every Java runtime. Core banking adapters, middleware and reporting tools often bundle their own JDK.

# find JDK and JRE trust stores on a host
find / -name cacerts -path "*security*" 2>/dev/null
# list eMudhra entries in one of them
keytool -list -keystore /path/to/cacerts -storepass changeit | grep -i emsign

The tracking site run by Mozilla's Dennis Jackson listed the Java fix as pending on 21 October. Follow your JDK vendor's guidance and test before changing production keystores.

4. Test from inside running workloads, not from a laptop. An error from the tracking site's test hosts is the result you want.

kubectl exec deploy/payments-api -- curl -sS https://dv-g3b-emudhra.we-have-a-problem.com/
kubectl exec deploy/payments-api -- curl -sS https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Without curl in the image, use the application's own HTTP client.

5. Check mobile app pinning. Search the Android and iOS code for pins.

grep -rn -E "pin-set|<pin digest" app/src/main/res/xml/ 2>/dev/null
grep -rn -E "CertificatePinner|TrustKit|pinnedCertificates" . 2>/dev/null

If an app pins the G3 root or an eMudhra intermediate, ship the app release before swapping the server certificate.

6. Check signed software. On Windows, look at the signer of installers and drivers you received recently.

(Get-AuthenticodeSignature .\installer.exe).SignerCertificate.Issuer

If a signature chains to the G3 ECC root, compare its issuing intermediate with the affected list on the tracking site. eMudhra says they issued no end-entity certificates, so such a signature needs investigation.

7. Rebuild container images with fresh base images so updated ca-certificates packages land, then redeploy. Updating the host does nothing for images.

Checks on partner integrations

1. Inventory outbound integrations from egress proxy logs, API gateway configuration or service mesh rules, and run the step 1 loop against them.
2. Inventory inbound mutual TLS. Find which CA files your servers use to verify partner client certificates.

grep -rnE "ssl_client_certificate|ssl_trusted_certificate|SSLCACertificateFile" \
  /etc/nginx /etc/apache2 /etc/httpd 2>/dev/null

If a client authentication trust file holds the whole public bundle, a forged client certificate could have passed. Cloudflare advises reviewing the CAs you trust for mTLS; trust only your partners' specific CAs.

3. Ask partners four questions, in writing:
   • Do any of your endpoints we call present a certificate chaining to the emSign ECC Root CA G3? If so, when will it be replaced?
   • Have your outbound clients that call us been updated to reject the revoked intermediates?
   • Do you trust public CAs for client certificate authentication on any interface we use?
   • Who is your contact if you notice an incident affecting our data? (CERT-In FAQ Q13 means both of you may need to report.)
4. Agree a change window. If a partner replaces a certificate and your side pins it or uses an allow list, schedule the swap together so payment flows do not stop.
5. Record answers in your vendor register. Our post on third-party risk lessons from the IDCF Cloud ransomware covers how to keep that register useful.

Talking to customers

Customers will see alarming headlines and ask whether their accounts are safe. Keep answers short, factual and attributed.

What you can say, if true for you:

• It affected eight certificates in eMudhra's global website certificate business; according to eMudhra, CERT-In and MeitY, there was no data breach and DSC and eSign are unaffected.
• Major browsers blocked the certificates within days.
• You have checked your websites, apps and partner connections and are updating what relied on them.

What not to say:

• Do not say "we were not affected" before you finish the checks above.
• Do not say eMudhra was hacked. No breach has been reported.
• Do not speculate about forged certificates. CERT-In and Google report no confirmed abuse; say that and stop.

Advice that helps customers: update browsers and phones, restart Android devices so the Play Services update applies (Google's advice), and never click through a certificate warning on a banking site.

A short holding statement many teams can adapt:

We are aware of reports about certificates issued by eMudhra's global website security business. Based on statements from eMudhra, CERT-In and MeitY, this did not involve a data breach and does not affect Indian Digital Signature Certificate or eSign services. We have reviewed our websites, apps and partner connections. Please keep your browser and phone updated and never ignore a security warning on a banking or payment site.

Give call centre and branch staff the same text.

What would have helped

Practices any team can use

• A queryable certificate and trust store inventory: hostnames, issuers, pinned apps, mTLS trust files and every bundled CA store in images and JDKs. RBI's asset inventory requirement is a natural home for it.
• Automated certificate rotation (for example through ACME), so moving to a new hierarchy takes hours, not weeks.
• Narrow mTLS trust: a named private CA, not every public root.
• Scheduled image rebuilds, so OS trust bundles stay current even when code does not change.
• A partner contact sheet with incident clauses: who to call, how fast, and who reports to CERT-In.
• Pre-approved customer messaging cleared by legal and compliance in advance.

For a wider view of the month, see October 2026 security incidents and what would have helped.

Where Safeguard fits

Safeguard helps with the inventory and update half of this incident. It does not help with the certificate authority half.

• Finding what you ship. SBOM and dependency scanning covers repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, so finding images with an old ca-certificates package or certifi below 2026.10.19 is a lookup. Our post on SBOM incident response walks through that workflow.
• Matching advisories. Vulnerability matching against vulnerability databases, with reachability analysis, helps prioritise the CVE side of your patch queue. A trust store change without an advisory will not show as a vulnerability.
• Holding the line. Policies and gates evaluated in the platform can stop a build that still carries an outdated bundle version.
• Making the change. Autonomous remediation can open fix PRs for dependency bumps; it ships off by default. The Safeguard CLI's assistant can edit a Dockerfile or lockfile and run the rebuild, asking for approval of each command under the /permissions mode you choose. safeguard exec runs a single assistant turn in CI. Desktop and phone apps can send work to a computer running the CLI and approve each command.

Where it does not help: Safeguard cannot inspect a CA's key ceremony, cannot tell you whether a forged certificate was used against you, does not monitor CT logs, does not file CERT-In or RBI reports, and will not see trust stores on appliances or firmware you never scan. No scanner would have prevented this incident; the keys were weak at the source.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in two modes, an agentic mode and a deterministic scanner mode, covers seven package ecosystems, and issues findings as SGZ advisories before they reach public CVE databases. The eMudhra problem was not a flaw in a package; it was weak keys produced in a CA's key ceremony, so Zero-Day Discovery does not apply here and did not flag it.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. A trust store change like this one may never receive a CVE, so do not wait for one.

Gold Registry at registry.safeguard.sh is paid. It provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages; an artifact loses its badge on regression. We do not claim any Gold image carried this incident's fix before the public update. The habit that matters: pull patched, signed base images from a curated source and rebuild on a schedule, so a ca-certificates change reaches production in days.

Common mistakes and troubleshooting

• Treating DSC news and TLS news as the same thing. Your document signing team and your web team need different instructions.
• Deleting every emSign root. Only the G3 ECC root is being removed.
• Fixing errors by turning off verification. Cloudflare warns against this explicitly.
• Testing only from a browser. Chrome was protected on 17 October; Java batch jobs were not.
• Rolling back a trust store fix when a partner call fails. Run the step 1 loop against the partner host. An emSign G3 chain means the partner needs a new certificate; escalate through your contact sheet.
• Assuming the six hour clock started on 17 October. Per the directions, it runs from when you notice an Annexure I incident on your side, not from public news.

FAQ

Do we need to report the eMudhra incident to CERT-In within six hours?

Probably not for the event itself, which happened at a CA. If you notice an Annexure I incident on your side, such as a forged certificate for your domain or interception, the six hour clock applies. Confirm with your legal team.

Are documents we signed with an eMudhra DSC still valid?

eMudhra, CERT-In and MeitY all say Indian DSC and eSign services are unaffected and run on separate infrastructure regulated by the CCA. Nothing suggests re-signing documents. Watch for MeitY's investigation findings.

Our internet banking site uses an eMudhra certificate. What now?

Check whether it chains to the emSign ECC Root CA G3. If it does, Google advises installing a certificate from another hierarchy before Chrome removes the root, expected on 27 October. eMudhra says it is issuing replacements to affected customers.

Has RBI, SEBI or IRDAI issued guidance on this?

We found none as of 21 October. RBI's 2026 cybersecurity directions still apply: six hour reporting to RBI on DAKSH, proactive notice to CERT-In, an asset inventory and third-party oversight. SEBI and IRDAI entities should check their own regulator's rules.

Could someone have impersonated our site to customers?

In theory, where a client trusted the affected chains. Google says no TLS certificates from the six web intermediates appeared in CT logs before Chrome's block, and CERT-In reports no confirmed exploitation.

Is our mobile app affected?

Only if it pins the G3 root or an eMudhra intermediate, or calls a server whose certificate chains to G3. Android phones also get a Play Services update; Google says a restart applies it.

What should we tell the board?

A key generation defect in a CA's global TLS business, not a breach; DSC and eSign reported unaffected; what you checked; what still needs changing; and the 27 October Chrome date.

To find every image and service that still ships an old CA bundle, download Safeguard and follow the CLI docs.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo fixes a lodash CVE, not a certificate problem, but the flow carries over: open the CLI in your payments service repo, ask it to bump certifi or the Dockerfile base image tag so the updated ca-certificates package lands, and approve each command before it runs.

Click through it at your own pace, or open it full screen.

Many Indian banks and government teams keep code in-house. The local runner demo shows setting up the runner on your own machine, approving it with its device code, then scanning from the terminal. For this incident, you would point those scans at your container images to see which still carry an old CA bundle.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a real session: the CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and approve or deny each command and file edit until the upgrade is done and tests pass. Here, a platform lead could ask for the base image rebuild in a service folder and review each change.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CERT-In advisory CIAD-2026-0050: Compromise of eMudhra intermediate CA certificates
• CERT-In directions under section 70B(6), 28 April 2022
• CERT-In FAQs on the Cyber Security Directions, May 2022
• RBI: Commercial Banks Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026
• RBI: NBFC Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026
• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Cloudflare: eMudhra certificate compromise
• eMudhra incident tracking and test site
• Business Today: MeitY says impact very limited, DSC and eSign unaffected
• The Tribune: MeitY forms special team to probe eMudhra certificate incident
• PSU Watch: eMudhra reports key compromise; CERT-In warns of fake websites
• ScanX: eMudhra reports TLS key flaw; India DSC and eSign unaffected
• The Hacker News: Eight eMudhra CA keys compromised

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.