Can you trust software signed under a compromised CA key?

Sometimes, and only with evidence. When a certificate authority's code signing key leaks, a binary signed and timestamped before the revocation date the CA records can still verify. Anything signed after that date, or never timestamped, is untrusted until you can prove where it came from. A signature was never proof of safety.

This question came up again this month. On 17 October 2026 a researcher reported that eight intermediate CA keys at the Indian certificate authority eMudhra had been generated so weakly that anyone could compute them from the public certificates. Six of the eight were TLS intermediates. Two, named EM OV CS CA - G3B and EM OV CS CA - G3C, were code signing intermediates. Browsers moved within hours on TLS. The code signing side raises an older question: what about binaries signed under a chain that can no longer be trusted?

We covered the incident itself in the eMudhra CA key compromise explained and the business fallout in eMudhra exits the TLS certificate business: what customers do now. This post goes wider: what a signature proves, how timestamps and revocation decide the fate of old signatures, what Windows, macOS and Sigstore check, and how to write a policy that never treats "signed" as "safe".

Key takeaways

• A code signature proves the file is unchanged and that someone held a key a CA certified. It does not prove the code is safe or the build was clean.
• Timestamps decide the fate of old signatures. Microsoft documents that an Authenticode timestamp keeps a signature verifiable after expiry or revocation, if it was valid when timestamped.
• Revocation dates can be set in the past. CA/Browser Forum rules say that for key compromise the date SHOULD be the earliest suspected compromise, so later signatures fail.
• A leaked CA key lets an attacker mint code signing certificates in any name. Verifiers that never learn of the revocation will accept them.
• eMudhra's preliminary statement says none of the eight intermediates issued end-entity certificates. If that holds, any binary chaining to its two code signing intermediates deserves investigation.
• macOS Gatekeeper relies on Apple's Developer ID and notarization, not commercial CA code signing certificates.
• Build provenance, transparency logs, SBOMs and reproducible builds give stronger evidence. Policies should require them where it matters.

What happened with the eMudhra code signing intermediates

The facts below come from our explainer, Google's Chrome security blog, BleepingComputer and The Hacker News. Where the sources differ, we say so.

Two details matter for code signing. First, Chrome blocked six intermediates, not eight: The Hacker News reports that Chrome's TLS verifier will not build a path through an intermediate restricted to code signing, so the two code signing intermediates were never a TLS risk in Chrome. Second, the sources disagree on Apple's date (19 October per The Hacker News, 22 October per BleepingComputer). Neither changes the advice below.

eMudhra's account is preliminary. It says the weak keys came from a wrap and unwrap step during the ceremony, that its root keys and other intermediates are unaffected, and that its domestic digital signature and eSign services run on separate infrastructure. None of the sources we read states that any software was signed under the two code signing intermediates. Google's post concerns HTTPS only and says no TLS certificates chaining to these CAs had been logged to Certificate Transparency before the block.

What does a code signature prove, and what does it not prove?

A code signature is a cryptographic statement made with a private key. When your operating system verifies it, it checks three things: that the hash of the file matches the signed hash, that the signer's certificate chains to a root it trusts, and that nothing in the chain is expired, revoked or explicitly distrusted at the relevant time. Microsoft describes Authenticode as providing "authorship and integrity guarantees for binary data." That phrase is precise, and the limits are in what it leaves out.

A valid signature proves integrity (one changed byte breaks it), that someone holding the private key signed the file, and that a trusted CA issued that key's certificate after some identity check.

It does not prove:

• That the code is safe. Signed malware verifies exactly like clean software.
• That the publisher meant to sign it. If an attacker reached the build server or signing service, the signature is real and the intent is not.
• That the build was clean. A compromised dependency is signed along with everything else.
• That the CA was sound. If the CA's key leaked, the chain proves only that someone holding that key signed it.
• That you got it from the right place. A signature binds to the file, not to the page you downloaded it from.

The last point showed up in the same news cycle. Researchers described a fake download site impersonating a well known firewall vendor's VPN client. According to The Hacker News weekly recap, the site served the genuine signed installer from the vendor's own content network while a pop-up on the fake page harvested VPN credentials. Some early summaries called it a signed malicious installer; the recap does not support that. The signature was perfect, and the risk was the channel around it.

For a related case where valid signatures sat on trojanized software, see why a valid signature did not make a signed installer safe.

