Take a CID222 appliance out of service: detach the clients that point at it, destroy its data and keys, and tell your CID222 contact about the licence.

Retiring an appliance is mostly work you do on everything except the appliance: the clients that were told to trust it, the gateway that was told to call it, and the copies of its disk you took. Do that while the appliance is still running, then destroy it.

What do I need?

Licence: Any
Role: admin_user

Prerequisites

The appliance is still reachable and you can sign in with a tenant that has the admin_user role.
Administrative access to the hypervisor, including its snapshots and the datastore the appliance lives on.
Administrative access to whatever distributed the appliance's root certificate — Group Policy, MDM, or the machines themselves.
Administrative access to the systems that point at the appliance: the web gateway, the firewall, the browser-extension policy, the Claude Code managed settings.
A decision about the data: an export you take before the appliance goes away, or none.

Warning

There is no decommissioning workflow in the product, no remote wipe, and no way to hand a licence back from the appliance. Everything below is a manual procedure. Work through it in order — several steps are impossible once the appliance is switched off.

Detach the clients first

Export anything you still need

Take whatever record you are required to keep — compliance reports, an event-log export, a database dump — following Backup and restore.

Once the appliance is destroyed, detections, sessions and event logs are gone. Decide this before, not after.

Stop sending traffic to the appliance

Remove the appliance from the paths that feed it: the web gateway's inspection service, the proxy auto-configuration your clients fetch, and any firewall rule or block-list that pulls from it.

Traffic returns to whatever the path did before CID222 was inserted. Confirm that is the behaviour you want — for a gateway configured to fail closed, removing the service can block users rather than pass them.

Withdraw the client policies that point at the appliance

Remove the browser-extension deployment policy, and remove the Claude Code managed-settings entry from your Claude organisation.

Both name the appliance's hostnames and carry a key issued by it. Clients stop routing through the appliance at their next policy refresh. An endpoint agent deployment is removed the same way, through whatever installed it.

Revoke the keys the clients were using

On API Keys, select Revoke for every gateway key issued to those clients.

This closes the window between withdrawing a policy and the last client picking the change up. It is belt and braces once the appliance is gone, and it matters while it is still running. Enrolled extension devices are revoked one at a time through the administration API rather than the dashboard, which carries no device list at 0.4 — ask your CID222 contact for the call if you need it, or rely on destroying the appliance.

Remove the trust you installed

Remove the appliance root certificate from your fleet

Withdraw the certificate from the store you pushed it to.

Remove the certificate from the Group Policy object under Trusted Root Certification Authorities and let the policy apply.

On a test machine, certmgr.msc no longer lists it after gpupdate /force.

Leaving a retired appliance's root CA trusted on a fleet leaves a private key you no longer control able to sign certificates those machines accept. Treat it as a credential to be withdrawn, not a leftover to be ignored.

Remove the inline proxy's root certificate as well, if you deployed one

Where devices were routed through the appliance's own inline proxy, remove that proxy's root certificate from the same stores.

It is a separate certificate from the appliance's HTTPS root, distributed separately, and it has to be withdrawn separately.

Remove the appliance's DNS records

Delete the A records for the appliance's names.

A name that resolves to a reused address is how a client ends up talking to something else that answers on it.

Destroy the appliance

Tell your CID222 contact the appliance is being retired

Send them the appliance's installation id, from Settings → License, and say it is being decommissioned.

The appliance cannot release or deactivate its own licence — it never contacts a licence server, so there is nothing to hand back. Retirement is recorded on the issuer's side, which is what stops the licence being counted against you at renewal.

Withdrawal on the issuer's side does not reach the appliance. Nothing on an appliance reads a revocation list, whatever its connectivity, so a retired appliance keeps working until its licence expires on its own dates. Destroying the disk is the control, not revocation.

Power the appliance off

Shut the guest down and power the virtual machine off.

Nothing further is served. Do not skip the earlier steps to get here — several of them need the appliance running.

Destroy the disk, not just the virtual machine

Delete the virtual machine and its virtual disks, and empty them from the hypervisor's recycled or orphaned storage.

The disk holds the TLS private keys, the licence, the database with its stored credentials, and the environment file that decrypts them. Removing the inventory entry while leaving the disk file on the datastore removes none of that.

Destroy the snapshots and backups

Delete every hypervisor snapshot of the appliance and every backup copy you took, including exports held off-box.

Each is a complete appliance. A backup you keep for records is a copy of production data and of the keys protecting it, and inherits the same handling requirements.

Remove any host directories that outlived the appliance

On a deployment where CID222 ran on a host you keep — rather than as a self-contained virtual machine — remove its containers and named volumes, then delete /var/lib/cid, /etc/cid and /opt/cid.

Those directories live outside the containers, so removing the stack does not remove them. They hold the licence, the identity, the trust anchors, the private keys and the environment file.

Verify

From a client machine, the appliance's names no longer resolve, and nothing answers on its former address.
On a representative client of each platform, the appliance root certificate is absent from the trust store.
A client whose traffic was routed through the appliance reaches the internet — or is blocked — according to the policy you intended after removal, not by accident.
The hypervisor lists no virtual machine, disk, snapshot or export belonging to the appliance.
Your CID222 contact has confirmed the installation id is recorded as retired.

If it fails

Clients still report a certificate error against a name that no longer exists → a stale DNS record or a cached entry. Confirm the record is deleted and let the cache expire.
Users lose access to sites they previously reached → the gateway or firewall path was removed without restoring the behaviour that preceded it. Re-check that step rather than the appliance.
A device keeps enforcing the retired policy → the managed policy is still deployed to it. Withdraw it from the management system that installed it; revoking keys on a destroyed appliance can no longer reach it.

Next steps

Backup and restore — how to take the export you may need before the appliance goes, and what a copy of it contains.
Hardening checklist — the same controls, read the other way round, when you build the appliance that replaces this one.

Decommission an appliance