A Valid Software Signature Is Only One Page in the Release Evidence

TL;DR: A compromised code-signing authority and a stolen publisher signing key are different incidents. Software teams should inventory their signer identities, verify artifacts under the policy their users actually apply, and connect signatures to independently maintained release records. A timestamp, familiar publisher label or valid signature is useful evidence with a defined scope; none alone proves that a binary is the release your organization intended to distribute.

The eMudhra incident extends beyond the browser's certificate dialog. The published affected-intermediate inventory includes code-signing authorities named EM OV CS CA - G3B and EM OV CS CA - G3C, alongside their cross-signed representations. This article uses that narrow fact to examine a software publisher's evidence requirements. It does not claim that malicious software was distributed through those authorities or that any particular publisher key was stolen.

The release dossier below belongs to fictional desktop-software company Vale Instruments. Its files, signing history and customer cases are invented. The exercise is dated October 22, 2026, and distinguishes three questions: who could issue a signing credential, which key signed a particular artifact, and whether that artifact belongs to an authorized release. Treating those as one question can produce a confident answer to the wrong problem.

Folder one: identify the credential, then identify the authority

Vale's first inventory is a list of publisher names displayed by its operating-system signature viewer. Several releases show the same company name, so the release manager assumes they share the same security status. The investigator asks for the exact signing certificate, its public key and the path used during verification. A display name is not a unique cryptographic identity.

The dossier records each supported release's artifact digest, signing-certificate fingerprint, public-key identity, relevant chain and timestamp information. It also records the platform and policy used to obtain the verification result. The goal is to connect a specific file to a specific signer under a specific decision process, rather than collect screenshots that happen to show a familiar name.

Microsoft's Authenticode overview describes publisher authentication and code integrity through digital signatures and certificate chains. Vale uses those concepts to define its inventory. It does not interpret a successful signature check as a statement that the program has no vulnerabilities, performs only desirable actions or was approved by Vale's current release manager.

The team then separates authority exposure from subscriber-key exposure. A compromised issuing authority can create a false credential for an accepting verifier. That does not itself demonstrate possession of Vale's existing private signing key. If investigators later find evidence that Vale's key or signing service was compromised, that becomes an additional incident with its own scope and containment work.

This distinction matters for the response. Replacing Vale's own key cannot, by itself, remove a compromised authority from every customer's trust policy. Updating a customer's trust policy cannot, by itself, establish that Vale's signing infrastructure was never misused. The dossier needs evidence at both boundaries if both questions are relevant.

The inventory also preserves multiple representations of the same authority. Cross-signed certificates can create different paths involving the same underlying key. Vale records certificate and public-key identities separately so it can reason about path changes without accidentally counting each representation as a different secret or overlooking another route to the same key.

Folder two: preserve the file before drawing conclusions

A customer sends Vale a suspicious installer. The support agent wants to run it to see whether it opens the expected application. The security team instead preserves the file and its acquisition context under the organization's handling procedure. Executing an unknown installer is not necessary to establish its digest, inspect its signature or compare it with an authorized release record.

The dossier records where the file came from, when it was obtained and whether any intermediary could have changed it. A filename such as the current product version provides little assurance. A download URL can be useful context, but it is not a substitute for identifying the exact bytes received. Mirrors, caches and repackaging can produce different files under similar names.

Vale compares the artifact's digest with a release manifest maintained through a separate controlled process. A matching digest establishes that the bytes match that recorded artifact, assuming the digest mechanism and manifest trust are appropriate. It does not independently establish that the recorded artifact was safe or correctly built. The manifest itself needs provenance and access controls.

If the file differs, the next question is why. A legitimate localized installer, an enterprise wrapper or a newly applied signature can change the whole-file digest. The investigation should distinguish an authorized variant from an unexplained modification. Vale maintains explicit variant records so support does not have to guess whether every mismatch is malicious.

The team avoids comparing only the executable code while ignoring the package that delivers it. Installers can contain scripts, configuration and additional payloads. The relevant artifact boundary depends on what the distribution mechanism authenticates and what the installer will execute. The dossier names that boundary instead of assuming one visible file covers everything the user receives.

This folder produces a stable reference for later analysis. Investigators can revisit the same bytes after a trust-policy update without confusing a changed file with a changed verification result. Preserving both is essential: an artifact can remain identical while the system's decision about its signer changes.

Folder three: choose the verification policy deliberately

Vale supports an ordinary desktop application and a separate driver package. The team cannot assume that a generic signature-verification command applies the same policy to both. SignTool's documentation distinguishes verification modes and policy options, including the default authentication policy and driver verification. A test should use the policy relevant to the artifact and its installation path.

The dossier therefore identifies the verifier version, operating-system state, policy selection and any relevant online or offline conditions. It records the complete result, including warnings and which signature was evaluated. A file can contain more than one signature, and a brief success message may not describe every signature or every intended installation scenario.

