Rotate IoT Device Identity Without a Factory Password

Rotate IoT Device Identity Without a Factory Password

A surprising number of plant-floor devices still authenticate with a password baked into the factory image. The password is the same on every unit. It is in the installer PDF. It has not changed since commissioning.

That is not a secret. It is a shared default with extra steps. Rotation has to work when the device is offline, when the plant network is not yours, and when a technician has ten minutes on site.

Long-lived factory credentials do not become safer with age

Teams delay rotation because a missed update bricks a line. The longer they wait, the larger the blast radius. A single leaked image gives an attacker the same credential as the rest of the fleet.

We treat factory credentials as bootstrap only. They are allowed for the first join to the gateway. They are invalid after the device receives its own identity. If a device is still using the factory secret after 72 hours on the network, it is a defect, not a configuration choice.

Provisioning identity is a one-time ceremony

Two workable patterns.

The first is a per-device key generated at the factory and listed in a sealed manifest. The gateway admits the device once, then issues a short-lived token and a device certificate. The factory key is marked used.

The second is a one-time join code the technician types at install. The code expires in 24 hours and is bound to a serial number. After join, the device stores a unique credential. The join code is dead.

We prefer the join code on brownfield fleets where the factory will not change their image. We prefer the sealed manifest when we control the build. Mixing both on the same product line creates two sources of truth and a third support queue.

Rotation has to survive an air gap

Plant networks drop. A rotation scheme that requires a round trip to a cloud CA every 12 hours will fail closed at 2 a.m. and look like a sensor outage.

We rotate on a 30-day certificate lifetime with a 7-day overlap. The gateway can issue the next certificate while the current one is still valid. If the device has been offline for more than 21 days, it must repeat the join ceremony. That is inconvenient. It is better than accepting a year-old cert because "the line was down."

Token lifetimes stay shorter: 72 hours, refreshed by the gateway. The gateway is the only component that talks to the plant identity service. Devices never hold a cloud API key.

A failure mode with cloned images

One rollout cloned a "golden" SD card across a batch of gateways. Every gateway presented the same device identity. Rotation appeared to work. The server saw one device with a lot of IP addresses.

The mitigation is a hardware serial bound into the first join. The identity service rejects a second join for the same serial from a different board identifier. Cloning then fails at provision time, not three months later in an audit.

Ownership during rotation

Someone owns the join manifest. Someone owns the gateway that signs device certs. Someone owns the exception list for devices that cannot rotate yet. Those are three roles. When they collapse into "the integrator," exceptions become permanent.

We review the exception list monthly. Any device still on a factory password after 30 days is either scheduled for a site visit or removed from the trusted set.

Final takeaway

Use the factory password once, to join. After that the device has its own identity, a 30-day cert, and a path to rotate while it is still online.