How ISO 27001 Solves Privileged Access and Shared Account Risks for MSPs

Why shared admin accounts are now a serious liability for MSPs

Shared administrator accounts are now a structural liability for managed service providers because they destroy individual accountability for sensitive actions. When several engineers share the same “admin” identity, you cannot reliably prove who did what, when or why, and both attackers and auditors treat that as an open door rather than a minor shortcut. Modern contracts and standards now expect named accountability, so shared logins look like unmanaged risk, not efficiency. Security commentary and industry guidance, including analysis from publications such as CSO Online, increasingly describe anonymous admin accounts as a red flag for regulators, cyber‑insurers and enterprise customers.

They also turn every privileged action into a guessing game: when multiple people use the same login, logs lose evidential value, disciplinary conversations become murky and incident timelines become hard to reconstruct.

This topic touches security, contracts and regulation, so treat the information here as general guidance, not legal or regulatory advice. You should always take decisions with your own legal, compliance or security advisers.

Shared admin accounts often conceal more risk than most MSPs realise.

How shared accounts quietly undermine your business

Shared admin accounts once felt practical because they gave a small team quick access to many systems, tenants and devices. As your MSP grows, the same pattern quietly undermines client trust, inflates incident impact and makes it harder to satisfy auditors or insurers who expect clear, person‑level accountability for changes in high‑risk systems.

Early on, you probably created one RMM “super admin”, a generic domain admin, a shared firewall login and catch‑all cloud tenant accounts. They saved time and helped you keep service levels high with a small team. Over time they blur accountability, expand the blast radius of any compromise and slow your response whenever something goes wrong.

In the 2025 survey, roughly 41% of organisations ranked managing third‑party risk and tracking supplier compliance among their top information‑security challenges.

The same shortcuts now work against you:

No individual accountability.: Logs only show “admin”, so you cannot prove which engineer made a specific change.
Huge blast radius.: One stolen password can open many client environments and internal systems in one move.
Slower incident response.: Teams waste time arguing about who acted last instead of focusing on containment and recovery.
Audit friction.: Auditors, enterprise customers and insurers expect named admin identities; generic logins trigger awkward findings.

If you imagine a major customer asking “who deleted this mailbox” or “who changed this firewall rule” and your only honest answer is “we do not really know”, you already feel the risk. The same thought experiment applies to an ex‑engineer who still remembers a shared credential or a contractor whose access was never fully revoked, yet can still log in as “admin”.

Why we trust our engineers is no longer enough

Trust inside your team still matters, but it can no longer stand in for structured controls over privileged access. Clients, regulators and insurers now expect evidence that you can prove who had access, who acted and how you prevent abuse, even when everyone on the team is well intentioned.

Trust is useful for culture but inadequate as a control for sensitive access. External stakeholders need to see that you have enforced unique identities, tight role definitions and accurate logs for high‑risk actions. Without that, they assume shared logins mask gaps in process, governance and oversight that could hurt them.

A few questions highlight the gap:

If MSPAdmin changed an Azure conditional access policy, could you prove which engineer did it?
If a cyber‑insurance claim needed proof only a few people had access, would your records be convincing?
If a regulator or enterprise client asked how you prevent a disgruntled ex‑employee using a shared admin, what would you show?

ISO 27001 gives you a structured way to answer these questions. It does not mention MSPAdmin by name, but its access‑control and logging requirements create a clear expectation: every privileged action should be traceable to a uniquely identified person, recorded and periodically reviewed.

A platform such as ISMS.online can help you treat this as a defined risk in your information security management system (ISMS), not an uncomfortable secret. When you can show that you recognised the issue, assessed the risk, chose appropriate controls and track them over time, your conversations with auditors and customers become much easier.

Book a demo

How ISO 27001 turns privileged access into a board‑level obligation

ISO 27001 turns privileged access from a convenient technical choice into a board‑level obligation linked to risk, contracts and reputation. Once you adopt the standard, directors are accountable for ensuring that access to critical systems is controlled, traceable and regularly reviewed, which makes shared admin accounts very hard to justify in any mature MSP. The standard’s clauses on leadership, risk treatment, access control and monitoring make top management responsible for establishing and overseeing the ISMS, so access to critical systems can no longer be treated as a purely technical matter. Guidance from ISO emphasises that responsibility for information security sits with leadership, even when day‑to‑day tasks are delegated to technical teams.

Most organisations in the 2025 ISMS.online survey reported that they had already been affected by at least one third‑party or vendor‑related security incident in the past year.

It also gives you a formal reason to move away from shared admin accounts and towards named, governed privileged access: the standard’s clauses and Annex A controls make individual accountability a requirement, not a nice‑to‑have, and shift privileged access from an internal habit that engineers define themselves to a governed topic the leadership team must understand, resource and monitor.

The core ISO 27001 requirements that apply to shared accounts

ISO 27001 expects you to treat risks such as shared admin accounts as documented information‑security risks with clear responsibilities and evidence. You must understand who is affected, how serious the issue is and what controls you will use to reduce it to an acceptable level.

