How a Hard Disk Drive Is Made: Platters, Heads, Motors and Firmware

A hard disk drive is made by coating polished aluminium or glass disks with a stack of sputtered magnetic films, a hard carbon overcoat and a molecule thin lubricant, then pairing those platters with read/write heads that are built by the thousand on ceramic wafers, much like chips. In a clean room, the platters go onto a spindle motor, the heads go onto an actuator arm driven by a voice coil, and the sealed drive gets servo patterns, firmware and days of testing before it is boxed. Firmware then runs the drive for life: it steers the heads, hides bad sectors, keeps SMART health logs and, on self-encrypting models, holds the keys.

This post goes one level deeper than our SSD build explainer and our post on rare earth magnets, which supply the voice coil and spindle motor magnets inside every drive. For erase commands in depth see our companion post on NVMe and ATA sanitize, and for building storage at home see our home NAS guide.

Drive makers keep process recipes, film thicknesses and yields to themselves. Where a primary source publishes a number we cite it; where none does, we describe the step without inventing a figure, and any arithmetic is labelled illustrative.

Key takeaways

• A hard drive has six big parts: platters, a spindle motor, read/write heads on sliders, an actuator arm swung by a voice coil motor, a sealed enclosure, and a controller board running firmware.
• Platters start as aluminium alloy or glass disks, polished extremely smooth, then get a sputtered stack of underlayers, a granular magnetic recording layer, a carbon overcoat and a lubricant.
• Heads are made on ceramic wafers with thin film lithography, then sliced into rows, lapped to set the reader dimensions, and cut into sliders whose air bearing surface lets them fly a few nanometres above the disk.
• Giant magnetoresistance, discovered independently by Albert Fert and Peter Grünberg in 1988, put sensitive read heads into drives from 1997 and won the 2007 Nobel Prize in Physics. Tunnel magnetoresistance heads came after it.
• Shingled recording (SMR) overlaps tracks for density, so rewriting one sector can mean rewriting a whole zone. Helium filling, HAMR and MAMR are other routes to more terabytes per drive.
• The drive's own firmware writes nothing you can see, but it decides almost everything: head positioning, sector remapping, SMART, caching, and encryption on self-encrypting drives.
• On Linux, smartctl and hdparm show model, firmware version, health and erase support. Always confirm the device path by serial number before any erase.
• NIST SP 800-88 Revision 2 (September 2025) defines clear, purge and destroy, and points to IEEE 2883 for device specific purge techniques such as dedicated sanitize commands and cryptographic erase. It also notes that degaussing, historically a purge technique for hard drives, has become more complicated as recording technologies have changed.

Substrate to boxed drive: the step table

This table is the map for the rest of the post. No manufacturer we could find publishes per stage yields, so each row names the check rather than a percentage.

Two cautions on the table. First, the order of steps 10 to 12 varies by maker and by product line; some drives self write most of their servo during the test phase. Second, steps 1 to 4 often happen in a separate media plant and steps 5 to 7 in a separate head plant, sometimes in different countries, so a single drive is a supply chain of its own.

A dated timeline of hard drive milestones

We have left helium, HAMR and MAMR product launch dates out of this table because the drive makers' own pages refused scripted requests while we researched this post, and we do not cite launch dates second hand. The zoned command sets (ZBC from T10, ZAC from T13) are covered in the SMR section below.

What is inside a hard drive?

Open a 3.5 inch drive (please do not, unless it is already headed for destruction; one fingerprint or dust particle ruins it) and you see a cast aluminium base, one or more shiny platters on a central hub, a triangular arm that swings across them, and on the underside a green or blue circuit board. Each part has a job.

Platters

Platters are the disks that hold data, coated on both sides with magnetic film. A 3.5 inch drive has a stack of them, separated by spacer rings and held by a clamp on the motor hub. Each surface has its own head, so a drive with N platters usually has 2N heads, though some low capacity models leave a surface unused. Data is stored in concentric tracks, and each track is divided into sectors, today usually 4096 bytes physically, often presented to the host as 512 byte logical sectors on "512e" drives.

Read/write heads and sliders

