BORIS for Autodesk Inventor - Secure Your CAD Designs

Broken eMudhra Certificate Keys: What the Windows, Java and Autodesk Trust Changes Mean for Inventor Workstations and CAD Teams | Autodesk Inventor | Register and Certify Ownership of CAD design

2026-11-03 15:22 News
On 17 October 2026 a researcher reported that the private keys of eight intermediate certificate authorities run by eMudhra, an Indian certificate authority, were so weak they could be worked out in under a second. Six of those authorities could issue website (TLS) certificates and two could issue code-signing certificates. Browsers, Microsoft, Apple and many software projects have since blocked them, and on 27 October Autodesk said it has found no direct impact on its products and services.
For most people the fix arrives quietly through browser and Windows updates. Engineering offices are different. CAD workstations are often locked down, kept offline or managed with automatic certificate updates switched off, and a lot of the software around Inventor and Vault brings its own list of trusted certificates. Those are exactly the places Microsoft, Cloudflare and JetBrains say still need attention.
No one has reported that the keys were used in an attack. This is a trust-store clean-up, not an emergency patch, and a useful test of whether your team knows which machines and tools decide what counts as trusted.
TL;DR: Inventor and Vault are not reported as affected, but the Windows machines and tools around them may still trust the broken certificates.

Eight eMudhra intermediate certificate authorities created in April 2025 had private keys that were tiny numbers; one was literally 4. With them, anyone could have created certificates that look trusted for any website, or signed software that looks as if it came from a trusted publisher. eMudhra revoked them on 18 October, and Microsoft released out-of-band updates KB5134133 and KB5134125 on 26 October for Windows devices that do not receive automatic certificate updates. For Inventor teams the work is simple: make sure every workstation and server gets Windows certificate trust updates, update Java and other tools that carry their own trust lists, never "fix" certificate errors by turning verification off, and keep dated proof of your design files that does not depend on one certificate authority.

What happened to the eMudhra certificates?

Certificate authorities vouch for websites and software publishers. Your computer trusts a short list of root certificates, and those roots sign intermediate certificates that do the day-to-day issuing. Whoever holds an intermediate's private key can issue certificates your computer will accept.
According to eMudhra's own incident statement, eight intermediate certificate authorities in its global TLS business were created in a key ceremony on 30 April 2025, added to browser trust lists in mid-2025 and passed two audit cycles. On 17 October 2026 an independent researcher reported to eMudhra, Apple, Google, Microsoft and Mozilla that their keys were weak. Mozilla blocked them in Firefox the same evening, and eMudhra revoked all eight on 18 October.
How weak? The Register reported that security researcher Scott Helme found one of the private keys "is the number 4", with others such as 56 and 115, and recovered them from the public certificates in under a second. A proper key of this type is a random 384-bit number. eMudhra later said a script error during the ceremony produced a second, weak set of keys that was used by mistake, and on 26 October its leadership wrote: "The flaw was ours."
Security vendor Qualys lists the affected intermediates as the EV, OV and DV TLS authorities in eMudhra's G3B and G3C families, plus two OV code-signing authorities in the same families. The issue is tracked as CVE-2026-111943. eMudhra says seven of the eight were never used in production and the eighth issued no certificates, that its infrastructure was not compromised and that its digital signature and eSign services run on separate systems. It has since offered customers replacement certificates from Sectigo, appointed KPMG as external reviewer on 30 October and is winding down its publicly trusted TLS business.

Why does a weak key matter if no certificates were issued?

Because anyone who calculates the key can issue certificates themselves. Cloudflare explained that an attacker could create a forged certificate for any domain and use it to impersonate servers and intercept or change traffic. With the two code-signing authorities, the risk is different: software signed with a forged certificate could look as if it came from a trusted publisher. Autodesk's bulletin lists both risks: website impersonation, interception of secure communications and malicious software disguised as software from a trusted publisher.
Revocation alone does not solve that, because not every program checks revocation reliably. That is why browsers and operating systems went further and stopped trusting the authorities, and in some cases the roots above them. Google removed the emSign ECC Root CA - G3 from the Chrome Root Store, and Mozilla removed the root that signed the intermediates from its NSS library. As of the reports we checked, nobody has seen these keys used in an attack.

What did Microsoft change in Windows?