This aligns with the structure of the standard itself, which starts with organisational context and interested parties, moves through risk assessment and treatment, and then defines roles, controls, monitoring and improvement activities.

At a high level, ISO 27001 expects you to:

Understand your context and interested parties (clause 4).
Assess and treat information‑security risks (clause 6).
Define and communicate information‑security roles, responsibilities and authorities (clause 5).
Monitor, log and review your controls (clauses 9 and 10, plus Annex A).

When you include shared admin accounts in your risk assessment, they typically score high, especially where they affect confidentiality, integrity and availability across many clients. Industry breach reports, such as the annual Verizon Data Breach Investigations Report, repeatedly highlight how compromised privileged credentials can drive multi‑system, multi‑client incidents. This forces you to decide, document and justify how you will treat that risk rather than leaving it as a tacit compromise.

Annex A then gives you more specific expectations around identity and access:

Access control and identity management.: Annex A expects controlled user registration, unique IDs, structured provisioning and careful privileged‑access rights management.
Logging and monitoring.: Logging controls only make sense if events can be tied to individuals, not anonymous shared identities.
Supplier and customer relationships.: Controls around supplier relationships and cloud services require clear contractual expectations about who can access customer environments and how that access is governed.

Taken together, these expectations give you a solid argument inside your organisation: continuing to use uncontrolled shared admin accounts is not compatible with ISO 27001’s principles or with board‑level accountability for risk.

Using ISO 27001 to justify change and investment

ISO 27001 gives you language and structure to justify change and investment in privileged access, especially when colleagues worry about disruption or cost. Instead of debating a single tool or configuration, you can show leadership that changing how you handle shared accounts is essential to meet the standard and protect the business.

The 2025 State of Information Security report notes that customers increasingly expect their suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2, as well as emerging AI standards.

For many MSPs, the biggest barrier is not technical capability but internal alignment. People worry about:

Slowing engineers down with more logins and approvals.
Breaking 24/7 support if controls are too rigid.
Spending on tools and projects when margins are already tight.

ISO 27001 helps you reframe those objections. You can show leadership that:

Shared privileged accounts are a documented, high‑impact risk in the ISMS with clear owners.
The risk is treated through explicit objectives, such as “no shared interactive admin accounts in production by year‑end”.
The standard effectively requires investments in access control, training and logging to reduce this risk to an acceptable level.

You can also link privileged access to management reviews and internal audits that directors already recognise as part of their governance duties. When privileged access appears in those forums with metrics, findings and actions, it is far easier to secure support for changes than if the issue only surfaces during technical discussions.

When you treat privileged access as a formal risk and control topic, you can track progress in management reviews, use metrics to demonstrate improvement and satisfy both auditors and customers. That is much easier than arguing case‑by‑case about a single tool or configuration change.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

Designing a privileged access framework that fits your MSP

A practical privileged‑access framework for your MSP sets out how you will identify, assign and govern powerful accounts across every client and internal system. Without this, you are left with one‑off decisions, inconsistent patterns and gaps that are hard to see until something goes wrong or an auditor asks difficult questions. Before you touch any tools, you need a clear, documented framework for how privileged access should work across your MSP and all client environments. ISO 27001 expects this kind of structured approach because it ties access decisions back to risk, controls and evidence rather than personal preference. The standard’s ISMS model is built around documented policies, risk assessments and control objectives, so a written framework for privileged access fits naturally with its requirements for risk‑based, evidence‑driven controls.

Define what “privileged” really means in your world

The first step is to define which identities genuinely carry elevated risk in your environment. That means looking beyond obvious “Domain Admin” labels and identifying every account that can change security, see lots of sensitive data or shut down key systems.

The word “admin” covers a lot of ground. To design sensible controls, you need a more precise vocabulary. Start by listing:

Internal systems: RMM, PSA, documentation, backup, password vaults, monitoring and identity providers.
Client‑facing systems: cloud tenants, firewalls, VPNs, hypervisors, on‑prem servers and key line‑of‑business applications.
Automation: scripts, bots and orchestration tools that act on behalf of engineers.

For each, identify the accounts and roles that can:

Change security settings.
Access large volumes of sensitive data.
Control availability, such as shutting down or deleting systems.

These are your privileged identities, human and non‑human. Your framework should explicitly cover:

Named privileged accounts: per‑engineer admin accounts in directories and tenants.
Service accounts: non‑interactive accounts used by services and automation.
Break‑glass accounts: emergency accounts used when normal routes fail.

Once you know what is in scope, you can decide at a policy level which patterns you will use, such as separating standard and admin identities, using role‑based access control, requiring strong authentication and central logging for privileged actions.

Step 1 – Catalogue systems and high‑risk identities

List internal and client‑facing systems, then identify every account that can change security, access sensitive data or affect availability.

Step 2 – Classify identities by type and purpose

Group accounts into named admin, service and break‑glass identities so you can apply consistent rules to each category.

Agree organisation‑wide patterns for separation of duties, role‑based access, strong authentication and logging before tuning them per client or system.

Your privileged‑access framework should read like a design document tied to your risk assessment and Annex A controls, not a list of individual opinions. That makes it defensible to auditors and easier to keep consistent across teams and customers.

