Remote access and PAM vendors as tier-zero suppliers: Classify, Contain and Revoke Them Before They Fail

The supplier that holds the keys to your privileged sessions is part of your tier zero, whether your supplier register says so or not. Remote support, privileged access management (PAM), remote monitoring and management (RMM), identity platforms and backup services with tenant-wide consent all hold machine credentials that can act on your estate without any of your staff signing in. When one of those suppliers is breached, the attacker inherits that reach. This guide draws the lesson from real breaches, sets out what tier-zero treatment means in practice for a supplier, and gives the controls, contract asks and response steps that limit the blast radius. It is for identity, PAM and third-party risk practitioners deciding which vendors need the strictest handling.

Key takeaways

• Anything that can control tier zero is tier zero. A vendor whose infrastructure key can reset passwords, push commands to endpoints or sign in to your tenant as an application sits at the same level as your domain controllers and identity provider.
• The breach report names this category directly. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) draws from BeyondTrust and the US Treasury the lesson that "a vendor's infrastructure keys can be keys to its customers", and its 90-day plan says to treat vendors with privileged or remote access as tier-zero suppliers and check how fast they can revoke keys.
• Vendor-side keys bypass your user controls. In the cases below no user was phished on the customer side: an API key, a client secret or a stolen session did the work, so MFA and single sign-on never came into play.
• Containment has to work without the vendor. You need a tested way to disable the service, cut its network path and revoke its grants in minutes, because vendor fixes and disclosures take days.
• Due diligence must ask about the vendor's own NHIs. How the supplier stores, scopes and rotates its infrastructure keys, signing keys and customer tokens matters more than its marketing claims about your accounts.

What the breaches show

The pattern is the same across very different products: a credential held by the supplier, not by the customer, opened many customers at once. Case facts below come from the NHI Mgmt Group breach pages linked in each row.

The report's cross-breach figures explain why this matters beyond a handful of cases: supply chain is the leading known route in, with 51 of the 200+ breaches analysed, and 56% of the breaches involved more than one kind of non-human identity.

Which suppliers belong in tier zero

Tier zero is not a product category. It is a test of reach: if a supplier's credential, agent or code-signing identity can change who has privileged access, or act with privileged access, it is tier zero. Use the table to classify.

Classify by the permissions actually granted, read from the consent record or role assignment, not by what the vendor says the product needs. Include shadow installations: AnyDesk customers were told to inventory every installation, including unsanctioned ones. MITRE ATT&CK tracks this route as T1199 Trusted Relationship and the tool abuse as T1219 Remote Access Tools.

What tier-zero treatment means for a supplier

Your normal third-party programme sets the baseline (see the Third-Party Risk Management Guide). Tier zero adds controls on three planes: what the supplier can reach, how its credentials are held, and how fast you can cut it off.

Limit reach

• Scope the managed estate: exclude domain controllers, identity provider admin accounts, break-glass accounts and PAM servers from remote support and RMM scope unless there is a named, approved need. The BeyondTrust key could reset passwords for local application accounts, so keep the number of those accounts small and remove any that are not used.
• Separate administrative consoles: run supplier consoles for tier-zero work only from Privileged Access Workstations, never from general user devices.
• Least-privilege consent: for multi-tenant apps, read the granted application permissions and remove any the product does not need. Directory write and role management rights on a backup app turn a data risk into a tenant takeover risk.
• No standing vendor sessions: require just-in-time, approved and recorded sessions for vendor staff. The Vendor Privileged Access Management (VPAM) Guide covers the access model in depth.

Constrain where supplier credentials work

• Network binding for single-tenant apps: Microsoft Learn states that Conditional Access for workload identities applies only to single-tenant service principals registered in your tenant, and that Microsoft and third-party SaaS applications, including multitenant apps, are not covered. Where you register a single-tenant app for a vendor integration, block token requests from outside the vendor's published IP ranges (Block access is the only grant; Workload Identities Premium licensing is required).
• Multi-tenant vendor apps: because Conditional Access does not cover them, rely on reducing permissions, alerting on sign-ins from unexpected addresses, and asking the vendor whether it offers a single-tenant or customer-owned registration option.
• Self-hosted where it changes the risk: a self-hosted remote access server removes the vendor's multi-customer infrastructure key from your threat model but adds patching duty. BeyondTrust patched its SaaS instances and released fixes for self-hosted ones; CVE-2024-12356 is in the CISA Known Exploited Vulnerabilities catalogue (added 19 December 2024), and ConnectWise ScreenConnect CVE-2024-1709 was added on 22 February 2024 with known ransomware use.

Be able to cut it off

