data.day

The Day the Admin Account Left, and the Client Files Followed

A shared admin account is a ticking time bomb. See how one departure can lock you out of your own business, and how to engineer true identity control.

The Crown Jewels in a Community Chest

We confuse “Collaboration” with “Communal Living.” In a business, we want to work on the same documents. This does not mean we should wear the same face.

When five employees share a single login—[email protected]—they are effectively sharing a single face. The Machine cannot distinguish between the Director, the Intern, or the Rogue Actor. It sees only “The Admin.”

This works until it fails. And when it fails, it fails totally.

The Vulnerability: The Single Point of Failure.

Consider the physical keys to your office. Would you melt them all down into one giant key, and hang it on a hook by the front door? Of course not. If one person takes the key, everyone else is locked out.

Yet, this is exactly what happens with shared digital accounts.

I witnessed a case involving a municipal service team. They shared a Dropbox login. The “owner” of the account was an employee who had set it up four years prior. When that employee was terminated, they went home, logged in, and changed the password.

Because they were the “Admin,” The Machine recognized them as the owner. The Machine does not know about labor disputes. It does not know about severance packages. It only knows that the person with the password is the King.

The remaining team was locked out of four years of evidence. They had to petition the vendor, who refused to help because, legally, the account belonged to the individual who created it.

The Architecture: Identity Isolation.

To prevent this disaster, we must enforce a strict rule: One Human, One Identity.

The Machine requires precise attribution.

  • Jane has an account.
  • Lars has an account.
  • The System logs what Jane does and what Lars does.

If Jane leaves, we disable Jane’s account. Lars is unaffected. The data remains.

Furthermore, we must separate “Use” from “Administration.” The daily user should not have the power to delete the entire database. We create a Super-Admin account—let us call it the “Root Key.”

We generate a complex password for this Root Key. We write it down on paper. We seal it in a physical envelope. We place it in a fireproof safe.

No one logs in as Super-Admin to check email. We only use it to issue new keys or revoke old ones.

This is not about lack of trust in your team. It is about minimizing the blast radius of a departure. People leave. Relationships end. Your data must survive the transition.

Thus, audit your logins today. If you are sharing a password, you are sharing a liability. Stop it.

FAQs

It costs extra for more seats. Can we just share one?

You are saving $20 a month to risk a $50,000 incident. This is bad arithmetic.

How do we hand over work if we don't share logins?

You use shared folders, not shared identities. The Machine must know *who* did the work, not just that the work was done.

What is the first step to fixing this?

Create a 'Break Glass' account. A separate admin login that is only used for emergencies, locked in a physical safe.