Problem

Reports of nodes occasionally generating a new NodeNum, beyond the expected one-time NodeNum assignment during initial PKI key generation.

Root cause

A node's NodeNum is a pure function of its PKI public key:

my_node_num == crc32(config.security.public_key)

createNewIdentity() already no-ops when the derived number is unchanged, and the public key is recomputed deterministically from the private key on every boot. So the NodeNum changes only when the keypair is regenerated, which happens only when a keygen path runs while config.security.private_key.size != 32. An unexpected NodeNum change therefore means the private key went missing at the moment a keygen path ran. Two paths could do that without the user intending a new identity:

1. Boot: a corrupt/transient config read wiped the keypair

loadFromDisk() collapsed every non-success loadProto() result for the config file into installDefaultConfig() (preserveKey=false), which memset()s config and destroys the private key → fresh keypair → new NodeNum.

But loadProto() returns distinct codes:

• DECODE_FAILED — file present but couldn't be decoded/decrypted this boot (flash bit-rot, torn write, transient decrypt failure)
• OTHER_FAILURE — file genuinely absent (true first boot)

Treating a transient/corrupt read identically to "no config at all" silently minted a brand-new identity. (loadProto() also zeroes the destination before the failed decode, so the key is already gone from RAM — nothing could preserve it after the fact.)

2. AdminModule security SET clobbered the keypair

config.security = c.payload_variant.security; wholesale-replaced the keypair, then regenerated whenever the incoming private_key.size != 32. A client that edits an unrelated security field (managed mode, admin keys, serial console, …) without round-tripping the private key would silently re-mint identity.

Fix

Boot (NodeDB.cpp): a new configDecodeFailed flag, set on DECODE_FAILED, gates the boot keygen and the boot config-save directly (not via region — robust against the userprefs/region overrides that run later in loadFromDisk()). On a decode failure the node:

• freezes its identity (no keygen → NodeNum unchanged, recovered from the separately-stored devicestate);
• leaves the unreadable config file untouched, so a transient failure self-heals on the next clean boot instead of being overwritten with defaults;
• boots radio-silent (region UNSET, TX off) until a good config is read back.

A genuinely-absent config (OTHER_FAILURE) still gets defaults + keygen as before.

AdminModule: when a security SET omits the private key but we already hold a valid one, the existing keypair is preserved and only the other security fields are applied. First provisioning and key import are unchanged; intentional reset goes through factory_reset.

Review

These changes went through an adversarial multi-lens review; findings addressed:

• [HIGH] USERPREFS_CONFIG_LORA_REGION re-set region after the degraded branch, defeating a region-based keygen guard → switched to gating keygen directly via the flag (no dependence on region surviving).
• [MEDIUM] the end-of-init saveToDisk could persist the degraded UNSET defaults over a transiently-unreadable file → boot config-save is now suppressed on a degraded boot.
• [LOW] PKI-excluded builds still clobbered the stored key → key-preserve moved out of the PKI #if.

Known limitation (follow-up)

If a config is permanently corrupt (not transient), recovering the node by setting the region still routes through ensurePkiKeys() and mints a new keypair → new NodeNum. This is inherent to genuine private-key loss and is now gated behind an explicit user action rather than happening silently on boot. The durable fix is to persist the PKI private key in its own small, atomically-written file independent of the LocalConfig blob; tracked separately.

Testing

• Native PlatformIO unit suite (Docker, CI parity): 499/499 test cases pass.

Local verification: native PlatformIO suite (Docker, CI parity) — 499/499 test cases pass.