Cisco IOS Password Recovery: config-register 0x2142 Method

2026年9月6日 LOG admin

A lost enable password on a Cisco IOS router is recoverable - by design - as long as you have console and physical access. The trick is the configuration register: a 16-bit value in NVRAM that ROMMON reads at boot. Setting it to 0x2142 makes IOS boot while ignoring the startup configuration (and therefore its passwords); you then reload the original config into memory, set a new password, and restore the register. This guide walks the procedure and the three mistakes that turn a 10-minute recovery into a reconfiguration project.

Prerequisites and What You Actually Need

Before touching anything, confirm you have the three things the procedure depends on:

Physical console access. Password recovery is a deliberate bypass of the authentication layer, and it only works from the console port. Telnet, SSH, SNMP and RADIUS will all happily tell you that you are locked out. Cable, adapter and a terminal application with 9600/8/N/1 and no flow control.
The ability to interrupt the boot. The window between POST and IOS loading is short (roughly the first 30-60 seconds). You need either a real break key or a terminal program that can synthesise one — this is the step that fails most often.
Authority to do it. On a production router this is a change with an outage: the device is offline for the duration, and routing adjacencies will drop. Have the maintenance window approved and a colleague who knows the topology on standby.

It also helps to know what the recovery does not do: it does not reveal the old password. It boots the device with no configuration, giving you a shell on a blank router. The old startup configuration is still intact in NVRAM — your job is to load it back and then set a new credential. Engineers who forget that second half end up with a working router and no OSPF.

What the Configuration Register Controls

0x2102   normal boot: load IOS from flash, load startup-config (default)
0x2142   password recovery: boot but IGNORE startup-config in NVRAM
0x2120   boot into ROMMON instead of IOS

The register is 16 bits read by ROMMON before IOS starts, so it is the one piece of configuration that applies to a router that has not yet loaded a configuration. The four low-order bits set the boot source; the bit that distinguishes 0x2102 from 0x2142 controls whether the startup configuration in NVRAM is consumed. That single bit is the entire mechanism: it is not a password bypass bolted onto the authentication code, it is the boot loader being told to skip a file. Other values worth knowing are 0x2100 (boot to ROMMON) and 0x2101 (boot to the boot helper image), which are the correct starting points when IOS itself will not load — a different problem from a forgotten password. On IOS XE devices the same behavioural flags exist as the confreg value, but the boot process is driven by the bootloader and the register value is translated; the numbers still work.

Router Recovery Procedure

rommon 1 > confreg 0x2142          ! ignore startup-config on next boot
rommon 2 > reset

Step by step:

Connect to the console port (9600/8/N/1) and power-cycle the router.
Within the first 60 seconds of boot, send the break sequence (Putty: Special Command > Break; send it after POST, just before IOS finishes booting) to drop into rommon 1 >.
Set confreg 0x2142 and reboot with reset. Answer no to the setup dialog (or Ctrl-C).
The router now boots with an empty running-config - type enable and no password is requested.
Restore the original configuration WITHOUT overwriting it: copy startup-config running-config (never copy running-config startup-config at this stage - that would erase your saved config).
Change credentials and reset the register, then save and reload:

Router# configure terminal
Router(config)# enable secret NewStrongPassword!
Router(config)# config-register 0x2102
Router(config)# end
Router# copy running-config startup-config
Router# reload

Verify with show version | include register - it reports the live value plus the value that will apply at next reload.

Read the output carefully, because it shows two numbers and only one of them matters for the next reboot. "Configuration register is 0x2142 (will be 0x2102 at next reload)" is the healthy end state after step 6: the running value is still the recovery value, but the saved value is normal. If you see "0x2142 (will be 0x2142 at next reload)" you forgot the config-register line, and the router will come back blank the next time it loses power.

On IOS XE hardware where confreg is not offered by the bootloader, the equivalent recovery still uses the same idea but the register is set from the bootloader menu or, on some platforms, by clearing the startup configuration at the prompt. Confirm the platform's recovery doc before you start — the register semantics are stable, the exact key sequence is not.

Catalyst Switch Procedure (No config-register)

Switches do not use the config-register shortcut. Instead: power-cycle while holding the Mode button, then at the switch: prompt rename the config file:

switch: flash_init
switch: dir flash:
switch: rename flash:config.text flash:config.text.old
switch: boot
Switch> enable
Switch# rename flash:config.text.old flash:config.text
Switch# copy flash:config.text running-config
Switch(config)# enable secret NewStrongPassword!
Switch# write memory

