How ISO 27001 A.5.17 Protects MSP Credentials From Multi-Tenant Breaches

Why are MSP credentials now the primary attack path?

MSP credentials are now a primary attack path because one privileged account can unlock many customer environments at once. Every technician login, token or API key concentrates risk across your portfolio, not just one client. Attackers see your MSP as a hub, so if they capture the right identity they can pivot quickly across tenants and turn your operational reach into their leverage at scale. Identity and access management guidance from national cyber security bodies, such as the NCSC’s 10 Steps advice on identity and access management, also highlights that compromise of privileged identities is one of the most common paths into organisations, which makes those identities especially critical in a multi‑tenant MSP model.

This information is general and does not constitute legal or compliance advice; you should always seek professional guidance for your specific situation.

Most organisations in the 2025 ISMS.online survey say they have been impacted by at least one third-party or vendor security incident in the past year.

The MSP-wide blast radius of a single credential

A single compromised technician account or tool credential can give an intruder almost the same reach your team has. In a multi‑tenant MSP stack, that can mean access to remote management consoles, cloud portals, backup systems and vendor dashboards that all trust the same identity. One mistake can therefore seed simultaneous incidents across many customers instead of a single isolated breach. Analyses of major supply‑chain and service‑provider breaches repeatedly show how compromise of a single service account, integration key or MSP tool credential can cascade rapidly across many downstream organisations.

Once an attacker holds that identity, they can move laterally across tenants, deploy malware as if they were part of your staff and tamper with logs or backups to hide their tracks. The result is not just downtime for one customer; it can be long‑term client loss, contractual penalties and serious reputational damage that undermines your growth plans.

Why traditional credential habits fail in multi-tenant environments

Traditional habits such as sharing admin passwords, saving credentials in browsers or keeping them in unstructured notes were barely tolerable in a single‑organisation network; they are unacceptable in an MSP. Your engineers move quickly between tenants, tools and support tasks, and convenience‑driven shortcuts are inevitable when there is no central way to work safely. In a multi‑tenant context, those shortcuts expose many environments at once.

If you still rely on shared global admin accounts or browser‑saved passwords, you already know how uncomfortable audits and customer questions can feel. These behaviours also destroy accountability. If several engineers share one account, you cannot see who did what, so you struggle to answer customer queries or audit questions with confidence. Regulators and enterprise buyers now expect privileged access to be individual, time‑bound and monitored, and they treat weak practices around authentication information as a direct business risk. Industry commentary increasingly describes identity as the new security battleground, with insurers and large buyers focusing on whether privileged access is tied to named users, constrained in time and auditable.

ISO 27001:2022 control A.5.17 was introduced to address the wider set of modern risks around authentication information, encouraging organisations-including MSPs-to move away from informal secret‑handling practices towards managed, auditable controls. It expects you to move from informal habits to a managed process where allocation, use, monitoring and revocation of authentication information are deliberate, documented and reviewable across all the environments you touch.

Book a demo

What does ISO 27001 A.5.17 actually expect from an MSP?

ISO 27001:2022 A.5.17 expects you to treat authentication information as a managed asset with a clear lifecycle. For an MSP, that means every password, token, key, PIN and recovery factor you handle for internal systems or customer environments must be created, stored, used, changed and revoked under rules you can explain and evidence. Owners, security leads and operations managers all need to be able to show how those rules work in practice. The wording of A.5.17 in ISO/IEC 27001:2022 makes clear that authentication information should be governed as part of your ISMS, with defined creation, use, change and revocation activities rather than ad hoc decisions.

Turning dense control language into plain English

The essence of A.5.17 is that any secret proving identity is managed deliberately, not left to personal preference or tribal knowledge. In plain English, the control expects you to define at least:

Who can request a credential.
Who approves that request.
How strong the credential must be.
How it is delivered to the user or system.
Where it is stored and protected.
When it must be reviewed or changed.
How misuse or compromise is detected.
How and when it is revoked.

These decisions should be consistent across your internal environment and your customer work. Your own service desk, remote monitoring and management (RMM) and professional services automation (PSA) platforms, documentation systems, backup consoles, source control and identity providers are clearly in scope. So are customer cloud tenants, on‑premises domains, firewalls, SaaS consoles and third‑party vendor portals where your staff use or store credentials for day‑to‑day work.