• A documented kill switch per supplier: disable the service principal or connected app, block the vendor's address ranges and agent update domains at the egress proxy, stop agent services through endpoint management, and revoke delegated admin relationships.
• Know the token tail: ConnectWise warned that previously issued access tokens may remain usable until they expire or are otherwise invalidated. Disabling the app is the start of containment, not the end.
• Owned break-glass path: make sure you can still administer endpoints and the tenant when the supplier's tool is switched off. See the Break-Glass Account Guide.

Due diligence questions specific to tier-zero suppliers

Ask for evidence, not yes or no answers. Each question traces back to a real case.

The full question set for NHIs held by any supplier is in the sibling guide on third-party NHI due diligence; for contract wording use the Third-Party Security Contract Clauses Template.

Implementing tier-zero supplier handling

1. Inventory (weeks 1 to 2): list every remote support, RMM, PAM, identity, device management and backup supplier. For each, pull the actual permissions from Entra enterprise applications, Google Workspace app access, delegated admin relationships and endpoint agent inventories. Include unsanctioned installs found by endpoint telemetry.
2. Classify (week 3): apply the reach test above and record the result in the supplier register with an internal owner. Anything that can change privileged access is tier zero.
3. Reduce (weeks 3 to 6): remove unneeded permissions and scope, take tier-zero assets out of remote support scope, and replace standing vendor access with approved sessions. Pilot each change first and record the previous permission set so it can be restored if a process breaks.
4. Write and test the kill switch (weeks 4 to 8): one page per supplier with the exact steps and owners. Run it in a tabletop and, for at least one supplier, in a live maintenance window: disable, confirm the tool stops, confirm your break-glass path works, re-enable.
5. Contract and evidence (next renewal): add the due diligence questions and notification terms to renewal. Escalate suppliers that cannot answer them to the risk owner for a documented decision.
6. Monitor (ongoing): wire the detections below into the SOC with named response playbooks.

Decision guidance

• SaaS or self-hosted remote access: SaaS removes your patching burden but concentrates many customers behind the vendor's keys; self-hosted removes cross-customer keys but puts you on the hook for fast patching of exploited flaws. Choose self-hosted only if you can patch internet-facing servers within days.
• Small organisations: you may have one MSP doing everything. Focus on the kill switch, a separate break-glass account the MSP cannot change, and the notification clause.

Detection and measurement

Customers detected the Okta session hijacks before the vendor confirmed them.

• Service principal sign-ins: alert on vendor app sign-ins from addresses outside the vendor's published ranges, and on first-time sign-ins to tenants or resources.
• Role and credential changes: alert when a vendor service principal is added to a directory role, or when new secrets or certificates are added to any application (ATT&CK T1098.001 Additional Cloud Credentials), the pattern seen at ConnectWise.
• Remote support activity: log and review sessions, password resets performed by the tool, and new local accounts it creates.
• Endpoint commands: alert on scripts or commands pushed by RMM or device management outside change windows.
• Signing trust: hunt for binaries signed with a revoked supplier certificate.

Common failure patterns

• Trusting the vendor's revocation alone: the vendor disables its app but issued tokens and secrets added to your other apps remain, as the ConnectWise case showed with client secrets valid until 2028 planted on other applications.
• Rotating "everything" except the integrations: after the Okta breach, the Cloudflare Thanksgiving breach happened because one service token and three service accounts were left unrotated in the belief they were unused.
• Applying Conditional Access advice to the wrong app type: workload identity policies do not cover multitenant vendor apps, so a plan that relies on them for a SaaS backup tool protects nothing.
• No fallback when the tool is off: the organisation cannot support users or administer servers once the supplier's service is suspended, so it delays switching it off.

Framework mapping

Practitioner checklist

• Apply the reach test to every remote support, RMM, PAM, identity, device management and backup supplier, and record tier zero in the register.
• Read granted permissions from the platform, remove what is not needed, and keep tier-zero assets out of remote support scope.
• Use workload identity Conditional Access only for single-tenant service principals; for multitenant vendor apps rely on permission reduction and sign-in alerting.
• Write and test a kill switch per supplier, including how to deal with tokens that outlive app disablement.
• Keep a break-glass administration path the supplier cannot alter.
• Ask each tier-zero supplier how it stores, rotates and scopes its cross-customer keys and signing keys, and how fast it can force-rotate.
• Alert on vendor service principal role assignments, new app credentials and sign-ins from unexpected ranges.

Standards and references

• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: Conditional Access for workload identities
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Trusted Relationship (T1199)
• MITRE ATT&CK: Remote Access Tools (T1219)

Related NHI Mgmt Group resources: Third-Party Access Guide · Vendor Privileged Access Management (VPAM) Guide · Privileged Remote Access Buyers Guide · BeyondTrust Hardening Guide · ConnectWise ScreenConnect Hardening Guide