Each head sits at the trailing edge of a slider, a tiny ceramic block about the size of a sand grain. The slider's bottom face, the air bearing surface, is etched with rails and pockets so that the rush of gas dragged along by the spinning disk lifts it. It flies a few nanometres above the surface, much closer than the wavelength of visible light. On it are two separate elements: a writer, an electromagnet that flips the magnetisation of grains on the disk, and a reader, a magnetoresistive sensor whose electrical resistance changes with the field beneath it. Modern heads also carry a small heater that expands the head locally to fine tune the flying height (often called thermal fly height control), and HAMR heads add a laser and a near field transducer.

Actuator arm and voice coil motor

The heads ride on stainless steel suspensions fixed to an arm that pivots on a bearing. At the back of the arm is a flat coil of copper wire sitting between strong permanent magnets, usually neodymium iron boron. Push current through the coil and the arm swings; this is the voice coil motor, named after the same principle in a loudspeaker. The firmware drives it in a closed loop many thousands of times per second using position information read from the servo patterns on the platters. Many current high capacity drives add a second, micro actuator stage (piezoelectric elements in the suspension) for finer correction, and some designs split the arm into two independently moving actuators to raise throughput.

Spindle motor

The platters spin on a brushless DC motor built into the base, typically at 5400 or 7200 revolutions per minute in desktop and NAS drives and up to 10,000 or 15,000 in older enterprise performance drives. Modern motors use fluid dynamic bearings, where a thin film of oil carries the load, which is quieter and longer lived than ball bearings. The motor also has permanent magnets, again usually rare earth.

The sealed enclosure

The base and cover form the head disk assembly. Air filled drives are not airtight: they have a breather hole with a filter so pressure can equalise with altitude, and a recirculation filter inside to catch particles. Helium filled drives are hermetically sealed, usually with a laser welded cover, because helium leaks through ordinary gaskets.

Controller board

The printed circuit board on the outside carries a system on chip with one or more processor cores, a read channel that turns analogue head signals into bits using signal processing and error correction, DRAM used as cache and for firmware data, a motor controller that drives both the spindle and the voice coil, and the interface (SATA or SAS). Inside the enclosure, near the heads, sits a preamplifier chip that boosts the tiny read signal and supplies write current. Some firmware and per drive calibration data live in flash on the board; much of the firmware is stored in reserved "system" areas on the platters themselves.

How are platters made?

Platter making is materials science and vacuum engineering, done at very high volume.

Substrate: aluminium or glass

Most 3.5 inch platters start as aluminium magnesium alloy blanks. The blanks are machined to size, then electroless plated with a hard nickel phosphorus layer, because bare aluminium is too soft to polish to the required finish. The plated disks are polished in several stages with progressively finer slurries until surface roughness is measured in fractions of a nanometre. Glass and glass ceramic substrates are used in most 2.5 inch drives and in some high capacity 3.5 inch drives. Glass is stiffer and can be made thinner, which helps fit more platters in the same height, and it tolerates the higher temperatures some media processes need. HAMR media in particular needs a substrate that survives high temperature deposition, which is one reason glass shows up in that generation.

Sputtered magnetic layers

The polished substrate goes into a sputtering line, a chain of vacuum chambers in which argon ions knock atoms off target plates and deposit them onto both sides of the disk at once. A typical perpendicular recording stack, from the bottom up, looks like this:

1. An adhesion layer so everything sticks.
2. A soft magnetic underlayer, which acts like a return path for the writer's field and makes the field at the recording layer stronger and sharper.
3. Seed and intermediate layers, often ruthenium based, that set the crystal orientation and size of the grains that grow above them.
4. The recording layer: a cobalt chromium platinum alloy mixed with oxides so that it forms tiny magnetic grains separated by non magnetic boundaries. Each bit covers a cluster of grains.
5. A capping layer that evens out switching behaviour across grains.

HAMR media swaps the recording layer for an iron platinum alloy with far higher magnetic anisotropy, which holds its magnetisation at much smaller grain sizes but needs heat to write.

Carbon overcoat and lubricant

A hard carbon overcoat, a few nanometres thick, protects the magnetic layers from corrosion and from the occasional head touch. On top goes a liquid lubricant, a perfluoropolyether a molecule or two thick, applied by dipping or vapour. The lubricant matters more than its thickness suggests: it lets the head survive brief contact and it has to stay put at thousands of rpm and, in HAMR drives, survive local laser heating.

Glide and certification

