Shared Admin Accounts and Other Terrible Love Stories

Every IT environment has at least one terrible love story.

Not the romantic kind. The operational kind.

The kind where everyone knows the relationship is unhealthy, but it has been going on for years, nobody wants to have the conversation, and somehow the shared admin account still has access to half the estate.

Shared admin accounts are one of those things everyone knows are a bad idea, right up until someone explains why they still need one.

“It’s just easier.”
“We all use it for support.”
“The vendor needs it.”
“It’s only for emergencies.”
“We’ve always done it this way.”

A timeless romance between convenience and future regret.

Why shared admin accounts exist

To be fair, they usually do not start as acts of villainy.

They start because something needs managing.

A system is installed.
A local administrator account exists.
A supplier needs access.
A support team needs to perform maintenance.
A migration is underway.
A device has to be configured quickly.
Someone creates an account because the work needs doing.

Then somebody else needs access.

Then another person.

Then a vendor.

Then a contractor.

Then the password gets saved somewhere “temporarily”.

And, as we established in Article 2, nothing is more permanent than temporary access.

Before long, the shared admin account has become part of the furniture. Nobody loves it, but everyone has adapted their lives around it.

Like a printer.

The problem is not just security

When people talk about shared admin accounts, they usually frame the issue as security.

That is true, but incomplete.

Shared admin accounts are also a problem for:

• accountability
• investigation
• access review
• leaver management
• audit evidence
• change control
• incident response
• supplier governance

The security issue matters. Privileged accounts have power. If they are compromised, misused, or poorly controlled, the damage can be significant.

But the accountability issue is just as serious.

If five people use the same admin account and that account makes a change, who made the change?

Technically, the account did.

Which is very clever, and almost completely useless.

Accountability dies in shared credentials

A named account creates a link between action and person.

A shared account breaks that link.

That means when something changes, breaks, disappears, reboots, gets reconfigured, or behaves suspiciously, the organisation has a harder time answering basic questions:

• who logged in?
• who made the change?
• was it approved?
• was it expected?
• was it a human or automation?
• was it internal or third-party?
• was it malicious, accidental, or routine?

If the answer is “the shared admin account”, then you have not really answered the question.

You have just pointed at the fog.

This matters during incidents. It matters during audits. It matters when someone leaves. It matters when suppliers change. It matters when a system behaves strangely and everyone starts doing that very specific IT face that says, “I am trying not to look alarmed.”

Why shared admin accounts survive

Shared admin accounts survive because they are convenient.

They remove friction.
They avoid process.
They keep old systems manageable.
They make supplier support easier.
They let people get things done quickly.

And in busy environments, convenience is seductive.

The trouble is that convenience often borrows risk from the future.

Shared admin accounts are easy today and expensive later. They reduce effort at the point of use, then increase effort during investigation, review, recovery, and governance.

They are the technical equivalent of putting everything in a cupboard before guests arrive.

The room looks fine.

Do not open the cupboard.

Warning signs you have a shared admin problem

You may have a shared privileged access problem if any of these sound familiar:

• multiple people know the same admin password
• the same local admin password exists on many devices
• a supplier uses a generic account
• emergency access accounts are used for routine work
• admin credentials are stored in documents, chats, or browsers
• nobody is sure who last used an account
• leavers are removed from normal systems, but shared passwords are not changed
• MFA cannot be tied clearly to the individual using the account
• logs show what account was used, but not who used it
• everyone agrees the account should be replaced, but not today

“Not today” is where controls go to become incidents.

Privileged access is different

Not all accounts carry the same risk.

A standard user account is one thing.

An account that can:

• create users
• change permissions
• install software
• modify systems
• access sensitive data
• disable protections
• change configurations
• affect backups
• administer infrastructure

is something else entirely.

Privileged access needs stronger controls because the impact is higher.

This is not about mistrusting IT staff, suppliers, or administrators. It is about recognising that powerful access needs better guardrails.

Good people still make mistakes.
Good accounts still get phished.
Good suppliers still need boundaries.
Good intentions still break production.

Lovely people can still accidentally flatten a permission model with the confidence of a Victorian engineer.

