Secure your own MSP tools first

Draw the management boundary

List the tools that administer, monitor or describe client environments. Include the identity provider, password vault, backup console, remote-access services and integrations alongside the obvious RMM and PSA. Record the technical owner and the business owner for each.

CISA's joint MSP advisory AA22-131A describes how a compromised provider can become an access route into multiple customer networks.^[6] The source linked here is the May 11, 2022 advisory preserved by the American Hospital Association, not a claim about today's incident frequency. Its recommendations include MFA, least privilege, logging and separation of customer environments.^[6]

Map the routes between tools and clients. A documentation integration may have broad read access; an RMM integration may be able to run commands. Keep those distinctions visible. Do not reuse administrator credentials across clients, a practice the joint advisory explicitly warns against.^[6]

This is an operating review, not a complete security baseline or a compliance assessment. Use your qualified security owner for the actual control design and authorized change procedures for implementation. If you suspect compromise, use the incident process instead of waiting for the next routine review.

Find every identity, not just every employee

Build an account inventory for each tool. Include named users, privileged accounts, service accounts, emergency identities, vendor support access and integrations. CIS Control 5 covers authorization for user, administrator and service accounts.^[7] Its scope is a useful reminder that a staff list is not an access inventory.

For each account, record its owner, purpose, privilege, authentication method, scope and evidence of continued need. Use safe identifiers and vault references. Passwords, keys and recovery codes do not belong in the inventory sheet.

Compare the roster with the identity system and each tool's own user list. Local accounts, guest identities and vendor access may require separate checks. Record discrepancies as unknown until somebody investigates; a failed export is not an empty account list.

Require named access for ordinary staff work. Keep privileged duties separate from routine email and browsing where the tool and architecture support that separation. Review shared operational accounts as exceptions with a reason and accountable owner rather than letting them disappear into a generic team login.

Check privilege and authentication together

Confirm that each role has only the access its duties need. Inspect client scope as well as the role name. A technician who can read one client's documentation needs a different boundary from an administrator who can export every client record.

CIS Control 6 covers creating, assigning, managing and revoking access credentials and privileges.^[8] Use that lifecycle to structure the review: who approves access, how it is granted, when it changes and how removal is verified.

Check MFA enforcement for ordinary and privileged access, including local or alternate login paths. The joint advisory recommends MFA on MSP accounts that access customer environments and treating those accounts as privileged.^[6] Verify the actual product controls in current vendor documentation; a setting on the main identity provider does not settle every other access path.

Where the tool supports stronger authentication, have the security owner select the method and test enrollment, recovery and lockout behavior. Record a missing capability as an exposure with an owner. Do not call an account protected merely because one enrolled factor appears in a screenshot.

Keep emergency access usable and exceptional

Document who can authorize emergency access, where the secure method is held and how its use is detected. Test it under an approved procedure with a person who may need it. A normal administrator demonstrating their everyday login has not tested the emergency route.

Microsoft's Entra emergency-access guidance calls for regular validation that accounts can sign in and perform administrative tasks, and for monitoring their activity.^[10] It also warns that emergency credentials and devices must not be caught by automated cleanup for inactivity.^[10] Follow current guidance for the actual platform; do not copy an Entra configuration into unrelated tools.

Keep the test result, date and restricted evidence reference in the review sheet. Leave authentication material in the approved secure store. Confirm the route remains available if the normal identity provider or a key staff member is unavailable. The technical owner must evaluate those dependencies rather than assuming an emergency account bypasses every outage.

Inventory the integrations and keys

List each integration's source, destination, accountable owner, identity, granted scope and approved purpose. Include API keys, OAuth grants, webhooks, automation runners and scheduled exports. Note whether it can read, write, execute commands or create a new integration.

Check that the scope matches its job. A report-only workflow should not inherit global write privileges for convenience. Give new automations a narrow authorized identity where supported, with a way to stop access independently of ordinary staff accounts.

Record credential expiry or the rotation rule required by your policy and vendor guidance. Identify downstream jobs before changing a credential. A key can be unused according to one tool and still support a monthly reconciliation. Verify dependencies, test replacement and retain a safe fallback before an authorized rotation or removal.

Offboard across the boundary

An approved staff departure should trigger checks in the identity provider, management tools, vault access, vendor portals and integrations owned by that person. Reassign service-account ownership instead of leaving it attached to a departed employee.

Verify removal in the receiving systems and review sessions, tokens and shared-secret exposure under each vendor's procedure. Disabling an ordinary login is not evidence that every separate credential has been removed. The joint advisory recommends disabling obsolete accounts and reviewing infrastructure that no longer serves a purpose.^[6]

Automate the roster comparison, task creation and missing-evidence reminders where the inputs are reliable. A person still authorizes the departure scope, distinguishes an emergency identity from a stale account and reviews the completion evidence. Automatic deletion based only on last-login age is a poor first workflow.

Make alerts reach somebody

Collect the events the security owner needs to detect misuse and reconstruct activity. Consider privileged sign-ins, role changes, new integrations, unusual exports, remote-command activity and emergency-account use, according to each tool's available logs.

CIS Control 8 calls for collecting, alerting, reviewing and retaining audit logs.^[9] The joint MSP advisory recommends logging delivery-infrastructure activity and maintaining a segregated logging regime.^[6] Decide retention, access and incident use with the security owner; this sheet does not set a universal retention period.

Run an authorized test event. Confirm its timestamp, tool and identity appear where expected, the alert reaches a receiving person and that person can find the response instruction. Test a missing-log or failed-collector condition too. A silent dashboard cannot tell you whether nothing happened or collection stopped.

Test recovery and count the review work

Identify what you need to recover the management service: configuration, operational records, secure access, vendor support routes and instructions available during a tool outage. Use the approved recovery process to test a representative restore or recovery task. Record scope, outcome and remaining gaps. A successful backup job alone is not restore evidence.

Remove unused integrations after dependency checks, standardize access requests and offboarding evidence, then automate reconciliations and alerts. Keep authorization, incident judgment and recovery ownership with people. Measure maintenance and review effort before crediting capacity to the change; security work can remain necessary even when automation produces no net hours saved.

The working discipline

Automate before you hire

Remove unused access after dependency checks and standardize account, integration and offboarding records. Automate roster comparisons and tested alerts, while people approve access changes, evaluate exceptions and own incident response and recovery.

Review the sequence →

Worksheet / Usable takeaway

MSP tooling review sheet

Review boundary: [tools / client-management routes / excluded systems / review date].
Accountable owners: [business / technical / security / receiving alert owner].
Tool record: [platform / vendor documentation URL / version or plan / evidence date].
Identity record: [safe account ID / person or service owner / purpose / client scope].
Access evidence: [role / need checked / local or alternate paths / MFA enforcement result].
Privileged and emergency access: [separate duties / authorization / restricted method reference / last test / gaps].
Integration record: [source / destination / identity / owner / read-write-execute scope / purpose].
Credential lifecycle: [safe vault reference / expiry or rotation rule / dependencies / last replacement test].
Offboarding check: [authorized event / systems checked / tokens and shared exposure reviewed / receiving owner].
Logs and alerts: [events / retention basis / restricted destination / collection-failure signal].
Alert test: [authorized event / time / received by / response instruction found / result].
Recovery test: [scope / date / outcome / remaining gap / secure evidence reference].
Status: [met / unmet / unknown / scoped exception with authority and review date].
Action: [exposure / correction / owner / due date / outcome check].
Automation boundary: [repeatable checks / human decisions / maintenance effort / pause route].

Open the worksheet: MSP tooling access and recovery review Download (Markdown)