Every finished platter is checked by flying a glide head lower than a real head would fly; any bump that touches it is a reject. A certifier then writes and reads test patterns across the surface to find defects. Platters that pass go to the drive plant, often packed in sealed cassettes. Much of the equipment and materials side of this industry meets through IDEMA, the International Disk Drive Equipment and Materials Association, which keeps a document library for its members; the process recipes themselves stay with each maker.

How are heads made on wafers?

Read/write heads are the most chip like part of a hard drive. They are built on round wafers of alumina titanium carbide (often written AlTiC), a hard ceramic chosen because it can be lapped and machined precisely and wears well. On that wafer, a sequence of thin film steps builds the writer coil and poles and the reader stack: sputtering and ion beam deposition, photolithography to pattern the shapes, ion milling and reactive etching to cut them, and electroplating for the thicker magnetic poles and copper coils. A single wafer carries tens of thousands of head structures.

The wafer is then cut into rows, called bars. Each bar is lapped, ground very finely, while the resistance of embedded sensors is monitored, so that the final height of the reader element (the stripe height) and the shape of the writer's pole tip come out right. Next the air bearing surface pattern is etched into the bar, a protective overcoat is added, and the bar is diced into individual sliders. Each slider is bonded to a gimbal at the tip of a suspension, wired to a flex circuit, and tested. A set of these head gimbal assemblies plus the arm and coil becomes the head stack assembly.

From GMR to TMR read heads

Reading bits means sensing a tiny magnetic field and turning it into a signal. Early heads used induction; later ones used anisotropic magnetoresistance. The big step was giant magnetoresistance. In its 2007 Nobel press release, the Royal Swedish Academy of Sciences explains that Fert and Grünberg independently discovered GMR in 1988, that very weak magnetic changes produce large changes in electrical resistance in a GMR system, and that the first GMR read head launched in 1997 and soon became the standard technology. The Academy credits GMR with making it possible to shrink hard disks so radically.

A GMR sensor is a sandwich of ferromagnetic layers separated by a thin non magnetic metal. One layer's magnetisation is pinned; the other, the free layer, turns with the field from the disk. When the two are aligned, electrons pass more easily; when they are opposed, resistance rises.

Tunnel magnetoresistance (TMR) heads replace the metal spacer with an insulating barrier, usually magnesium oxide, only about a nanometre thick. Electrons tunnel through it, and the tunnelling probability depends strongly on the relative orientation of the two magnetic layers, which gives a larger change in resistance and a stronger signal from a smaller sensor. Current is passed perpendicular to the layers rather than along them. TMR readers are now the norm in hard drives, and the same magnetic tunnel junction idea is the basis of MRAM memory.

Perpendicular recording

Until the mid 2000s, drives used longitudinal recording, with each bit's magnetisation lying flat along the track. As bits shrank, the grains got so small that thermal energy could flip them spontaneously, the superparamagnetic limit. Perpendicular magnetic recording (PMR) stands the magnetisation on end, pointing into or out of the disk. That allows thicker grains for a given footprint, and the soft underlayer lets the writer's single pole produce a stronger field. Perpendicular recording, often shortened to CMR (conventional magnetic recording) when contrasted with SMR, is the base on which every current recording method builds.

What are SMR, CMR, helium, HAMR and MAMR?

These names describe different ways to put more terabytes into the same 3.5 inch box. Some change the recording physics, one changes the gas inside, and one changes the track layout and with it how rewriting behaves.

CMR and SMR

In conventional recording, tracks sit side by side with small guard bands, and any sector can be rewritten in place. The Zoned Storage documentation, maintained by the community around the Linux zoned block ecosystem, explains that shingled magnetic recording removes those gaps by writing tracks so that each new track partly overlaps the previous one, like roof shingles. The SMR writer is deliberately wider than a final track, which gives a stronger field for high coercivity media, and the reader only needs the narrow strip that remains uncovered.

The catch is in the rewrite. Because a sector can sit under a later shingle, the same documentation notes that changing it requires rewriting the shingles above it, so SMR drives group tracks into zones that must be written sequentially, while reads stay fully random. There are three ways to deal with that:

• Drive managed SMR hides the constraint. The drive accepts random writes, stages them in a cache region and later rewrites zones in the background. The Zoned Storage docs say these drives need no host changes, but that their performance depends on the firmware and on the workload. Sustained random writes or a long RAID rebuild can overwhelm the cache and stall the drive.
• Host aware SMR exposes zones but still accepts random writes, so software can optimise if it wants to.
• Host managed SMR exposes zones and rejects writes that do not follow the sequential rule. Only software built for zones (zoned file systems, device mapper targets, object stores) can use it.

The host aware and host managed models are standards: INCITS T10 defines Zoned Block Commands (ZBC) for SCSI and SAS drives, and INCITS T13 defines the Zoned ATA Command set (ZAC) for SATA. The Zoned Storage docs note that no standard exists for drive managed behaviour, which is entirely up to the firmware. The Linux kernel supports zoned devices natively; the kernel's zonefs documentation describes a simple file system that exposes each zone of a zoned device as a file.

For a NAS or RAID array, the practical lesson is to know which kind of drive you have before you buy, because a drive managed SMR disk can behave very differently from a CMR disk during a rebuild. Our home NAS guide covers rebuilds and resilvering.

Helium filled drives

Air is dense enough to create drag and turbulence at 7200 rpm, which costs power and buffets the heads and the thin platters. Helium is about one seventh the density of air, so a sealed helium drive needs less power to spin, runs cooler, and lets designers use thinner platters packed closer together, which is how many current 3.5 inch drives fit eight, nine, ten or more platters into the standard height. The cost is the seal: helium escapes through ordinary gaskets, so these drives use a hermetically welded cover and often report a helium level attribute in SMART.

HAMR

Heat assisted magnetic recording uses media whose grains are so magnetically stable that no practical write head could flip them at room temperature. A small laser on the slider, focused through a near field transducer to a spot smaller than the wavelength of light, heats a tiny area of the disk for well under a nanosecond, the writer flips it while it is hot, and it cools in place. That allows smaller stable grains and so more bits per square inch. The engineering hurdles include the transducer surviving the heat, lubricant that tolerates it and glass substrates for the media.

MAMR and energy assisted PMR

Microwave assisted magnetic recording adds a spin torque oscillator in the write gap that produces a high frequency field, helping grains switch under a weaker main field. Related "energy assisted" designs push a bias current through the write pole to sharpen the field. Both aim to extend perpendicular recording without the heat of HAMR. Makers use different names and implement different parts of the idea, so read each maker's own technical page rather than assume two drives labelled with similar words work the same way.

Comparison: recording approaches

Why is hard drive assembly done in clean rooms?

Because the head flies a few nanometres above the platter, a single smoke particle or skin flake is a boulder by comparison. A particle trapped between head and disk can scratch the media, damage the head, or start a chain of debris that ends in a head crash. Assembly of the head disk assembly therefore happens in clean rooms, typically ISO class 5 (traditionally "class 100") or better at the point of assembly, with operators in full suits, filtered laminar airflow and automation wherever possible. Parts are washed, dried and kept in sealed carriers until they are used. Outgassing matters too: adhesives, labels and plastics inside the enclosure are chosen so they do not release vapours that condense on the disk.

How servo patterns are written

A hard drive does not know where its tracks are by mechanical measurement. It reads position information, the servo pattern, embedded in wedges spaced around every surface. Each servo wedge carries a preamble, a track identifier and fine position bursts that tell the controller how far off track centre the head is. The firmware samples these wedges thousands of times per revolution and corrects the voice coil current to keep the head centred.

Writing those patterns has been a manufacturing step for as long as drives have had embedded servo. In the classic method, a servo track writer in the clean room holds the head stack with a precise external positioner and writes the patterns while the drive is open. As tracks narrowed and capacities grew, this became a bottleneck, so makers moved to self servo writing, where a seed pattern is written (sometimes on a single surface, sometimes printed or written to blank platters before assembly) and the drive's own firmware then propagates servo patterns across every surface, track by track. Each maker uses its own mix, and none publishes the full process, so treat any description of a specific line as a simplification.

Calibration and burn in

After servo writing, every drive goes through a long internal test that can last many hours or days in heated racks. During it, the firmware:

• tunes the read channel and the head's heater settings for each head and each zone;
• measures how well each head writes and reads and adjusts the zone layout, which is why two drives of the same model can have slightly different internal layouts;
• scans the full surface for defects and records them in the primary defect list so that those sectors are never used;
• checks the motor and actuator under temperature.

