Host reports incorrect encryption key status when operating system is re-installed but Fleet host record is not deleted

[allenhouchins]

UPDAYE: @noahtalerman: We decided to document the expected workflow as the expected behavior. PR is here.

---

Fleet version: 4.60.1

Web browser and operating system: Any

---

💥  Actual behavior

If a user needs to wipe and re-install their OS, when Fleet is reinstalled, Fleet will report incorrect encryption key status because it attaches itself to the exist host ID record. I have had customers/prospects report this on both Linux and Windows.

🧑‍💻  Steps to reproduce

1. Setup a Linux or Windows host in Fleet and verify successful encryption key escrow
2. Wipe the device and re-install the OS without deleting the host record in Fleet
3. Enroll the device to Fleet and notice the encryption key status is incorrect. We also have an encryption key stored that is unusable.

🕯️ More info (optional)

Semi-related to this: #24592
Slack thread (Linux): https://fleetdm.slack.com/archives/C07GLME5P7C/p1733868862303489
Slack thread (Windows): https://fleetdm.slack.com/archives/C080TU8UP45/p1733934648582779

🛠️ To fix

@marko-lisica:
Docs improvement as this is expected behavior
#26377

[sharon-fdm]

Hey team! Please add your planning poker estimate with Zenhub @iansltx @ksykulev @lucasmrod @mostlikelee

[gillespi314]

@georgekarrv, this issue probably requires additional product input to define expected behavior as it relates to some long-standing questions regarding the host lifecycle and how/if Fleet should be responsible for differentiating wiped hosts from other hosts during fleetd enrollment/re-enrollment.

Generally speaking, Fleet preserves host records unless and until the host is deleted in Fleet. The reason for this, as I understand it, is that there are myriad scenarios where fleetd enrollment/re-enrollment can happen (e.g., fleetd is uninstalled and re-installed on the same host) and so far at least there has been a bias toward preserving as much of the historical record as possible as the default.
The current approach runs into questionable UX when it comes to workflows that involve re-imaging devices from the IT warehouse as it introduces some friction to the process when we expect admins to delete the host from Fleet manually.

There are a wide range of scenarios for wiping a host, some of which have limited visibility to Fleet. And so the challenge becomes how to best support the re-imaging workflow in a way that is clearly defined and deterministic, while at the same time not falling into the trap of relying on a bunch of ad hoc, platform-specific heuristics that will be difficult to maintain overtime as the platforms drift over time. With that in mind when these sorts of issues have been raised in the past, the bright-line, keep-it-simple approach that depends on the IT admin deleting the host in Fleet has been considered "good enough" (at least that's where things ended up the last time we were working through this with Roberto). There's room for improvement to be sure, but I think will require a fair bit of design thinking plus development effort to get it right.

[marko-lisica]

Hey @allenhouchins, this is expected behavior for now. I talked with @noahtalerman and for now we decided to improve Wipe and lock guide: #26377

If you think we should improve this further, please file a feature request.

[noahtalerman]

FYI @marko-lisica I merged in your PR so I'm closing this bug.

[fleet-release]

Host reborn anew,
Keys align in cloud city,
Fleet's truth shines through.