Protecting Administrator Access in EDGEBIC

Every EDGEBIC site needs two administrator accounts: the protected founding account created on first launch, and one break-glass account whose password lives in a password manager. In EDGEBIC by User Solutions only an administrator can unlock a locked account, reset a password, or change the database connection, which makes a single administrator a single point of failure. This post covers what the built-in protections actually guarantee, what they do not, and how to keep access working when people move on.

Role design sits in the four roles most plants need. This post is about the fifth role, the one that already exists and is easy to take for granted.

What Is Protected, and What That Means

Two records cannot be deleted: the founding administrator account created the first time the application starts against a new database, and the built-in Administrator role. The role always holds every permission, including new ones added by product updates, and it cannot be narrowed.

That protection is real and worth understanding precisely. It guarantees a site cannot lock itself out by deleting its own access path. It guarantees a new capability shipped in an upgrade is always reachable by somebody on day one. And it guarantees that when custom roles drift, there is a role that definitionally has not.

What it does not guarantee is that anyone knows the password. A protected account nobody can sign into is a locked door with a very sturdy frame. That is the gap the second account closes.

Why Two, Not One and Not Four

One is a single point of failure, and the failure is more mundane than people imagine. Five consecutive wrong passwords lock an account for 15 minutes by default, and clearing a lock immediately requires an administrator using the Unlock action on the Users list. A sole administrator who mistypes five times waits out the window with the plant waiting too. Password resets are the same story: an administrator resets other people's passwords, so the sole administrator has nobody to reset theirs.

Four is too many, because every extra holder is another person who can open the data-clearing utility and another account whose compromise reaches everything. If four people need to do administrative-feeling work, most of them probably need a wider planner role rather than administrator rights. Read the split in deciding who may change the schedule.

Two is the working number: the founding account plus one break-glass account, with the second one's credentials in your password manager rather than in a head or a drawer.

Keep Daily Work Out of the Admin Account

The administrator who plans all day from their administrator account is doing something quietly risky, and there is a specific reason beyond general principle.

The toolbar button that sounds like a layout reset opens the data-clearing dialog, which can clear tables as well as screen layouts. That dialog is guarded (a red banner, a confirmation word to type, an expandable view of what each scope cascades to) but the guard only helps someone who reads it. Spending eight hours a day in an account that can reach it is unnecessary exposure. Everything about that utility, including the reset-button trap, is in the data clear tool and when to use it.

So give your administrator two accounts: a named planner account for planning, an administrator account for administration. The side benefit is an honest access review, because you find out what a planner role actually needs when your most capable user is working inside one.

Never Share the Admin Login

One account per person, always, and the administrator account is where this rule is broken most often, usually with a good excuse.

Sign-ins, failed attempts, lockouts, user and role changes, password resets, and permission denials are all recorded permanently in an append-only security audit trail inside the database. There is no browsing screen for that trail in the application: it exists as a record your administrator or support can query when a compliance question arrives. Every one of those entries names an account. When two people share the administrator account, the trail records that the administrator did something, which is exactly the information you already had.

Succession: What to Do Before Somebody Leaves

The order here matters, because doing it in reverse leaves a gap.

Step 5 is the one people get wrong under time pressure. Deactivating bars the next sign-in attempt and preserves everything the account did; deleting removes the identity. The offboarding routine in full is in deactivating users and offboarding, and the written pack is in handing over to a new IT owner.

The Small Practices That Keep It Healthy

Force a password change on every account you create. The must-change-password flag means the temporary password you typed into a chat message stops working the first time it is used.

Review the Users list quarterly. The Active and Locked columns answer two questions in one glance: who still has access who should not, and who has quietly stopped using the system because they are locked out. Both belong on the quarterly admin health check.

Know the unlock path before you need it. Locked accounts are cleared immediately from the Users list rather than waiting out the window; the walkthrough is in how to unlock a locked-out user, and the triage for a sign-in that fails for other reasons is in a user cannot sign in.

Administrator access is the one part of the system that cannot be recovered by any other part of the system. Two accounts, a password manager entry, and a tested successor are what turn that from a risk into a footnote. For the full administrator reference, read the EDGEBIC admin guide, and for how the plan itself is protected by the same model, how role-based access protects the schedule.