FedRAMP Explained

Questions / Answer

When a CA Fails: What Continuous Monitoring Owes Your Trust Store

October 22, 2026

A cloud server chained to a browser window whose padlock turns red, a gear inspecting the chain

Your FedRAMP package lists your cryptography. It names your cipher suites and your key lengths. This week asks a harder question. Who signs your signatures, and what happens when that signer fails?

What happened

On October 17, 2026, a researcher reported that eight eMudhra intermediate certificates had compromised private keys. The keys were generated with almost no randomness. Anyone could recover them from public certificate data. Six of the certificates sign TLS traffic. TLS is transport layer security. Two sign code.

Mozilla announced the compromise on the oss-security mailing list. The certificates were trusted by the Mozilla, Microsoft, Apple, and Chrome root programs. Mozilla and Chrome blocked them on October 17. Apple and Microsoft also moved to block the affected certificates. eMudhra revoked them on October 18.

Chrome will remove the emSign ECC Root CA-G3 certificate from its root store starting October 27, 2026. Removing a root can break legitimate sites that still chain to it. Trust removal has its own blast radius.

The FedRAMP angle

FedRAMP continuous monitoring expects you to track changes in your supply chain and your cryptography. A CA compromise is both. Your monthly scan will not catch it. Your trust store review will.

Three artifacts belong in your package after an event like this. The assessment record that shows which of your systems chained to the affected CA. The remediation record that shows the blocks landed everywhere, including containers and embedded components. The risk note for any system that cannot take a trust store update quickly.

Your authorizing official needs one more thing. The residual risk statement for clients you do not control. A customer browser you do not manage may keep trusting the weak chain until its vendor updates land.

What to do this week

Check your service against the eight eMudhra intermediates. Check your vendors too. A SaaS product inherits the PKI of every component it embeds.

Add CA compromise to your incident response plan if it is not there. Name the owner of trust store updates. Define the deadline. Practice it once. The browser vendors did this in hours. Your plan should aim for the same day.

Sources

  • eMudhra Intermediates Compromise, Dennis Jackson, Mozilla, oss-security mailing list, October 20, 2026. https://www.openwall.com/lists/oss-security/2026/10/20/1
  • India's cybersecurity agency warns of compromise of eMudhra intermediate CA certificates, CERT-In advisory reported October 21, 2026.
  • Original diagram by PolicyCortex.

Next step

Want control evidence that pulls itself from your live systems? See how PolicyCortex collects it on Azure.