After a Signing Key Is Stolen: Why Revocation and Software Recovery Are Different Problems

1. The announcement is not the repair

Imagine a software publisher discovering that someone obtained an update-signing key. The publisher stops using it, issues a warning, and releases replacement trust information. Its incident page says the key has been revoked. Yet some client machines have been offline for weeks, some have downloaded but not installed the repair, and some may already be running software distributed during the compromise.

This is a fictional incident, not a report of a breach at a named organization. It exposes a gap that the word “revoked” can conceal: a decision made by the publisher is not automatically a change in every client's trust state, and a changed trust state is not automatically a repaired installation.

The Update Framework, or TUF, addresses secure delivery and verification of software updates. Its actual latest specification, checked on October 29, 2026, identifies itself as version 1.0.37, modified October 8, 2026. Version matters: a specification index can lag behind the document reached through its latest link. TUF specification, version 1.0.37 as checked.

That framework is one useful reference point, not a universal updater or a promise that software is safe merely because metadata verifies. Other documents examined here include IETF firmware-update architecture and manifest guidance, Uptane's vehicle-update standards, NIST's code-signing and firmware-resilience guidance, and SLSA's description of build provenance. Their scopes differ. Combining ideas from them does not certify an invented system as conformant with any of them.

To make the distinctions concrete, this article follows a fictional publisher of noticeboard software. Its application, called Noticeboard Example, displays nonsensitive announcements on managed computers. The name, fleet, keys, releases, incident records, and test expectations are all invented. No real key is exposed, no actual repository is modified, and no live client is tested.

The exercise follows several separate questions. Has the publisher stopped unauthorized signing? What authority lets a client accept replacement keys? Has the client actually received and verified the new trust information? Does it have the intended software bytes? Has installation completed? Is the device operating in an acceptable state afterward? A single green incident-status field cannot answer all of them.

The distinction matters to anyone reading a vendor response, evaluating an update system, or trying to understand why a large recovery takes longer than issuing a new certificate. Revocation can be essential. It is not a remote eraser for old trust decisions, previously installed software, or damage already done.

2. Revocation changes authorization; it does not undo mathematics

NIST's code-signing white paper identifies private-key theft as a threat because the stolen key can be used to sign unauthorized code. It also distinguishes signing, verification, certification, and trust-anchor management, and recommends that verifiers support revocation checking or a secure way to update trust anchors. Those are components of a system, not synonyms for one centralized action. NIST, Security Considerations for Code Signing.

In the Noticeboard Example scenario, call the compromised signing key K-old. A signature created with that key does not become mathematically malformed because the publisher posts a notice. The security decision changes because the verifier should no longer accept K-old under the relevant policy, or should apply the applicable rules about when and how a signature was made. The exact treatment depends on the ecosystem; this article does not assert one universal certificate-revocation rule for every operating system.

Now separate three fictional records. Record A says the incident team disabled access to its signing service. Record B says replacement trust metadata no longer authorizes K-old. Record C says a particular client validated and adopted that metadata. A is evidence about the publisher's service. B is evidence about the intended new policy. C is evidence about that client's state. One record cannot stand in for the others.

Disabling the signing service may prevent further authorized use of a key stored only there. If the private key was copied, however, disabling that service does not reach the copy. That is why the response must consider what clients will accept, not only whether the publisher's own signing button has been turned off. The fictional scenario explicitly assumes key extraction; a different incident involving only unauthorized requests to a protected signing service would need a different investigation.

There is another important distinction between a certificate and a directly trusted public key. Some systems use certificate chains; others rely on an application-specific trusted-key arrangement. The response must follow the actual mechanism rather than ask for a certificate revocation that the client does not use. NIST's architecture discussion recognizes both certificate-based and other trusted-key arrangements. NIST's code-signing architecture.

For the fictional publisher, a precise first statement would therefore identify what was disabled, what trust information changed, and which clients have confirmed the change. It would not claim that all previously downloaded files disappeared or that every disconnected client immediately learned the new policy. Those are separate observations requiring separate evidence.