Drives that fail are reworked or scrapped. Those that pass go to final test, where the interface, capacity, security features and firmware revision are checked and the serial number is recorded.

What firmware runs on a hard drive?

A hard drive is a small computer. Its firmware runs on the controller system on chip and does several distinct jobs.

Servo control

The servo loop reads position from the servo wedges and drives the voice coil and any micro actuators. It handles seeks (moving between tracks as quickly as possible without overshoot), track following (staying centred despite vibration and platter runout) and parking the heads on the ramp when power is lost, using the energy left in the spinning platters.

Defect management

Every drive ships with defects. The primary defect list (P list) holds those found in the factory; sectors on it are skipped and the logical block numbering slides past them. The grown defect list (G list) holds sectors that fail later; the firmware remaps them to spare sectors. The host sees a clean range of logical block addresses either way. SMART attributes such as the reallocated sector count and the pending sector count show how often this happens, and a rising count is one of the clearest signs a drive is failing.

SMART

Self Monitoring, Analysis and Reporting Technology is defined for ATA drives in the T13 ATA Command Set standards and has equivalent log pages in the SCSI world defined by T10. It records attributes (temperature, power on hours, reallocated sectors, seek errors and many vendor specific counters), runs short and extended self tests on request and keeps an error log. The smartmontools project's smartctl and smartd read all of this on Linux, BSD, macOS and Windows.

Caching and power management

Firmware manages the DRAM cache, reorders queued commands to reduce head movement (native command queuing on SATA, tagged queuing on SAS), handles write cache flushes and spins the drive down when idle if told to.

Encryption on self-encrypting drives

Self-encrypting drives (SEDs) encrypt every sector with a media encryption key held by the controller. The host never sees that key; it unlocks access with a password or a key wrapped by its own. The Trusted Computing Group publishes the Opal Security Subsystem Class for client drives and the Enterprise SSC for data centre drives, which define how ranges, locking and authentication work. Changing the media encryption key makes old data unreadable in seconds, which is the basis of cryptographic erase. Our SSD post covers published research on weak SED implementations; the same rule applies to hard drives, which is that you should only rely on drive encryption when you trust the specific firmware.

ATA drives also have an older ATA Security feature set, with user and master passwords and the SECURITY ERASE UNIT command, and newer drives add the Sanitize feature set with block erase, overwrite and crypto scramble options, defined in the T13 ATA Command Set.

How firmware updates are delivered

Hard drive firmware is delivered as a binary image from the drive maker or from the server or NAS vendor who resells the drive. It is sent to the drive with the ATA DOWNLOAD MICROCODE command on SATA or the SCSI WRITE BUFFER command on SAS. On Linux, hdparm has a --fwdownload option that sends the file with DOWNLOAD MICROCODE, either whole or in segments if the drive supports it, and the hdparm manual warns that the option is extremely dangerous and could destroy both the drive and its data. Most people use the drive maker's own update tool, a server's management controller, or a NAS operating system update instead.

Three things to know about drive firmware updates:

1. They fix real defects in a program that controls every write, so read the release notes on your maker's support page for your exact model and firmware version before and after you update.
2. Updates are model and sometimes OEM specific. A firmware image for a server vendor's variant of a drive will not install on the retail version, and vice versa.
3. Not every drive verifies a signature on new firmware. Enterprise drives increasingly do; consumer drive behaviour varies and is often not documented. Record the firmware version you run, as you would any other software version.

HDD vs SSD: cost, endurance and erase methods

The figures in the first rows change every year, so we have kept them qualitative; check current price lists and the maker's datasheet for the drive in front of you.

Step by step: health, firmware and erase support on Linux

The commands below run on any recent Linux distribution with smartmontools, hdparm and, for self-encrypting drives, sedutil installed. Read only commands come first. Destructive commands come last, each with a warning and a device check.

1. Install the tools

# Debian and Ubuntu
sudo apt install smartmontools hdparm sg3-utils

# Fedora and RHEL family
sudo dnf install smartmontools hdparm sg3_utils

sedutil is distributed by the Drive Trust Alliance project as source and release binaries; check your distribution first, and if you build it, record the version.

2. Find the right device and record its identity

Device names like /dev/sda can change between boots. Always identify a drive by model and serial, and use the stable path under /dev/disk/by-id/ in scripts.