For each major design choice, ask:

What risk does this reduce, such as misuse of RMM admin or uncontrolled cross‑tenant access?
Which ISO 27001 control or set of controls does it help implement?
How will you demonstrate that it is in place and working in practice?

For example, you might decide that:

All access to client tenants uses named identities with explicit role assignments.
All privileged actions on production systems are logged centrally and reviewed regularly.
Break‑glass accounts are used only under defined conditions and always reviewed afterwards.

These decisions reduce the risk of untraceable changes, support access‑control and monitoring controls and give you clear evidence to present in audits or customer due‑diligence reviews.

A framework like this gives your teams a reference to work from. It also gives auditors and enterprise customers confidence that you are not improvising privileged access on a per‑client, per‑engineer basis, but making risk‑based decisions aligned with ISO 27001.

Building a multi‑client RBAC model that actually works

A workable role‑based access control (RBAC) model lets you apply least privilege across dozens or hundreds of clients without drowning in exceptions. The aim is to design roles once at the provider level, then map them consistently to tenant‑specific permissions so engineers can work efficiently and safely. With your framework defined, you need an RBAC model that you can apply across many clients without losing your mind. The goal is to make least privilege practical by assigning engineers to stable roles and mapping those roles to the right permissions in each tenant, rather than granting ad hoc rights every time someone asks.

Standardise roles at the provider level

Provider‑level roles give you a reusable language for access across tools and clients. Instead of reinventing permissions per system, you attach each engineer to one or more standard roles that describe their responsibilities and risk profile.

Start by designing a provider‑wide role catalogue that reflects how your MSP works, not how a single tool labels permissions. Typical examples:

Service desk roles: L1, L2 and L3 support.
Operations roles: NOC and SOC analysts and duty engineers.
Project roles: cloud engineers, network engineers and architects.
Management roles: service‑delivery and account managers with view‑only access.

For each role, define:

What they must be able to do to perform their job.
What they must not be able to do, such as destructive changes in certain environments.
Which systems they need to reach internally and at clients.

Then, for each client, map those provider roles to tenant‑specific permissions. That might mean “L2 Support” becomes a defined Microsoft 365 role in one tenant, a firewall admin role in another and a specific server permission set in a third.

This keeps your conceptual model stable while allowing technical differences per client. It also makes joins and leavers easier: you add or remove roles rather than editing permissions system by system.

A simple before‑and‑after view helps illustrate the improvement:

Pattern	Weak practice	Stronger alternative
Service desk access	Ad hoc rights granted per ticket	Standard L1–L3 roles mapped to tenant permissions
Cross‑tenant admin	Single “super admin” for all clients	Defined multi‑tenant role with scoped visibility
Project engineering	Temporary elevation left in place for days	Time‑bound access linked to project and change logs
Management visibility	Shared report logins	Named read‑only roles with clear scope and logging

Avoid global “god” accounts and include automation

A RBAC model only delivers value if you actively avoid patterns that silently reintroduce shared or uncontrolled power. Global “god” accounts and ungoverned automation are the most common ways that happens in MSPs.

The main RBAC mistakes MSPs make are:

Giving a few engineers one account that can change everything in every environment.
Ignoring scripts, bots and automation that act with broad, hidden privileges.

To avoid this:

Keep internal roles for your own systems distinct from client roles; engineers do not need the same identity for your PSA and customer firewalls.
Make cross‑tenant administration explicit; design dedicated roles for those who must work across many clients, with carefully scoped permissions and strong logging.
Treat automation as a first‑class identity; every script or tool that can change client systems should use a dedicated service account with limited permissions and auditable activity.

In practice, that might mean replacing a single “MSPGlobalAdmin” account with:

A provider‑level “Cloud Engineer” role mapped to named identities in each tenant.
A “SOC Analyst” role with limited but well‑logged visibility across clients.
A set of service accounts in each automation platform that can only perform the tasks required, not arbitrary changes.

RBAC like this takes work to design, but it pays off. When a new engineer arrives or a contractor leaves, you add or remove roles rather than hunting for ad hoc permissions and shared logins. When an auditor asks who can make high‑risk changes in a tenant, you can answer by role and identity, not by guesswork.

Clear roles and named admin accounts turn access from a tangle of exceptions into something you can actually govern.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Implementing the right IAM, PAM, logging and monitoring controls

Once you know how privileged access should look, you need identity, access and monitoring controls that enforce those decisions in daily operations. This is where you translate policy into specific changes in directories, tenants and tooling that engineers use every day. A framework and RBAC model only matter if you can enforce them in the real systems your engineers use. This is where identity and access management (IAM), privileged access management (PAM) and monitoring controls turn design choices into repeatable behaviour. They should align with ISO 27001 expectations.

Strengthen identity first

Identity is the foundation on which every other privileged control rests. If you cannot trust who is logging in, no amount of logging or policy will give you the assurance you need across client environments. Everything else rests on solid identity. Key steps include:

