Shipping Datasets on Encrypted Drives: Hardware, Keys and Custody

When a shipped drive beats a network transfer

Ship a drive only when the network path is slower, costlier or not permitted, because physical media adds loss, theft and custody risk that an encrypted transfer avoids [1]. University IT security guidance makes the same point: use secure electronic transfer by default and mail media only when you must [1]. The usual triggers in AI data work are archives above roughly tens of terabytes over a thin uplink at the supplier, raw media (audio, video, scanned page images) whose volume dwarfs its record count, and air-gapped training or evaluation enclaves that have no inbound internet path.

Before choosing a drive, run the numbers for multi-terabyte network transfer tools and for cross-account cloud bucket delivery. Also note that the managed appliance many teams used to reach for is gone for newcomers: as of October 2026, AWS Snowball Edge is closed to new customers and no Snow Family device can be ordered by them [3]. For the overall delivery picture, start at the dataset delivery hub and the existing answer on how licensed data is delivered.

Hardware-encrypted versus software-encrypted drives

Hardware-encrypted drives do the cryptography inside the device and can carry an independent FIPS 140-3 validation, while software-encrypted volumes depend on the sender's host, tooling and configuration being right. Neither is automatically safe; what matters is what you can verify.

For hardware drives, look up the module in the NIST Cryptographic Module Validation Program (CMVP) validated-modules search rather than trusting a box that says "FIPS". Match the certificate number, vendor, module name and hardware and firmware versions to the unit you will receive, and confirm the certificate is on the active list rather than the historical one. New validations are issued against FIPS 140-3, and as of October 2026 FIPS 140-2 certificates were moved to the historical list on 21 September 2026 [5], so a drive that only cites a FIPS 140-2 certificate should not be accepted where a current validation is required.

Rugged, tamper-evident, optionally FIPS-validated removable drives are a mature product category built for moving data between disconnected environments [4]. Treat the vendor's datasheet as a starting point and the CMVP record as the evidence.

Keeping the key out of the box

Send the key, PIN or passphrase by a different channel and to a different person than the drive, so that intercepting one shipment yields nothing usable [1]. In practice that means one of three patterns:

• Asymmetric wrap. The receiver publishes an OpenPGP or age public key; the sender encrypts the volume passphrase (or the per-archive keys) to it and sends that small file over email or a portal. Only the receiver's private key can open it. The dataset encryption key exchange guide covers fingerprint checks and rotation.
• Split knowledge. Half of a keypad PIN goes by encrypted message and half by a verified phone call, each to a different named person.
• Release on receipt. The sender withholds the key until the receiver confirms intact seals and serial numbers, which also gives you a clean event for the custody log.

Never write the passphrase on the drive, the packing slip or the courier waybill. Agree a duress word or a "do not release" signal in advance in case the receiving contact changes. Record key fingerprints and who received each fragment in the same log as the physical handoffs.

Packaging and chain of custody in transit

A defensible chain of custody is a continuous, signed record of who held the drive, when, and in what seal state, from the sender's bench to your loading dock. The glossary entry on chain of custody and the explainer on chain of custody for data give the general definition; for drives, the concrete controls are these.

• Serialized tamper-evident bags or tape, with the serial photographed against the drive's own serial number before sealing.
• A tracked courier service with signature on delivery, addressed to a named recipient, not a general mailroom.
• Two drives in separate shipments when the dataset is irreplaceable or the window is tight, each with its own seal.
• No dataset description on the outside of the package; the waybill should not reveal the contents.

Illustrative example: invented to show structure; it does not describe an available dataset.

If a seal serial does not match, the bag shows tampering, or the drive serial differs, stop. Do not plug the drive in; photograph everything, quarantine it and notify the sender.

Receiving and verifying the drive

Mount and verify the drive on an isolated, single-purpose host before any byte reaches your training storage. A data ops runbook for the receiving side usually looks like this:

1. Isolate. Use a host with no route to production and, for air-gapped enclaves, a dedicated transfer station on the low side. Disable autorun and automount.
2. Open read-only. For LUKS2, open the mapping and mount with ro; for keypad drives, use the read-only mode if the model offers one.
3. Verify the manifest. Check the sender's signature on the manifest file first, then run sha256sum -c (or b3sum for speed) against every file. Compare file counts and total bytes to the delivery specification. The manifest and checksum verification guide covers formats and partial failures.
4. Scan. Run malware scanning on the decrypted content, especially on office documents and archives inside media collections.
5. Copy to controlled storage. Use rsync --checksum or a copy tool that re-hashes on write, then verify again at the destination. Apply the access controls in access control for licensed training data.
6. Log intake. Record dataset version, manifest hash, operator and time, and link it to the license record. The licensed dataset intake checklist lists the remaining checks.

Expect real failure modes at multi-terabyte scale: filenames that are illegal or collide by case on the receiving operating system, files that exceeded a FAT32 4 GB limit on the sender side, hashes computed before a last-minute re-export, and USB bridge chips that drop under sustained reads. Each surfaces as a manifest mismatch, which is why the manifest has to be produced from the final bytes on the drive.

Wiping, returning or destroying the drive

Once the copy is verified, decide whether the drive is returned, sanitized or destroyed, and record that decision with the same rigor as the delivery. NIST SP 800-88, the media sanitization guideline (Rev. 2, September 2025), sorts methods into Clear, Purge and Destroy, with cryptographic erase as a Purge technique [2]. For self-encrypting and keypad drives, cryptographic erase (destroying the media encryption key) is usually the fastest route to unrecoverable data; for plain drives carrying software volumes, follow your approved purge or destroy method [2].

Match the outcome to the license: if the agreement requires deletion of delivery media, keep a certificate or log entry naming the drive serial, method and date. The guide to certificates of data destruction shows what that record should contain. Do not reuse a delivery drive for a different supplier without sanitization.

Specifying drive delivery in your request

Write the physical delivery terms into your delivery specification so the sender knows exactly what to ship. Include the drive class (hardware-encrypted with an active CMVP certificate, or a named software scheme), filesystem, manifest format and hash algorithm, key exchange pattern, courier and seal requirements, named recipients, and what happens to the drive afterward. The delivery specification template has fields for each.

When you source data through SourceX, delivery runs through private, access-controlled workflows and only after an executed agreement and supplier approval, never as email attachments; every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. You can describe the delivery you need on the buyers page, and the related answer on encryption in transit covers network delivery.

Request a large operational dataset

SourceX sources operational datasets from US companies on request, including document archives, engineering records and new recordings of hands-on work, and manages the licensing and purchase process. Nothing is held in stock, a request does not guarantee a match, and each release is approved by the supplying company. Describe the dataset you need delivered.