eMudhra's statement on its revoked intermediate CAs is damage control masquerading as an incident report. The private scalars behind eight NIST P-384 intermediate CA keys were all below 256: 4, 56, 66, 115, 155, 156, 230, and 237. These were supposed to be 384-bit elliptic-curve secrets. Instead, every single private key could be recovered by testing at most 255 candidate points. Blaming "AI-assisted tooling" for the discovery is absurd. On an elliptic curve, the public key is Q = d \cdot G. When the private scalar d is an integer between 1 and 255, recovering it is trivial: test candidate scalar multiples of the generator against the published public key. No exotic exploit. No neural networks. Scott Helme recovered all eight private keys on a standard laptop in under a second. Mozilla independently confirmed the result. eMudhra claims that because no certificates were issued and their servers weren't breached, there was no customer impact. That completely misses how PKI works. Anyone who recovers an intermediate CA's private key can sign fraudulent certificates without accessing the CA's servers. The signatures are generated offline. Whether a client accepts them depends on its trust store and revocation policies, not whether eMudhra's network was breached. Two of the eight compromised intermediates were for Code Signing, not TLS. Code signing has no universal Certificate Transparency requirement like browser TLS. Someone holding those recovered private keys could sign unauthorized software that appears to come from a trusted signing authority, without the signature ever showing up in public CT logs. The absence of an issuance record on crt.sh doesn't eliminate that risk. All eight intermediates were cross-signed by Sectigo under its AAA Certificate Services root in May 2025. Chrome and Mozilla had already phased that root out, but it remained active in Microsoft and Apple root programs at the time. That opened additional trust paths across major operating systems, meaning the trust implications were never confined to one browser or platform. eMudhra framed the blast radius as "one customer ecosystem in the US." Separately, its engineers estimated on Mozilla Bugzilla (#2083449) that roughly 30,000 certificates required emergency migration after root programs distrusted their parent ECC root, ~97% coming through ACME. That is a massive operational disruption. Go also had to ship CVE-2026-111943 specifically to hardcode a denylist into crypto/x509. Invoking "FIPS 140-2 Level 3 HSMs" explains nothing. eMudhra admitted that a flawed "key wrap/unwrap step" in their ceremony generated the weak keys. HSM certification only guarantees physical boundary security. It cannot stop broken scripts or flawed workflows from handling and publishing invalid key objects. When your CA private scalar is literally 4, the ceremony controls failed. eMudhra also notes that this went undetected through two independent audit cycles. Yet 16 months ago (Mozilla Bug 1970728), six of these exact intermediates were caught publishing CRLs with invalid signatures because the wrong CA key configuration was used. Sectigo sent an alert, and eMudhra’s internal spam filter quarantined the warning. The red flags were already waving in June 2025. Four questions eMudhra must answer on Bugzilla with technical facts, not corporate assurances: * What precisely went wrong in the key wrap/unwrap step that generated private scalars below 256? * Why did ceremony verification controls fail to catch these keys before certificates were published? * Why were intermediates designated for non-production use submitted to Sectigo for cross-signing? * Have all other keys generated through this ceremony workflow been independently revalidated across your eSign and enterprise PKI pipelines? Cut the deflection, drop the corporate gaslighting, and own your shit in public.