What good looks like

Good privileged access management does not mean making administration impossible.

It means making administration controlled.

That usually means:

Named admin accounts

Wherever possible, administrators should use named accounts.

That gives the organisation a clear link between action and person.

Separate admin accounts

Administrative work should be separated from everyday activity where appropriate.

Nobody should be casually reading email, browsing the web, and administering critical systems from the same highly privileged account like it is a 2009 small business server and fate has not yet developed consequences.

MFA for privileged access

Privileged accounts should have MFA.

If MFA is annoying for normal accounts, it is still necessary.

If MFA is annoying for privileged accounts, it is extremely necessary.

Least privilege

Users should have only the privileges required to perform their role.

Not every technician needs domain admin. Not every supplier needs global admin. Not every urgent request needs the biggest key on the ring.

Logging

Privileged actions should be logged where possible.

Logs should support investigation, not merely exist as decorative telemetry.

Review

Privileged access should be reviewed regularly.

Who has it?
Why do they have it?
Do they still need it?
Is it being used appropriately?
Can it be reduced?

Emergency access with control

Break-glass accounts may be needed, but they should be tightly controlled.

That means:

• strong credentials
• protected storage
• limited use
• monitoring
• documented access
• review after use

A break-glass account is not a convenient shortcut. It is an emergency hammer.

Stop using it to open tins of beans.

What about vendors and suppliers?

This is where things often get messy.

Suppliers may need access to support systems. That can be legitimate.

But supplier access should still be:

• named where possible
• approved
• time-bound
• limited to what is required
• protected with MFA where available
• logged
• removed when no longer needed
• reviewed periodically

The phrase “the vendor needs access” should not be treated as a magic spell that bypasses governance.

Vendors can have access.

They do not need a skeleton key and a sleeping bag.

How to fix shared admin accounts without breaking support

Do not begin by deleting everything and declaring victory.

That is how you create chaos with a policy document in your hand.

Start deliberately.

Step 1: Find the shared privileged accounts

List:

• domain admin accounts
• local admin accounts
• application admin accounts
• supplier admin accounts
• emergency accounts
• service accounts being used interactively
• generic accounts used for support

If nobody knows whether an account is shared, that is already useful information.

Unpleasant, but useful.

Step 2: Classify by risk

Prioritise accounts with:

• broad administrative rights
• access to sensitive systems
• internet-facing access
• supplier use
• weak or unknown password controls
• no MFA
• no clear owner
• active use by multiple people

Do not treat all shared accounts equally. Some are merely untidy. Some are quietly holding a flamethrower.

Step 3: Replace with named access where possible

Move administrators to named privileged accounts.

That restores accountability and makes reviews meaningful.

Step 4: Protect what cannot be removed immediately

Some shared accounts may take time to eliminate.

Until then:

• change the password
• store it in an approved password manager
• restrict who can access it
• apply MFA where possible
• log use
• document the reason it still exists
• set a review date

Temporary controls should not become retirement plans.

Step 5: Separate service accounts from human accounts

Service accounts should run services.

Humans should not be logging in as service accounts because “it works”.

That way lies audit sadness.

Step 6: Review regularly

Privileged access should not be set once and forgotten.

Access changes as people, suppliers, systems, and business processes change.

Your review process is what stops today’s exception becoming tomorrow’s breach path.

The role of policy

This is exactly where policy needs to be clear.

A good Privileged Account Management Policy should say:

• privileged access must be named where practical
• shared admin accounts must be avoided or justified
• privileged access requires stronger authentication
• administrative access must be reviewed
• supplier access must be controlled
• emergency accounts must be monitored
• exceptions must be documented

That is not bureaucracy.

That is the organisation deciding it would quite like to know who is holding the keys.

Reasonable, really.

Final thought

Shared admin accounts are convenient.

That is why they survive.

But convenience is not the same as control.

If everyone can use the same privileged account, then nobody is properly accountable for what that account does.

And when something goes wrong, “we all knew the password” is not a defence.

It is the incident title.

Which admin account in your environment is still shared because fixing it feels inconvenient?