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.

Which of these are you doing

The procedure below is written for a permanent retirement. Three other situations borrow parts of it, and each skips something.

Situation	Which parts apply
Permanent retirement	All of it, in order
Replacing this appliance with a new one	Everything except removing the trust: the new appliance has its own root certificate, so distribute that before you withdraw this one, or clients lose both at once. See Replace rather than retire
An evaluation that ended	Detach the clients and destroy the appliance. Tell your CID222 contact the installation id is finished with, so it is not counted at renewal
Taking the appliance out of the traffic path for a while	Only the second step — stop sending it traffic. Leave the trust, the DNS records and the appliance in place, and expect the licence to keep ageing while it is idle

Warning

Take the export you need before anything else. Once the appliance is destroyed, its detections, sessions and event logs are gone, and there is no product feature that hands them back. There is also no way to reconstruct them from the licence issuer's side — the appliance never sent anything there.

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.

Replace rather than retire

Replacing an appliance is a decommission with an overlap, and the overlap is the point: run both appliances at once for long enough that every client has moved, then retire the old one with the procedure above.

Build the replacement and give it its own identity

Deploy the new appliance and complete its setup wizard.

It generates its own installation id. A licence is bound to that id, so the new appliance needs a licence issued against it — the old one's file does not transfer. Request it as soon as the new appliance exists.

Carry the configuration across deliberately

Re-enter the provider credentials, the directory configuration and the filter rules on the new appliance, or restore a backup of the old one onto it.

A restore brings the old appliance's installation identity with it, which is what you want when the new box replaces the old one outright — and is exactly what you must not do if both are to run at once. Two appliances presenting the same identity is a support conversation, not a deployment.

Distribute the new root certificate before withdrawing the old one

Push the new appliance's root certificate to your fleet while the old certificate is still trusted.

Both are trusted for the overlap. Withdrawing the old one first is what makes a replacement look like an outage.

Move the clients

Point the gateway rule, the proxy auto-configuration file, the extension policy and the Claude Code managed settings at the new appliance's names.

Traffic appears on the new appliance. Watch its detections feed rather than assuming the policy landed.

Retire the old appliance

Work through the procedure above, from Detach the clients first.

The old appliance stops serving and its keys and data are destroyed.

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.
During a replacement, a client reports its key is refused → A gateway API key is refused. It is pointed at the appliance whose keys you revoked; move it to the replacement.
During a replacement, the browser extension cannot attest or fetch its policy → The browser extension cannot attest, sign in, or fetch its policy
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