TL;DR: Eight eMudhra intermediate CAs were created with recoverable private keys, letting attackers forge certificates in seconds and prompting browser blocks, revocation and trust-store updates, according to Red Sift. The incident shows why revocation-only thinking fails when non-browser clients, embedded systems and private trust stores still accept revoked chains.
At a glance
What this is: Red Sift describes how eight eMudhra intermediate CAs were issued with private keys that could be recovered from the public certificate, forcing browsers and major platforms to block them and exposing weak trust-store governance.
Why it matters: This matters because identity and access decisions increasingly depend on certificate trust outside browsers, where revocation gaps, private trust stores and embedded clients can still accept forged chains.
Context
A certificate authority incident becomes a governance problem when the trust model assumes browser enforcement will protect every client. In reality, server-to-server TLS, mTLS, embedded devices and private trust stores often rely on local bundles that do not check revocation or certificate transparency, so the blast radius extends well beyond the browser security boundary.
The eMudhra case is a reminder that machine trust is only as strong as inventory, revocation distribution and trust-store hygiene. Where an organisation depends on machine identity lifecycle controls, a compromised intermediate can turn a certificate chain into a reusable access path unless every client path is refreshed.
Key questions
Q: What breaks when a certificate authority intermediate is compromised?
A: The trust chain breaks wherever clients still accept the affected intermediate or root, even if browsers have already blocked it. Services may continue to validate forged certificates in local runtimes, private trust stores and embedded systems unless those trust anchors are removed and validation paths are tested end to end.
Q: Why do browser blocks not fully protect server-to-server TLS traffic?
A: Browser blocks help only where the browser itself enforces revocation or certificate transparency. Many non-browser clients trust static bundles on disk and may not check revocation at all, so a forged certificate can still be accepted by APIs, automation, language runtimes and appliances until those stores are updated.
Q: What do security teams get wrong about certificate lifecycle management?
A: Teams often expect CLM to decide what is trusted, when its real job is to automate discovery, renewal, and distribution. That confusion blurs governance and operations, which makes audit trails weaker and creates a false sense that inventory equals policy.
Q: How should teams handle certificate trust after a CA compromise?
A: Treat the event as a trust inventory problem first and a certificate replacement problem second. Identify every certificate that chains to the affected intermediates or roots, remove those trust anchors where you control them, and reissue or migrate any service that still depends on the exposed chain.
Technical breakdown
How a weak intermediate CA becomes a reusable trust anchor
An intermediate CA is a delegated signing authority: if its private key is compromised, every certificate it issued inherits that risk. In this case, the issue was more severe because the private key could be recovered from the public certificate, meaning no theft was needed. Once a trust store accepts that intermediate, any forged leaf certificate chaining to it can appear valid to a client that does not independently verify revocation or transparency. That is why CA compromise is not just about the CA itself, but about every trust decision downstream of it.
Practical implication: Treat compromised intermediates as a trust-anchor emergency and remove them from every trust store that can be controlled.
Why browser revocation does not protect non-browser clients
Browsers can react quickly because they ship revocation list updates and enforce certificate transparency checks for public TLS. Many other clients do not. Curl, Python, Node.js, Go, Java, CI runners, package managers and embedded systems often trust a bundle on disk and may not check revocation at all. That creates a split control environment: one path is blocked, another still accepts the same forged chain. The governance problem is not whether browsers respond, but whether the organisation has mapped where certificate validation actually happens across its estate.
Practical implication: Inventory every TLS-consuming client path and verify which ones enforce revocation or CT, not just which ones use TLS.
Why code signing makes the exposure harder to scope
Code-signing intermediates are different from TLS intermediates because signed binaries are not logged in certificate transparency. That means defenders cannot simply query a public log to know what was issued or used. If a code-signing CA is weak or compromised, timestamping alone does not prove trust, because the signing chain itself is the problem. This is a classic provenance gap: you may know that code was signed, but not whether the signing authority was sound at the moment of signature. For software supply chains, that is enough to invalidate trust. See the Cryptographic Key Management Guide.
Practical implication: Revalidate software trust assumptions when code-signing intermediates are exposed, even if timestamps and signatures still verify.
Threat narrative
Attacker objective: The objective is to mint trusted-looking certificates that bypass validation and can be used for interception, impersonation or software trust abuse.
- Entry occurred through a flawed CA key-ceremony process that produced weak private keys, so the attacker did not need to steal a live secret.
- Credential access followed when the private key could be recovered directly from the public certificate in under a second.
- Escalation happened because the recovered key let the attacker forge certificates that chained to trusted roots and intermediates.
- Impact was the collapse of trust for affected TLS and code-signing chains across browsers, private trust stores and non-browser clients.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate authority compromise is now an identity governance problem, not just a PKI problem. When an intermediate CA can be recovered from public material, the real failure is delegated trust without sufficient lifecycle control. Organisations need to think about certificate issuance as a privileged identity event, because every downstream service that trusts that chain inherits the compromise. The practitioner implication is to treat intermediate CA inventories and trust-store distribution as part of identity governance, not as a narrow infrastructure task.
The named failure mode here is trust-store fragmentation. Browser revocation happened quickly, but many server-side clients, appliances and automation stacks still trust local bundles that do not consult the same signals. That means an organisation can believe a chain is dead while private runtimes still accept it. The practitioner implication is to map certificate validation paths by runtime, not by application owner, and to close the gap where browser policy ends and machine trust begins.
Private keys embedded in a recoverable certificate destroy the assumption that the CA boundary is the security boundary. In this case, the certificate itself was enough to reconstruct the key, which means ordinary issuance controls failed before any external attacker had to break in. That is why CA governance must include key-ceremony assurance, not just revocation response. The practitioner implication is to audit how delegated signing keys are created, stored and validated before they are ever trusted.
Code-signing exposure changes the software trust question from authenticity to provenance integrity. If a signing authority is weak, signature validation alone can still produce false confidence because the chain of trust is what failed. That matters for supply-chain assurance, release pipelines and endpoint trust decisions that assume signed code is inherently safe. The practitioner implication is to recheck any software trust model that treats signature presence as proof of trustworthiness.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Trust-store fragmentation: the same certificate can be blocked in browsers and still remain accepted in runtimes that rely on static bundles, which means machine trust governance has to be measured by client path, not by vendor block list. That is why certificate lifecycle work increasingly sits beside identity governance rather than below it.
The practical risk is that CA compromise becomes a latent access issue across APIs, CI runners and embedded systems that do not consume the same revocation signals. The control objective is therefore consistent trust distribution, not just rapid public revocation response.
Where private trust stores and pinned configurations exist, certificate compromise can persist long after browsers have reacted, so teams need a separate inventory for every non-browser validation path.
For practitioners
- Update every trust store that validates TLS Refresh operating system bundles, language runtimes, container base images and vendored certificate stores so they no longer trust the compromised intermediates or removed roots.
- Remove compromised CAs from private trust stores Purge the affected intermediates and the emSign ECC Root CA - G3 from mTLS configurations, VPNs, API gateways and certificate pinning settings where they were manually trusted.
- Reissue certificates that chain to affected roots Move affected services to a still-trusted root before users encounter browser removal or application failure, and treat every chain ending in the compromised intermediates as untrusted.
- Verify non-browser validation paths Test curl, Python, Node.js, Java, CI runners and embedded devices separately, because browser blocking does not guarantee the same outcome in machine-to-machine traffic.
- Audit certificate inventory for chain exposure Search by issuer key identifier and chain hashes so you can find certificates even when servers present different chains, then confirm whether any live service still depends on them. See the Service Account Inventory Template.
Key takeaways
- The incident shows that a compromised CA intermediate can become a reusable trust anchor across browsers, APIs and machine-to-machine traffic.
- The scale of the problem is shaped less by browser response than by how many private runtimes, trust stores and embedded clients still accept the chain.
- The limiting control is complete certificate inventory and trust-store hygiene, because revocation alone does not reach every validation path.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Service Account Inventory Template · Identity Incident Response Playbook
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The intermediate private keys were recoverable from public certificates, which is an exposed-secret failure. |
| NHI-04 — Insecure Authentication | Clients trusted certificates chained to weak intermediates, so authentication depended on a broken trust assertion. | |
| NHI-07 — Long-Lived Secrets | The compromised CA chain persisted across browsers and non-browser clients until trust stores were updated. | |
| Recommendation — Treat any recoverable CA key material as secret leakage and remove trust before the chain is reused. Revalidate certificate authentication paths when a CA intermediate is exposed or revoked. Shorten trust windows by rotating and removing certificate authorities from every applicable trust store. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate lifecycle and revocation handling fall under authenticator management for machine trust. |
| Recommendation — Apply IA-5 controls to inventory, revoke and replace compromised certificate authenticators promptly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Recovering the private key enables certificate impersonation and downstream interception or misuse. |
| Recommendation — Map exposed CA keys to credential access and hunt for forged chains used in interception or impersonation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Certificate trust is an IAM issue in cloud and hybrid estates where machines authenticate with certs. |
| Recommendation — Review certificate trust anchors under CCM IAM and remove compromised authorities from machine trust paths. | ||
Key terms
- Intermediate Certificate Authority: An intermediate certificate authority is a delegated signing layer that issues certificates on behalf of a higher-level root CA. In device trust programmes, it helps scale issuance while preserving separation of duties, but it also becomes a critical governance point because its policies shape device identity integrity.
- Trust Store: A set of certificates that a system accepts as trusted for authentication or encryption decisions. If the store is stale or poorly maintained, systems may continue accepting identities that should no longer be valid, which turns trust management into an operational security risk.
- Certificate Transparency: Certificate Transparency is a public logging system for certificates issued by major certificate authorities. It helps investigators link public keys to issued certificates, but it is a discovery layer, not a remediation control, and it does not revoke compromised material by itself.
- Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect certificate trust, lifecycle control and identity governance across modern estates.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org