2fe8c56d9c
in comments # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [ ] Added/updated automated tests - [ ] Where appropriate, [automated tests simulate multiple hosts and test for host isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing) (updates to one hosts's records do not affect another) - [ ] QA'd all new/changed functionality manually For unreleased bug fixes in a release candidate, one of: - [ ] Confirmed that the fix is not expected to adversely impact load test results - [ ] Alerted the release DRI if additional load testing is needed ## Database migrations - [ ] Checked table schema to confirm autoupdate - [ ] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [ ] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [ ] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [ ] Verified that the setting is exported via `fleetctl generate-gitops` - [ ] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [ ] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [ ] Verified that any relevant UI is disabled when GitOps mode is enabled ## fleetd/orbit/Fleet Desktop - [ ] Verified compatibility with the latest released version of Fleet (see [Must rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md)) - [ ] If the change applies to only one platform, confirmed that `runtime.GOOS` is used as needed to isolate changes - [ ] Verified that fleetd runs on macOS, Linux and Windows - [ ] Verified auto-update works from the released version of component to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
4 KiB
Prevent tampering of Fleet Orbit on Windows
Introduction
On Windows, users with administrative rights can remove or modify management agents like Fleet Orbit. Unlike many EDR and DLP tools with built-in tamper protection, Fleet does not attempt to hide or lock itself down. This is intentional. Fleet is built on openness and transparency, with enforcement driven by policies you can see and manage.
But that doesn’t mean you’re left unprotected. To keep the agent in place, IT teams can add guardrails using a combination of:
- A Fleet policy with automation that enforces protection by running a script if tampering occurs
- A PowerShell script that applies hardened registry values (executed automatically by the policy)
- A Windows configuration profile that blocks MDM unenrollment (a separate control that complements the above)
Together, these components create a self-healing enforcement loop that ensures protections remain in place, without relying on hidden or opaque mechanisms.
Hardening the installer
One way to harden the installer is to apply registry values through a PowerShell script. These values help prevent uninstallation or tampering of protected applications.
Windows hardening PowerShell script
Policies in Fleet
A Fleet policy confirms that the hardened registry key exists. If the key is missing, the policy fails, triggering automation to rerun the script. Once applied, the policy becomes compliant. If tampering occurs later, the cycle repeats.
Fleet policy for Windows hardening
Note: On first run, this policy intentionally fails to ensure automation executes the hardening script.
Blocking unenrollment
A Windows configuration profile can prevent devices from unenrolling from MDM. This is a separate measure from the policy and script but adds another layer of protection.
Block MDM unenrollment configuration profile
Microsoft CSP reference: The AllowManualMDMUnenrollment CSP is only supported on certain versions of Windows. Verify compatibility before deployment.
Advanced approaches
Some organisations may already use additional controls to protect against tampering:
- ADMX-backed CSPs
TheADMX_AddRemoveProgramsCSP can restrict software removal across all applications, not just Fleet. - Application control solutions
Tools like AppLocker can block the execution of unapproved installers or uninstallers. Powerful, but they require careful design and broader adoption.
The policy and script combination provides a self-healing loop, while the configuration profile and advanced approaches add complementary protection.
Conclusion
By combining a Fleet policy with automation, a PowerShell hardening script, and a configuration profile, admins can enforce dependable protection against tampering with the Fleet Orbit agent and installer settings.
Fleet’s open model makes enforcement visible and verifiable without relying on concealed or fragile mechanisms.
Want to learn more about how Fleet approaches transparent, cross-platform device management?
Visit fleetdm.com or check out the other guides for macOS, Windows, and Linux.