The eMudhra incident is usually described through its effect on HTTPS. Six of the eight affected intermediates could issue TLS certificates. The other two were associated with code signing. That detail changes the scope of a security review because a network scanner can observe a TLS chain far more easily than it can inventory every signed binary, installer and build pipeline.
The reviewed sources do not report a forged code-signing certificate or a malicious signed release. Apple said its frameworks do not trust the two code-signing CAs for the TLS purpose, while Microsoft and other trust-store operators handled the broader certificate set in their own programs. The absence of a reported misuse is not a reason to ignore build and signing infrastructure.
Separate the two evidence problems
TLS exposure asks which service presents which chain to which client. Code-signing exposure asks which artifact was signed by which key, who published it and which platform trusts the signer. The useful evidence lives in build logs, signing service records, certificate inventories, release manifests and endpoint signature checks.
ZoomEye can help with the network side of the incident. The query ssl.cert.issuer.cn="eMudhra" returned 1,456 certificate-issuer observations on October 30, 2026. That is a view of public TLS certificate data. It provides no information about Authenticode signatures, macOS notarization, package signatures or the private keys used by a release pipeline.
This boundary should be explicit in the incident record. An eMudhra issuer appears in a public TLS certificate does not tell a reviewer whether a software artifact is trusted. A clean public TLS scan does not close a code-signing investigation.
Inventory signing dependencies
List every signing service, hardware token, certificate store and build account that can produce a release. For each, record the CA hierarchy, certificate subject, serial number, public-key hash, validity period and whether the signing action requires a second approver. Link the signing identity to the artifacts it has produced.
Then collect evidence from the build system. A release manifest should identify the artifact digest, signing identity, timestamp and the verification result on a clean machine. Code-signing credentials should not be available to ordinary build jobs. If a certificate is stored on a server, the private key protection and access log matter as much as the certificate's identity.
Use trusted verification, not file names
Platform signature tools should report the signer chain and trust result. Compare those results with the inventory rather than relying on a vendor name in a file path. If a release was signed during the incident window, preserve the artifact and its signature record for review. Do not re-sign or overwrite it before the original evidence is captured.
The response owner should also test revocation and timestamp behavior. A signature can remain valid after a signing certificate is revoked when a trusted timestamp proves that the signature was created before the revocation. That is a policy-specific decision, so the reviewer should apply the platform's documented rules rather than assume that every old artifact is invalid.
The public 1,456-certificate observation remains useful for finding TLS endpoints and understanding the scale of eMudhra use. It cannot replace a signing inventory. The two workstreams should share the incident timeline and certificate fingerprints while keeping their evidence separate.
Completion
The code-signing review is complete when every release path has an identified signer, the signer chain has been checked against the affected set, and the platform verification result is recorded for representative artifacts. If no affected signer is found, the conclusion should state which inventory and time window were checked. A scanner count is not that conclusion.