Third-party remote access is often created under time pressure and then treated as permanent infrastructure. A vendor needs to repair an application, a managed service provider needs administrative reach, or a contractor needs a temporary path into a project environment. The risk does not end when the ticket closes. Accounts, tunnels, allowlists and trust relationships can remain long after the original need changes.
CISA and partner agencies note that managed service providers commonly require privileged connectivity to customer systems and that compromise of a provider can enable activity across multiple customer environments. The practical response is not to ban every remote connection. It is to make each connection attributable, bounded, observable and removable.
Describe the relationship before the technology
Record the supplier, contract owner, technical owner, supported service, business purpose, systems reached, data involved, permitted activities, support hours, escalation contacts and end date. State whether the provider operates a service continuously or connects only for approved work. These are different risk models and should not share one generic access rule.
Document responsibility for identity proofing, multifactor authentication, endpoint security, log review, incident notification and access removal. A contract phrase such as industry-standard security does not identify who will disable a compromised account at 02:00.
Use named identities and strong authentication
Give each external operator a distinct identity where the platform allows it. Avoid shared vendor accounts that prevent attribution and survive staff turnover. Require multifactor authentication on remote and privileged paths, and define how authentication methods are enrolled, replaced and revoked.
Where federation or a provider-managed identity is used, confirm which organization controls the identity lifecycle and what evidence is available to the customer. A successful sign-in proves possession of an accepted identity; it does not prove that the current person is still assigned to the contract.
Constrain reachable systems and allowed actions
Place the connection at the narrowest useful boundary. Restrict destination networks, ports, applications, management planes and source conditions. Separate production, non-production and backup administration. If the supplier supports one application, it should not inherit a general route to unrelated identity, hypervisor or security systems.
Apply least privilege inside the destination as well as on the network. A VPN limited to one subnet can still expose a broadly privileged account. Use task-specific roles, time-bound elevation and explicit approval for high-impact changes where practical.
Make temporary access actually expire
Define start and end conditions in the access record. Prefer time-bound policy, expiring accounts or just-in-time activation over calendar reminders. For recurring support, require periodic owner confirmation rather than treating contract renewal as automatic technical approval.
Review accounts, certificates, API credentials, firewall rules, identity-provider assignments, remote support agents and site-to-site tunnels together. Removing one login does not close a second path that was created during an earlier incident.
Log presence, activity and outcomes
Capture authentication, session start and end, source, destination, privilege activation, administrative actions and file transfer where supported and proportionate. The customer should know which relevant records remain with the provider, how an investigation can obtain them, and how quickly suspected misuse will be reported.
Alert on access outside expected windows, repeated authentication failure, use of dormant accounts, connection from unexpected locations, new remote-access tooling and changes that expand reach. Logging without an owner or response procedure only records the problem after the fact.
Prepare a fast and safe shutdown
Document how to disable the provider identity, terminate active sessions, revoke tokens or certificates, remove routes or policy and preserve evidence. Identify who can authorize the shutdown and how service impact will be managed if the provider also operates a critical system.
Exercise the path using a controlled scenario. Confirm that internal staff can identify active access, contact the right people, disable it, verify closure and restore approved access later. The exercise should not require exposing real credentials or interrupting production solely to prove the control.
Close the lifecycle with evidence
At offboarding, reconcile the original access record with the deployed state. Remove identities and trust, recover equipment, rotate shared secrets that could not be individually attributed, retain required records and document remaining dependencies. An accountable owner should sign off that the technical paths were checked, not only that the contract ended.
A well-run third-party access process makes the useful path easy to approve and the obsolete path difficult to forget.