According to the 2025 ISMS.online survey, many customers now expect their suppliers to align with formal frameworks such as ISO 27001, ISO 27701, GDPR, Cyber Essentials and SOC 2.

You cannot simply say “those are the customer’s credentials” if your people handle them regularly. If a secret is created, stored, used or supported by your team, it falls under your A.5.17 process and needs to be covered by your policies, procedures and evidence, even when the system technically belongs to the customer.

Scoping “authentication information” so you do not miss anything

A.5.17 expects you to be precise about what “authentication information” means in your context rather than focusing only on obvious passwords. Supporting guidance in ISO/IEC 27002:2022 for control A.5.17 explicitly broadens the term to cover tokens, keys and other secrets used to prove identity, not just passwords. In practice, that means including less visible secrets alongside user credentials so they are not forgotten in your control design. When you start listing them, the number of different secret types in a multi‑tenant MSP can be surprising.

You will usually need to account for items such as:

API keys, client secrets and tokens used in automation and integrations.
SSH keys, certificates and VPN pre‑shared keys used by engineers and tools.
Recovery codes and hardware token seeds for multi‑factor authentication.
Biometric templates on devices or systems you configure or administer.

A structured scoping exercise identifies where these items exist, which systems they protect and which teams use them. From there, you decide which policies and procedures need updating, which tools must be brought into your information security management system (ISMS) and where new controls are required. The aim is that when an auditor, customer or insurer asks “how do you manage authentication information?”, you can show a clear end‑to‑end lifecycle rather than a collection of disconnected practices.

To reinforce that shift, it helps to contrast legacy habits with A.5.17‑aligned practices:

Area	Old habit	A.5.17‑aligned practice
Credential creation	Ad hoc account creation	Approved, logged and linked to a risk/control
Storage	Browser, notes or shared spreadsheets	Central vault with role‑based access
Rotation and revocation	Only after incidents	Scheduled reviews plus event‑driven revocation
Evidence	Screenshots in email chains	Controlled records linked to ISMS controls

Seeing the differences laid out like this makes it easier for teams to appreciate why the control matters and where daily work needs to 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

Where do MSPs really leak and misuse authentication information today?

MSPs often leak and misuse authentication information in more places than leaders expect because secrets appear in many tools, workflows and shortcuts. When you look closely at technicians’ daily work, it is common to find credentials scattered across browsers, chat logs, tickets, personal password managers, documentation systems and scripts. A.5.17 pushes you to acknowledge those realities and decide how they will be governed.

Hidden credential sprawl across tools and teams

The first surprise in most MSPs is how many non‑user secrets exist that nobody actively owns. Beyond named user accounts, you will typically discover:

Shared administrator logins for RMM, PSA, backup and documentation tools.
Service accounts in customer domains for monitoring, backups or integrations.
Long‑lived API keys for cloud services, webhooks or vendor APIs.
Encryption keys and certificates held informally on engineers’ devices.

Many of these secrets have no clear owner, no documented purpose and no expiry date. They may have been created during a migration, project or emergency and then left untouched because they “just work”. Industry studies on credential habits report similar patterns, with numerous high‑value accounts lacking clear ownership, documentation and defined expiry in many organisations, as highlighted in work such as the Security Credential Habits study. Because these secrets run quietly in the background, they are rarely included in routine access reviews or risk assessments, yet they are attractive targets: powerful, predictable and often poorly monitored.

In the 2025 ISMS.online State of Information Security survey, about 41% of organisations named managing third-party risk and tracking supplier compliance as a top security challenge.

A.5.17 gives you a reason-and a requirement-to bring these hidden assets into a controlled inventory. Implementation commentaries on A.5.17 emphasise that organisations should identify and manage all forms of authentication information, which naturally leads to maintaining an inventory of such secrets as part of the control scope. That inventory is the foundation for any serious attempt to reduce attack surface and demonstrate control to customers, auditors and insurers who want to understand how you manage privileged access.

Everyday habits that undermine even strong technology