Central directory and SSO.: Move towards a single source of identity truth, such as a cloud identity provider, for your engineers. Use single sign‑on for as many admin‑capable systems as possible.
Separate identities.: Give each engineer a standard user identity and one or more admin identities, depending on roles. Admin identities should be used only for privileged work.
Strong authentication.: Require multi‑factor authentication for all privileged access, including RMM, PSA, password vaults, cloud control planes and VPNs.

From there, tackle credentials that are still shared or stored in ad hoc ways:

Introduce a password vault or secrets store for service accounts and any remaining shared credentials.
Ensure access to those secrets is brokered, logged and, where possible, time‑bound.
Rotate high‑risk credentials regularly and whenever someone with access leaves or changes role.

Step 1 – Consolidate identities and enable SSO

Pick a primary identity provider, connect major admin systems to it and phase out local, unmanaged admin accounts.

Step 2 – Split standard and admin identities

Issue separate admin identities for privileged work and ensure everyday tasks happen under standard user accounts.

Step 3 – Enforce strong authentication and vault secrets

Enable multi‑factor authentication for privileged access, store shared or service credentials in a vault and monitor who retrieves them.

Design your logging and monitoring around privileged activity

Logging is how you prove your controls are working and how you spot misuse before it becomes a major incident. For privileged access, you need to be deliberate about which events you collect, where they go and who reviews them.

For privileged access, focus on:

What to log.: Administrative sign‑ins, privilege elevation, changes to security settings, creation or removal of admin accounts, changes to backup and monitoring configuration and access to sensitive data stores.
Where to log it.: Forward logs from critical systems to a central log platform or SIEM so you can correlate activity across clients and tools.
How to review it.: Define who reviews privileged‑access logs, how often they do so and what triggers an investigation.

It is better to have a smaller, well‑defined set of high‑value privileged events that you reliably collect and review than a huge, unmanageable stream nobody looks at.

For high‑risk operations, consider:

Jump hosts or admin workstations: , so privileged sessions are kept separate from everyday browsing and email.
Session recording or command logging: for highly sensitive systems, especially where technical constraints force the continued use of a shared account.

These measures help you meet ISO 27001’s expectations for logging and monitoring, and they make incident response materially more effective when something goes wrong.

Control without evidence rarely survives scrutiny when auditors or clients start asking questions.

Embedding privileged access into everyday MSP operations

Privileged access becomes sustainable when it is baked into how you run onboarding, offboarding, change control and reviews, not when it sits in a one‑off project document. Operational teams need processes that make the right behaviour the default rather than the exception. The hardest part of fixing privileged access is not designing controls; it is changing daily habits and keeping evidence up to date. ISO 27001 expects privileged access to be integrated into your operational processes, not treated as a one‑off clean‑up or a side project owned only by security.

Update your policies and people processes

Policies and runbooks shape how engineers and managers behave when nobody is watching. If those documents still assume shared logins or informal approvals, your privileged‑access improvements will quickly erode and drift back to old shortcuts.

Your access‑related policies and runbooks should clearly state:

Shared admin accounts are not permitted in normal operations.
All privileged access must be requested, approved, implemented and recorded through defined processes.
Admin identities are personal, not shared, and engineers are accountable for actions taken under those identities.

To make that real:

Integrate privileged‑access steps into your joiner‑mover‑leaver processes; new starters should be onboarded into roles, movers should lose old access as well as gaining new and leavers should have access revoked promptly.
Involve HR and procurement so that contractor and supplier access follows similar patterns and is removed on schedule.

Crucially, explain the “why” to your engineers and service managers. When people understand that named admin accounts and logging protect them as well as clients – by making it clear who did what and when – they are more likely to engage constructively than if they see the changes as bureaucratic overhead.

An ISMS platform such as ISMS.online helps you keep these people processes visible and auditable. You can link policies, role definitions, joiner‑mover‑leaver tasks and training records to specific risks and controls, so you always have up‑to‑date evidence that your privileged‑access rules are understood and followed.

Make reviews, audits and metrics routine

Regular reviews and simple metrics stop privileged access from drifting back into bad habits. They also give leaders and auditors clear evidence that you are maintaining control over powerful accounts across all clients and systems.

ISO 27001 puts a lot of emphasis on monitoring and continual improvement. Clauses on performance evaluation, internal audit and corrective action require you to check whether controls work, address non‑conformities and improve over time, so structured reviews and metrics for privileged access align closely with the standard’s intent. For privileged access, that means:

Roughly two‑thirds of organisations in the 2025 ISMS.online survey said that the speed and volume of regulatory change are making compliance significantly harder to sustain.

Scheduling regular access reviews for privileged roles; service‑delivery and security leads should jointly review who holds which roles, whether they still need them and whether any new shared accounts have appeared.
Explicitly including privileged‑access and shared‑account checks in internal audits and management reviews; any recurrence of shared admin accounts should be treated as a non‑conformity with corrective actions tracked to completion.
Tracking a small set of metrics that show whether your controls are improving, for example:

Count of shared interactive admin accounts.
Time taken to fully revoke privileged access for leavers.
Percentage of in‑scope systems sending admin logs to central monitoring.
Completion rate for scheduled privileged‑access reviews.