3. Ask which signing authority was compromised

TUF separates responsibilities into root, targets, snapshot, and timestamp roles. Root metadata identifies trusted keys and thresholds. Targets metadata identifies downloadable files and can delegate authority; snapshot and timestamp metadata help describe a consistent and sufficiently fresh repository view. The separation limits the meaning of any one role's signature. TUF, Roles and metadata.

For Noticeboard Example, imagine a deliberately simplified arrangement. An offline root role uses three distinct keys and requires two valid signatures. A separate release role authorizes application packages. Another role describes the release-metadata set, while a frequently renewed record helps clients determine whether they have current information. This is an instructional sketch, not a complete TUF configuration or a recommendation to copy these parameters into production.

The incident begins with the release-signing key being stolen. It does not begin with all root keys being stolen. That difference matters because the remaining trusted authority may be able to authorize replacement release keys. If the entire authority that defines trusted keys is also compromised, the recovery problem is materially different. The article's later examples state which assumption applies rather than slide between them.

A useful incident inventory would identify the key's role, authorized scope, storage and use environment, and the evidence about what an attacker could do with it. A statement that “a key was compromised” is not enough to tell whether the attacker could authorize one package family, change repository metadata, or replace the root of trust itself.

The distinction is similar to separating a permission from the person holding it. A key should not be treated as universally authoritative merely because it produces a valid signature. Its authority is established by the system's trust configuration. Conversely, moving a key to a new storage device does not automatically reduce the authority that clients assign to it.

Consider two fictional release channels, stable and experimental. If the intended delegation allows a key to authorize only experimental packages, a stable-channel package carrying that key's signature should not be accepted merely because the signature verifies. The test must check the authorized scope as well as the cryptographic result. This example illustrates a permission boundary; it does not claim that every updater implements delegation in the same way.

Operational independence also matters. Three key labels do not necessarily represent three independent barriers if one compromised environment can use all three. The fictional two-of-three root arrangement assumes distinct keys and appropriately separated control. The threshold calculation alone cannot establish that those operational assumptions are true. An incident review must examine the actual custody and access paths rather than infer independence from a diagram.

4. Work through an incident record instead of saying “rotation complete”

TUF clients advance through root versions one step at a time. Each successor needs enough verified, distinct-key signatures under both the existing and replacement root policies; duplicated signatures do not supply additional votes. The workflow can traverse expired starting or intermediate roots, but the root reached at the end must pass the expiration comparison against the fixed update-start time. These are specification requirements, not test results for Noticeboard Example. TUF's root-update requirements.

Now put the protocol aside and examine a fictional incident packet. At 10:00, the incident coordinator opens case N-42. At 10:12, a release operator prepares replacement metadata identified as R-13. At 10:27, a publishing job records success. At 10:31, the status page announces that the trust update is available. At 10:35, the fleet dashboard shows a green field labeled “rotation complete.” None of these timestamps is an actual experimental observation; the packet is a designed example of how administrative records can get ahead of evidence.

The first reconciliation question is what the publishing job actually did. Its record identifies an upload destination, object identifier, byte count, and completion time. That can support a statement about an upload. It contains no client identifier, retrieval result, verification result, or persistent-state observation. The green dashboard field was copied from the publishing job rather than computed from client confirmations. Its label is broader than its evidence.

A second record concerns Client Cedar. It shows a retrieval attempt beginning at 10:40, an object identifier matching R-13, a verification outcome reported by the configured verifier, and a local-state observation at 10:42. For this invented exercise, assume the verifier is an independently tested implementation and the observation channel is suitable for the task. The article does not reproduce its algorithm or claim to have run it. The record's useful contribution is its connection between one identified object, one identified client, and one observed transition.

A third record looks similar but contains no client identifier. It might be a duplicate of Cedar's event, a test-machine event, or evidence from a second client. Until that ambiguity is resolved, it cannot legitimately increase the number of confirmed clients. Assigning it to whichever missing device makes the chart look complete would invent evidence. The uncertainty is about attribution, even if the event itself is authentic.