What happens to software signed before a CA is revoked or distrusted?

Timestamps: the date that matters is when it was signed

Under the CA/Browser Forum Code Signing Baseline Requirements (version 3.11.0), code signing certificates issued from 1 March 2026 may be valid for no more than 460 days. Software lives far longer, so timestamps let a signature outlive its certificate.

When you sign with SignTool, it can send your signature to a time stamp authority (TSA), which returns a countersignature carrying a trusted time. Microsoft's documentation says this lets a signature verify even after the signing certificate has expired or been revoked, because the verifier trusts it if the certificate was valid at the timestamped time. Without a timestamp, Microsoft warns, the signature becomes invalid when the certificate expires and Windows treats the binary as unsigned.

So for a timestamped binary, the question becomes: was the chain valid at the time in the timestamp?

Revocation dates: when the CA says the problem started

A CRL entry records a revocation date. For code signing it is deliberately flexible, because of timestamps. The Code Signing Baseline Requirements tell the CA to "determine an appropriate value for the revocationDate based on its own investigation", allow it to set a historic date, and say that for key compromise events the date SHOULD be the earliest date of suspected compromise. Microsoft's Trusted Root Program also requires that a CA "must be able to revoke a certificate to a specific date as requested by Microsoft."

This produces a clean rule for timestamped signatures:

• Timestamp before the revocation date: the signature can still verify. The CA is saying the key was sound at that time.
• Timestamp on or after the revocation date: the signature fails, because the chain was revoked when it was signed.
• No timestamp: the signature is checked against the current time, so once the revocation is known it fails.

For a key that was weak from the moment it was generated, the honest "earliest date of suspected compromise" is the creation date. We could not confirm which revocation date eMudhra recorded for the two code signing intermediates. You can read it yourself from the issuing CA's CRL, as shown in the walkthrough below.

Distrust of the root: the blunt instrument

Removing or disabling a root is not targeted: every chain under it fails, whatever the timestamp says. Mozilla removed emSign ECC Root CA - G3 from NSS on 20 October and Chrome plans to on 27 October, but those are TLS decisions. Code signing trust on Windows is governed separately by the Microsoft Trusted Root Program, whose requirements note that code signing roots can be set to "disable" in Windows.

The last row is where real risk lives. Every rule above assumes the verifier has current revocation data.

Which operating systems and tools actually check revocation for code signatures?

Revocation only protects machines that learn about it. Here is how the main platforms behave, based on their own documentation.

Windows: Authenticode, the disallowed list and SmartScreen

Windows has three layers that matter here.

Authenticode verification. Microsoft documents that SignTool's verify command checks whether the signing certificate was issued by a trusted authority and whether it has been revoked. /tw warns when a signature has no timestamp, and /all checks every signature on a dual signed file.

The disallowed certificate trust list. Microsoft distributes explicitly untrusted certificates as disallowedcertstl.cab through automatic root updates, and its documentation says machines that can reach Windows Update receive updated lists daily. Disconnected environments do not, unless an administrator syncs them with certutil -syncWithWU and points clients at an internal share by Group Policy. A machine that has not synced in weeks has not heard about recent blocks.

SmartScreen reputation. Microsoft Defender SmartScreen checks downloaded apps and "the digital signature used to sign a file." Items with established reputation pass silently; items without it draw a warning. A certificate freshly minted from a leaked CA key has no reputation, so SmartScreen is a useful backstop. Microsoft notes it does not cover files on internal shares, and users can click past warnings.

One more Windows detail is worth checking rather than assuming. Microsoft's Trusted Root Program requirements say code signing does not support ECC keys, and the eMudhra intermediates used P-384 ECC keys under an ECC root. We could not confirm whether Windows ever treated emSign ECC Root CA - G3 as a code signing anchor. Check your own machines with the commands below rather than relying on that inference.

macOS: Developer ID, notarization and Gatekeeper

Apple's Platform Security guide says Gatekeeper, by default, requires software from outside the App Store to carry a registered developer signature and Apple notarization. Developer ID certificates are created in an Apple developer account, so the chain Gatekeeper cares about is Apple's own, not a commercial CA's.

Notarization adds a second check. Apple's Developer ID page says the notary service automatically scans Developer ID signed software for malicious software and common signing problems, then issues a ticket that tells Gatekeeper the software has been notarized. The ticket can be stapled to the app, disk image or package with xcrun stapler.