Recording the outcomes of reviews, audits and metrics in your ISMS gives you the evidence you need for ISO 27001 audits and client due‑diligence exercises. It also gives leadership a clear view of where privileged access remains a concern and where you are making progress, helping them prioritise further improvements.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Dealing with legacy systems and break‑glass access without breaking ISO 27001

Legacy systems and emergency access are often where your best privileged‑access intentions collide with technical reality. ISO 27001 is built around risk management rather than absolute technical uniformity, so it expects you to recognise these constraints, treat them as risks and apply compensating controls you can explain and evidence. Most MSPs can demonstrate much stronger control over modern cloud platforms than over older appliances, but you still have to account for both types of system in your ISMS.

Most MSPs have at least a few awkward systems that force them to bend their privileged‑access rules. Some devices only support one local admin user; some line‑of‑business systems have hard‑coded “sysadmin” accounts; some appliances were never designed for modern identity controls. ISO 27001 expects you to face those constraints honestly, not pretend they do not exist.

Treat legacy limitations as explicit, managed risks

When a system forces you to keep a shared or weak privileged pattern, you should not silently treat it as an exception. Instead, you should document the limitation, treat it as a risk and show what you are doing to reduce that risk until you can replace or upgrade the system.

Many MSPs have at least a few awkward systems that force them to bend their privileged‑access rules:

Old firewalls that only support one local admin account.
Legacy on‑premises applications with a single “sysadmin” user.
Appliances with no concept of named roles or central identity.

Instead of pretending you have fixed them, bring them into your ISMS:

Document them as specific assets with a clear vulnerability, such as “only supports single shared admin credential”.
Assess the risk in terms of likelihood and impact, noting how many clients or services depend on the system.
Define compensating controls, such as:

Putting the shared credential in a vault with check‑out and logging.
Limiting network access to the management interface.
Forcing access through a monitored jump host with session recording.
Restricting which engineers are allowed to use the account.

Record who owns each risk, what controls are in place and when you will review or replace the system. This keeps the issue visible in risk and management reviews and shows auditors and customers that you are managing the limitation, not ignoring it.

Design and govern break‑glass access carefully

Emergency access routes are necessary when normal controls fail, but they are also attractive shortcuts if you do not design and govern them properly. ISO 27001 expects you to treat them like any other control: defined, documented, logged and reviewed.

Emergency access is another area where bad habits persist. You may genuinely need a fallback route when:

The identity provider is down.
A misconfiguration locks out normal admin paths.
A severe incident demands immediate action under time pressure.

Rather than allowing ad hoc shortcuts, design a break‑glass process that answers:

Who can trigger emergency access and under what conditions.
Which account or accounts are used, where credentials are stored and how actions are logged.
How long emergency access lasts before it is automatically revoked or rotated.
What retrospective review happens afterwards.

Engineers should understand that using break‑glass access is not a personal failure, but it is an event that will be reviewed and documented. Aligning this process with your business‑continuity and disaster‑recovery plans helps you maintain security standards even in difficult circumstances.

A simple comparison can help teams understand the difference between weak and strong patterns:

Area	Weak practice	Stronger practice
Legacy device access	Shared password known by many	Password vaulted, jump host, limited authorised use
Break‑glass credentials	Stored in an engineer’s notebook	Stored in a vault with dual‑control access
Post‑incident review	No formal follow‑up	Mandatory review and documented lessons learned

By treating legacy constraints and emergencies as part of your ISMS – with risks, controls and evidence – you stay aligned with ISO 27001 while facing operational realities honestly.

Book a Demo With ISMS.online Today

ISMS.online gives you a practical way to embed privileged‑access governance into your ISO 27001 programme, so you can move away from shared admin accounts without losing responsiveness or control. It brings your risks, controls, tasks and evidence into one environment, so you do not have to juggle spreadsheets, documents and ad hoc reviews when auditors or customers ask hard questions.

What you can test in a pilot

A focused pilot helps you see how structured privileged‑access governance feels in real life before you commit to a wider rollout. You can choose a high‑risk area, such as your cloud administration function or RMM platform, and model the relevant risks, controls, roles and exceptions in one place.

The State of Information Security 2025 report shows that almost all surveyed organisations list achieving or maintaining security certifications, such as ISO 27001 or SOC 2, as a top priority.

In a pilot, you can:

Model privileged‑access risks, control mappings, RBAC decisions and exception cases in one workspace.
Link joiner‑mover‑leaver workflows, access‑review schedules and internal audits to specific controls and risks.
Assign owners, due dates and reminders for tasks such as retiring shared accounts or reviewing break‑glass usage.
Store artefacts such as role definitions, access‑review records, internal‑audit findings and management‑review minutes alongside the relevant risks and controls.

This shows how structuring your ISMS in ISMS.online makes it easier to retire shared accounts without harming responsiveness. You can experiment with different review frequencies, metrics and task assignments while still keeping a clear evidence trail for auditors and customers.

What a good outcome looks like

A successful pilot should give you clear improvements in visibility, control and confidence around privileged access, not just another tool in your stack. You should feel more able to explain your position to auditors, customers and your own leadership team.