An updated machine and a disconnected machine may produce different outcomes because they have different trust information available. Vale treats that difference as an investigation input. It does not call the disconnected result authoritative merely because it is reproducible, and it does not claim the online result automatically covers every customer's offline installation process.

The team uses controlled test machines appropriate to its supported population. It avoids weakening trust settings on a production workstation to reproduce acceptance of a suspect artifact. Where historical behavior matters, investigators preserve a documented test environment and isolate it from ordinary work. The purpose is to understand a policy decision without introducing the artifact into a trusted operational context.

A rejection needs interpretation too. It can reflect an untrusted path, a signature mismatch, an unsupported algorithm, unavailable status information or another policy condition. Vale records the reason and relevant evidence rather than labelling every failure “malware.” The same precision prevents an availability issue caused by legitimate distrust from being misreported as proof that the customer's copy was modified.

The acceptance result is bounded: this artifact passed or failed this verification process under these conditions. That statement is strong enough to support a release decision when combined with the rest of the dossier. Inflating it into a universal claim about all platforms would make the evidence less reliable, not more reassuring.

Folder four: the timestamp answers a time question

Vale's release manager points to a timestamp and says that an old signature must remain acceptable forever. The reviewer separates the useful property from the overstatement. Microsoft's timestamp documentation explains how timestamping can support verification after the signing certificate expires. It is not a universal exemption from every later distrust decision or platform policy.

The timestamp involves its own evidence and trust relationship. Vale records the timestamped signature, the timestamp authority's information and the relevant verification result. It does not treat a date shown in the file's ordinary metadata as equivalent to a cryptographically authenticated timestamp. A filesystem creation date can change during copying and does not establish when a publisher signed the artifact.

The team also distinguishes certificate expiry from compromise and policy distrust. These events can have different implications, and the verifier's rules determine how they are handled. Vale follows the current platform guidance for the specific case rather than inventing a simple rule that every signature before a date is automatically safe or every old signature is automatically invalid.

For a hypothetical release signed before the incident became public, the dossier asks whether the signing credential and timestamp were valid under the relevant conditions, whether the artifact matches Vale's authorized record and whether the current client policy accepts it. The publication date of a news story is not itself a trusted signing boundary. A key can have been weak before the issue was discovered.

Re-signing also needs care. Applying a new signature to an old binary changes the distributed artifact and may alter how clients identify it. Vale preserves the original, records the reason for the new release and produces a new manifest entry. It does not quietly overwrite historical evidence and then describe the new file as byte-for-byte identical to what customers previously downloaded.

The timestamp folder therefore supports a precise historical assessment while leaving current acceptance to the correct policy. Its value comes from connecting time evidence to an identified signature, not from turning an old date into permanent immunity from trust changes.

Folder five: establish that Vale intended this release

A mathematically valid signature can exist on software that the organization did not intend to ship. A signing service might be misconfigured, a build pipeline might be compromised or an authorized operator might sign the wrong artifact. Those possibilities are separate from the eMudhra incident and require their own evidence; they illustrate why signer identity does not exhaust release authorization.

Vale connects each accepted artifact to a release approval, source revision and build record. SLSA's provenance model describes verifiable information about where and how artifacts were produced. The company uses that concept to structure its evidence, while recognizing that a provenance statement is useful only when its producer and verification policy are trusted for the claim being made.

The release approval names the artifact digest and intended distribution channel. A general approval to publish version seven is weaker than an approval tied to the exact output that will be served. The connection prevents a later file substitution from inheriting an earlier human decision merely because it retains the same version label.

The build record also identifies relevant inputs and configuration. A source revision alone may not determine the output if dependencies, build tools or external assets vary. Vale does not claim reproducibility unless it has actually established the required conditions. It records enough provenance to investigate which process produced the file and why it differs from another candidate.

A signing operation is then reconciled with that approved artifact. The team asks whether the service signed the intended input, which credential it selected and how the result entered distribution. Logs should identify operations without exposing private keys or unnecessary secrets. The review should be able to detect an unexpected signing request rather than merely count successful requests.

The dossier remains useful even when no compromise is found. It lets Vale answer a customer's concrete question: is this installer one of the releases we authorized, and which evidence supports that answer? That is a stronger service than asking the customer to rely on a publisher name alone.

Folder six: the update channel needs its own authority model

Vale's updater downloads a manifest and then a package. HTTPS authenticates the delivery connection under the client's TLS policy, while package signatures and update metadata can establish additional properties. The team maps those mechanisms separately. It does not assume that a browser's trust update automatically changes every decision inside its installed updater.

The Update Framework specification, version 1.0.37 at the time of review, describes roles, signed metadata and protections against several update attacks. Its model is relevant because update authorization can be rooted in application-managed trust rather than relying solely on the public TLS certificate hierarchy. Adopting such a design still requires correct integration and lifecycle management; citing the framework does not confer its properties on an unrelated updater.