So a leaked commercial CA code signing key does not, by itself, get software past Gatekeeper on a default install. macOS is not immune to signing abuse: researchers have reported malware signed and notarized under real Developer ID accounts, and the Apple pages we reviewed do not describe the revocation flow in detail.

Linux packages, Java and other verifiers

Linux distributions sign repositories with their own keys, so a commercial CA's code signing key has no bearing on apt or dnf. Java JAR signing, PowerShell scripts, Office macros, PDF signatures and some allowlisting tools do rely on CA chains, each with its own revocation defaults. Treat each as a separate verifier; many fail open when they cannot reach a CRL or OCSP responder.

Sigstore: short lived certificates and a public log

Sigstore takes a different route to the same problem. According to its documentation, the signer generates a key pair, proves its identity to the Fulcio CA with an OpenID Connect token, and receives a certificate that Fulcio documents as "valid for 10 minutes." The private key is discarded after one use, and the signature, certificate and artifact digest are recorded in Rekor, an append-only transparency log.

With no long lived signing key, there is no key to leak years later and no long revocation tail. The trust question moves to two places: the identity provider account used to sign, and Sigstore's own root of trust. Because every signature is in a public log, an identity owner can watch Rekor for signatures they did not make. That is a detection property traditional code signing lacks.

How would an attacker use a leaked code signing key?

No attack steps here, just the shape of the threat. There are two different keys to think about.

A leaked subscriber key lets an attacker sign files as that one company, inheriting its name and, for a while, its SmartScreen reputation. This is why the Baseline Requirements have required subscriber keys to live in hardware modules since 1 June 2023.

A leaked intermediate CA key, as with eMudhra, is broader. Whoever holds it can issue new code signing certificates in any subject name they choose, then sign with those. CERT-In's concern, as summarized in our explainer, was exactly this: malware signed so it appears trusted. In practice, such a certificate would:

• pass naive "is this file signed by a trusted chain" checks on machines that have not received the revocation or disallowed list;
• pass allowlisting rules written by issuer name or by "any trusted publisher";
• start with zero SmartScreen reputation, so it would draw a warning on internet downloads to Windows machines with SmartScreen on;
• fail on any verifier that checks revocation and has current data, because any new signature is timestamped after the revocation date or not timestamped at all.

Backdating a forgery under an early revocation date would need a valid timestamp from a TSA, and the Baseline Requirements require TSAs to keep their CA keys in offline hardware modules. So the realistic risk is not old signatures. It is verifiers that never learn about the revocation, and policies that treat any trusted signature as a pass.

How do you find software in your estate signed under an affected chain?

Start from the facts in this case. If eMudhra's preliminary statement is accurate and none of the eight intermediates issued end-entity certificates, there should be no legitimate binaries chaining to EM OV CS CA - G3B or EM OV CS CA - G3C. That turns the search into an anomaly hunt: any hit is a finding to investigate, not a vendor to call for a re-signed build.

The broader method works for any future CA compromise:

1. Inventory signed executables on endpoints, servers, software distribution shares and golden images.
2. Extract the full signer chain for each, not just the leaf subject.
3. Match on public keys (SPKI hashes), as Chrome did, because cross-signed copies share a key but not a certificate. Our explainer lists the hashes.
4. Compare each match's timestamp with the revocation date in the CRL.
5. Quarantine and investigate every match.

Endpoint management tools can run the PowerShell in the walkthrough below at fleet scale.

Should vendors re-sign releases, and how should they tell customers?

If you are a software vendor and your releases are signed under a chain that has been revoked or distrusted, the answer is yes, re-sign, and do it openly. If they are signed under a healthy chain and the incident is someone else's CA, you have nothing to re-sign, but customers may still ask, so be ready with a short statement.

A good re-signing plan:

• Get a new certificate from a different hierarchy, not a sibling intermediate under a CA its root programs are still reviewing. Our exit post covers the same logic for TLS.
• Ship a new version number rather than silently re-signing. Re-signing changes the file hash, which breaks hash allowlists.
• Timestamp every signature with an RFC 3161 TSA, using SHA-256 for both the file digest and the timestamp digest, as Microsoft recommends.
• Publish hashes and provenance for the new builds, ideally as signed attestations customers can verify with a command.
• Revoke your old certificate if there is any chance its key was exposed, and ask the CA to set the revocation date honestly.
• Tell customers plainly: which versions were affected, which chain they used, what the new chain is, how to verify the new build, and whether any action is needed for installed copies.