Good outcomes typically include:

Shared admin accounts reduced or removed in the pilot area, with named roles and identities in place.
Clear dashboards or reports showing who holds which privileged roles and when they were last reviewed.
A documented, repeatable process for onboarding, changing and removing privileged access that engineers accept.
Evidence packs that make ISO 27001 audits and client due‑diligence exercises smoother and less stressful.

If you want to reduce the risk and stress of shared admin accounts, strengthen your ISO 27001 storey and give your team a clearer, calmer way to manage privileged access, booking a demo with ISMS.online is a straightforward next step. You will see how the pieces fit together in practice and can decide whether this is the right backbone for your own privileged‑access journey. Choosing ISMS.online also signals that you take named, auditable privileged access under ISO 27001 seriously and expect the same from your partners.

Book a demo

Frequently Asked Questions

How does ISO 27001 really change the way MSPs justify (or retire) shared admin accounts?

ISO 27001 forces you to treat shared admin accounts as an explicit business risk with owners, decisions and evidence, not just an operational habit.

How ISO 27001 turns “MSPAdmin” into a board‑level decision, not an engineer’s workaround

Under a working Information Security Management System (ISMS), a catch‑all login like “MSPAdmin” or “global‑admin@client” stops being invisible plumbing. It becomes something you must describe, assess and defend in simple, non‑technical terms:

You record how a single credential could affect confidentiality, integrity and availability across many customers.
You capture that as a specific risk with an owner, likelihood, impact and a chosen treatment (accept, reduce, transfer or avoid).
You link that decision to concrete controls in your Statement of Applicability, access‑control policy and logging/monitoring procedures.

At that point you are no longer debating “engineering preference.” You are staring at a risk record that effectively says, “we know one compromised password could hit multiple tenants at once, and we are prepared to live with that.” It is very hard for a board, investor or auditor to accept that position without heavy compensating controls and a clear exit plan.

ISO 27001 does not explicitly outlaw shared accounts, but its focus on accountability, traceability and continual improvement makes long‑lived generic logins increasingly indefensible. Most managed service providers that move towards certification find those accounts shrinking into tightly constrained exceptions or disappearing entirely.

How ISO 27001 gives you language that lands with leaders and customers

Many MSP engineers have been uneasy about shared logins for years, but their arguments stalled at “this feels unsafe.” ISO 27001 gives you artefacts and terminology that speak directly to non‑technical stakeholders:

Owners and boards: recognise a concentrated failure point that could be impossible to justify to shareholders or insurers after an incident.
Enterprise customers: now expect named activity, periodic access reviews and ISO‑aligned practices in security questionnaires and contracts.
Auditors: ask how you attribute privileged actions to real people, how quickly you can investigate a suspicious change and how often you challenge existing rights.

When you can show a risk entry describing shared credentials, demonstrate how it maps to your access‑control policy and SoA, and present a roadmap to named privileged access, you are no longer asking for “nice‑to‑have hygiene.” You are protecting revenue, reputation and certification in language leadership already uses.

If you want that conversation to be easier, it helps to document the shared accounts you still have, annotate why they exist, and sketch the steps to remove or contain them. That turns a vague worry into a specific, time‑bound plan that boards, auditors and customers can understand and support.

The ISO 27001:2022 expectations that matter most are the ones that shape how you decide, grant and oversee powerful rights across tools and tenants, rather than any single clause or control number.

The practical questions ISO 27001 keeps asking about powerful accounts

When you strip away the headings, the standard keeps circling a handful of very direct questions about admin access in a managed service environment:

Have you identified privileged access – especially anything spanning several customers or key internal platforms – as an information‑security risk?
Can you tie each powerful path back to a named person, a defined role and a business justification?
Do you enforce strong authentication and good credential hygiene wherever an engineer can make fast, far‑reaching changes?
Can you reconstruct what happened if something looks wrong, using logs that show who did what, when and from where?
Are your contracts and working arrangements with customers and suppliers explicit about who holds which rights and who governs those rights?

Those questions cut across several parts of ISO 27001:2022, including risk assessment and treatment, access control, logging and monitoring, and supplier relationships. The standard is largely tool‑agnostic: it does not mind whether you use vendor A or vendor B, but it does care that your answers are consistent and repeatable wherever privileged access exists.

For MSPs, that landscape usually includes RMM platforms, cloud portals, identity providers, security appliances, backup systems and SaaS services managed on a client’s behalf. A weakness in any of those often undermines the assurances you give elsewhere, which is exactly what customers and auditors are looking to uncover.

How to work back from outcomes instead of drowning in clause lists

A practical way to align with those expectations is to start from what you want an auditor or customer to be able to see, and then trace that back to ISO themes:

Identify the places where admins can do real harm.
List a small but representative set of internal platforms and client tenants where someone could change security posture, delete data or disrupt availability.
Ask three plain questions about each one.

Is admin access tied to individuals, or do shared logins still exist?
Is each person’s access as narrow and role‑based as is realistic, given how they work?
Is activity logged and reviewable in a way that would stand up in an investigation?