Even if you roll out modern tools, everyday human habits can undermine them quickly. Engineers may export passwords from a vault into a spreadsheet so they can “work offline”, paste admin passwords into tickets or chat for convenience or re‑use personal secrets when creating new accounts. Multi‑factor authentication may be enforced on flagship systems but quietly disabled or bypassed where it slows people down.

If your secrets are still scattered across browsers, chat and personal tools, you already know how hard it is to reason about risk. These behaviours are understandable under time pressure, but they directly conflict with A.5.17’s expectation of controlled allocation and management. They also make it hard to answer basic questions after an incident, such as “exactly which secrets could this compromised laptop have exposed?” or “which customer tenants were at risk from this account?”. Without those answers, your incident response and customer communication quickly lose credibility.

Small design changes help reduce the need for unsafe workarounds, for example you can:

Disable browser password storage for administrative accounts.
Block exports from your central vault by policy and technical controls.
Require multi‑factor authentication for all privileged roles, not just headline systems.

These moves do not remove all human risk, but they shrink the space where informal workarounds can quietly erode your control environment and create hard‑to‑trace credential exposure.

How should you design an A.5.17‑aligned multi-tenant authentication strategy?

An A.5.17‑aligned authentication strategy for MSPs classifies credentials by impact and sets minimum protections per tier. Once you understand your credential landscape, you can move from individual habits to a defined model where different types of secrets have clear treatment rules. The goal is that compromise of one credential does not automatically endanger every customer tenant you support.

Defining credential tiers and minimum protections

A practical way to start is to define tiers of authentication information based on impact and then attach clear minimum controls to each tier. This lets you scale sensible rules across tenants instead of negotiating every account individually. Staff also learn quickly which secrets demand stricter handling and why certain steps are non‑negotiable.

You might define tiers such as:

Tier 1 – Break‑glass and platform owners: emergency accounts, identity provider super‑admins, core RMM and PSA owners.
Tier 2 – Tenant and system administrators: customer tenant admins, domain admins, firewall admins, high‑privilege SaaS roles.
Tier 3 – Engineering and support roles: named staff accounts with elevated but constrained privileges in tools and tenants.
Tier 4 – Service and automation identities: service accounts, scripts, schedulers and API integrations.
Tier 5 – Standard user accounts and low‑risk secrets.:

For each tier, you define minimum controls such as multi‑factor authentication, storage requirements, rotation frequency, monitoring expectations and approval processes. That turns vague guidance into concrete rules like “Tier 1 and 2 secrets live only in the vault, are accessed through a privileged workflow and are rotated automatically every ninety days or after any incident”.

The value of this model is that it scales. As you add tenants, tools or regions, you classify new credentials into the right tier and apply the same baseline protections, rather than inventing new rules each time. Over time, staff think in tiers and understand why some secrets have stricter handling expectations.

Balancing ambition, legacy constraints and business goals

It is tempting to design a perfect model where no privileged account exists without just‑in‑time elevation and every secret is rotated daily. In reality, you must balance ambition with the constraints of legacy systems, customer budgets and your own capacity. Some systems cannot support modern models yet, and some customers will only move at a certain pace.

You might decide that “no standing privilege” is achievable for cloud tenant admin roles using built‑in privileged identity management features, but that certain on‑premises systems will rely on traditional accounts for now. You document this, specify compensating controls such as tighter monitoring or stricter physical security, and schedule periodic re‑evaluation to avoid indefinite exceptions.

It is also important to keep business goals in view. Your strategy should support fast customer onboarding, smooth integration of acquisitions and compliance with sector‑specific expectations such as financial or healthcare regulations. Used this way, A.5.17 becomes less of a compliance checkbox and more a way to reduce the risk that one set of credentials can undermine your entire service portfolio.

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

Book your demo

What architectures actually work for vaults, PAM, KMS and JIT in an MSP stack?

MSPs benefit from a simple reference architecture that combines identity, secrets vaulting, privileged access management and key management into one coherent design. The aim is to reduce how often staff need to see or handle raw secrets while still supporting real‑world workflows. When these building blocks work together, you gain the visibility and control A.5.17 expects without paralysing your engineers.

