When One Byte Breaks the Chain: A PKI Incident Field Guide

Scope

This guide outlines the technical requirements and Operational Planning and Control for public key infrastructure (PKI) certificate management within ISO/IEC 27001:2022 and SOC 2 frameworks. You'll find specific clause references, implementation steps, and a breakdown of what went wrong in the eMudhra incident, where a one-byte private key compromised eight intermediate certificates trusted by major root stores like Chrome, Mozilla, Microsoft, and Apple.

Use this guide when designing certificate lifecycle controls, preparing for an assurance engagement focused on cryptographic operations, or responding to a certificate authority failure affecting your trust chain.

Key Concepts and Definitions

Certificate Authority (CA): An entity that issues digital certificates. This is a critical third-party service provider requiring vendor risk assessment under ISO/IEC 27001:2022 Clause 5.19.

Intermediate Certificate: A certificate signed by a root CA that can sign end-entity certificates. The eMudhra incident involved eight intermediate certificates, six for TLS and two for code signing.

Private Key Strength: The security of a key pair depends on key length. The affected certificates used elliptic curve cryptography meant to have 48-byte keys but were generated with one-byte keys, making them easy to crack.

Cross-Signing: When an established CA signs another CA's certificate to extend trust. Sectigo cross-signed the deficient eMudhra certificates in May 2025, showing how trust dependencies can propagate risk.

Certificate Revocation List (CRL): A list of revoked certificates. Unlike web browsers that check CRLs automatically, many applications and embedded systems don't, requiring manual updates to distrust compromised certificates.

Requirements Breakdown

ISO/IEC 27001:2022 Controls

Annex A 8.24 (Use of cryptography): Implement a policy on cryptographic key management that defines minimum key lengths, approved algorithms, and key generation procedures. The eMudhra script that generated one-byte keys violated this control.

Your cryptography policy should specify:

• Minimum key lengths for each algorithm type (e.g., 2048-bit RSA, 256-bit ECC)
• Approved random number generators for key material
• Separation between test and production key generation environments
• Mandatory code review for any script affecting cryptographic operations

Annex A 5.19 (Information security in supplier relationships): When relying on external CAs, you're outsourcing a critical security function. Supplier agreements must include:

• Right to audit cryptographic operations
• Notification requirements for security incidents affecting issued certificates
• Service level commitments for certificate revocation and replacement
• Evidence of the CA's own ISO/IEC 27001 certification or WebTrust audit

Annex A 8.32 (Change management): The eMudhra incident stemmed from a script deployed in April 2025. Your change management process must treat cryptographic infrastructure changes as high-risk:

• Mandatory security review before deployment
• Test environment validation with key length verification
• Rollback procedures for certificate generation systems
• Post-deployment validation that generated keys meet policy requirements

SOC 2 Trust Services Criteria

CC6.1 (Logical and physical access controls): Your certificate management systems require privileged access controls. The script that generated weak keys should have been subject to:

• Segregation of Duties Policy between developers who write key generation code and operators who deploy it
• Multi-party approval for changes to production certificate systems
• Audit logging of all key generation operations with automated alerting on anomalies

CC7.2 (System monitoring): Implement detective controls to catch key generation failures. Implement:

• Automated validation that generated keys meet minimum length requirements
• Alerting when key material deviates from policy parameters
• Regular sampling and manual inspection of issued certificates

Implementation Guidance

Certificate Lifecycle Controls

Start with an inventory. Document every certificate your organization depends on, including:

• Issuing CA and intermediate chain
• Expiration dates
• Systems and applications that validate these certificates
• Update mechanisms for certificate revocation information

For the eMudhra incident, affected organizations needed to migrate 30,000 certificates to an alternative trust chain. If you can't answer "which systems trust eMudhra intermediates?" in under an hour, your inventory isn't sufficient.

Vendor Risk Assessment for CAs

Your third-party risk assessment for certificate authorities should include:

• Review of the CA's most recent WebTrust audit report or ISO/IEC 27001 certificate
• Incident history (check CT logs and browser root program disclosure pages)
• Cross-signing relationships that could propagate trust issues
• Geographic and regulatory considerations

Cryptographic Operations Testing

Don't rely solely on the CA's controls. Implement your own validation:

• Parse issued certificates to verify key lengths match your policy
• Test certificate chain validation in your applications
• Maintain a test environment that can simulate certificate revocation
• Document your procedure for emergency certificate replacement

Consider a scenario where your primary CA experiences a trust event. How quickly can you:

1. Identify all affected certificates?
2. Generate replacement certificates from an alternative CA?
3. Deploy new certificates to production systems?
4. Verify that clients trust the new chain?

If you don't have documented procedures and haven't tested them in the past year, you're not ready.

Common Pitfalls

Assuming browsers protect everything: Web browsers check CRLs automatically, but standalone applications, mobile apps, and embedded systems often don't. The Go, Python, Rust, Java, RedHat Linux, and Ubuntu communities all required manual patches to distrust the eMudhra intermediates. Your risk assessment must account for non-browser certificate validation.

Ignoring cross-signing risks: When Sectigo cross-signed eMudhra's certificates, they extended trust without necessarily extending oversight. Your vendor risk assessment should map the full trust chain, not just your direct CA relationship.

Treating key generation as routine automation: The eMudhra incident began with a script deployed in April 2025 that generated weak keys, which were "mistakenly used for certificate signing because the key labels were similar." This is a change management failure. Cryptographic operations require heightened scrutiny, mandatory code review, security testing, and post-deployment validation.

Overlooking certificate transparency logs: Certificate Transparency (CT) logs provide a public record of issued certificates. Monitor CT logs for certificates issued to your domains by CAs you don't recognize. The researcher who discovered the eMudhra issue found it through certificate analysis, not through CA disclosure.

Quick Reference Table

Version note: This guide references ISO/IEC 27001:2022. If you're still operating under the 2013 version, map Annex A 8.24 to A.10.1.1, Annex A 5.19 to A.15.1.1, and Annex A 8.32 to A.12.1.2.

When your auditor asks how you'd respond to a CA trust event, walk them through your certificate inventory, vendor risk assessment, and emergency replacement procedures. The eMudhra incident required coordinated updates across multiple programming languages, operating systems, and browser vendors. Your controls should assume you won't get advance warning.