A device onboarding that's discovered fresh each time should be a written procedure, not improvisation.
Deep-dive
- Needed to put a handheld scanner on a heavily restricted factory network that ran default-deny, so an unknown device got no access.
- On first connection the scanner couldn't reach the upstream server.
- Several independent access-control layers each had to be cleared before the device could associate and reach the server.
- Each gate was invisible until the one before it was cleared, so they were found one at a time, not all at once.
- Root cause was process, not tech: there was no written onboarding procedure, so it was figured out fresh each time.
- It took most of a day; in the end the scanner reached the server and the work was done.
Code
# onboarding runbook for a default-deny network — run top to bottom 1. switch port: MAC allowlist 2. NAC / 802.1X: register the device cert 3. assign the device-class VLAN 4. firewall: device subnet -> app server:port 5. verify: reach the server, then the app handshake
Say it (English)
- ·I had to get a handheld scanner talking to equipment on a locked-down factory network.
- ·The network was default-deny, so the device got nothing at first and couldn't reach the server.
- ·There were several access-control layers stacked, and each one was invisible until I cleared the one before it.
- ·I worked through them one at a time and it ended up taking most of the day.
- ·The real problem was that onboarding a device here wasn't a written procedure, so every time it gets figured out from scratch.
Push it further
- Write the device onboarding as a step-by-step runbook covering every access-control layer, run top to bottom.
- Document each gate up front so they aren't discovered one at a time on the next device.
- Keep a checklist of what default-deny requires for a new device to associate and reach the server.