A fourth record names Birch but includes an observation time from the previous day. Its arrival after the incident does not make it a fresh observation. A fifth names Alder and records a failed retrieval. That is useful diagnostic evidence, not a successful transition. The coordinator can now report one confirmed client, one failed attempt, one old observation, and one unattributed event, rather than four apparent confirmations.

Object identity also needs reconciliation. Suppose the publishing record names R-13 but the verification event names R-13-test. These are deliberately invented labels, not cryptographic hashes. The mismatch might be harmless shorthand, a staging-versus-production confusion, or a genuinely different object. The packet needs the actual identifiers used by the system and a documented explanation. It should not silently normalize different strings into a single supposed artifact.

The same discipline applies when two records disagree about completion. A verifier might record success immediately before the process crashes; a later observation might show that the expected state was not retained. The useful result is not “one success and one failure, average them.” It is a sequence requiring investigation. The team must establish what state the client will use on its next relevant action.

This evidence exercise does not decide which cryptographic protocol a publisher should deploy. It explains why generating a key, publishing metadata, observing verification, and confirming a client's retained state are different claims. A concise public update can preserve those distinctions: replacement metadata published; one client confirmed in the sample packet; several records unresolved. That wording is less dramatic than “complete,” but it can be defended from the actual evidence described.

5. An offline client has its own history

Suppose the fictional publisher distributes the replacement trust metadata at noon. Client Cedar is online and adopts it at 12:10. Client Birch is offline in storage. Client Alder is connected but cannot reach the metadata endpoint. The publisher has performed one distribution action, but the three clients now have different observable states.

Cedar can be checked for the newly trusted metadata version and the intended rejection of K-old. Birch has not received anything simply because a server changed. Alder's network connection does not prove that its update check succeeded. Treating “online” as equivalent to “updated trust” would erase the distinction that matters in the incident.

A compact fictional record makes the gap visible:

The table says nothing yet about installed software. Cedar might have current trust metadata but still need to install a package. Birch might be running an older unaffected release. Alder might have downloaded a package before the incident. Those facts require additional fields. Combining them prematurely into “protected” or “compromised” would claim more than the record shows.

For a returning device, the record should preserve its last confirmed state rather than fill the gap with an assumption. In the fictional exercise, Birch's storage inventory says that it was placed on a shelf in August. Its application log ends in July. Neither record establishes the software or trust state it will actually use in October. A controlled inspection may resolve the gap; a calendar-based guess does not.

The packet should also distinguish clock observations from clock assumptions. Suppose Birch's local event says 08:00 while the coordinator's receipt log says 08:17. The difference could reflect a clock offset, delayed delivery, or different events. Without a clock relationship or other sequencing evidence, subtracting the two timestamps does not measure a seventeen-minute update. The original records should remain intact while the team determines what they represent.

This is not a reason to ignore time checks or move a device's clock to suppress an error. It is a reason to preserve the time source, event meaning, and uncertainty in the report. A returning-client exercise is valuable when it exposes such missing evidence, even if it prevents an attractive completion percentage from being announced immediately.

6. An authorized return to older software is not the same as a replayed authorization

The word “rollback” can refer to two different actions. An attacker may replay old authorization information to push a client toward an obsolete state. An authorized operator may deliberately restore an earlier software release because a newer one is defective. A secure update system needs to distinguish the authority and metadata sequence from the human-readable software version.

RFC 9124, the IETF's informational firmware-manifest model, makes that distinction explicit. Its monotonically increasing sequence number belongs to the manifest, not to the firmware version. A newer authorized manifest can specify an older firmware version. The document separately addresses compatibility and expiration considerations. RFC 9124, A Manifest Information Model for Firmware Updates.