Link gaps to ISO expectations.
Anywhere the answer is “no” or “only partly,” tie that gap back to risk handling, identity and access management, authentication strength, monitoring quality or supplier/customer governance.

From there you can choose tactics that fit your size and client base. Smaller MSPs often start by removing shared accounts from a few core systems, enabling multi‑factor authentication and introducing simple privileged‑access reviews. Larger providers may move towards centralised identity, fine‑grained roles and dedicated privileged‑access tools.

Whatever route you choose, ISO 27001 is satisfied when you can show that your privileged‑access model is intentional, documented and challenged regularly, rather than improvised per customer or platform. If you can tell that storey clearly today, you are already ahead of many peers.

How should an MSP design RBAC so engineers have enough access without “god‑mode” accounts?

You design role‑based access control so that engineers work through reusable, well‑defined roles mapped across platforms, instead of through a handful of global accounts that quietly bypass client boundaries.

Why the real starting point is role design, not individual platform settings

If you build rights tenant by tenant, or console by console, you quickly collect exceptions that nobody remembers authorising. That makes privileged access difficult to explain to customers and almost impossible to review rigorously.

Starting from roles keeps the model human‑centred and easier to defend:

You describe the work you actually do: “L2 cloud engineer,” “NOC analyst,” “on‑site field engineer,” “incident lead.”
For each role, you decide what actions it must be able to perform, what it must not do, and which systems it should touch.
You then translate those decisions into specific permission sets in each relevant platform and customer tenant.

Handled this way, people hold roles and roles map to rights. You avoid granting access directly to arbitrary accounts or email aliases, which is often how “temporary” super‑user identities end up lingering for years.

Customers generally accept that some engineers will have cross‑tenant powers, particularly for out‑of‑hours or complex work. What they struggle with is the idea that those powers live in a couple of mysterious generic accounts. Roles that are documented in your ISMS, applied consistently and reviewed on schedule give them something they can understand and challenge.

How to stop people, clients and automation from bleeding into each other

Even with well‑named roles, privileged access can drift if you do not deliberately separate people, clients and automation:

A senior engineer’s normal account gradually becomes the universal break‑glass login because “they know how everything works.”
A script runs under a human admin identity that also has wide interactive rights.
A tool logs into every tenant as “msp‑admin” because it was quicker to set up once.

To prevent those patterns becoming normal, you can build a small number of firm boundaries into your design:

Separate internal platform roles from client roles.: No single personal identity should control both your own core systems and a long list of customers by default.
Define specific cross‑tenant roles for staff who genuinely need to work at scale, and wrap those roles in strong authentication and meaningful logging.
Create dedicated service accounts for automation, with narrow scopes, documented owners and clear lifecycle processes, so you can rotate or revoke them without touching human access.

If you document these decisions in your access‑control policy, role descriptions and risk records, and keep them current, you give auditors and customers a structure they can assess instead of a tangle of one‑off permissions. That structure also makes future decisions faster: new tools, new customers and new services can either be mapped cleanly to existing roles or flagged as exceptions that need deliberate approval.

What is a realistic way for an MSP to move from shared admin logins to named privileged access?

A realistic path away from shared admin logins is to treat the change as a managed, low‑risk programme rather than a big‑bang event, and to prove progress with simple, repeatable steps.

How to turn “we should stop sharing” into steady, low‑drama delivery

Most teams already agree shared logins are a bad idea; the blockage is usually time and structure. You can reduce that friction by giving the work a clear pattern:

Make the current state impossible to ignore.
Build a quick view of admin‑capable identities across your core tools and a small set of representative customers. Tag each as named, shared, service or emergency, and highlight where one credential spans many tenants.
Rank by blast radius and operational sensitivity.
Start where compromise would hurt most: RMM platforms, identity providers, major cloud portals or backup systems. These often give you the biggest security improvement and the strongest storey for leadership and customers.
Define what “good enough” looks like for each platform.
Usually this means named identities bound to roles, strong authentication, usable logs and some form of periodic access review. Agreeing that target upfront prevents arguments mid‑change.
Move in contained waves with rollback plans.
Change a specific group, shift a defined set of customers or migrate one platform at a time. After each wave, confirm support operations, monitoring and automation still work, and adjust before you expand.
Bake the new pattern into how you join, move and leave people.
Update onboarding, internal transfers, leaver processes and emergency procedures so they rely on the named model rather than rebuilding shared logins by habit.

Treated this way, the programme becomes part of running the business, not an all‑or‑nothing project that has to fight for attention. Each completed wave gives you less shared risk, more traceability and better stories for due‑diligence conversations.

Why showing your direction of travel can be as persuasive as the destination

From the perspective of ISO 27001, customers and insurers, being able to demonstrate a credible journey away from shared logins already changes how you are perceived:

Your risk register can show a concrete “before” and “after” picture, with clear owners and target dates.
Change records, approvals and test notes prove that you are not improvising, but following a pattern and learning from each step.
Admin log samples move steadily from anonymous “admin” actions to named, role‑aligned events in the systems that matter most.
Internal review notes confirm that old credentials have been removed, narrowed or tightly wrapped with compensating controls.