A practical reference architecture uses a central identity provider, a shared vault, a privileged access management layer and structured key management that all reinforce each other. Staff authenticate once, receive the right level of access and rarely handle raw secrets directly. This reduces attack surface and makes it easier to prove to customers and auditors that you manage authentication information consistently.

A typical pattern for an MSP looks like this:

Identity provider at the centre: all staff authenticate via a central identity platform enforcing strong multi‑factor authentication and conditional access.
Secrets vault for human‑used credentials: administrators avoid browsers or notes and use a central vault to retrieve privileged passwords when needed.
PAM workflows for high‑risk operations: technicians request approved, time‑bound elevation instead of using shared admin logins for tenant administration.
Key management for cryptographic material: encryption keys and certificates are managed in a dedicated system that enforces rotation and records usage.

In this design, the vault, PAM and key management system integrate with your identity provider so access to them is governed centrally. Staff identities map to roles, and those roles determine which secrets they can use and under what circumstances. This directly supports A.5.17’s emphasis on controlled allocation, secure use, monitoring and revocation of authentication information.

Designing for tenant separation, resilience and real workflows

An MSP‑specific design must also account for tenant separation and resilience so you can keep services running safely. You need to be able to answer questions such as:

How do you ensure an engineer with access to many tenants cannot easily cross boundaries when using privileged tools?
Will you use a single central vault for all customers, or separate logical or physical vaults for different segments or high‑risk clients?
What happens if the vault, identity provider or PAM service is unavailable during an incident or major outage?

Answers will depend on your size and risk appetite, but they should be explicit rather than assumed. Many MSPs adopt patterns such as per‑tenant roles in RMM and cloud platforms, per‑tenant logging where possible and clear separation of duties between engineers who design access and those who approve or review it.

Day‑to‑day realities also need attention. Remote support sessions, scripting, out‑of‑hours troubleshooting and project work all create pressure for shortcuts if your architecture is too rigid. Bringing operational leaders into the architectural conversation early helps you design patterns that are both secure and workable for your technicians.

A platform such as ISMS.online can help you document and track this architecture alongside the policies, risks and controls that support it, so you can evolve the design without losing sight of why it looks the way it does or how it supports A.5.17.

How do you run lifecycle operations for MSP secrets in practice?

Lifecycle operations turn your strategy and architecture into daily behaviour by defining how secrets are requested, created, used, rotated and revoked. A.5.17 expects that secrets are not only created securely but also changed, retired and reviewed in a disciplined way. For MSPs, this lifecycle must cover staff movements, customer onboarding and offboarding, tooling changes and incident response across many tenants. Guidance for A.5.17 in ISO/IEC 27002:2022 reinforces this by describing lifecycle activities such as registration, management, revocation and replacement of authenticators.

Defining standard workflows for creation, rotation and revocation

A robust lifecycle model covers the full journey of each credential or key, from request to retirement. It turns ad hoc reactions into a repeatable sequence of steps so that different credential types follow consistent paths with appropriate approvals, checks and evidence at each stage. That consistency is what makes lifecycle management visible and auditable.

You can express the lifecycle as five simple steps.

Step 1 – Create with purpose and approval

Creation is requested through a defined process, justified with a business reason and approved where risk is high. Secrets are generated using secure defaults such as strong randomness and unique values, not reused patterns.

Step 2 – Store and distribute securely

New secrets go straight into the appropriate vault or system and are delivered to staff or systems using encrypted channels. They are never copied into uncontrolled locations such as email, chat or personal notes, even temporarily.

Step 3 – Use with least privilege and logging

Use is mediated by tools that enforce least privilege, apply multi‑factor checks where appropriate and log who used which credential, for what purpose and when. Staff use named accounts instead of shared logins wherever possible.

Step 4 – Review and rotate regularly

Secrets are revisited on a defined schedule to confirm need, adjust privileges and rotate values. Additional rotation is triggered by events such as role changes, suspected compromise, vendor advisories or significant architectural updates.

Step 5 – Revoke and destroy cleanly

When a secret is no longer needed, it is revoked promptly and removed from vaults, systems and documentation. Cached copies are cleared so the credential cannot be accidentally reused in scripts, notes or old playbooks.

