Retiring and removing a machine

Dynacop protects the sign-in screen, so removing it must never brick a machine. Follow one rule:

1. Retire (archive) the resource

In the panel, archive the resource. From that moment the backend tells the agent to stand down: MFA is no longer enforced on that machine, sign-ins pass through, and the resource moves to the retired state.

Retiring is reversible — Restore puts it back exactly as it was, with all access intact.
A retired machine is deliberately exempt from fail-mode: closed — offboarding never locks anyone out.
The panel asks for confirmation if the machine is still online.

2. Uninstall the agent

Uninstall Dynacop for Windows Login from Programs & Features (or via your deployment tool). During uninstall the agent:

notifies the cloud (best-effort), so the panel shows a “removed” badge,
removes its service, credential provider, files, and local state,
clears any Shield firewall rules it created — no orphan blocks are left behind.

If a machine was wiped or reimaged instead, no notification arrives — that’s normal; the resource just goes offline (and stale after 30 days).

3. Delete the resource

Once the machine shows removed (or you know it’s gone), delete the resource in the panel. This permanently removes it and its access records.

Safety nets

Deleting first won’t brick the machine. If an installed agent finds its resource deleted, it fails open and stops enforcing — by design. Keep agents updated for this behavior.
Version upgrades never deregister — only a real uninstall does.
Resources silent for over 30 days are flagged stale so orphans are easy to spot.

Offboarding a person instead

To remove a person (not a machine): deactivate them under Resource Users — every access is cut instantly while their audit history is preserved. See person lifecycle.