Use a fictional sequence to see the difference. Noticeboard Example's client has accepted manifest sequence 101, which authorizes software release 4.2. An authorized recovery team decides that release 4.1 is the appropriate temporary restoration target in this scenario. It issues new manifest sequence 102 describing that release under the required authority and checks. The software version decreases, but the authorization sequence moves forward.

Now compare an old copy of manifest sequence 99 that also points to release 4.1. The payload version is the same, but the authority record is not. A client that has already accepted sequence 101 should not treat replayed sequence 99 as equivalent to the newly authorized 102. Looking only at the string “4.1” would miss the security distinction.

The example assumes that the recovery team has actually evaluated whether release 4.1 is acceptable. A newer manifest does not make a vulnerable old release safe. It records a current authorized decision; it does not replace the engineering analysis behind that decision. If the older release contains the vulnerability that caused the incident, restoring it could recreate the problem.

There is also a compatibility question. Suppose release 4.1 expects a data format that release 4.2 has already changed. An authentic and current authorization does not automatically reverse that migration. The recovery plan must account for the application's state, configuration, and data, not just the executable version. This is a fictional compatibility hazard, not a claim about a particular product.

The practical test therefore records at least two different identifiers: the authorization sequence and the selected software artifact. It also records why that artifact was chosen and whether the restoration preserves the required behavior. Calling both identifiers “the version” invites a reader to confuse a deliberate, newly authorized restoration with an attacker-controlled replay.

7. Detecting a freeze does not deliver the missing update

TUF's security guidance distinguishes rollback, freeze, and mix-and-match attacks. It also states an important limit: a client may be able to recognize that current updates are unavailable without being able to obtain them through an obstructed channel. Detection and availability are different properties. TUF, Security.

Consider a fictional freshness check. A client is evaluating a newly encountered metadata record that expires at 12:00 UTC on October 3. Its trusted update-start time is 12:00 UTC on October 4. Assume the record's signatures, role, version relationship, and other relevant checks are otherwise acceptable. Its expiration is still a day in the past. A valid signature does not make that time comparison disappear.

The expected result of this isolated test is refusal to treat the expired candidate as fresh authorization. The test does not establish that the client can download a newer candidate. If the network path is blocked, the publisher is unavailable, or the server is presenting stale information, the client may remain unable to proceed. Correctly refusing an unacceptable update can preserve one security boundary while leaving an operational problem unresolved.

The fictional incident report should therefore distinguish “freshness validation blocked installation” from “the client received the repair.” The first is evidence that a check produced the intended result under the test assumptions. The second requires a later successful retrieval and validation. Reporting the first as the second would inflate the recovery count.

Time itself is an assumption that needs attention. If the client's clock is wrong or its time source is not trustworthy, an expiration comparison may not represent real elapsed time. The example deliberately assumes a trusted time value; it does not prove that every device has one. Changing the clock to make a failed check pass would not establish freshness and is not an appropriate repair for the trust problem described here.

There is also a difference between refusing new authorization and deciding what an already installed application should do. A noticeboard might continue displaying a previously approved local message while its updater reports a problem. Another system might need a different response. The update framework does not, by itself, determine every application's safe degraded mode. That behavior belongs in the product's design and risk analysis.

A useful recovery exercise includes both conditions: a stale candidate that must not be accepted and a legitimate current candidate that should be obtainable through the intended recovery path. The first demonstrates rejection. The second demonstrates restoration of useful service. Combining them into a single vague “update check passed” would lose the very distinction the exercise is meant to reveal.

8. Individually signed files can still form the wrong release

Imagine that Noticeboard Example ships two related components: a display application and a template renderer. Release Set One pairs display version 4.1 with renderer version 7. Release Set Two pairs display version 4.2 with renderer version 8. Both sets were authorized at different times. The recovery team intends to install Set Two.

A distribution error presents the display from Set Two alongside the renderer from Set One. Each file might have a valid signature associated with an authorized historical release. That does not establish that the combination is the current approved set. A verification process that examines each file independently but ignores the relationship between them can miss the inconsistency.