Some of these steps can be automated; others rely on human discipline. The important point for A.5.17 is that each category of credential has a clear lifecycle path and that you can show auditors and customers where you follow it and how you handle exceptions.

Handling exceptions, emergency access and human factors

No lifecycle is complete without clear rules for exceptions and emergencies. There will be systems that cannot support modern authentication, and there will be times when normal access paths fail and you need break‑glass options. A.5.17 does not forbid this; it expects you to control it visibly and thoughtfully.

For exceptions, you can assign a risk owner, document why the exception exists, define compensating controls such as extra monitoring or stricter physical security and give it an expiry date for re‑evaluation. That turns what could be a permanent weakness into a managed, time‑bound risk you can discuss openly with customers and auditors.

For emergency access, you can define how special accounts are created, where the credentials are stored, who can use them, how use is logged and how the credentials are rotated or revoked after use. That way, you preserve both availability during crises and accountability afterwards.

You also need to plan for human realities: staff leaving unexpectedly, contractors completing engagements, mergers and acquisitions changing who owns which systems or tenants. Integrating joiner‑mover‑leaver processes across HR, customer‑relationship systems and identity platforms dramatically reduces the chance that privileged accounts are left orphaned. When these lifecycle processes are captured as workflows in your ISMS, with clear owners and evidence, it becomes much easier to show auditors and customers that A.5.17 is not just a policy on paper.

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

Book your demo

How do you govern, evidence and stay audit-ready for A.5.17?

Governance is where the control language, architecture, workflows and daily behaviours come together into a storey outsiders can understand. When auditors or enterprise customers assess you, they want to see not just that you own good tools but that you govern authentication information coherently and can prove it. Governance helps you show that your controls are real rather than aspirational.

Governance makes the way you already work visible, intentional and easier to improve.

Building an evidence storey that makes sense to outsiders

A.5.17‑related evidence usually falls into several buckets that together describe how you manage authentication information across your MSP. Thinking in those buckets helps you collect proof that is meaningful to auditors and customers rather than a pile of unconnected artefacts. Best‑practice implementation guidance for A.5.17 and broader ISMS operation frequently organises evidence in this way, so that policies, configurations, logs and training records jointly illustrate how authentication information is governed in practice.

Typical evidence sets include:

Policies and standards: that define how authentication information is requested, approved, created, stored, used, rotated and revoked.
Procedures and runbooks: that explain how you handle scenarios such as onboarding, tenant admin creation or suspected credential compromise.
Configuration records: from vaults, privileged access systems, identity platforms and key management tools that show how design matches policy.
Logs and reports: that demonstrate how secrets are actually used, including privileged session records, access reviews and rotation events.
Training and awareness records: that prove staff have been briefed and have acknowledged key responsibilities for handling authentication information.

The strongest evidence sets tie these items together into concrete examples that matter. For instance, you might show a standard for managing API keys linked to a risk register entry on third‑party integrations, a runbook for regenerating keys and the associated logs showing recent rotations. That kind of traceability reassures auditors and customers that your practice is deliberate and monitored, not improvised.

You can think of this as telling a clear storey: “Here is our rule, here is how we implement it, here is how we check it and here is proof that it really happens.” When that storey is consistent across tenants and tools, your governance posture feels credible rather than cosmetic.

Embedding A.5.17 into your governance rhythm

Governance works best when it is part of your regular rhythm, not a scramble before an external audit. You can embed A.5.17 into that rhythm by:

Scheduling periodic reviews of high‑risk credentials and keys, where owners confirm necessity, adjust privileges and verify that storage and rotation meet requirements.
Reviewing logs and alerts related to privileged access and secret usage, and treating anomalies as triggers for both incident response and process refinement.
Incorporating lessons from incidents, near misses and penetration tests into updated policies, standards and architectures.
Including A.5.17 status in management reviews and risk committee updates, aligning with ISO 27001’s expectation that top management periodically consider the status of controls and residual risk across your ISMS.

About two-thirds of respondents in the 2025 ISMS.online survey say the speed and volume of regulatory change are making compliance harder to sustain.

