Setting Up Role-Based Access for Your WISP NOC Team

It's the default starting point for almost every small WISP — one admin account, shared across the whole team. It works fine until something goes wrong at 2am and nobody can say who touched what, or until a tech who left six months ago still technically has the password.

• Admin — full control: user management, settings, device add/remove, everything. Keep this to the people actually responsible for the system, not everyone who happens to be senior.
• Operator — acknowledge alerts, run backups, run discovery, add devices. This is the right role for most on-call techs: enough to actually do the job during an incident, without the ability to change who has access.
• Viewer — read-only. Good for a manager who wants dashboard visibility, a junior tech still ramping up, or an external contractor who needs to see status without being able to change anything.

For most small-to-mid WISP teams: two admin accounts (never one — if the only admin leaves or locks themselves out, you want a second person who can fix it), operator accounts for everyone on the on-call rotation, and viewer accounts for anyone else who just needs visibility.

• Disable (don't just forget about) accounts for anyone who leaves the team.
• The last remaining admin account can't be disabled, demoted or deleted — a deliberate guard rail, not a bug, so you can't accidentally lock everyone out.
• Sessions end at logout or tab close by design — there's no “remember me forever” option, which is the right default for shared ops machines.

In the public demo, the login gate is exactly that — a gate, not a vault. It's enough to separate who-did-what during a demo session, but it isn't a production security boundary on its own. Real enforcement — PBKDF2 password hashing and server-issued tokens — lives in the exported auth.py, which only matters once you've deployed the self-hosted backend. Set up real accounts there before giving anyone outside your core team access.