← All news
ARTICLE
16 October 2026 Updated on 26 September 2026 2 min read

MSP FAQ: keep human and machine access separate across tenants

Service accounts and automation tokens now outnumber human users at most organizations. OWASP's NHI guidance says they need their own identities and lifecycle.

In this article
  1. Why NHIs need separate governance
  2. Short-lived over standing
  3. What this means in an MSP's tenant model

MSPs juggling technician access and automation across dozens of customer tenants face a specific version of a growing industry problem: non-human identities — service accounts, API keys, automation tokens — need to be governed differently from the humans who create them.

Automated fare gates at a subway station entrance for card-based access
Photo: Secondarywaltz (CC BY-SA 4.0), Wikimedia Commons.

Why NHIs need separate governance

OWASP's Non-Human Identity Top 10 project notes that machine identities are not intrinsically tied to a person and that common human security controls, such as MFA, do not map cleanly onto them. The mismatch is mainly about lifecycle: when a technician leaves, their account is usually disabled within hours, but the service accounts and API keys they created can keep running with full permissions unless someone explicitly finds and revokes them. Because non-human identities can outnumber human accounts by a wide margin in modern environments, an MSP that governs both the same way is effectively leaving its largest identity population unmanaged.

Short-lived over standing

The consistent recommendation across OWASP and the Cloud Security Alliance is to replace long-lived secrets with ephemeral, short-lived tokens that expire automatically, rather than credentials that work indefinitely once issued. A leaked long-lived token gives an attacker unconstrained time; a token that expires in minutes to hours bounds the damage even if it leaks.

What this means in an MSP's tenant model

  • Use distinct identity providers or service principals for human technicians versus automation.
  • Never let a technician's break-glass credential double as a pipeline's service credential.
  • Bind machine tokens to a single customer tenant — never issue a standing key that spans every tenant.
  • Keep token lifetimes measured in minutes to hours, and rotate on any personnel or automation change.
  • Log identity class (human or non-human) alongside tenant ID on every access record.

The fix is not a single tool but a governance habit: treat automation as its own population of identities, with its own least-privilege scope per tenant, rather than an extension of whichever technician set it up.

Sources: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.