A customer notice can be short, but if it cannot answer "how can you check", it is not finished.

What stronger evidence exists beyond a signature?

A signature answers "who held the key". Supply chain security needs answers to "how was this built", "what is inside it" and "could someone else get the same result". Each has a standard.

Build provenance (SLSA)

The SLSA provenance specification defines provenance as "an attestation that a particular build platform produced a set of software artifacts." It records the builder identity (builder.id), the build type, the external parameters a user supplied, and resolvedDependencies, the exact inputs such as a git commit, each with a digest. A consumer can check that an artifact was built by the expected builder from the expected source. SLSA is clear about its limit: provenance does not prove the inputs were good; that has to be verified separately.

Artifact attestations in CI

GitHub's artifact attestations generate signed build provenance for binaries and container images from a workflow, using the actions/attest action with id-token: write and attestations: write permissions. Consumers verify with gh attestation verify, naming the repository the artifact should have come from. The same action can attach an SBOM attestation in SPDX or CycloneDX format.

Transparency logs and SBOMs

Sigstore's Rekor log makes every signature public, so a signature made with your identity is there for you to find. An SBOM lists the components inside a build; it does not prove origin, but signed as an attestation it is bound to one artifact digest and answers "does this release contain the vulnerable library" in minutes.

Reproducible builds

The Reproducible Builds project defines a build as reproducible when, given the same source, environment and instructions, "any party can recreate bit-by-bit identical copies of all specified artifacts." If two independent builders produce the same hash, a compromise of one builder or one signing key stops being invisible.

How do you write a policy that does not treat "signed" as "safe"?

Many policies say "only run signed software". That sentence is where this kind of incident gets in. A template you can adapt:

1. Signature is necessary, not sufficient. Unsigned executables are blocked outside developer environments; signed ones are evaluated further.
2. Publisher, not issuer. Allow rules name specific publishers (subject plus the expected issuing chain), never "any certificate from a trusted CA".
3. Timestamp required. Signatures without a trusted timestamp are treated as unsigned for production use.
4. Revocation must be current. Endpoints sync the disallowed list and root updates within a set window, such as 48 hours, including disconnected networks.
5. Provenance for what you build. Internal releases and container images must carry build provenance from an approved builder and an SBOM attestation, verified at deploy time.
6. Provenance or equivalent for what you buy. For critical third party software, ask vendors for provenance, an SBOM and their signing process, and record the answers.
7. Incident trigger. When a CA or signing key is reported compromised, run the estate search within one business day and treat every match as an incident until cleared.
8. Exceptions expire. Any exception to the above has an owner and an end date.

Step by step: check signatures, chains and provenance

These commands are safe to run and change nothing. Replace file names with your own.

Windows: verify an Authenticode signature and its timestamp

:: Verify with the default authentication policy, verbose, all signatures,
:: and warn if any signature is not timestamped
signtool verify /pa /v /all /tw "C:\Installers\ExampleSetup.exe"

# Show signer, issuer and timestamp for one file
$sig = Get-AuthenticodeSignature "C:\Installers\ExampleSetup.exe"
$sig.Status
$sig.SignerCertificate | Format-List Subject, Issuer, NotBefore, NotAfter, Thumbprint
$sig.TimeStamperCertificate | Format-List Subject, Issuer

Windows: find any signed file whose chain includes a given intermediate

# Search a folder tree for signatures that chain through a named intermediate.
# Adjust the paths and the issuer substrings for the incident you are checking.
$targets = @('EM OV CS CA - G3B', 'EM OV CS CA - G3C')
$paths   = @('C:\Program Files', 'C:\Program Files (x86)', 'D:\SoftwareShare')