If you still prepare evidence in shared folders and emails a few weeks before each audit, you know how stressful that can be. An ISMS platform such as ISMS.online can make this easier by acting as the single place where you define A.5.17 controls, link them to risks, assign owners, capture evidence and schedule reviews. Instead of relying on ad hoc documents and spreadsheets, you get a living system that reflects how authentication information is actually managed and where improvement is still needed.

When governance is visible in this way, A.5.17 drives better decisions. You are no longer guessing which secrets matter most or hoping that good habits hold; you are using evidence to steer your MSP towards fewer surprises and more resilient customer relationships.

Book a Demo With ISMS.online Today

ISMS.online helps you bring A.5.17 to life by connecting your policies, risks, architectures and evidence in one structured system so you can show auditors and customers that you treat authentication information as a critical asset. For MSP leaders and security teams, that means your credentials and secrets become a source of confidence rather than anxiety, even as your customer base grows.

See your A.5.17 storey end-to-end

When you explore ISMS.online, you can see how it helps you turn a technical control into a clear, auditable narrative. Instead of chasing screenshots and spreadsheets before each audit, you work in an environment that links risks, controls, actions and evidence as you go. That shift makes it easier to brief stakeholders and prove to demanding customers that you run a disciplined operation.

In the 2025 ISMS.online survey, almost all organisations listed achieving or maintaining security certifications such as ISO 27001 or SOC 2 as a top priority.

You can use ISMS.online to:

Capture A.5.17 policies and standards in clear language that non‑specialists can understand and follow.
Map secrets and privileged access risks across internal systems and customer environments in one view.
Link specific control activities-such as credential rotation or access reviews-to risk register entries and audit requirements.
Store and reference evidence such as configuration screenshots, export files and meeting notes without hunting through email and file shares.

This kind of end‑to‑end view turns control A.5.17 from a line in a standard into a narrative you can stand behind when customers or auditors ask difficult questions. It gives you a single, coherent place to track how your MSP allocates, uses and revokes authentication information across many tenants and tools.

Plan your next ninety days with confidence

A short, focused implementation plan is often more valuable than a distant grand vision. With your team and an ISMS.online specialist, you can shape the next three months around a few concrete moves that strengthen A.5.17 in practical ways without overwhelming staff or disrupting customer service. In practice, many busy MSP teams find that working to a focused ninety‑day plan is more manageable than trying to tackle everything at once.

Step 1 – Build a realistic credential inventory

Identify your highest‑risk credentials, service accounts, API keys and key stores, and record where they live, which systems they protect and who owns them.

Step 2 – Establish baseline policies and standards

Define practical policies and standards for authentication information that reflect your MSP’s size, toolset and existing processes, and assign clear owners for each document.

Step 3 – Stand up essential lifecycle workflows

Implement a minimal set of workflows for creation, rotation, review and revocation of privileged accounts and keys, including clear triggers and responsibilities for each step.

Step 4 – Assemble a starter evidence pack

Collect initial evidence showing meaningful progress against A.5.17 so you can brief stakeholders, insurers and auditors with confidence and plan further improvements.

From there, you can iterate, adding sophistication as your people, processes and architectures mature, without losing sight of the fundamentals you have already put in place. Small, consistent steps build a much stronger posture than occasional big pushes before audits, and a ninety‑day plan feels like a realistic horizon for most MSP teams.

If you want your credentials and secrets to support your growth instead of silently undermining it, choosing ISMS.online as the home for your ISMS is a practical next step. It gives you a framework, content and workflows shaped by real ISO 27001 experience, so you are not starting from a blank page or trying to glue together scattered documents. That makes it far easier to deliver an A.5.17 implementation that protects your customers, supports your technicians and strengthens your business.

Book a demo

Frequently Asked Questions

How does ISO 27001:2022 A.5.17 really change authentication for an MSP?

ISO 27001:2022 A.5.17 effectively turns every password, token and key your MSP touches into a governed asset with clear rules, ownership and evidence, not just “things people remember or store somewhere”. You are expected to define how authentication information is created, protected, used, rotated and revoked, and to prove that consistently across your own stack and every customer tenant you manage.

