1. Issuance of digital signature certificates and eSign services, regulated by the Controller of Certifying Authorities (CCA) under MeitY.
   
   
2. Issuance of digital certificates trusted by major browsers and operating systems, used to secure websites, software and online communications.

The second function is international in nature and operates under global trust framework. It is governed by international standards and subject to independent audits, including Web Trust audits conducted by BDO International Limited.

The affected private keys were generated with insufficient cryptographic randomness. The P-384 elliptic-curve private keys had values smaller than 256 and could be recovered almost instantly from their corresponding public keys. The weakness arose during key generation and does not indicate a vulnerability in the P-384 cryptographic algorithm itself. Whereas eMudhra has stated in its public press release, "A flaw in the key generation ceremony caused a wrap / unwrap step to produce a second set of weak keys along side the original strong keys. The weak keys were the ones published to the browser root stores."

eMudhra revoked the eight affected intermediate certificates on October 18, 2026. M/s Mozilla blocked the six affected TLS intermediate certificates through its OneCRL certificate block list on October 17, 2026. Mozilla released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to protect users whose configurations prevent them from receiving OneCRL updates. Mozilla has also updated the trusted certificate list in Network Security Services (NSS) 3.131.1 to remove the root certificate emSign ECC Root CA - G3, which signed the affected intermediates.

Impact

An attacker able to exploit the compromised TLS private keys could issue fraudulent TLS certificates and potentially impersonate legitimate websites or intercept or modify data exchanged between users and servers, potentially facilitating credential theft, sensitive data exposure, and financial fraud. Compromised code-signing keys could be used to issue fraudulent certificates, enabling malicious software to appear digitally signed by a trusted publisher.

Google reported that no TLS certificates chaining to the six affected TLS intermediates were recorded in Certificate Transparency (CT) logs before its blocking action. eMudhra has also stated that the affected intermediates had not issued end-entity certificates. As of October 21, 2026, the cited public disclosures do not establish confirmed malicious exploitation of the affected keys.

Removal of emSign ECC Root CA - G3 from browser and application trust stores could render legitimate certificates issued under that root untrusted, potentially disrupting affected websites and services.

Target Audience

Best Practices

• Apply security updates: Update Firefox, Firefox ESR, Chrome, supported Android components, and other affected browsers, applications and operating systems to the latest security releases provided by their respective vendors.
  
  
• Update certificate trust stores: Ensure that operating systems, applications, servers and devices receive the latest certificate revocation and distrust information from their respective vendors. Verify that affected certificate chains are rejected by the relevant clients.
  
  
• Review certificate dependencies: Identify certificates and services chaining to the affected intermediate CAs or emSign ECC Root CA - G3. Assess the impact of the intermediate-certificate blocking measures and root-store changes on websites, applications and other dependent services. Include relevant cross-signed certificate chains in the review.
  
  
• Replace affected certificates: Obtain replacement TLS certificates from a trusted, unaffected PKI hierarchy where required. Administrators should also replace otherwise legitimate certificates chaining to emSign ECC Root CA - G3 if they will no longer be trusted by the relevant clients.
  
  
• Verify TLS certificates: Validate certificate chains, issuer information, validity periods and revocation status. Do not bypass certificate-validation warnings or disable certificate verification. Confirm that applications reject certificates chaining through the compromised intermediate CA keys.
  
  
• Monitor certificate issuance: Monitor Certificate Transparency logs and security alerts for unauthorised certificate issuance, unexpected certificate changes and other suspicious activity involving affected domains or services. CT monitoring should supplement, rather than replace, certificate revocation and trust-store controls.
  
  
• Review independent certificate trust stores: Examine applications, programming-language runtimes, container images, TLS libraries, network appliances and embedded systems that maintain separate CA certificate bundles or do not reliably check certificate revocation. Apply applicable vendor updates and redeploy affected components where necessary.
  
  
• Review code-signing trust: Software vendors and administrators should verify the trust and revocation status of relevant code-signing certificate chains and use additional software integrity and provenance checks where appropriate.
  
  
• Strengthen CA key management: Certification authorities should use approved cryptographically secure random number generators, implement appropriate hardware security module (HSM) controls, and review key-generation procedures and key-lifecycle management to prevent recurrence of similar weaknesses. Independent verification of generated key parameters, key identifiers, certificate-signing request (CSR) mappings and maker-checker controls should form part of the key-generation process.
  
  
• Maintain secure configurations: Ensure that applications, embedded devices and other systems receive timely security and trust-store updates. Where vendor support is unavailable, assess exposure and implement appropriate compensating controls.