This is an immediate certificate-trust remediation task, not a conventional patching exercise. Cisco estates may retain affected issuers in embedded certificate bundles, manually configured trust stores or service-specific certificate settings, and administrators need to establish where those chains are trusted before removing them or replacing dependent certificates.
On 27 October, Cisco materially expanded its emergency advisory covering eight compromised eMudhra issuing certificate authorities (CAs). Cisco says an error in eMudhra’s April 2025 key-generation ceremony left the private keys recoverable within seconds. Six affected CAs could issue Transport Layer Security (TLS) certificates; two could sign software.
A compromised intermediate CA key can be used to create certificates that appear to belong to legitimate sites or software publishers. Systems that still trust the relevant chain may accept those forged certificates. There is no single Common Vulnerabilities and Exposures (CVE) identifier or universal patch here: the outcome depends on the trust stores, certificate bundles and deployed identities in each estate.
Operational position on 28 October 2026: Cisco says it is not aware of malicious use. That is reassuring only in the narrow sense that Cisco has reported no confirmed exploitation. It isn’t a reason to defer distrust: possession of a CA private key removes the normal barrier to producing convincing certificates.
Why this reaches beyond eMudhra customers
Certificate validation depends on a chain of trust. An intermediate CA sits between a root authority and the certificate used by a website, service or software publisher. If its private key is compromised, an attacker can potentially create certificates that chain back to it.
Cisco says the affected intermediates were cross-signed by Sectigo’s AAA Certificate Services root in May 2025. That made the chains broadly trusted even where eMudhra’s own root was not natively trusted. The exposure is wider than eMudhra’s customer list or a browser-root-store update.
Cisco appliances and management platforms may carry their own certificate bundles, embedded trust material or product-specific certificate configuration. Updating an administrator workstation’s operating-system trust store does not show that a firewall, switch, identity appliance or virtual management system has stopped trusting the affected issuers.
EMudhra says the affected intermediates were revoked within 14 hours of confirmation and that its investigation found they had not issued publicly trusted end-entity certificates. That is important context, but it doesn’t eliminate the need for emergency distrust. The concern isn’t only whether eMudhra issued a legitimate customer certificate through these intermediates; weak CA keys could be used to create a fraudulent certificate that appears to chain through them.
What Cisco has confirmed — and what remains unsettled
Cisco says a product not listed is considered not affected by its review. Read the lists closely, though. “Impacted”, “under investigation” and “not vulnerable” are different states, and the advisory changed again on 27 October.
Cisco lists Packaged Contact Center Enterprise, Unified Contact Center Enterprise, Unified Contact Center Express and Real Time Monitoring Tool as impacted with immediate remediation, each associated with Cisco bug records. Secure Email Gateway, Secure Email and Web Manager, Secure Firewall Threat Defense (FTD), Secure Firepower Management Center (FMC), and Unified Customer Voice Portal are also listed as impacted.
For Secure Email Gateway and Secure Email and Web Manager, Cisco says the Trusted Root 2.8 update is normally retrieved automatically. Estates configured for manual updates need an administrator to invoke the documented process. Unified Customer Voice Portal updates its untrusted certificate list in the background through its standard Automatic Root Certificates Update mechanism. Those controls help only if automatic updates are operating and the appliances can reach their update service.
Cisco also lists software fixes for several products. Available version numbers include ThousandEyes Enterprise Agent Application-hosting Agent 5.2.2, RoomOS 11.41.2.3 and 26.7.4.3, Duo Access Gateway 3.2.0, Duo Agentic Authorization Connector 1.0.1, and Duo Network Gateway 3.4.1. Don’t assume the remainder are available because a version is named. Cisco’s table labels them target releases: Enterprise Chat and Email 2026.04.1 is dated 30 October; IOS XR 26.4.1 is dated 30 November; and Intersight Virtual Appliance 1.1.8-2 is a planned November 2026 target, not a release confirmed as available on 28 October.
The same applies to Cyber Vision 5.6.2, the Secure Network Analytics 7.6.1 Rollup patch, Meraki MV Smart Camera firmware, NSO releases and several Ultra Packet Core components. Treat advisory dates as planning information, not proof that protection has arrived. Cloud services are a separate case: Cisco says Duo Cloud and Secure Access are remediated with no customer action required, while Meraki Dashboard, Webex Calling and Webex Meetings remediation remained in progress at the time of the update.
| Estate area | Cisco’s status on 27 October | Practical action |
|---|---|---|
| FMC and FTD | Impacted; Cisco has published containment and certificate-bundle guidance. | Verify certificate-bundle update status and inspect separately configured trusted CAs and trustpoints. |
| ISE and ISE-PIC | Still under investigation. | Review installed system and trusted certificates now; do not wait for the investigation to conclude. |
| NX-OS and selected switching platforms | Listed under investigation, with specified affected trains for MDS, Nexus 3000 and Nexus 9000. | Map actual release trains, then follow the advisory for product updates and changes. |
| Cloud services marked remediated | Cisco says no customer action is required. | Record the vendor assertion, retain advisory evidence and monitor for status changes. |
| Cloud services marked “in progress” | Remediation incomplete. | Do not treat as closed; monitor Cisco’s advisory and assess compensating controls. |
Don’t wait for the product investigation to finish
For UK and Channel Islands organisations, the immediate work is mostly unglamorous: certificate inventories that should already exist, appliance configuration reviews that may be overdue, and careful change control around authentication services.
Identity Services Engine shows why this isn’t merely a firmware-update exercise. Cisco says the affected eMudhra authorities are not in ISE’s default trusted store, but warns that deployments may have added them after installation. Its guidance calls for checking system certificate chains, trusted certificates, LDAP (Lightweight Directory Access Protocol) secure-authentication settings, secure syslog targets and, where applicable, RADIUS (Remote Authentication Dial-In User Service) Datagram TLS (DTLS) certificate selection.
If an affected authority appears in ISE’s trusted certificates, deletion may be appropriate — after establishing what the certificate is trusted for. Removing a CA used for endpoint authentication, administrator authentication, IPsec or infrastructure connections can break access control or logging. Cisco’s advice is to migrate dependent services to a new CA first. That is the awkward operational trade-off: leaving trust in place is dangerous, but indiscriminate removal can disrupt authentication when teams most need reliable access.
Several networking products remain under investigation. Cisco specifically identifies MDS 9000 releases 9.4(1) through 9.4(5a); Nexus 3000 releases 9.3(9) through 9.3(18) and 10.x except 10.1; Nexus 9000 standalone NX-OS releases 9.3(9) through 9.3(18) and 10.x except 10.1; and Nexus 9000 fabric switches in ACI mode on code trains 15.x and 16.x. IOS XE, APIC, cBR-8, Secure Web Appliance, ISE and ISE-PIC are also still listed as under investigation.
That doesn’t mean every listed system is exploitable in every deployment. It means Cisco has not finished determining product-level impact. For organisations with substantial Cisco estates, that is enough to put the affected release trains on the incident worklist now.
Priority actions for the next working day
- Build a certificate-trust inventory: identify Cisco appliances, management platforms and virtual appliances with bundled trust stores, manually imported CA certificates, certificate pinning (restricting accepted certificates) or TLS-inspection policies.
- Search for the affected eMudhra chains: include appliance trust stores, internal application stores, Java keystores and manually configured CA bundles. Record where each is trusted and for what service.
- Apply available remediation: confirm automatic root or bundle updates have completed; manually trigger Cisco-documented updates where required.
- Replace dependent certificates before deleting a required trust anchor: prioritise administrator authentication, VPN, machine identity, LDAP and secure logging paths.
- Track planned fixes separately: place Cisco’s future-dated releases in change planning, but do not describe them as deployed protection.
- Review telemetry: look for newly observed certificate issuers, unexpected TLS inspection failures, unfamiliar signed binaries and certificate-validation exceptions introduced by users or administrators.
Secure Firewall can contain part of the risk, but not solve it
Cisco’s FMC guidance offers a useful compensating control: a TLS decryption policy can block server certificates with the known affected eMudhra issuer names. This can reduce exposure for unmanaged or headless systems that have not yet received trust-store remediation. It is containment, not a substitute for removing trust and replacing affected certificates.
The limits matter. The control needs TLS visibility, correct policy association and rule order; bypass paths can leave traffic untouched. Cisco also cautions that TLS 1.3 behaviour depends on software version and settings, and teams should validate visibility before claiming coverage. A firewall rule that cannot see the certificate cannot reliably decide on its issuer.
FMC and FTD can automatically update a local CA bundle used for Cisco service connections, with Cisco documenting that capability from FMC/FTD 7.0.5, 7.1.0.3, 7.2.4 and 7.3.0 onwards. Those are feature thresholds, not universal upgrade recommendations. Cisco also says the local bundle is separate from trusted-CA objects used for SSL decryption and from device trustpoints used for identity or VPN certificates. Checking one does not clear the others.
Revocation is not enough on its own
Revocation is necessary, but it isn’t a magic eraser. A client has to obtain and honour revocation information, while embedded or stale trust stores can lag well behind browser and operating-system updates. The sensible posture is active distrust, not passive confidence that the wider Web public key infrastructure (PKI) will eventually tidy this up.
Cisco says it knows of no malicious use, and eMudhra says no publicly trusted end-entity certificates were issued from the affected intermediates. Both points support a measured response. Neither makes this a low-priority ticket. The severity comes from the collapse of a trust boundary, not a published exploit chain against one appliance.
For UK and Channel Islands organisations, the immediate work is mostly unglamorous: certificate inventories that should already exist, appliance configuration reviews that may be overdue, and careful change control around authentication services. That’s still better than discovering during an incident that the network trusted more certificate authorities than anyone realised.
Sources and further reading
Spot an error?
If something factual looks wrong, outdated or misleading, flag it here. Corrections are reviewed separately from normal article comments and reader questions.