The switch approach is a file-system operation rather than a register change, which is why it looks different: the boot takes place normally and simply cannot find the configuration. Renaming rather than deleting is the important detail in that sequence. The file is moved aside, not destroyed, so the original configuration is recoverable throughout. Step 2 of the IOS-side advice applies identically here — do not run write memory until copy flash:config.text running-config has completed, or you will write a nearly empty configuration over the file you just renamed back.

On stacked Catalyst platforms remember that the recovery affects the active switch only; once the stack is up again, confirm that the member numbering, the stack ports and any configured priority survived, since a blank running configuration makes no claim about which unit should be active.

The Three Classic Mistakes

Skipping copy startup-config running-config - you set a new password on a blank device and lose OSPF, interfaces, ACLs, everything (the old config is still safe in NVRAM - restore it).
Forgetting to reset 0x2142 back to 0x2102 - the device works now, but the next reboot skips startup-config again and the next engineer finds an unconfigured router.
Not saving - enable secret changes running-config only; without write memory the new password vanishes on reload.

All three share a root cause: treating the recovery as a password operation. It is a configuration-restoration operation that happens to end with a password change. Keep that framing and each of the three steps becomes obvious: load the old configuration, reset the boot flag, persist the result.

Verifying the Recovery Before You Walk Away

show version | include register — the "will be" value must be 0x2102.
show startup-config — the saved configuration is populated and contains the interfaces, routing protocol and ACLs you expect, not just the new password line.
show ip interface brief — every interface that should be up is up.
show ip route summary or the routing protocol's neighbour table — adjacencies have re-formed.
Reload once more, out of hours, and confirm the router comes back configured. A recovery that has never been tested by a reload is an assumption, not a fix.

Choosing the Right Credential Once You Are Back In

You are standing in front of a blank router with enable working and no password; this is the moment to fix the reason you are here.

Router(config)# enable secret Str0ng-Enab1e-Secret
Router(config)# no enable password
Router(config)# username netops privilege 15 secret Str0ng-User-Secret
Router(config)# aaa new-model
Router(config)# aaa authentication login default group tacacs+ local
Router(config)# line vty 0 4
Router(config-line)# login authentication default
Router(config-line)# transport input ssh

enable secret stores an MD5/SHA hash; the older enable password is stored reversibly and is trivially decoded by anyone who reads the configuration file. If both exist, IOS uses the secret — but leaving the password line in place hands an attacker the credential anyway, so remove it. The same logic applies to service password-encryption: it obfuscates plaintext passwords with a weak, publicly documented algorithm and creates a false sense of safety. The real fix is to stop storing passwords the router can reverse and to authenticate against AAA with a local fallback account.

When the Procedure Does Not Work

The break sequence does nothing. Usually the terminal program, not the router. Verify with another client (or a different USB-serial adapter), and remember that on some laptops the break key must be sent from the terminal menu rather than the keyboard.
You land in ROMMON but confreg is not offered. The platform uses a menu-driven bootloader (common on IOS XE hardware); use the bootloader's own recovery option, or set the register through the bootloader menu.
IOS never loads and you cannot break at all. That is a software-image or flash problem, not a password problem — boot the boot helper image and restore the image, the register value will not help.
The router boots but the interfaces stay down. The configuration was restored but the router is on the wrong interfaces or has lost its licensing state; re-read show startup-config against your expected baseline.
The switch will not enter the switch: prompt. On Catalyst, the Mode button must be held through the initial power-on self test, not pressed afterwards.

Each of these failures is diagnosable from the console, and none of them requires wiping the device. That is worth stating plainly, because the reflex response to a failed password recovery is often to escalate straight to a factory reset — the one action in this whole procedure that is genuinely destructive.

Security Implications

Password recovery is a designed feature: physical console access equals root access, which is exactly why wiring closets are locked and why no service password-recovery exists for high-security environments (it blocks the ROMMON bypass - but if you then lose the password, the only path is a full wipe, so keep offline config backups). The same "lost access" problem on Huawei gear uses the BootROM menu instead - see our 华为交换机 Console 密码恢复指南, and for Junos the access model is user/class-based from the start (Junos user accounts guide). If the router will not boot at all rather than merely being locked, that is a different failure - covered in our ASR 9000 boot-loop recovery article.

The right conclusion is not "recovery is dangerous" but "recovery is the fallback for a process failure". Two habits remove most of the risk: keep offline copies of every device configuration (the recovery becomes a restore rather than an archaeology exercise), and make authentication depend on something you cannot lose — TACACS+/RADIUS with a local fallback account stored in a password manager, rather than a shared enable password living in one engineer's memory.