Endpoint Decommissioning Procedure

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This procedure defines how Glassbreak permanently removes workforce endpoint devices from service so that no Glassbreak or customer information can be recovered from them after they leave the issued workforce member's custody. It operationalises the asset-return and device-wipe expectations in the Offboarding Policy §7 and applies whether the device is being returned to stock, re-issued to another workforce member, donated, sold, or physically destroyed.

2. Scope

This procedure applies to the following endpoint classes:

  • Managed workstations (laptops, desktops, virtual workstations).
  • Mobile devices used for MFA, secure communications, or other Glassbreak work.
  • Hardware security keys (FIDO2 / U2F authenticators).
  • Removable media authorised under the Clear Desk & Clear Screen Procedure §3.4.
  • Other peripherals that hold persistent storage (external drives, USB-attached SSDs, network attached storage, smart card readers with onboard memory).

Cloud-hosted compute and storage decommissioning is handled through OpenTofu state changes and is out of scope for this procedure.

3. Triggering events

This procedure is invoked on any of the following events:

  • A workforce member departure under the Offboarding Policy §7 (asset return).
  • Hardware replacement (refresh cycle, fault, damage, upgrade).
  • Role change that retires the device from Glassbreak work.
  • Loss of trust in the device — for example, after the travel-confiscation scenario in the Remote Working Procedure §4.4 or any other event that may have given an untrusted party physical access.
  • End of supported life for the device (manufacturer no longer issues security updates).

4. Procedure

4.1 Intake

  1. The device is received by the Security Officer (or a delegate) in person or by tracked shipping per the Offboarding Policy §7.
  2. The serial number is verified against the asset register entry. Discrepancies are investigated before proceeding.
  3. The device is logged into the decommissioning register with date of receipt, condition, and reason for decommissioning.

4.2 Pre-wipe checks

  • All sessions and account bindings on the device have already been revoked under the Offboarding Policy §5 before the device arrives. The Security Officer verifies the access register confirms this before proceeding.
  • Where the previous user has identified knowledge of files on the device requiring extraction before wipe (e.g. handover material), the file extraction is performed and the files placed in the approved Glassbreak document store. No personal files are extracted.
  • Where the device's full-disk-encryption recovery key was held by Glassbreak, the recovery key is confirmed available before the wipe is initiated; a failed wipe with no recovery key forces a more aggressive procedure under section 4.5.

4.3 Secure erase — workstations and mobile devices

For each supported OS class, the published wipe method listed in the workforce handbook is followed:

  • macOS workstations — Erase All Content and Settings via Recovery (Apple silicon) or full Erase Disk via Disk Utility followed by reinstall from Recovery (Intel). The device is then re-enrolled in the management profile or marked for stock per section 4.6.
  • Windows workstations— Reset this PC with the "Clean data" option, followed by BitLocker key rotation on first boot if returning to stock.
  • Linux workstations — Full overwrite of the storage device, OS reinstall on a freshly generated LUKS volume, secrets directory verified empty.
  • iOS / Android mobile devices— Erase All Content and Settings (iOS) or factory reset with encryption-enabled reset (Android), followed by the Find-My / device-search service confirming the device is no longer associated with the workforce member's account.

The wipe is performed by the Security Officer or by a workforce member explicitly delegated for that wipe. The wipe is not delegated to the departing workforce member.

4.4 Hardware security keys

  • Hardware keys are reset using the manufacturer's reset procedure. The reset clears all credentials and PIN.
  • Where the device cannot be reset (firmware fault, counter-locked, unknown PIN), the key is physically destroyed under section 4.5.
  • Reset keys may only be re-issued to another workforce member after a fresh PIN has been set by the new holder and the key has been enrolled against the new holder's accounts.

4.5 Physical destruction

Physical destruction is required when:

  • The device cannot be reliably wiped (drive failure, encryption key unrecoverable, OS or firmware fault).
  • The device held material the loss of which would be a SEV-1 or SEV-2 incident if recovered (production signing key material on a hardware key, master operator credential).
  • The device is suspected to have been tampered with at a hardware level (the "loss of trust" trigger in section 3).
  • The device is out of supported life and is not being re-issued or returned to stock.

The destruction method is appropriate to the storage class:

  • SSDs and NVMe drives — physical destruction of the storage chips by an approved disposal service that issues a certificate of destruction. Crushing, shredding, or incineration as documented by the service.
  • Spinning HDDs — physical destruction (shredding or degaussing followed by shredding) by an approved disposal service that issues a certificate of destruction.
  • Hardware security keys with persistent secret material — physical destruction in the presence of the Security Officer or with photographic evidence retained in the decommissioning register.
  • Removable media — shredding or incineration appropriate to media type.

4.6 Disposal vs return-to-stock

After the wipe (or destruction) step is complete:

  • Return to stock— the device may be re-issued to another workforce member only after the re-imaging or device-setup procedure for that OS class has been completed and the device has been enrolled against the receiving workforce member's account per the Onboarding Policy §4.1.
  • Resale or donation — permitted only after a successful wipe (section 4.3) and a fresh operating-system installation, with no trace of previous configuration or account binding. Devices that fall under section 4.5 are not eligible for resale or donation.
  • Disposal— physical disposal via an e-waste service appropriate to local regulation. For devices destroyed under section 4.5, the disposal service's certificate of destruction is retained.

5. Attestation of wipe

  • For every device, the executor records in the decommissioning register: date of wipe or destruction, OS class, wipe method used, serial number, and a written attestation signed by the executor that the procedure was completed.
  • For devices destroyed under section 4.5, the certificate of destruction issued by the disposal service is filed with the register entry.
  • For hardware keys destroyed in-house, photographic evidence is filed with the register entry.
  • Where the device handled customer plaintext or persistent production credentials at any point, the Security Officer signs a second attestation countersigning the executor's record.

6. Records

  • The decommissioning register is retained for at least 5 years from the date of decommissioning.
  • The asset register is updated to mark the device as decommissioned with the date and reference to the decommissioning register entry.
  • Certificates of destruction are retained for at least 7 years.
  • Where a workforce departure triggered this procedure, the register entry is cross-referenced with the offboarding-checklist entry under /policies/offboarding §12.

7. Failure handling

  • A failed wipe (drive error, OS will not boot to reset, unknown PIN on a hardware key, reset locked out) is logged in the decommissioning register and the device is routed to physical destruction under section 4.5.
  • A missing or unreturned device follows the lost-device handling in the Remote Working Procedure §4.6 and is recorded as an incident under the Incident Response Policy.

8. Review

This procedure is reviewed at least annually and after any incident attributable to incomplete decommissioning. The next scheduled review is 27 May 2027.

9. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.

Stay Updated

Get product updates and security insights. No spam, unsubscribe anytime.

We respect your privacy. See our privacy policy.