When a prospective customer or auditor asks, “how do you manage powerful access across tenants?”, you can then answer with a specific, lived‑in storey rather than a hope. That calm, grounded answer is often what distinguishes providers who are working systematically on privileged access from those who are relying on good luck and good intentions.

How can an MSP handle legacy systems and emergencies without losing control of admin rights?

You handle legacy systems and emergencies by treating them as exception paths with rules, constraints and reviews, rather than as permanent excuses to bypass your privileged‑access model.

Keeping legacy platforms on a short, well‑documented leash

Almost every MSP supports technology that was never designed for modern identity or logging: single‑admin appliances, line‑of‑business systems with weak access control, or hardware that predates role concepts altogether. ISO 27001 recognises these realities; what it looks for is whether you have owned the weakness and wrapped it appropriately.

A pragmatic pattern usually includes:

Recording the limitation clearly in your asset register and risk log, using customer‑ and board‑friendly language.
Restricting where and how the system can be reached, using network segmentation, jump hosts or VPNs.
Storing any unavoidable shared credential in a controlled vault, with named ownership, approvals and logs for each use.
Limiting the number of engineers allowed to use that route, and reviewing their access regularly.

This does not make the system “good as new,” but it shows that you have compressed the exposure and made conscious trade‑offs visible to decision‑makers. It also strengthens your case when you argue that a replacement project is not just “nice to have,” but a logical next step in your risk treatment plan.

Designing emergency access so it is rare, auditable and forgets itself

Serious incidents create pressure to “just get in and fix it,” and people under pressure invent shortcuts. If you do not design emergency access deliberately, those shortcuts can become the invisible back door everyone uses next time.

A more controlled approach tends to have a few consistent elements:

A simple written definition of what counts as an emergency and who can authorise break‑glass access.
Separate credentials or identities: for emergency use, with narrower scopes than your strongest day‑to‑day admins where possible, and stored differently.
Fast rotation or disablement after use, so anything exposed during the incident cannot be quietly reused.
A lightweight but mandatory post‑incident review of each use, even if the situation felt routine.

If you combine that with straightforward guidance to engineers about when and how to invoke emergency paths, you make it more natural for them to use the official route than to improvise. That, in turn, gives you evidence you can show to customers and auditors: a short list of break‑glass episodes, recorded reasons, and checks that nothing was left behind.

Being able to explain how you stay in control when things are at their messiest is increasingly important in enterprise due diligence. Many buyers now ask more detailed questions about emergency access than about day‑to‑day admin, because it is where weak governance often shows most clearly.

What kinds of privileged‑access evidence actually reassure auditors and MSP clients?

The evidence that reassures auditors and MSP clients is the kind that shows design, operation and oversight all pointing in the same direction, rather than a pile of unconnected documents and log files.

Turning scattered artefacts into a single, credible privileged‑access storey

When outside parties look at how you manage powerful rights, they tend to pull on three strands:

How you intend things to work: – policies, role descriptions, diagrams and risk entries that describe your privileged‑access model in plain language.
How things actually work day to day: – onboarding and offboarding records, access‑change approvals, example admin logs and service‑account details.
How you check and improve: – internal reviews, audit findings, follow‑up actions and periodic reconciliations between your design and reality.

For an MSP, a joined‑up view might look like this:

A privileged‑access or access‑control policy that explicitly covers multi‑tenant environments, shared credentials, service accounts and emergency paths, and that references your ISO 27001 controls.
A small number of role definitions that engineers recognise and that map cleanly into the permission sets you use in RMM tools, cloud portals and other key systems.
Evidence that joiners are granted rights based on those roles, movers have their access adjusted when their responsibilities change, and leavers lose admin privileges promptly.
Samples of admin logs from a few critical systems showing named actions tied to those roles, along with review notes or tickets from regular checks.
A simple register of known exceptions – legacy systems, constrained shared accounts, emergency paths – with owners, justifications and review dates.

When that material is fragmented across email, personal folders and unlabelled spreadsheets, even a solid practice can appear weak under scrutiny. When it is structured and cross‑referenced, you can walk an auditor or enterprise buyer from risk to role to log in minutes, which changes the tone of the assessment significantly.

Why a clear privileged‑access storey is starting to differentiate MSPs commercially

Large customers, insurers and regulators increasingly treat privileged access as a quick indicator of overall maturity. If you can answer “who can do what, where, and under which conditions – and how do you know?” with specific, documented examples, you stand out from providers relying on vague assurances.

That clarity is becoming a practical differentiator. Buyers who have been caught out by opaque admin arrangements in the past often probe this area early in the sales cycle. When you can show that your privileged‑access model is designed, implemented and checked in a way that aligns with ISO 27001, you make it easier for them to say yes – and to justify that yes internally.

If you have not done so already, it is worth assembling a small, reusable privileged‑access evidence pack: the core policy, a role catalogue, a few annotated log excerpts and a summary of recent reviews. That one asset often pays for itself quickly in smoother audits, less stressful questionnaires and more confident conversations with the customers you most want to win and keep.

Fixing Privileged Access & Shared Accounts in MSPS Using ISO 2700