Where does A.5.17 actually reach in an MSP environment?

For a typical MSP, A.5.17 reaches well beyond staff logins or a single password manager. It reshapes how you handle authentication in:

RMM and PSA platforms: that can reach hundreds of endpoints and customer tenants.
Documentation and knowledge systems: where “how‑to” steps and passwords often get mixed together.
Backup, monitoring and DR consoles: that quietly hold broad, persistent access.
Cloud tenants and identity providers: where a few roles can change everything.
Vendor portals and licencing systems: used to manage entitlements across customers.

Instead of relying on tribal knowledge or scattered notes, you’re expected to:

Maintain a dependable view of who can reach what across internal and customer systems.
Apply simple, repeatable rules for issuing, protecting, rotating and revoking each type of credential.
Make sure joiner–mover–leaver changes actually remove access and trigger rotations where needed.
Hold enough structured evidence that you can explain your approach calmly to auditors and enterprise buyers.

When you capture these rules, responsibilities and workflows in a structured Information Security Management System (ISMS) such as ISMS.online, you move from “we think it’s under control” to being able to show exactly how authentication information is governed in a multi‑tenant, tool‑heavy MSP world.

The real shift is not stricter passwords; it is treating every secret as an asset with a lifecycle you can explain and prove.

How can an MSP reduce the impact when a powerful credential is inevitably stolen?

You reduce impact by assuming at least one valuable credential will be compromised and designing your environment so that it unlocks as little as possible, for the shortest realistic time, with clear traces when it’s used. A.5.17 encourages you to engineer for a smaller, more visible “blast radius” instead of betting everything on never losing a key.

What does a smaller blast radius look like in day‑to‑day MSP practice?

In most MSPs, a practical pattern set looks like this:

Named admin identities only: retire shared “global admin” accounts and tie elevated roles to individual users in your identity provider with strong multi‑factor authentication.
Role‑based access across core tools: align RMM, PSA, cloud platforms and documentation systems to “least privilege for role, customer group and geography”, not “everyone can do everything everywhere”.
Just‑in‑time elevation: grant full admin rights only for a specific task and time window, then automatically drop back to lower privileges.
Controlled admin entry points: force privileged work through hardened paths (for example, privileged access management, bastion hosts or tightly controlled jump boxes), rather than any laptop on any network.
Centralised logging and alerting: send privileged activity logs to a common place so unusual actions stand out and can be tied back to real people, tickets and timeframes.

Designed this way, a stolen technician password remains serious but stops being a skeleton key for “every customer at once”. When you record these design choices in your ISMS and link them to A.5.17, you can show auditors, insurers and demanding customers that you have deliberately engineered down the blast radius instead of hoping compromise never happens.

What belongs in a hardened credentials and secrets playbook for an MSP?

A hardened playbook explains how you group credentials into tiers, the minimum safeguards each tier must have, and how you run and improve those safeguards over time. It replaces “everyone knows to be careful” with “we follow this model every day, and these records show it”.

Which elements matter most for a multi‑tenant MSP?

For most managed service providers, a useful playbook includes:

Clear credential tiers: for example, break‑glass accounts, platform‑wide admin in RMM and cloud, tenant‑level admin, engineer accounts, service accounts and automation secrets.
Baseline safeguards per tier: multi‑factor authentication expectations, where secrets are stored (vault vs. platform), maximum lifetime, rotation cadence, logging depth and review frequency.
Standard tooling combinations: how you use your identity provider, password or secrets vault, remote access stack and logging tools together so the rules are enforced without slowing engineers to a crawl.
Exception and legacy handling: how you document and contain older platforms, niche vendors or inherited environments that cannot yet meet your ideal standard.
A simple change roadmap: which safeguards you will tighten this quarter, this year and before major contract renewals or platform changes.

When you model this playbook in ISMS.online as policies, standards, linked assets, risks and controls, it stops living in one senior engineer’s notebook. It becomes something you can teach new staff, review with leadership and present to auditors or enterprise risk teams as your clear, stable approach to credentials and secrets.

How should an MSP handle service accounts, API keys and automation secrets differently?

