admin@ Is Not a Person: Taking Software Accounts Back From Shared Inboxes

Every UK team of a certain size has one. It sits on the contact page, it collects supplier invoices, and it quietly holds the keys to a dozen online tools that nobody can quite remember buying. Sometimes it is admin@. Sometimes info@. Occasionally it@, if the person who set it up was feeling formal.

None of this happened on purpose. Shared inboxes accumulate software accounts the way kitchen drawers accumulate takeaway menus. Someone needed to get the team into a project tool on a Friday afternoon, admin@ was already open in a tab, and that was that. Two years later the same address is the recovery contact on your finance system.

That is worth an afternoon of your time.

Three different things get called the same thing

Before you start making a list, it helps to separate what you are looking at, because the risk varies quite a lot.

A proper shared mailbox. In Microsoft 365 or Google Workspace this has no separate sign-in: people get access through delegation and there is no password of its own. It is the least bad version, though still not a person.

A shared login. One address, one password, and everyone signs in as it. The password lives in a notes app, a spreadsheet called Passwords, or a very old envelope. This is the version that causes incidents.

An alias or group. Fine for receiving mail. Genuinely dangerous the moment it is used as a recovery address or a billing contact, because it quietly routes the important things somewhere nobody watches.

Most messy estates have all three, often wearing the same address.

Why an unowned account is a problem even when it works

The first casualty is named ownership. If a tool is registered to admin@, then nobody in the business can honestly say they look after it. When the renewal notice arrives, it arrives in a queue. When the vendor changes its terms, the email lands somewhere between a delivery notification and a newsletter. When the bill is queried, the trail runs back to a mailbox rather than a person.

The second casualty is multi-factor authentication. MFA is meant to prove that a specific individual is signing in. If four people can read the codes, or if a reset link lands in a shared inbox that anyone can open, what you have is a group password with extra steps. It still stops the casual attacker. It does nothing about the person who left in March and still has the inbox on their phone.

The third is the audit trail. Your SaaS logs will record that admin@ changed a permission, exported a report or deleted a project. They will not tell you who was sitting at the keyboard. In a dispute, or during an internal review, that is the answer you actually need.

There is a compliance angle too. Under UK GDPR the controller has to be able to demonstrate accountability. Regulators are not especially interested in whether the address on the account had a person's name in it, but they are interested in whether anyone could describe who was responsible for the system.

Finding the accounts: an afternoon, not a project

Start with money rather than with software. Pull three months of card and bank statements, plus anything billed through the App Store or Play Store, and list every recurring charge that looks like software. Then add the free tools that never appear on a statement but hold your data anyway.

For each one, sit down with whoever has admin access and write down four things: the sign-in address, the recovery email, the billing contact, and the named owner of the account. Where the answer to any of those is a shared inbox, highlight it.

Then search. Open the shared mailbox and search for phrases like "reset your password", "verify your email", "welcome to", "your invoice" and "renewal". You will be surprised how much of your estate announces itself this way. It is a fast way to find accounts nobody has thought about since onboarding.

While you are in there, check two things that are easy to miss. First, inbox rules and forwarding: a rule sending mail to a personal address is a red flag, whether or not it was set with bad intent. Second, connected apps and API tokens, because a shared address with an OAuth grant to a reporting tool is still a live key even after you change the password.

Finally, look sideways at your domain, DNS and identity provider. The shared inbox is often the recovery address on the account that controls the domain itself, which is a genuinely uncomfortable place to find one.

The recovery address is where MFA goes to die

Here is the bit that catches people out. You can move a tool to a named owner, enable MFA, and still leave the front door open, because the recovery address on that account is still info@ and the reset email still lands in a mailbox with five people on it.

So treat recovery as its own line in the audit. A good default is a monitored group with named, current members, rather than a single person who might be on holiday or a shared inbox that anyone can read. Whichever you choose, make sure it is protected by MFA in its own right and that membership is reviewed when people leave.

Moving the keys without causing an outage

You do not need a big programme. You need a sequence.

Keep the address, retire the credential. The shared address can stay as a notification alias so invoices and support replies keep arriving. What changes is the sign-in identity, which moves to a named person.

Change the password once, properly. Generate a new one, store it in the password manager under the named owner, and force a sign-out of all sessions. If the tool has API keys or personal access tokens, rotate them now rather than later, because an old token will happily outlive the password change.

Repoint the recovery and billing addresses. Both should go to a person or a monitored group. Update the vendor's records and check the next invoice actually arrives where you expect it.

Do not delete the mailbox. Convert it to a shared mailbox, keep it readable for a few months with forwarding to the new owner, and only then consider retiring it. Deleting it early is how you lose the history of what was agreed with a supplier.

Re-check your integrations. Anything that signs in with the old address, from a scheduling tool to a helpdesk connector, needs testing before you assume it works.

Write it down, or it will drift back

Keep a simple register: tool, previous sign-in address, new named owner, date changed, recovery address, billing contact updated yes or no. It takes ten minutes a row and it doubles as your evidence if anyone ever asks who is responsible for a system.

Shared inboxes are not the enemy. They are useful, cheap and genuinely good at collecting enquiries. The problem is the accounts that grew out of them and never moved on. The test of a tidy setup is simple: for every tool on your list, you can name a person without opening a spreadsheet and shrugging.