TUF's metadata documentation explains the snapshot role's purpose in maintaining a consistent view of targets metadata, rather than allowing an attacker to combine metadata from different repository states. This is a repository-consistency property, not a general proof that every dependency combination is functionally correct. TUF's snapshot metadata explanation.

In the fictional test, the expected release record identifies two artifact digests, D-display-42 and D-renderer-8. These are explanatory labels, not real cryptographic digest strings. The received display matches the first expected artifact; the received renderer matches an older label, D-renderer-7. The correct conclusion is that the received set does not match the selected release record. It is not enough to say that two out of two files carry signatures.

The mismatch could arise from a malicious action or an ordinary distribution mistake. The record alone does not establish intent. It establishes a specific inconsistency that should prevent the system from declaring the selected release complete. Investigation can then determine why the wrong component was presented.

Now suppose both expected digests match, but the two components are still incompatible because the publisher tested them poorly. The metadata check may pass while the application fails. This is not a contradiction: consistent delivery and software quality are different properties. A recovery report should state which property it has evidence for rather than use “verified” as a substitute for every possible assurance.

The example also shows why filenames and version labels are insufficient identifiers. A file named latest-renderer can point to different bytes at different times. A visible version string can be reused accidentally or misleadingly. The recovery record needs the actual artifact identity under the system's chosen integrity mechanism, associated with the intended release decision.

That record is especially important when the response spans several distribution locations. The publisher can correct one origin while a mirror, cache, or disconnected deployment still has an older set. Correct metadata relationships help clients reject an incoherent view, but operators still need evidence about what each relevant distribution path and client actually received.

9. A replacement signature does not rebuild a trustworthy release pipeline

A stolen signing key is one possible compromise. A compromised build environment is another. In the fictional incident, the team initially knows that K-old was extracted. It does not yet know whether source code, build configuration, dependencies, or the artifact store were altered. Generating K-new answers only part of that uncertainty.

SLSA's version 1.2 provenance specification describes information about how an artifact was produced, including the build definition, builder identity, and resolved dependencies. Consumers use that information to compare a build with expectations. The meaning of the builder identity includes the entities trusted to run and record the build faithfully. SLSA v1.2, Build Provenance.

For Noticeboard Example, suppose the replacement release record identifies source revision R-17, build configuration C-6, builder B-clean, and artifact digest D-repair. Those names are fictional identifiers. The purpose is to describe the relationships that must be reconciled, not to manufacture a realistic-looking attestation or pretend that those objects exist in a public repository.

The team then finds a package signed by K-new whose recorded builder is B-old, the environment still under investigation. A new signature does not answer whether B-old was trustworthy when it produced the package. The team needs evidence about the build and the environment, not simply confirmation that the new signing key worked.

Conversely, a package built through the intended clean process could be rejected by clients that have not adopted the new trust metadata. In that case the problem may be distribution of authority rather than corruption of the package. The two failures can produce the same user-facing symptom—an update that does not install—but require different responses.

A useful reconciliation compares the selected source revision, build configuration, relevant dependencies, builder identity, output artifact, and release authorization. If the identifiers do not align, the record should explain the difference or remain unresolved. Matching text fields is not sufficient when the evidence itself comes entirely from an untrusted environment. The provenance must have a trust basis appropriate to the decision being made.

This also prevents a mistaken shortcut: re-signing an existing package without establishing whether it is the intended package. Re-signing may change the credential associated with the bytes while preserving every problem in those bytes. Whether re-signing is appropriate depends on the incident evidence and the ecosystem's requirements; it should not be treated as a universal substitute for rebuilding or investigating.

The public explanation can remain concise while retaining this distinction. “Replacement signing authority deployed” describes one result. “Replacement artifact rebuilt from the reviewed inputs through the designated environment” describes another. “Clients installed and validated the replacement” describes a third. A credible recovery account identifies the evidence for each instead of letting the newest signature carry the entire narrative.

10. Already installed software creates a separate recovery problem

