Every Raspberry Pi ships with a serial number burned into the chip at the factory. It is the closest thing a Pi has to a built-in, no-extra-hardware identity, which makes it handy when you are running a fleet of devices and need to tell them apart.
§2026 Update
This post is from 2017, written against the early Pi models. The original one-liner still works on every Pi I have tested, including the Pi 4 and Pi 5, so nothing below is broken. But the picture has filled out since then, and a few things are worth knowing before you lean on the serial for anything real.
There are three places to read it now. The classic source is /proc/cpuinfo, which is what the original post used and what almost every tutorial still shows.
cat /proc/cpuinfo | grep ^Serial | cut -d":" -f2
The second source is the device tree, exposed by the firmware. It returns the same value and avoids parsing the larger cpuinfo dump:
cat /sys/firmware/devicetree/base/serial-number
That path holds the full value with the leading zeros. If you only want the unique tail (the part that actually varies between boards), grab the last eight hex digits:
cat /sys/firmware/devicetree/base/serial-number | tail -c 9
The third source is the firmware tool vcgencmd, reading straight from the one-time-programmable (OTP) memory where the value lives:
# Pi 4 and earlier (BCM2711 and below): serial is OTP row 28
vcgencmd otp_dump | grep ^28:
# Pi 5 (BCM2712): the rows shifted, serial is row 31
vcgencmd otp_dump | grep ^31:
On the older chips, row 28 holds the serial, row 29 holds its bit-inverted copy as a tamper check, and row 30 holds the board revision. On the Pi 5’s BCM2712 the layout moved: serial is row 31, board revision is row 32. If you script otp_dump, do not hard-code the row across models.
The Pi 5 also carries a second, longer identity. It generates a 64-bit serial from the hardware random number generator on first boot and stores it in OTP, and it exposes a separate device unique ID that matches the 2D data-matrix code laser-etched onto the board:
cat /proc/device-tree/chosen/rpi-duid
If you need an identifier you can read off the physical board with a camera or a label scanner, the rpi-duid on a Pi 5 is the one that lines up with what is printed on the PCB.
One caveat I wish the original post had made clearer: the serial is an identifier, not a secret. It is readable by anything running on the Pi, and /proc/cpuinfo is just a text file that software can fake. There have also been field reports of duplicate serials on cloned or counterfeit boards, so “unique” holds in practice but is not a guarantee you should bet security on. Use it to tag and route devices. Do not use it, on its own, as the key that unlocks your data. More on that below.
Original article below. Everything from here down is the post as originally written. The 2026 Update above covers what’s changed since.
§Reading the Serial
Here is the original one-liner, which is still the fastest way to get the value on any Pi:
cat /proc/cpuinfo | grep ^Serial | cut -d":" -f2
Example output:
00000000e215b4a2
The value is sixteen hex digits. The leading zeros are padding; the lower eight digits (e215b4a2 above) are the part that actually identifies the board. That tail is what I store when I am keying off the serial.
§Using It as a Device Identifier
An interesting use is “binding” software, a license, or a configuration to a specific Pi. I lean on this when I deploy fleets of unattended IOT devices: each one reports its serial, and the central server uses that to decide which config and which media that device should pull. I first ran across the idea in a suggestion on the Stack Overflow question “Securing data on SD card Raspberry Pi”.
The trap, and the reason for the caveat above, is treating the serial as if it were a password. Encryption keyed only to a serial that any process on the device can read, and that an attacker holding the SD card can read off the chip directly, is not protecting much. If you want the serial to gate something sensitive, pair it with a real secret: enroll each device’s serial on the server, hand back a per-device token over TLS, and let that token do the actual unlocking. The serial tells you which device is asking. The token is what proves it should be answered.
For plain identification, fleet inventory, or routing, the serial is perfect and costs you nothing extra in hardware.