Default Passwords, Shared Logins and the Accounts Nobody Owns

If I had to pick one security problem that's on nearly every older site I walk into, it wouldn't be an unpatched supervisor or a flat network. It would be the accounts. Factory passwords still on the controllers. One "admin" login everybody shares. Accounts for technicians who left years ago, at contractors who no longer have the contract.

It's the least glamorous part of BAS security and the easiest to fix, because it needs no new equipment and no network changes. It needs a list, a few hours and someone willing to own it.

Default credentials: the password in the manual

Most controllers, supervisors, routers, gateways and even network switches ship with a default username and password so you can log in the first time. Those defaults are published in installation manuals, and lists of them circulate freely. A device still on its factory password effectively has no password.

Where to look:

• Supervisors and front ends, both the BAS application login and the operating system login underneath it.
• Field controllers with a web interface or a configuration login. Many have one, and it's often never changed because the day-to-day work happens through the supervisor.
• IP-to-MS/TP routers and protocol gateways. These are the forgotten ones. They're configured once at install and then nobody logs in again for a decade.
• Network switches, wireless bridges and cellular routers installed by the BAS contractor rather than IT.
• Power meters, VFDs and plant controllers with Ethernet ports and web pages of their own.

Some newer products force a password change on first login, which helps. Many installed devices predate that. Assume every device is on its default until you've checked.

The shared admin account

The next problem is the one login everybody uses. It's usually called admin, or the contractor's name, or "operator". The facility manager knows it, the day engineers know it, every tech at the service contractor knows it, and it's on a sticky note inside the panel door.

A shared account causes three problems at once:

• No accountability. The audit log says "admin changed the AHU-3 schedule". Which admin? You can't tell, so you can't ask them why.
• No way to remove one person. When someone leaves, the only way to cut them off is to change the password for everyone, which nobody wants to do, so nobody does.
• Too much power for most users. The shared account is almost always the full administrator, because it has to do everything anyone might need.

It's the scenario in the "Everyone logs in as admin" exercise, and the fix is the same on every platform: named accounts.

Named accounts and roles

Every person who logs in gets their own account, tied to their name. Every account gets a role that matches what that person actually does. Most supervisors support something like this, even if the role names differ:

This is least privilege in practice: each person gets what their job needs and no more. The energy consultant pulling trends doesn't need to override a chiller. The operator adjusting a schedule doesn't need to create accounts.

The administrator role deserves special care. It should belong to the owner — a named person at the building, or their IT team — rather than to the contractor. The contractor can hold a technician account, and borrow administrator rights for specific tasks. That way the owner can always remove a contractor, and a contractor can't lock the owner out of their own building.

The accounts nobody owns

Run an account listing on a supervisor that's been in service ten years and you'll find names nobody in the room recognises. Some are technicians from the installing contractor. Some are from the contractor before that. One or two are "test", "temp" or "vendor" with no owner at all.

Every one of those is a working login held by someone with no current reason to use it. Most are harmless people who've moved on. But you can't tell which, and neither can the owner.

Clean-up is straightforward:

1. Export or screenshot the full user list from the supervisor, and from any controller or router that has its own local accounts.
2. For each account, record the person, their company and their role. Mark any you can't identify.
3. Ask the owner to confirm who should still have access. It's their building and their decision.
4. Disable, don't delete, accounts that are no longer needed. Disabled accounts keep their history in the audit log; deleted ones can make old log entries harder to trace.
5. Change the password on anything shared that has to stay for now, and set a date to replace it with named accounts.
6. Set a routine: review the list at least once a year, and whenever a contractor changes.

The routine matters more than the first pass. The best trigger is joiners and leavers: when a technician leaves your company, the owners of every site they had access to should find out, and those accounts should be disabled that week. Build it into your own offboarding checklist.

Passwords: where they should live

The honest answer to "where do we keep the passwords?" on a lot of sites is a spreadsheet on a shared drive, a notebook in the plant room or a sticky note on the monitor. All three are readable by far more people than should have them.

A password manager is the practical replacement. The owner's IT team probably already runs one, and most can share a vault with specific people and log who opened which entry. For a contractor managing many sites, a company password manager with per-site vaults beats any spreadsheet.

• Unique per site and per device class. The same password on every controller in the building is better than the default, but not much. The same password across every customer is the worst of all.
• Long rather than clever. A long passphrase is easier to type on a controller keypad than a short string of symbols, and harder to guess. Some older devices cap password length or character sets; use the longest the device allows.
• MFA where the platform supports it, at least on remote access and on administrator accounts. See remote access without opening the building to the internet.
• No passwords in email or text messages. Share through the password manager, or read it out over the phone if you must.

Handover: getting it right the first time

The easiest time to fix accounts is before the building is occupied. At handover, the owner should receive:

• A list of every device with a login — supervisors, controllers, routers, gateways, switches — confirming none is on its default password.
• The credentials themselves, delivered through the owner's password manager or another secure method, not printed in the O&M manual.
• A user list for the supervisor, with each account's person, company and role.
• The owner's administrator account, created and tested by the owner's representative, not just written down.
• Commissioning accounts disabled. The accounts used by the start-up team and the commissioning agent shouldn't outlive the project.

If you're taking over an existing site from another contractor, the same list is your starting audit. Ask for it on day one. What the previous contractor can't produce tells you where to start.

The takeaway

Accounts are the one security control every technician can improve on the next visit without a change request, a budget or IT's involvement. Change the defaults, give people their own logins, give the administrator role to the owner, and disable the names nobody recognises. It won't make the news. It will close the door most people would actually walk through.

Once the accounts are sorted, the next steps are hardening the supervisor and its controllers and getting the BAS off the office network.

Found a wrong number or a broken link? Tell me and I’ll fix it.