NIST's platform-firmware resiliency guidance distinguishes protection, detection, and recovery. Its discussion of recovery also warns that simply restoring the vulnerable version can create a repeated attack-and-recovery cycle. The document concerns platform firmware; its broader lesson here is that preventing future unauthorized updates and recovering an affected installed state are different engineering tasks. NIST SP 800-193, Platform Firmware Resiliency Guidelines.

Return to Cedar, the fictional client that successfully adopted root version 13. Suppose Cedar installed a suspicious package before the trust change. The new root can change which future updates Cedar accepts. It does not establish that the suspicious package has stopped running, that altered configuration has been restored, or that exposed credentials remain safe. Those outcomes require incident-specific assessment and remediation.

The exercise deliberately avoids prescribing a universal cleanup sequence. A compromised desktop application, a damaged boot component, and a device with an altered hardware-backed trust arrangement are not the same case. The correct recovery method depends on what remains trustworthy, what evidence is needed, and what the product supports. A generic command to reinstall the latest version could be inadequate or destructive.

Uptane's deployment guidance illustrates why role matters. It distinguishes repository-key incidents from compromised electronic-control-unit keys. For compromised ECU keys, it recommends manual replacement procedures in its vehicle context because the manufacturer may be unable to know whether a remote replacement is reaching an intended ECU or an attacker-controlled party. That is specialized guidance, not an instruction for readers to modify a vehicle themselves. Uptane Deployment Best Practices 2.1.0.

The distinction applies to evidence as well as action. If a compromised component can generate the report claiming that it is healthy, the report's trustworthiness is part of the problem. A dashboard message alone may not establish recovery. The response needs an observation channel or verification method suitable to the suspected compromise, rather than assuming the affected component can certify itself.

For Noticeboard Example, define three separate fictional states. “Trust updated” means the client adopted the intended signing authority. “Replacement installed” means the designated package was installed according to the applicable process. “Operationally validated” means the specified post-recovery checks succeeded. A client may reach the first state without the second, or the second without the third.

Even the third state is bounded by the checks performed. Displaying the correct test announcement does not prove that every possible persistence mechanism, data alteration, or exposed secret has been addressed. The record should identify the assessment scope. If the investigation found only a narrowly contained signing incident, that scope may differ from a confirmed endpoint compromise.

The important claim is not that recovery must always involve the most drastic imaginable action. It is that the chosen action must match the established incident and remaining trust. Revocation is evidence about future acceptance policy. It is not retrospective evidence that an earlier installation was harmless or that its effects have been undone.

11. Downloaded, installed, and working are different fleet counts

IETF RFC 9019 separates update discovery, download, installation, and status tracking in its firmware-update architecture. Uptane's standard likewise distinguishes metadata and image verification, installation, and reporting. Both make it possible to describe progress more precisely than a single undifferentiated “updated” flag. RFC 9019, Firmware Update Architecture; Uptane Standard 2.1.0.

Suppose Noticeboard Example has 1,200 registered clients in a fictional recovery exercise. Nine hundred are reachable during the observation window. Of those, 840 validate the new trust metadata, 780 obtain and validate the intended replacement artifact, 750 complete installation, and 720 pass the defined functional checks. Assume these are nested stages for the same cohort, with no double counting and no clients skipping stages.

The figures support several different percentages. Trust refresh covers 70 percent of the registered fleet: 840 divided by 1,200. Functional validation covers 60 percent: 720 divided by 1,200. Among the 750 installations, 96 percent pass the specified functional checks. Reporting only that last percentage would omit the 450 registered clients that have not reached installation, including the 300 not reachable during the window.

The remaining clients also fall into different categories. Sixty reachable clients have not validated the new trust metadata. Another sixty have updated trust but not validated the replacement artifact. Thirty have the artifact but not a completed installation. Another thirty have installed it but not passed the functional checks. The 300 unreachable clients remain a separate uncertainty, not an automatic finding of either compromise or successful recovery.

