Unique Credentials and Shared Admin Accounts: A Common MSP Challenge

If your organisation manages a fleet of client devices, servers, domains, or cloud services, you've likely run into a tension between two Cyber Essentials requirements that, on the surface, seem to pull in opposite directions.

On one hand, devices and systems need default credentials changed on first use, with those passwords kept current and known to whoever needs to administer them. On the other hand, Cyber Essentials requires that all user and administrator accounts are accessed using unique credentials — meaning no two people should be logging in with the same username and password.

This challenge shows up at several different levels: local admin accounts on individual laptops, the built-in "Administrator" account on servers and domains, and the root or Global Administrator accounts that come by default with cloud platforms. The underlying issue is the same in each case — a single, powerful account that multiple people need to use — but the right way to resolve it looks a little different depending on the layer you're working at.

Why This Matters

A shared credential isn't just a compliance technicality. If several people all log in as "admin" with the same password, there's no way to tell from the logs which of them made a given change, installed a piece of software, or accessed a particular resource. In a security incident, that ambiguity can matter a great deal. Unique credentials aren't just a box-ticking exercise — they're what makes accountability and audit trails possible in the first place.

Local Admin Accounts on End-User Devices

For many MSPs, the day-to-day reality is that a device arrives, a technician logs in with a local admin account, sets a secure password, and lets the rest of the IT team know so anyone can support that device going forward. It's a sensible, practical process — but if several technicians are all using the same local admin credential, that account is no longer uniquely attributable to one person.

The good news is that this is a solved problem. A few well-established approaches:

Automated password rotation (e.g. Windows LAPS) Rather than a static password that's manually changed and shared by word of mouth, tools like Windows LAPS (Local Administrator Password Solution) randomise and rotate the local admin password automatically, per device. Technicians retrieve the current password by authenticating with their own individual login to a central console — so the retrieval step is uniquely attributable, even though the local account name itself stays the same. This also has the side benefit of keeping passwords current without anyone needing to remember to change them.

Access brokered through RMM or PAM tooling Many MSPs already use a Remote Monitoring and Management (RMM) platform or a dedicated Privileged Access Management (PAM) tool to carry out admin tasks. In this model, the technician logs into the RMM/PAM platform with their own unique credentials (ideally with multi-factor authentication), and the tool handles the local admin credential in the background — the technician never sees or types the shared password at all.

Individual named admin accounts Rather than one shared local admin login, some organisations provision a separate local admin account per technician on each device. Conceptually straightforward, but scales less well across larger device fleets.

Least-privilege elevation tools (e.g. Endpoint Privilege Management) Where devices are managed through a modern endpoint platform, tools such as Microsoft's Endpoint Privilege Management allow standard user accounts to elevate for specific pre-approved tasks without a shared admin account being involved at all.

Servers and Domains: The Built-In "Administrator" Account

Windows Server and Active Directory both ship with a built-in account, typically named "Administrator," that has full control over the machine or domain. It's meant as an initial setup account, not as the account your team uses day to day — but it's common to see it left active and used routinely, sometimes by more than one person.

The general shape of the fix mirrors the local admin problem, with a couple of domain-specific additions:

• Disable or rename the built-in account after initial setup, and issue each administrator their own uniquely named account with the appropriate admin rights, typically granted through an Active Directory security group rather than by sharing a single login.

• Treat the built-in Administrator account as a "break-glass" account. Keep it disabled under normal circumstances, with its password known to very few people and stored securely (for example, in a password vault with restricted access), and only enable it for genuine emergency scenarios — such as when domain trust or normal authentication has broken down.

• Consider Just-In-Time or Privileged Access Management for domain admin rights, where standing admin group membership is avoided in favour of time-limited elevation that's requested, approved, and logged each time it's used (Microsoft's Privileged Access Management for Active Directory and Entra ID's Privileged Identity Management both work this way).

• Enforce MFA on all administrative accounts, not just the built-in one — domain admin rights are a high-value target, and password strength alone isn't a sufficient control at this level.

  
  

Cloud Services: Root and Global Administrator Accounts

Cloud platforms present a similar pattern, usually with even higher stakes, since a compromised root or Global Administrator account can affect an entire tenant or cloud environment rather than a single machine.

• Microsoft 365 / Entra ID creates a Global Administrator account during initial setup. Ongoing administration should be handled through individually named accounts assigned specific admin roles (via Entra ID role-based access control) rather than everyone using Global Administrator for everyday tasks.

• AWS provides a root account tied to the account email address, which AWS itself recommends locking away and using only for a small number of tasks that genuinely require it. Day-to-day administration is handled through individually named IAM users or roles, ideally with MFA and time-limited elevated access via IAM roles rather than standing admin rights.

• Google Workspace, Azure, and most other major platforms follow the same pattern: a powerful default account for initial setup, and role-based, individually attributable accounts for everyday administration.

The common recommendation across all of these platforms is to treat the default all-powerful account (root, Global Administrator, Owner, etc.) as a break-glass account: secured with strong MFA, its credentials stored securely and known to very few people, used rarely, and ideally monitored so that any use of it triggers an alert. Routine administration should happen through named accounts with only the level of access each person actually needs.

The Common Thread

Whether you're looking at a laptop's local admin account, a domain's built-in Administrator, or a cloud platform's root account, the same principle applies: the account a person authenticates with should be theirs alone, and it should carry no more privilege than the task requires. Whether that's achieved by rotating passwords automatically, brokering access through a management tool, provisioning individually named accounts, or reserving the most powerful account for rare, tightly controlled emergency use, the goal is the same — every login should be traceable to one individual, and standing access to the most powerful accounts should be kept to a minimum.

If your current process relies on a team manually sharing a password after each change, or on day-to-day work being done through a built-in Administrator, root, or Global Administrator account, it's worth treating that as an area for improvement rather than an unavoidable trade-off. The tooling to close this gap already exists, is widely adopted, and in most cases integrates with infrastructure you're already using.

This article is intended as a high-level overview to help applicants understand the shape of this challenge across devices, servers, domains, and cloud services, and the general categories of solution available. It is not a step-by-step implementation guide — the right approach will depend on your existing tooling, environment, and team structure. If you're unsure which option best fits your setup, your assessor or IT provider can help you work through the specifics.