lsblk -o NAME,SIZE,MODEL,SERIAL,ROTA,TRAN,MOUNTPOINTS
ls -l /dev/disk/by-id/ | grep -v part

ROTA is 1 for a rotating drive and 0 for flash. TRAN shows the transport, such as sata, sas or usb.

3. Read identity, firmware version and SMART health

sudo smartctl -i /dev/sdX        # model, serial, firmware version, capacity, rotation rate
sudo smartctl -H /dev/sdX        # overall health self assessment
sudo smartctl -A /dev/sdX        # attribute table
sudo smartctl -x /dev/sdX        # everything: logs, temperatures, device statistics

The smartctl manual says -i prints the model, serial number, firmware version and ATA standard version, and -x prints all SMART and non SMART information. The Firmware Version: line is the value to record in your inventory and to compare with the maker's support page; on ATA drives the output usually also carries a Rotation Rate: line that confirms you have a spinning drive. On a SATA drive, the attribute table shows reallocated, pending and offline uncorrectable sector counts; on SAS drives, smartctl -x shows the grown defect list size and error counter logs instead.

4. Run a self test

sudo smartctl -t short /dev/sdX
sudo smartctl -t long /dev/sdX     # can take many hours on a large drive
sudo smartctl -l selftest /dev/sdX # read the results when it finishes

5. Check whether the drive is SMR or zoned

cat /sys/block/sdX/queue/zoned     # none, host-aware or host-managed
lsblk -z                           # zone model column for every disk

A drive managed SMR disk reports none here, because it hides its zones. To find out if a drive is drive managed SMR, check the maker's datasheet for that model number.

6. Check security and erase support

sudo hdparm -I /dev/sdX | sed -n '/Security:/,/^$/p'
sudo smartctl -g security /dev/sdX

hdparm -I asks the drive for its identification data and prints it in an expanded format; on ATA drives its Security section shows whether the ATA Security feature set is supported, enabled, locked or frozen, and the drive's own estimate of how long a security erase takes. The feature list in the same output shows whether the drive reports sanitize support. smartctl -g security reads the same ATA security state; the smartctl manual lists security among the settings -g can get. If the drive shows as "frozen", the BIOS locked it at boot; a suspend and resume cycle or a hot plug usually clears that, but follow your platform's guidance.

For a self-encrypting drive:

sudo sedutil-cli --scan
sudo sedutil-cli --query /dev/sdX

The scan shows which drives report TCG Opal support.

7. Before any erase: the device path check

Every command from here on destroys all data on the target. Run this check before each one, and stop if anything does not match.

DEV=/dev/disk/by-id/ata-MODEL_SERIAL   # the stable path you recorded in step 2
EXPECTED_SERIAL="WD-XXXXXXXX"          # the serial printed on the drive label

readlink -f "$DEV"
sudo smartctl -i "$DEV" | grep -i 'serial number'
lsblk -o NAME,SERIAL,MOUNTPOINTS "$(readlink -f "$DEV")"
findmnt -S "$(readlink -f "$DEV")" || echo "not mounted"

Confirm that the serial matches the label, that nothing on the drive is mounted, that it is not part of an active RAID or ZFS pool, and that you have a tested backup of anything you need.

8. Erase with a sanitize command (preferred where supported)

Warning: this permanently erases the whole drive. Repeat the device path check in step 7 first.

# SATA or SAS drive; on SATA the Linux SCSI to ATA translation layer passes it on
sudo sg_sanitize --overwrite --zero "$DEV"
# or, on a self-encrypting drive that supports it:
sudo sg_sanitize --crypto "$DEV"
# monitor progress from another terminal
sudo sg_requests --num=9999 --progress "$DEV"

sg_sanitize comes from sg3_utils and sends the SCSI SANITIZE command. Its manual says the command first appeared in the SBC-3 revision 27 draft, that it is closely related to the ATA SANITIZE command, and that the SCSI to ATA Translation standard (from the SAT-3 revision 4 draft) maps one to the other, so on a SATA disk the overwrite pattern must be 4 bytes long, which --zero satisfies. The tool gives you 15 seconds to change your mind unless you pass --quick, so do not pass it. The manual also notes that a sanitize operation continues after power is restored until it is complete. An overwrite of a large hard drive takes many hours.

Some builds of hdparm also offer ATA sanitize options, but the Debian hdparm manual page we checked does not document them, so check hdparm --help on your own system before relying on them.