Get-ChildItem -Path $paths -Recurse -Include *.exe,*.dll,*.msi,*.sys,*.ps1 -ErrorAction SilentlyContinue |
ForEach-Object {
  $s = Get-AuthenticodeSignature $_.FullName
  if ($s.SignerCertificate) {
    $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
    $chain.ChainPolicy.RevocationMode = 'NoCheck'   # we want the chain, not a verdict
    [void]$chain.Build($s.SignerCertificate)
    $names = $chain.ChainElements | ForEach-Object { $_.Certificate.Subject }
    foreach ($t in $targets) {
      if ($names -match [regex]::Escape($t)) {
        [pscustomobject]@{
          File      = $_.FullName
          Signer    = $s.SignerCertificate.Subject
          Status    = $s.Status
          Timestamp = $s.TimeStamperCertificate.Subject
          Match     = $t
        }
      }
    }
  }
}

Name matching is a quick first pass. For a firm answer, compare each chain element's public key hash against the SPKI hashes published for the incident, because cross-signed copies share a key but not a name.

Windows: confirm the machine has current distrust data

certutil -verifyctl Disallowed | findstr /i "lastsynctime"
certutil -verifyctl AuthRoot   | findstr /i "lastsynctime"

If the last sync is old, the machine has not heard about recent distrust decisions. For disconnected networks, Microsoft documents syncing with certutil -syncWithWU \\server\share and pointing clients at that share by Group Policy.

Read the revocation date from a CRL

# Download the CRL named in the certificate's CRL Distribution Point, then:
openssl crl -in issuing-ca.crl -inform DER -noout -text | less
# Look for the serial number of the revoked intermediate, its Revocation Date,
# and the CRL entry reason (for example CA Compromise)

macOS: inspect signer authority and Gatekeeper's verdict

codesign -dv --verbose=4 /Applications/Example.app 2>&1 | grep -E "Authority|Timestamp|TeamIdentifier"
spctl --assess --type execute -vv /Applications/Example.app
xcrun stapler validate /Applications/Example.app

The Authority lines show the chain. For Developer ID software you should see Apple's Developer ID chain, not a commercial CA.

Sigstore: verify a blob against an expected identity

cosign verify-blob \
  --bundle release.tar.gz.sigstore.json \
  --certificate-identity "https://github.com/example-org/example-repo/.github/workflows/release.yml@refs/tags/v1.4.0" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  release.tar.gz

Pinning the identity and issuer is the whole point. A Sigstore signature from an unexpected identity is as meaningless as a signature from an unknown publisher.

GitHub Actions: produce and verify build provenance

name: release
on:
  push:
    tags: ['v*']
permissions:
  id-token: write
  contents: read
  attestations: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make dist
      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-path: 'dist/example-cli'

gh attestation verify dist/example-cli -R example-org/example-repo

Scan what you build and ship for components and known vulnerabilities

safeguard scan --dir .
safeguard scan --image registry.example.com/example-app:1.4.0
safeguard scan --sbom vendor-sbom.cdx.json

Results land as JSON under ./output. This tells you what is inside a build and which known vulnerabilities it carries. It does not judge whether a binary is malicious.

Where Safeguard fits

Safeguard does not operate a CA, run key ceremonies, decide which roots your operating systems trust, or judge whether a signed binary is malicious. Those stay with the platform vendors, your CA and your endpoint tools.

Where it helps is the evidence beyond the signature. Safeguard's attestation and signing support covers SLSA provenance, Sigstore (Fulcio and Rekor, keyless), in-toto and X.509 signatures, and it records component provenance and attestations alongside the SBOMs it builds from repositories, container images and SBOM files. Policies and gates evaluated in the platform can require provenance or an attestation, not only a signature, before a build moves forward, with actions to block, warn, notify or require approval. For software you buy, the Third-Party Risk Manager lets you onboard vendors, request SBOMs and record what each vendor has told you, so the question "which of our suppliers sign under that chain" has somewhere to be answered and tracked. When an incident like this lands, the platform shows which projects contain a given component and version, which shortens the "are we affected" step for the code you build.

Common mistakes

• Treating "signed" as "safe". A signature is identity and integrity, not a safety verdict.
• Allowlisting by issuer. "Trust anything from this CA" is exactly the rule a leaked CA key exploits.
• Skipping timestamps. Untimestamped signatures die with the certificate and blur the line between old and new signatures during an incident.
• Assuming the browser fix covers everything. Chrome's CRLSet and Mozilla's OneCRL protect browsers. Code signing trust on Windows, Java tools and internal allowlists are separate verifiers with separate update paths.
• Ignoring disconnected machines. Air gapped and tightly firewalled systems do not get Microsoft's daily disallowed list unless someone syncs it.
• Matching on names only. Cross-signed intermediates share a key but differ in name and serial. Match on the public key.
• Trusting the download page. A genuine signed installer served from a fake page is still a phishing attack.