Microsoft acted in two steps. First it added the eight intermediates to the Windows Disallowed Certificate Trust List and pushed a separate CRLSet update so that Microsoft Edge and WebView2 block the affected TLS certificates without a browser update. Windows devices that receive automatic certificate trust list updates got these changes on their own.
Then, on 26 October 2026, it released out-of-band updates: KB5134133 for Windows 11 versions 24H2, 25H2 and 26H2, and KB5134125 for Windows 10 versions 21H2 and 22H2. They remove seven certificates from the Windows trust list: six eMudhra G3 roots and an AAA Certificate Services cross-sign. The same seven were removed from the Edge trust list on 27 October. Microsoft says these packages are meant for systems without Internet access, systems that cannot reach its certificate update service and systems where automatic certificate trust list updates are turned off. In its own words, removing a root "is not the same as revoking the known impacted intermediate certificate authorities": it is a wider decision that can also affect legitimate certificates under those roots.
That last point matters for suppliers and partners. eMudhra said on 28 October that about 30,800 certificates under the affected G3 hierarchies belong to one US customer ecosystem that is moving to another root. If a supplier portal, file transfer site or internal service you use has a certificate that chains to one of the removed roots, it may start showing certificate errors on updated machines. Microsoft's advice is to find such certificates and replace them, not to trust them again locally unless a security review approves it.

Does this affect Autodesk Inventor or Vault?

Autodesk says no direct impact has been identified. Its bulletin of 27 October 2026 states that it found the eMudhra certificates in use by some third-party components, but that a compromise of those components would not impact Autodesk products or services. Out of caution, Autodesk is refreshing its list of trusted certificate authorities. The bulletin also warns that some applications and systems may stay vulnerable until their own security updates are complete.
So there is nothing to patch in Inventor itself today. The exposure sits around it: the Windows trust store on each workstation and server, the browsers and embedded web views that open Autodesk sign-in pages and the Vault web client, and the scripts, connectors and build tools your team runs alongside Inventor. This follows the same pattern as the php2shell PHP flaws and October's Fusion advisories: Inventor is fine, the systems around your designs need checking.

Where can old certificate trust hide in an Inventor office?

Windows is only one trust store. JetBrains noted on 30 October that Java runtimes such as Oracle JDK, OpenJDK and Amazon Corretto trusted the affected certificates, and that applications with their own bundled trust stores need separate updates. Cloudflare told customers to check container images and indirect dependencies, and Qualys notes that Go 1.27.3 and 1.26.10 now reject these chains. In an engineering office, that list usually includes more than people expect.
Where it livesTypical Inventor-office exampleWhat to check
Windows trust storeInventor workstations, Vault server, file and licence serversAutomatic certificate trust list updates on, or KB5134133 / KB5134125 installed
Offline or restricted machinesShop-floor PCs, CAM stations, air-gapped project networksUpdated Disallowed list delivered by your own process
Browsers and web viewsEdge, Chrome, Firefox, sign-in windows inside desktop appsCurrent browser and WebView2 versions
Java runtimesPDM and ERP connectors, build servers, some CAM and PLM toolsUpdated JDK or vendor build, on every server and agent
Bundled trust listsPython, Node.js and Go scripts, APS integrations, containersRebuilt images and updated dependencies
Your own certificatesSupplier portals, internal sites, signed add-insNo chain to the removed eMudhra G3 roots
Proof of your designs that does not depend on one certificate authority.

BORIS for Autodesk Inventor registers your CAD files from inside Inventor and gives each registered version a blockchain timestamp and a certificate of ownership. The timestamp is anchored on a blockchain rather than signed by a single certificate authority, and your models do not have to leave your machine.

👉 See how BORIS for Autodesk Inventor works

Why are CAD workstations more likely to miss the fix?

Because CAD managers often lock them down on purpose. Workstations are frozen to a validated configuration, kept off the Internet for export-controlled projects, or managed with group policies that turn off automatic root certificate updates. Shop-floor and CAM PCs may run older Windows builds. Microsoft's own target list for the out-of-band updates reads like a description of a typical engineering network: devices without Internet access, devices that cannot reach the certificate update service and devices where automatic updates are disabled.
Our guides on Windows 10 workstations after ESU Year 1 and the .NET 10 update for Inventor and Vault cover the same problem from another angle: machines that are left alone to stay stable also miss the updates that keep them safe. Virtual Vault servers need the same care; the VMware ESX logging zero-day explains why the layer underneath matters too.

What about signed software and add-ins?

Two of the broken authorities could issue code-signing certificates, and Microsoft blocked both. Code signing tells Windows and your users who published a program. A forged certificate would let malware carry a trusted-looking publisher name, which is why the Autodesk bulletin mentions it. Inventor teams install many small tools: add-ins, iLogic helpers, translators, viewers and licence utilities, often downloaded by engineers themselves.
A valid signature is a useful signal, not proof. Install add-ins only from known sources and check that the publisher on the signature matches the vendor you expect. Our overview of Inventor add-ins, iLogic and the API explains what each kind of extension can reach, the trojanized Claude Code extension showed how a trusted name can hide malware, and the Siemens Software Center ClickFix attacks showed how often fake installers target engineering staff.

