People re-lock a bootloader for a few reasons: selling the phone, returning it under warranty, or passing a banking app's root check that also flags an unlocked bootloader. The command is short — fastboot flashing lock — but running it on a device that isn't back on a clean stock image first is the single most common cause of a bootloop that looks identical to a hard brick.
An unlocked bootloader skips signature verification on the boot, system, and vendor partitions, which is what lets fastboot flash a custom recovery, a patched boot image, or a full custom ROM in the first place. Locking flips that check back on: at every boot, the bootloader verifies the currently flashed images against the manufacturer's signing key (or, on AVB-based devices, against the vbmeta hash chain) before it will proceed. If anything currently flashed doesn't match a signed, expected image, the locked bootloader refuses to boot rather than silently allowing it.
This is the part people skip: locking does not restore stock partitions, it only re-enables the check against them. If you lock while a custom ROM, a patched boot.img, or a custom recovery is still flashed, the very next boot fails verification and the device drops into a bootloader error screen or an endless restart loop. Unlike an unlocked device, a locked one generally won't let you fastboot flash your way out either, since flashing itself is restricted once locked — on many devices only fastboot flashing unlock is still permitted, which wipes data and starts the cycle over.
vbmeta.img if you had previously flashed one with --disable-verity --disable-verification, since those flags leave persistent flags set that a plain lock won't clear on some devices.fastboot flashing lock, confirm on-device if prompted, and let it reboot.See the full guide to vbmeta and disable-verity flags if you flashed one of those during rooting — clearing it correctly before locking matters more than people expect.
Locking the bootloader does not reset a device's warranty/flash counter on brands that track one (Samsung's KNOX counter is the best known example). Once tripped, that counter is permanent regardless of subsequent lock state, and it can disable warranty coverage or certain security features like Samsung Pass or Knox-backed apps even after returning to a fully stock, locked configuration. If warranty status matters, check whether your specific brand tracks this before assuming a clean re-lock erases the history of having been unlocked.
Re-locking with matching stock firmware generally restores a clean hardware attestation result, since Play Integrity and similar checks read the verified boot state rather than a persistent "was ever unlocked" flag on most devices. There are exceptions: a handful of OEMs burn a one-time fuse when the bootloader is first unlocked, and no amount of re-locking clears a blown fuse. If integrity checks still fail after a clean stock lock, that's the likely explanation, and it isn't fixable by software.
A device stuck bootlooping after a premature lock is not necessarily gone. Most fastboot-capable devices still accept fastboot flashing unlock on a locked-but-bricked bootloader precisely so this situation is recoverable — it wipes data, but it gets you back to a state where you can flash a full stock image properly, boot successfully, and repeat the lock in the correct order. Devices that reach EDL or a manufacturer-specific emergency download mode when fastboot itself is inaccessible have one more recovery layer below that.
Background on verified boot: Android Verified Boot documentation.