Fix it without waiting for upstream

A CA key leak is a trust problem, not a code bug, but the response looks the same: find what you ship, prove where it came from and replace what you cannot vouch for. The same discipline applies to the open source components inside your signed releases.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

Is software signed with a revoked certificate safe to run?

Not automatically. A signature timestamped before the CA's revocation date can still verify on Windows. One signed after that date, or never timestamped, is untrusted until vendor hashes or provenance prove where it came from.

Does revoking a code signing certificate break software that is already installed?

Timestamped signatures from before the revocation date keep verifying. Later and untimestamped signatures fail once the verifier learns of the revocation. Whether installed software is re-checked at launch depends on the platform and file type.

Can a hacker sign malware with a stolen certificate?

Yes. With a stolen subscriber key they can sign as that publisher. With a stolen intermediate CA key they can issue new certificates in any name. Revocation, distrust lists, reputation services and provenance checks are what stop those signatures from being trusted.

Why did Chrome block six eMudhra certificates and not eight?

According to The Hacker News, Chrome's TLS verifier will not build a path through an intermediate restricted to code signing, so the two code signing intermediates could not affect HTTPS in Chrome. Chrome blocked the six TLS intermediates by public key, which also covered their cross-signed copies.

Does a leaked CA key affect macOS apps?

Not through Gatekeeper on a default install. Gatekeeper requires an Apple Developer ID signature plus notarization for software from outside the App Store, so a commercial CA's code signing certificate does not satisfy it. Other tools on a Mac that rely on CA chains should be checked separately.

How do I check who signed a Windows file?

Run signtool verify /pa /v /all /tw file.exe from the Windows SDK, or in PowerShell use Get-AuthenticodeSignature file.exe and inspect SignerCertificate and TimeStamperCertificate. Build the full chain to see every intermediate, not just the leaf.

Is Sigstore safer than traditional code signing?

It removes the long lived signing key, the asset that leaks in incidents like this, and logs every signature publicly. Trust shifts to the signer's identity account and Sigstore's root. Many teams use both: Authenticode for Windows, Sigstore plus provenance for the pipeline.

What should a software vendor tell customers after a signing key compromise?

Affected versions, the old and new chains, how to verify new builds (hashes and provenance), whether installed copies need action, and who to contact. Ship re-signed builds as a new version.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, run safeguard, ask it to fix the lodash CVE in a repo, and watch it read the finding, ask before each command, move package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing, then show /permissions, /model and /scan .. The same approval driven flow fits the provenance work in this post, with a human approving each change to your build.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. During an incident like a CA key leak, this is how a team can ask questions about components and projects in plain language, while keeping control of which tools the assistant can call.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. Running scans locally suits release engineers who want to check a build and its SBOM before signing it, without sending the build anywhere first.

Click through it at your own pace, or open it full screen.

To try it on your own builds, download Safeguard and follow the CLI documentation.

Quick check

Sources

• The eMudhra CA key compromise explained (Safeguard)
• eMudhra exits the TLS certificate business: what customers do now (Safeguard)
• Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates (Google)
• Eight eMudhra CA keys compromised (The Hacker News)
• Mozilla, Google, Apple block compromised eMudhra CA certificates (BleepingComputer)
• eMudhra private keys compromised (The Register)
• Weekly recap (The Hacker News)
• Time stamping Authenticode signatures (Microsoft Learn)
• SignTool (Microsoft Learn)
• Configure trusted roots and disallowed certificates in Windows (Microsoft Learn)
• Microsoft Defender SmartScreen overview (Microsoft Learn)
• Microsoft Trusted Root Program requirements (Microsoft Learn)
• Code Signing Baseline Requirements (CA/Browser Forum)
• Gatekeeper and runtime protection in macOS (Apple Platform Security)
• Developer ID (Apple Developer)
• Sigstore overview (Sigstore)
• Fulcio certificate authority overview (Sigstore)
• SLSA provenance v1.0 (SLSA)
• Using artifact attestations to establish provenance for builds (GitHub Docs)
• Definition of reproducible builds (Reproducible Builds)

Last reviewed: 23 October 2026. Root program decisions on eMudhra are still moving; check the linked advisories for the latest status.