Service accounts and automation keys need to be treated as powerful identities with owners, scopes and expiry, not quiet configuration details that sit untouched until something breaks. They often hold wide, long‑lived access and no named human identity, which makes them attractive to attackers and easy to overlook if you do not manage them on purpose.

What does good governance of non‑human identities involve for an MSP?

Effective governance usually rests on a few habits:

Maintaining a live inventory: of service accounts, API keys and automation secrets across RMM, backup, monitoring, cloud platforms, vendor portals and internal tooling.
Assigning an accountable owner and purpose: to each non‑human identity, with documented least‑privilege scopes and a clear record of where it is used.
Centralising secret storage: in a controlled vault or platform, instead of scattering values across scripts, tickets, shared folders, wikis or local configuration files.
Defining and enforcing rotation triggers: scheduled rotations plus changes after staff departures, vendor incidents, platform breaches or major configuration changes.
Including non‑human identities in reviews and incidents: routine access reviews, incident triage and post‑incident analysis should always ask “which automations and integrations might be affected or abused here?”

When you manage non‑human identities through your ISMS, with consistent policies, risks, controls and evidence, you can show that A.5.17 covers the quiet automation layer of your stack as thoroughly as human administrators. That reassures larger customers who worry most about integrations and scripts that could grant broad, unseen access if mishandled.

How can an MSP show that A.5.17 is operating in reality, not only on paper?

You show A.5.17 is real by tying together what you say in policies, how you have designed your environment and what actually happens day to day. Auditors and enterprise customers are looking for a storey they can follow: “this is our policy, these are the controls and tools we use, this is how we test them, and these examples show recent activity”.

Which kinds of evidence usually convince auditors and enterprise buyers?

Evidence that typically lands well for A.5.17 includes:

Policies and detailed standards: that describe how you issue, protect, rotate and revoke credentials and secrets across internal and customer systems, in language engineers can follow.
Configuration exports or screenshots: from identity providers, vaults, privileged access tools and key management services that demonstrate those standards enforced in real settings.
Activity logs and reports: showing privileged actions, secret rotations, access reviews and incident handling over time, not just for a single week.
Training and acknowledgement records: for staff who handle high‑impact authentication information, especially those with access to multiple tenants.
Outputs from internal audits and management reviews: where you have challenged your own approach, captured findings and recorded specific improvements.

If you link all of this inside ISMS.online as controls with mapped risks, owners, actions and attached evidence, you avoid last‑minute hunts through old tickets and screenshots. Instead, you maintain a steady “A.5.17 storey” you can put in front of boards, insurers and customer risk teams whenever they ask how you manage access to your own and your customers’ estates.

When you can show changes, not just policies, people stop worrying that your security lives in slides rather than systems.

How can ISMS.online help an MSP implement A.5.17 without overwhelming engineers?

ISMS.online helps you design, operate and evidence your A.5.17 approach in one structured environment instead of spreading policies across folders and evidence across email threads and chat history. It lets you focus first on the highest‑impact credentials and secrets, demonstrate progress quickly, then extend coverage at a pace your team can realistically support.

What are sensible, low‑friction steps for the next ninety days?

Many MSPs make visible progress in a short period by:

Building a focused inventory: of their most powerful admin accounts, service accounts and API keys across core platforms such as RMM, PSA, cloud identity, backup and remote access.
Agreeing honest baseline policies and standards: for authentication information that reflect how they work today, then storing them in ISMS.online with named owners, review dates and linked controls.
Capturing a handful of core workflows: -for example, admin account provisioning, privilege changes, revocation and break‑glass use-inside ISMS.online and tying them to associated risks and evidence.
Assembling a starter evidence pack: that shows real movement against A.5.17, including at least one access review, one rotation event and one internal check, ready to brief leadership and answer tougher customer questions.

From there, you can widen coverage across more tenants and tools, refine your architecture as maturity grows and embed regular reviews without turning every improvement into a major project. If you want credentials and secrets to support growth instead of silently expanding your exposure, using an ISMS like ISMS.online to make your first ninety‑day plan visible, owned and achievable is a strong way to start.

A.5.17 Authentication Information – Hardening MSP Credentials & Secrets