9. Erase with ATA Security Erase (drives without sanitize)

Warning: this permanently erases the whole drive and can leave it locked if interrupted. Repeat the device path check in step 7 first.

sudo hdparm --user-master u --security-set-pass p "$DEV"
sudo hdparm --user-master u --security-erase p "$DEV"
sudo hdparm -I "$DEV" | sed -n '/Security:/,/^$/p'   # confirm "not enabled"

Do not run this through a USB bridge; many bridges mangle ATA pass through. Connect the drive directly to a SATA port.

10. Self-encrypting drives: PSID revert

Warning: a PSID revert destroys all data by generating a new media key. Repeat the device path check in step 7 first.

sudo sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID PSID_FROM_LABEL "$DEV"

The sedutil command reference says this resets the drive to factory defaults using the 32 byte PSID printed on the drive label, and that if the locking SP is active it erases all data. It is the recovery path when the password is lost, and in effect a cryptographic erase.

11. Verify and record

After any erase, read back a sample of sectors to confirm they are zeros or random, record the model, serial, firmware version, method, date and operator, and keep that record with your asset register. NIST SP 800-88 Revision 2 asks organisations to build a sanitization program with proper techniques and controls, and a record you can show an auditor is part of that.

How should you plan secure disposal of hard drives?

NIST SP 800-88 Revision 2, published in September 2025 and superseding Revision 1 from 17 December 2014, defines three methods. Clear applies logical techniques to all user addressable storage locations, through the normal host interface, to protect against simple, non invasive recovery. Purge applies physical or logical techniques that make recovery infeasible with state of the art laboratory techniques while leaving the media potentially reusable; NIST says to prefer purge over clear when possible and to consult IEEE 2883 for acceptable purge techniques, which can include overwrite, block erase and cryptographic erase using dedicated, standardised sanitize commands. Destroy makes recovery infeasible and leaves the media unable to store data again. Revision 2 keeps device specific techniques, other than cryptographic erase, out of its own scope and defers to IEEE 2883 for them.

For hard drives the practical choices are:

• Reusing a drive inside your organisation: clear or purge, verify, record.
• Selling, donating or returning a leased drive: purge with sanitize or crypto erase, verify, record.
• Drives that fail, cannot be verified or held very sensitive data: destroy, with a certificate of destruction that lists serial numbers.

Degaussing exposes the drive to a strong magnetic field. NIST SP 800-88 Revision 2 says physical purge techniques historically included degaussing for magnetic hard drives, that degaussing should not be used on flash, and that it has become more complicated as storage has moved to hybrids of magnetic and non magnetic storage and to new magnetic recording variants. There is also a practical consequence: a field strong enough to erase the data also erases the factory written servo patterns, so the drive cannot be reused. Plan degaussing as part of a destroy process and confirm with your degausser's maker that it is rated for the coercivity of the drives you feed it.

Common mistakes

• Erasing the wrong drive. Device names change between boots. Use /dev/disk/by-id/ paths and match the serial before every destructive command.
• Assuming a quick format erases data. A file system format writes new metadata and leaves almost everything else in place.
• Running ATA commands through a USB enclosure. Many bridges do not pass security or sanitize commands correctly, and a failed security erase can leave a drive locked.
• Buying drive managed SMR for a RAID array without checking. Rebuilds can slow sharply or time out. Check the datasheet.
• Treating SMART "PASSED" as proof of health. The overall flag trips late. Watch reallocated, pending and uncorrectable counts and run long self tests.
• Not recording firmware versions. When a maker publishes a firmware fix, you need to know which drives run the affected version.
• Mixing OEM and retail firmware images. Use the image from the vendor that supplied that exact drive.
• Opening a drive to "fix" it. Without a clean room the platters are contaminated immediately. Send it to a recovery service or destroy it.
• Degaussing and then reselling. A degaussed modern drive is scrap; plan it as destruction.
• Trusting drive encryption blindly. Use it, but know whether the firmware's implementation has been assessed, and consider software encryption on top for sensitive data.

FAQ

What is a hard drive platter made of?

Most 3.5 inch platters are aluminium magnesium alloy plated with nickel phosphorus; most 2.5 inch platters and some high capacity drives use glass or glass ceramic. On top go sputtered magnetic layers, a carbon overcoat and a thin lubricant.