Vale examines what its existing updater accepts. Does it bind the package digest to authenticated metadata? Does it enforce the intended product and channel? Can it detect an attempt to serve an older authorized release when policy requires a newer one? A genuine old binary can still be the wrong update. Authenticity and freshness answer different questions.

The company also considers metadata expiry and disconnected customers. A client should have an explicit response when it cannot establish a current update decision. Silently treating stale information as fresh can undermine the update policy, while an unexplained hard failure can leave users stranded. The appropriate behavior needs to be designed, tested and communicated for the product's environment.

Key rotation for the updater is a separate lifecycle from replacement of the public HTTPS certificate. Vale identifies the trust anchor already installed in clients, the authorized transition mechanism and recovery options. It does not bootstrap a new trusted update key merely by downloading it over a connection whose identity is the subject of the incident.

The resulting map shows which controls remain effective under which failures. That is the practical value of layered evidence. If one authority is distrusted, the team can understand what else authenticates the package and where a repair is required, rather than either disabling all checks or assuming another layer automatically compensates.

Folder seven: customer remediation without unsafe shortcuts

Vale prepares a replacement release only after the artifact, signer and distribution evidence are ready. The release notes identify what changed: a signing credential, a packaging step, an updater policy or application code. These are different changes with different compatibility implications. Customers should not have to infer the scope from a new file date.

The support plan avoids instructing users to disable operating-system trust checks broadly. A legitimate installer rejected after a trust change needs an approved replacement or a supported enterprise deployment procedure. Making a warning disappear is not the same as establishing the identity and authorization of the software being installed.

Enterprise customers may have additional application-control policies. A change in signer or artifact digest can require their administrators to update an allow rule through their normal process. Vale provides precise public identifiers and authenticated release information. It does not ask customers to whitelist every file bearing a similar publisher string or to accept an entire directory indiscriminately.

For offline environments, the company supplies a documented package and verification route appropriate to the customer's requirements. That route must establish how the customer authenticates the manifest and obtains relevant trust information. Merely moving the file onto removable media does not solve the trust problem. The transport method and the authorization evidence remain separate.

The support team also preserves reports of unexplained files. A customer whose installer does not match an authorized artifact deserves investigation, even if a current trust update causes the signature to fail. The failure can prevent execution while the file remains useful evidence about attempted distribution or an unauthorized variant.

Vale measures remediation by the supported installation and update paths it has repaired. Download counts alone do not establish that affected clients installed the replacement, and a published release does not guarantee that every enterprise distribution mirror refreshed it. The company records those remaining distribution responsibilities explicitly.

An evidence table for the release decision

The final dossier uses a compact decision table. Each row has a distinct owner and can fail independently.

The table is not a scoring system where four green rows compensate for one unresolved authority question. A release needs the evidence required by its own design. Some failures concern availability and others concern authenticity, but both can block the promised customer outcome.

Vale's incident statement consequently distinguishes what was found from what was done preventively. It can report a trust-policy update, a replacement signer or a repaired distribution path without claiming that its own private key was stolen. If misuse is confirmed, the statement can name the affected artifacts and evidence. Precision supports both urgent response and fair communication.

A mirror can serve yesterday's decision after today's repair

Vale discovers that its main download endpoint serves the replacement installer while a regional mirror still serves the earlier artifact. Both files have familiar names, and both were authorized at different times. The incident coordinator records the mirror's actual digest and cache state rather than accepting the main site's result as proof of complete distribution.

The repair includes the metadata that points clients to the file. Updating a package without updating an authenticated digest can cause correct clients to reject it. Updating a manifest while a cache still returns old bytes can produce the same symptom. The team tests the package and its associated metadata as a coherent release through each supported distribution route.

This case does not require a malicious actor to create a real customer problem. It shows why publication and distribution are separate stages in the dossier. Vale closes the mirror entry only after observing the intended artifact and metadata together, and it retains the previous identifiers so support can recognize reports from clients that have not yet received the replacement.

Keep the dossier after the emergency ends

The most useful result is a maintained relationship between release approval, artifact identity, signer identity and client acceptance. Vale attaches that relationship to ordinary releases so it does not have to rebuild the evidence during the next certificate incident. Old artifacts remain traceable even when their present-day trust status changes.

The company also rehearses a signer transition with test material and a supported client cohort. The exercise asks whether a replacement can reach users without relying on the authority being retired. It records failure behavior and support instructions before a real emergency compresses the schedule.

A code-signing certificate is a meaningful part of software trust. Its value is strongest when the team knows exactly what claim it supports and connects that claim to the rest of the release evidence. The eMudhra event is a reason to inspect those connections carefully, while keeping authority compromise, subscriber-key compromise and unauthorized software distribution as separate findings until evidence joins them.

Sources

• eMudhra Incident: Affected Intermediate Inventory
• Microsoft: Authenticode Digital Signatures
• Microsoft: SignTool
• Microsoft: Timestamping Authenticode Signatures
• SLSA 1.2: Provenance
• The Update Framework: Specification