[Robotics](https://rankshieldrobotics.com/) / [Blog](https://rankshieldrobotics.com/blog/) Blog / Operations # You Sold the Robot. Who Still Has the Keys? A robot that leaves your control carries more than hardware: device credentials, a navigation map that is effectively a floor plan of your building, your network configuration, and a binding to a cloud account that does not travel with the chassis. Fleet security spends its attention on robots arriving and operating. Almost none of it is spent on robots leaving, which is the one moment when everything the machine learned about you goes somewhere else. By RankShield Robotics, Robot Security Research | Published September 1, 2026 ## Key takeaways - A decommissioned robot holds credentials, facility maps, network configuration and task policy , distributed across several compute units rather than one disk. - The current standard is NIST SP 800-88 Revision 2, published 26 September 2025 [1](#ref-1) . Revision 1 was formally withdrawn the same day [2](#ref-2) , and most robotics guidance still cites it. - Revision 2 shifts the emphasis to establishing a sanitization programme rather than per-device technique, and points to IEEE 2883 or an approved standard instead of device-specific methods [1](#ref-1) . - It expands cryptographic erase , including key sanitization using ISO/IEC 19790 zeroization [1](#ref-1) . For a robot, destroying a key beats chasing every storage location. - The technique standard behind it, IEEE Std 2883-2022 , defines Clear, Purge and Destruct, and only the first two leave a robot you can still sell [3](#ref-3) . - Crypto erase only works if the key was unique to that unit . A key shared across a model line cannot be erased, because destroying one copy leaves it on every peer. ## What does a robot actually carry when it changes hands? More than most decommissioning processes assume, and in more places. A mobile robot typically holds device credentials and keys, a persistent navigation map built from months of operating in your building, the Wi-Fi network configuration it used to get there, task policy and skills describing what it was asked to do, and local logs. That data is spread across the locomotion computer, the controller, sometimes removable media, and occasionally the sensors themselves. The navigation map deserves particular attention because it is the item people consistently fail to classify as sensitive. A SLAM map of a warehouse, a hospital ward or a data centre floor is a measured internal floor plan, produced by a machine that was allowed to drive everywhere. It is not a document anyone would deliberately email outside the organization, and it leaves in the robot without anyone deciding that it should. Then there is the half that does not leave at all. The robot was bound to a cloud account, and telemetry it uploaded lives in the vendor's infrastructure under that binding. You can hold the chassis in your hand and be no closer to reaching that data, which is a genuinely different problem from wiping a laptop. Two sanitization problems. Holding the robot reaches one of them, and only if the key protecting it was unique to that unit. ## Why is this becoming more common now? Because units are starting to move between owners at a rate the industry has not had before. Early robot fleets were largely one-way: organizations bought, deployed, and eventually scrapped. A maturing market produces upgrades, lease returns, RMAs, redeployments between sites and business units, and genuine secondary sales, and each of those is a handover event. US policy has quietly added to the pressure. As we covered in [the analysis of the FCC Covered List](https://rankshieldrobotics.com/blog/fcc-robot-ban-robots-you-already-own/), foreign-produced advanced robotic devices authorized before 28 July 2026 remain lawful to import, sell and use, while new models generally cannot obtain authorization. That makes an already-authorized unit a more valuable asset than an equivalent one that cannot enter the market, and assets that hold their value get resold rather than scrapped. So the volume of handovers is rising for structural reasons, while the practice of sanitizing a robot before handover barely exists. That gap is the subject of this article, and it is one of the few robotics security problems where the fix is almost entirely process rather than product. ## What changed in NIST SP 800-88 Revision 2? Quite a lot, and the timing matters because most published guidance on wiping devices still cites the previous version. NIST published SP 800-88 Revision 2, Guidelines for Media Sanitization, on 26 September 2025 [1](#ref-1), and Revision 1 was withdrawn on the same date, superseded by the new revision [2](#ref-2). If a checklist you are working from cites Revision 1 without noting that, it predates the current guidance. The most significant shift is one of altitude. NIST describes the focus as "maintaining the confidentiality of sensitive information by establishing an agency or enterprise media sanitization program as part of media disposal or reuse" [1](#ref-1). Rather than telling you which technique to apply to which device, it asks whether you have a programme at all: a policy, defined roles, and a repeatable process. For robotics that reframing is helpful, because no per-device appendix was ever going to cover a machine with four compute units and a cloud account. Two technical changes follow from it. Device-specific technique detail is replaced with a recommendation that organizations "comply with IEEE 2883, NSA specifications, or an organizationally approved standard" [1](#ref-1). And cryptographic erase gets expanded treatment, including guidance to broaden "the types of cryptographic keys that may be used for CE" and on "key sanitization using the state of practice ISO/IEC 19790 zeroization" [1](#ref-1). ## What does IEEE 2883 actually require? It is the technique standard NIST now defers to, and it is worth knowing what it contains before you cite it in a policy. IEEE Std 2883-2022, Standard for Sanitizing Storage, was published in June 2022 and defines sanitization as the process of denying access to data on storage media "such that reasonable assurance exists that the data cannot be retrieved or reconstructed" [3](#ref-3). It prescribes three methods: Clear, Purge and Destruct [3](#ref-3). Method | What it does | Device afterwards | Clear | Logical techniques applied to user data at all addressable locations, protecting against simple non-invasive recovery through the same host interface available to the user [3](#ref-3) | Reusable | Purge | Sits between the other two, targeting resistance to laboratory recovery rather than only to interface-level recovery | Generally reusable | Destruct | Physical destruction such as disintegrating, incinerating or melting, leaving target data unrecoverable with state-of-the-art laboratory techniques [3](#ref-3) | Unusable | One caution if you go looking for the detail yourself. Several widely circulated summaries of IEEE 2883 give Purge and Destruct word-for-word identical definitions, which cannot both be right, since the two differ precisely on whether the device survives. Work from the standard rather than from a summary of it, which is a general rule that applies with unusual force here because the distinction between "reusable after sanitization" and "destroyed" is the entire question when you are selling a robot rather than scrapping it. For a robot the reusable methods are the ones that matter commercially. Destruct sanitizes a unit you were never going to sell. Clear and Purge, and cryptographic erase alongside them, are what let a machine change hands with its data left behind. ## Why is cryptographic erase the right primitive for a robot? Because the alternative does not scale to the shape of the device. Overwrite-based sanitization requires you to enumerate every location data was written and reach all of it. On a robot that means the locomotion computer, the controller, any removable media, sensor caches, and whatever the vendor put somewhere you did not expect. Miss one and the sanitization is incomplete in a way that produces no error. Cryptographic erase inverts the problem. If everything the unit stores is encrypted under a key, sanitization becomes destroying that key rather than pursuing every copy of the ciphertext. NIST's expanded treatment of CE, including zeroization to ISO/IEC 19790 [1](#ref-1), is the standards-side recognition that this is how modern devices should be handled. It is faster, it is verifiable, and it does not depend on knowing every place data landed. It also fails completely under one condition, and that condition is common in robotics. ## What happens if the key is shared across the model line? Cryptographic erase stops meaning anything. The premise of CE is that destroying the key renders the data infeasible to recover. If the same key is present on every unit of that model, destroying this unit's copy accomplishes nothing: the key still exists, on a thousand peers, in the hands of anyone who extracts it from any one of them. This is the decommissioning consequence of a defect we have written about from the operational side. In [the piece on credential blast radius](https://rankshieldrobotics.com/blog/robot-fleet-one-credential-blast-radius/), a shared model-line key meant one compromise reached every unit. Here the same architecture means no unit can be cleanly retired. It is the same design choice producing a second, unrelated-looking failure, which is usually the sign that the choice rather than the symptom is the thing to fix. A unit-unique credential held in hardware makes both problems tractable at once. Compromise stays on the unit, and retirement is a key destruction you can perform and verify. That is why [per-robot attested identity](https://rankshieldrobotics.com/solutions/robot-identity-attestation/) is a decommissioning control as much as an access control, which is not how it is usually sold. ## What about the half that stays in the vendor cloud? You cannot sanitize it by holding the robot, and you should stop treating it as an afterthought. When a unit is bound to a vendor account, the telemetry it uploaded sits in infrastructure you never had custody of. Wiping the chassis does not reach it, and neither does destroying an on-device key, because the cloud copy was never encrypted under that key. Two failure modes follow, and they point in opposite directions. If the binding is not ended, the buyer's robot may still be associated with your account, or your account may retain reach into a machine you no longer own. We have already seen what a mis-scoped cloud binding does at scale in [the piece on robot telemetry](https://rankshieldrobotics.com/blog/robot-telemetry-egress-eu-data-act/), where a control plane treated one owner's token as authority over thousands of other people's units. A handover that leaves bindings ambiguous is the same class of problem created deliberately. The practical steps are unglamorous. Unbind the unit through the vendor's process and then verify the binding actually ended rather than trusting the confirmation screen. Ask the vendor, in writing, what data they retain after unbinding and what deletion you can request. Record the answer, because "we assumed it was deleted" is not a position you want to occupy later. ## Who carries the exposure after the sale, the seller or the buyer? Both, differently, which is why neither side reliably raises it. The seller's exposure is confidentiality: a floor plan of their facility, their network configuration, and possibly credentials that still authenticate somewhere, now sitting in a machine owned by someone else. Nothing about that is visible to them after the unit leaves, so the failure is silent by construction. The buyer's exposure is trust in the opposite direction. They have acquired a machine whose provenance they cannot verify: they do not know what firmware it actually runs, whether it retains a binding to a previous owner's account, or whether anything was added to it during a life they have no record of. Buying a used robot is buying an unattested device and connecting it to your network, which is a decision most organizations would refuse if it were phrased that way. The clean answer for the buyer is to treat an incoming used unit exactly as an untrusted device until it proves otherwise: re-provision identity from scratch, attest the firmware against a known reference before it joins anything, and refuse to accept a credential that arrived with the hardware. [Firmware attestation](https://rankshieldrobotics.com/solutions/firmware-attestation-rats/) is what turns "the seller said it was clean" into something checkable. ## What would a clean handover actually look like? Eight steps, most of which are decisions rather than technology. Inventory where the unit stores data. Confirm that data is encrypted under a key unique to the unit. Destroy that key and verify the destruction. Remove maps, network credentials and task policy explicitly rather than assuming an app unlink removed them. Unbind from the cloud account and confirm it. Ask the vendor what remains and what deletion is available. Revoke the unit's identity in your fleet so a returning robot is not automatically trusted. And produce a record of what was done. That last step is the one worth insisting on, and it aligns with where Revision 2 puts its emphasis: a programme with defined process and documentation rather than an ad hoc wipe [1](#ref-1). A sanitization record turns an assertion into evidence, which matters for the same reason it mattered in [the piece on liability and disclosure](https://rankshieldrobotics.com/blog/robot-liability-evidence-eu-product-liability-directive/). If you are ever asked what left the building inside that robot, "we have a signed record of what was sanitized, by what method, verified by whom" is a materially different answer from "we believe it was wiped." Honest scope: none of this is legal or compliance advice, and the applicable requirements depend on what data your robots handle and where you operate. The worksheet below is a readiness prompt, and everything runs in your browser. ## What should you do before the next unit leaves? Find out whether you have a process at all. Ask whoever handled the last robot that left your control, for any reason, what they did to it. In most organizations the answer is that it was boxed and shipped, and that answer is the finding. Then decide the two things that determine whether a process is even possible: whether unit data is encrypted under a per-unit key, and who owns the cloud unbinding step. The worksheet below produces a dated checklist you can hand to whoever runs the next handover, including the credential question, because that single architectural fact decides whether cryptographic erase is available to you or not. Interactive tool ### Robot Handover Checklist For the next unit you sell, return, RMA or scrap. Nothing you enter leaves your browser. Answer for the next unit you would sell, return, RMA or scrap. The score matters less than which rows you cannot tick. You know every place the unit stores data: locomotion PC, controller, sensors, removable media Unit data is encrypted under a key unique to that robot, so destroying the key sanitizes it That key is destroyed at handover, and the destruction is verified rather than assumed Facility maps, network credentials and task policy are removed, not just unlinked in an app The robot is unbound from your cloud account, and you confirmed the binding actually ended You asked the vendor what data remains in their cloud and what deletion you can request The unit's identity is revoked in your fleet, so a returning robot is not trusted The handover produces a record: what was sanitized, by what method, verified by whom How is the robot's credential issued? Shared across the model line or product familyOne per site or per tenantUnique to each unit, held in hardware HANDOVER READINESS 0of 8 steps in place Download your handover checklist ## Frequently asked questions about robot decommissioning, sanitization and handover **What data does a robot hold when it is decommissioned?** Typically device credentials and keys, a persistent navigation map amounting to an internal floor plan of the site it worked in, Wi-Fi and network configuration, task policy and skills, and local logs. Unlike a laptop this is distributed across several compute units, and sometimes removable media or sensor caches. Separately, data the robot uploaded during its life sits in the vendor cloud under the account it was bound to, which wiping the physical unit does not reach. **Which sanitization standard applies, and is NIST SP 800-88 still current?** The current version is NIST SP 800-88 Revision 2, Guidelines for Media Sanitization, published 26 September 2025 [1](#ref-1). Revision 1 was withdrawn on that date and superseded by Revision 2 [2](#ref-2). This matters because a large amount of published decommissioning guidance still cites Revision 1. Revision 2 emphasizes establishing an organizational sanitization programme rather than device-by-device technique, and points organizations to IEEE 2883, NSA specifications, or an organizationally approved standard [1](#ref-1). **What is cryptographic erase and why does it suit robots?** Cryptographic erase sanitizes data by destroying the key it was encrypted under, rather than overwriting every location the data occupies. It suits robots because a robot writes data across several compute units and sometimes removable media, so enumerating every location is error-prone and a missed location produces no error. NIST SP 800-88 Revision 2 expands CE guidance, including the types of keys usable for it and key sanitization using ISO/IEC 19790 zeroization [1](#ref-1). **Can you cryptographically erase a robot with a shared key?** Not meaningfully. Cryptographic erase depends on the destroyed key being the only way to recover the data. If the same key is provisioned across an entire model line, destroying this unit's copy leaves the key intact on every other unit, and anyone who extracts it from any peer can still recover the data. In that architecture sanitization has to fall back to overwrite or physical destruction. A unit-unique credential held in hardware is what makes crypto erase available. **What should the buyer of a used robot do?** Treat it as an untrusted device until it demonstrates otherwise. Re-provision its identity from scratch rather than accepting whatever credential arrived with the hardware, attest the firmware against a known-good reference before connecting it to anything that matters, and confirm no binding to a previous owner's cloud account remains. You are acquiring a machine whose software history you have no record of, which is a materially different proposition from buying new, and worth pricing accordingly. **Does unbinding the robot from a cloud account delete the data?** Not necessarily, and you should not assume it. Unbinding typically ends the association between the unit and the account; what happens to telemetry already uploaded is a separate question governed by the vendor's retention practice. Ask in writing what is retained after unbinding and what deletion you can request, and record the answer. Also verify the unbinding actually took effect rather than relying on a confirmation screen, since an ambiguous binding after a sale can leave either party with reach they should not have. **What does RankShield Robotics provide for decommissioning?** Per-robot identity rooted in hardware, which is what makes cryptographic erase meaningful at retirement and what lets you revoke a departing unit so a returning robot is not automatically trusted. Attestation, so an incoming used unit can be checked against a known-good firmware reference rather than accepted on the seller's word. And tamper-evident provenance, so the record of what a unit did during its life with you ends cleanly and can be produced later. We do not perform media sanitization or issue certificates of sanitization. ## References - NIST. Guidelines for Media Sanitization: NIST Publishes SP 800-88r2 . 26 September 2025. [www.nist.gov/news-events/news/2025/09/guidelines-media-sanit](https://www.nist.gov/news-events/news/2025/09/guidelines-media-sanitization-nist-publishes-sp-800-88r2) - NIST Computer Security Resource Center. SP 800-88 Rev. 1, Guidelines for Media Sanitization (withdrawn 26 September 2025, superseded by Rev. 2) . 2014, withdrawn 2025. [csrc.nist.gov/pubs/sp/800/88/r1/final](https://csrc.nist.gov/pubs/sp/800/88/r1/final) - SNIA. IEEE 2883 Sanitization of Storage (IEEE Std 2883-2022, published June 2022) . 2022. [www.snia.org/educational-library/ieeetm-2883-sanitization-st](https://www.snia.org/educational-library/ieeetm-2883-sanitization-storage-2022) ## Keep exploring [SOLUTIONPer-robot attested identity](https://rankshieldrobotics.com/solutions/robot-identity-attestation/)[BLOGOne credential, your entire fleet](https://rankshieldrobotics.com/blog/robot-fleet-one-credential-blast-radius/)[SOLUTIONRevocation and kill switch](https://rankshieldrobotics.com/solutions/robot-kill-switch-dead-man-credential/) ## Retire a robot the way you onboarded it. Unit-unique identity you can destroy, attestation for units arriving, and a record that ends cleanly. [Request early access](https://rankshieldrobotics.com/request-access/) This article is for general information and does not constitute legal, compliance or data-protection advice. NIST SP 800-88 Revision 2 is referenced as the current version of that guideline as published; organizations should work from the publication itself and from any sector or national requirements that apply to them. Whether particular robot data is personal data, and what obligations attach to its deletion, depends on your jurisdiction and use case and is a question for qualified counsel. RankShield does not perform media sanitization and does not issue certificates of sanitization.