What should Inventor teams do now?

  1. Check Windows trust updates. Make sure every workstation and server receives automatic certificate trust list updates. Where they are blocked by policy, install KB5134133 (Windows 11) or KB5134125 (Windows 10).
  2. Cover the offline machines. Deliver the updated Disallowed Certificate Trust List to air-gapped, shop-floor and CAM PCs through your own process, and repeat it for future changes.
  3. Update browsers and web views. Keep Edge, Chrome, Firefox and WebView2 current on CAD workstations, since sign-in and web clients run there.
  4. Update Java and bundled trust lists. Patch Java runtimes on connector and build servers, update Python, Node.js and Go dependencies and rebuild container images.
  5. Find certificates on the removed roots. Check supplier portals, internal sites and signed tools for chains to the eMudhra G3 roots, and ask vendors for replacements.
  6. Never disable verification. If a tool shows a certificate error, fix the certificate. Turning off checks to make an error go away removes the protection.
  7. Control signed software. Keep an approved list of add-ins and utilities, with publisher names, and do not let users install tools from unknown sources.
  8. Keep dated proof. Register key design versions with BORIS so their existence and date can be shown independently of any one server, workstation or certificate authority.
For more background, read our remote CAD team security protocols, how to share CAD files securely with contractors and the complete guide to CAD data protection.

What does this incident say about digital trust?

Website and software certificates rest on a small number of organisations keeping their keys secret and well made. Here a script error at one of them created keys anyone could guess, and the hierarchy still passed two audit cycles. The response was fast, with Mozilla blocking the intermediates within hours, yet Microsoft, Autodesk and JetBrains all say some systems stay exposed until their trust lists are updated.
For your design data, the lesson is to avoid resting important proof on a single point of trust. Our explainer on verifiable blockchain certificates shows how a timestamp anchored on a public blockchain can be checked by anyone, and blockchain timestamps for design authorship explains how that supports ownership claims.

The bigger picture

This week's news on our sister sites shows the same pressure on the systems around design data.
CADChain explains how its CAD data protection technology works across CAD systems.

Conclusion

The eMudhra incident did not break Inventor, and nobody has reported an attack using the weak keys. It did show how much depends on trust lists that most CAD offices never look at. Microsoft's out-of-band updates of 26 October exist for exactly the kind of locked-down, offline machines engineering teams like to run. Check that every workstation and server gets certificate trust updates, update Java and bundled trust lists, replace any certificates on the removed roots, never switch off verification and keep proof of your designs that does not depend on one certificate authority.
Your designs, your proof.

BORIS for Autodesk Inventor gives every registered file a blockchain timestamp and a certificate of ownership, straight from Inventor.

👉 See how BORIS for Autodesk Inventor works

FAQ: the eMudhra certificate compromise and Inventor teams

What happened to eMudhra's certificates?

On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities, created in April 2025, were tiny numbers that could be recovered in under a second. Six could issue website certificates and two could issue code-signing certificates. eMudhra revoked all eight on 18 October.

Was anyone attacked with the weak keys?

No exploitation has been reported. eMudhra says seven of the eight authorities were never used in production and the eighth issued no certificates. The risk was that anyone could calculate the keys and issue certificates themselves.

Is Autodesk Inventor or Vault affected?

Autodesk's bulletin of 27 October 2026 says no direct impact on Autodesk products and services has been identified. Autodesk found the certificates in some third-party components, said their compromise would not affect its products and is refreshing its list of trusted certificate authorities.

Which Windows updates remove the eMudhra roots?

KB5134133 for Windows 11 versions 24H2, 25H2 and 26H2, and KB5134125 for Windows 10 versions 21H2 and 22H2, both released on 26 October 2026. They are meant for devices without Internet access, devices that cannot reach Microsoft's certificate update service and devices with automatic certificate trust list updates turned off.

What else besides Windows needs updating?

Anything with its own trust list: Java runtimes such as Oracle JDK, OpenJDK and Amazon Corretto, tools built with Python, Node.js or Go, container images and some vendor tools. Update them or rebuild them with current certificate data.

What should we do if a tool shows a certificate error?

Find out which certificate it is and get it replaced. Do not disable certificate verification to make the error go away; that removes the protection the error is giving you.

How does BORIS help?

BORIS for Autodesk Inventor registers CAD files with a blockchain timestamp from inside Inventor, so you can show which version of a design existed and when, without relying on a single certificate authority. It does not replace Windows updates, certificate management or legal advice.