These numbers are invented. They do not estimate the performance of TUF, Uptane, any vendor, or any actual fleet. They show how a denominator can change the apparent result. The incident report should preserve the observation window and the definitions of each stage so that later counts can be reconciled with earlier ones.

Report timestamps need the same care. Suppose a status record arrives at the dashboard at 14:00 but describes a successful check performed at 09:00, before an incident identified at 10:00. The arrival time does not turn the old observation into post-recovery evidence. In this fictional record, the dashboard must retain the observation time and the state it measured. Otherwise a delayed message can make an unchanged client appear freshly validated even though no new check occurred.

A power interruption provides a further test case. Suppose a client has validated the replacement artifact but loses power during installation. A download-complete event cannot establish which software will run after restart. The system's supported installation and recovery behavior must be tested under controlled conditions. The expected outcome depends on its design; this article does not assume every product uses the same atomic-update or fallback mechanism.

A useful record identifies the pre-interruption state, the point of interruption, the state found after restart, and whether the intended application behavior can be restored through the authorized process. It should not mark the client complete merely because the package exists on disk. Keeping the stages separate makes operational problems visible without confusing them with failures of signature mathematics.

12. What a bounded recovery test can establish

The fictional incident can now be reduced to six proposed acceptance cases. They are design-level tests for an authorized environment with synthetic keys and artifacts, not results from running a real TUF implementation or probing a production repository. A production assurance claim would require implementation testing, configuration review, and the relevant operational evidence.

The first case supplies the incident packet with a successful publishing job but no client evidence. The reporting system should identify publication as complete while leaving client adoption unresolved. Adding Cedar's attributed verification and retained-state observation should change Cedar's record, not every device's record. A duplicate event with no reliable identity should not increase the completed-client count.

The second case supplies conflicting or incomplete event histories: a late-arriving old observation, a retrieval failure, and a verification result followed by an unexplained state discrepancy. The expected reporting outcome is a visible distinction among those conditions, with the original timestamps and identifiers preserved. The test checks evidence reconciliation, not a new implementation of cryptographic verification. Its success would mean that the incident report does not conceal the unresolved cases behind a single green field.

The third case presents a newly encountered candidate whose expiration precedes the trusted update-start time, while the other isolated conditions are acceptable. The expected result is rejection as fresh authorization. A subsequent current candidate tests whether the recovery distribution path actually works. Refusing stale material and obtaining the replacement are recorded as distinct outcomes.

The fourth case presents a mixture of individually recognizable components that does not match the selected release record. The expected result is refusal to declare that release complete. A second candidate containing the intended components still needs installation and functional checks; artifact consistency does not replace them.

The fifth case compares old manifest sequence 99 with newly authorized sequence 102, both naming the older software release in the example. A client that has accepted sequence 101 should distinguish replayed old authorization from a current authorized restoration decision. Compatibility and suitability of that older release remain separate conditions, not facts established by the increasing sequence number.

The sixth case follows an affected client through trust refresh, replacement-artifact validation, installation, and defined post-recovery checks. It includes an interruption during installation and a case where an untrusted component reports its own success. The purpose is to expose what each observation can actually establish, not to assume that every reassuring report is authoritative.

A report that says five of these six cases passed should identify the remaining failure. It should not call the system “83 percent secure.” The cases cover different properties and failure modes; they are not interchangeable measurements of one universal security percentage. A failure in authority continuity cannot be averaged away by several successful download tests.

The broader lesson is practical rather than theatrical. A signing-key incident is not resolved everywhere at the instant a publisher changes a record. Recovery is a sequence of justified trust decisions and observed state changes across systems with different histories. A useful public account names those states, preserves uncertainty where clients are unreachable, and distinguishes a repaired delivery mechanism from a repaired installation.

The most important question after “Was the key revoked?” is therefore not whether the announcement sounded decisive. It is whether the intended clients learned the new authority through a trustworthy path, obtained the intended software, and reached the verified recovery state appropriate to the incident. Those are the claims that turn a revocation notice into evidence of actual recovery.