Credential Handling Inside the Platform

A provider accumulates administrator credentials for every client it serves. How those are stored and used is the part of the business with the least margin for improvisation.

Controls for “Credential Handling Inside the Platform” need named owners and protected review time as well as technical safeguards. Using the practical overview can make that recurring governance workload visible across the team, but it should never replace access logs, incident evidence or least-privilege administration.

For an independent operational benchmark, compare the local practice with CISA Secure Our World guidance; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What accumulates

Domain administrator accounts at each client.

Local administrator passwords, frequently shared across a client's estate.

Service accounts for backup, monitoring and applications.

Vendor portals, hosting panels, firewall consoles.

And accounts created by technicians for convenience and never recorded.

The shared local administrator problem

One password across every machine at a client is common and is the thing that turns a single compromised machine into the whole estate.

Unique local passwords per machine, rotated, held in a managed system, is the standard answer and the tooling to do it is widely available.

If a client has one shared local password, that is the finding to raise first.

Where credentials should live

A dedicated secrets system with access control and audit, not in the documentation platform's free-text fields, not in scripts, not in a spreadsheet.

Integrated with the RMM where possible so that scripts retrieve rather than embed.

Credentials in script bodies are the recurring finding in reviews of this industry, and they persist in version history long after the script is corrected.

Access to them

Per technician, per client, logged.

A technician serving three clients should not be able to retrieve credentials for the other forty.

This is the control that limits the damage from a single compromised staff account, and it is the one most often absent because it is inconvenient.

Rotation

On staff departure, always.

On client offboarding, always, and it is the client's responsibility to action but yours to prompt.

Periodically for the highest-privilege accounts.

And immediately on any suspicion, without waiting for confirmation.

The accounts nobody recorded

Created during a project, used once, never removed.

They exist in every estate.

Finding them is an audit against the directory rather than against your own records, because your records are precisely what they are missing from.

Telling the client

They should know which accounts you hold and at what privilege.

A list, in their documentation, reviewed annually.

Most clients have never been told and most would be surprised, which is a poor position to be in if something happens.

What to check

Do your clients have unique local administrator passwords?

Are any credentials embedded in scripts?

Can a technician retrieve credentials for clients they do not serve?

And does each client know which accounts you hold?

The point

Credentials embedded in script bodies are the recurring finding in reviews of this industry, and they persist in version history after the script is fixed..

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.