How close does a hard drive head fly to the disk?

A few nanometres, closer than the wavelength of visible light. A heater in the head adjusts the gap during reads and writes, which is why dust or a fingerprint inside a drive is fatal.

Why are some hard drives filled with helium?

Helium is far less dense than air, so the platters create less drag and turbulence. That lowers power and heat and lets makers use thinner platters packed closer, which raises capacity. The drive must be hermetically sealed.

What is the difference between CMR and SMR hard drives?

CMR drives write tracks side by side and can rewrite any sector in place. SMR drives overlap tracks like roof shingles for more density, so rewriting data can mean rewriting a whole zone, which slows sustained random writes.

What is HAMR on a hard drive?

Heat assisted magnetic recording. A tiny laser on the head heats a spot on the disk for a fraction of a nanosecond so very stable magnetic grains can be written, which lets bits be packed more densely.

How do I check a hard drive's firmware version on Linux?

Run sudo smartctl -i /dev/sdX and read the "Firmware Version" line, or sudo hdparm -I /dev/sdX and read "Firmware Revision". Compare it with the maker's support page for your exact model.

Can you securely erase a hard drive with a firmware command?

Yes, if the drive supports it. A sanitize command (ATA or SCSI), ATA Security Erase, and a cryptographic erase on self-encrypting drives all run inside the drive and reach sectors the host cannot address. Verify the result and record it.

Does degaussing work on modern hard drives?

NIST notes it was historically a purge technique for hard drives but has become more complicated as recording technology changed. It also erases the servo patterns, so the drive cannot be used again. Treat it as part of destruction, and confirm the degausser is rated for your drives.

How long do hard drives last?

It depends on workload, temperature, vibration and model. Watch SMART counters rather than relying on age, and plan replacement with backups in place.

Are hard drives still made for new systems?

Yes. Hard drives remain the lower cost per terabyte option for bulk and archive storage, and makers continue to raise capacity with helium, SMR, HAMR and energy assisted recording.

Where Safeguard fits, honestly

Safeguard does not make, test or analyse hard drives. It does not scan drive firmware, verify firmware signatures, generate a hardware bill of materials, manage devices or erase media, and its models are single-purpose security models for software. The fit is narrower: the software around storage is ordinary software. Inventory agents that collect smartctl output, health dashboards, disposal trackers, NAS operating systems you build, and the smartmontools, hdparm, sg3_utils and sedutil packages inside your images all carry open source components. Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects carry a given component and version, and can open fix pull requests when a fixed version exists, with autonomous remediation switched off by default.

Every time a server, NAS or laptop image is rebuilt, it pulls storage tools, update clients and their libraries again, and those open source components can carry known vulnerabilities of their own. The fit is indirect, because Safeguard does not touch drive hardware or firmware, but the tooling you build to monitor and retire drives is part of your software supply chain like everything else.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval and pushes nothing. The same flow fits a drive inventory service or a SMART health dashboard your team maintains.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits teams who build NAS or server images, with smartmontools and sg3_utils included, on their own hardware.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. An on call engineer can approve a fix in a fleet tooling repository without anything running unattended.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Nobel Prize, Press release: The Nobel Prize in Physics 2007 (giant magnetoresistance)
• Nobel Prize, Scientific background: The Discovery of Giant Magnetoresistance (2007)
• IBM, RAMAC: the first hard disk drive (IBM history)
• NIST CSRC, SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025)
• NIST, SP 800-88 Rev. 2 full text (PDF)
• INCITS Technical Committee T13, AT Attachment
• INCITS Technical Committee T10, SCSI storage interfaces
• T10, Draft standards and technical reports (SBC, SPC)
• Zoned Storage, Shingled Magnetic Recording Hard Disks
• Linux kernel documentation, ZoneFS: Zone filesystem for zoned block devices
• Linux kernel documentation, Zoned Loop Block Device
• smartmontools project, smartctl manual page source
• hdparm(8) manual page, man7.org
• Debian manpages, hdparm(8) (trixie)
• Debian manpages, sg_sanitize(8) from sg3-utils
• Debian manpages, lsblk(8) from util-linux
• Drive Trust Alliance, sedutil Command Syntax
• IDEMA, International Disk Drive Equipment and Materials Association

Last reviewed: 23 October 2026.