Third-Party Vendor Privileged Access: Auditing and Controlling What Your Vendors Can Do

An internal employee who requests Domain Admin access gets scrutinized. A vendor support engineer who says they need Domain Admin to install the product gets it provisioned in 15 minutes because the alternative is delaying the implementation. This asymmetry runs throughout vendor access management. Vendors typically receive more trust at initial provisioning than the access actually warrants, and that access is rarely revisited once the implementation or project phase ends. The mechanics that create this problem are predictable. First, vendor access is often provisioned by the team closest to the vendor relationship, not by identity and access management teams who would apply least-privilege analysis. A network engineer sets up a vendor account for their monitoring tool vendor and gives it what they think it needs, without cross-checking against a privilege model. Second, vendor accounts frequently survive project endings. When the implementation is complete, access is not revoked because someone might need it for support. That support need never materializes, but the account persists for years. Third, time pressure during incidents causes privilege escalation without cleanup. A vendor is asked to debug a production issue and needs elevated access urgently. The access is granted. The cleanup never happens. Over a long enough timeline, the vendor account accumulates a history of emergency escalations that were never reversed.

The SolarWinds SUNBURST attack is the canonical case study for understanding why vendor privileged access is a strategic target. SolarWinds Orion had broad privileged access to customer networks because network monitoring legitimately requires it. When attackers compromised SolarWinds' build pipeline and inserted the SUNBURST backdoor into the Orion update, every customer that installed the update received a persistent implant with the full permissions that SolarWinds Orion had been granted. Customers had not been breached directly. Their vendor's software update pipeline had been weaponized. The forensic picture showed that the most severely compromised organizations were those where SolarWinds had been granted broad network access without segmentation constraints. Organizations that had limited SolarWinds to read-only access on specific network segments, or that had placed the SolarWinds server in a management VLAN with no lateral movement paths, had a much smaller blast radius. The Kaseya VSA attack in July 2021 followed a similar structural pattern but exploited a different mechanism. Kaseya VSA is an RMM (Remote Monitoring and Management) platform used by MSPs to manage endpoints on behalf of their customers. REvil exploited a zero-day in the VSA on-premises software to push a malicious update through the MSP's management console to all managed endpoints. The privilege model was the problem: Kaseya VSA agents ran with SYSTEM-level privileges on managed endpoints because remote management requires it. When the update delivery mechanism was weaponized, that system-level access became the attacker's execution context on thousands of endpoints across hundreds of MSP customers. The pattern from both attacks: vendors with legitimate privileged access, standing access that existed continuously rather than on demand, no session recording to provide forensic visibility, and insufficient network segmentation to limit blast radius.

Before you can control vendor access, you need to know what exists. Most organizations do not have a complete inventory of external accounts with privileged access. Building that inventory requires querying multiple data sources and correlating the results. Start with Active Directory. Query all user accounts and look for accounts with email addresses from external domains in the mail or userPrincipalName attributes. Cross-reference these against the privileged groups: Domain Admins, Enterprise Admins, Schema Admins, Backup Operators, Account Operators, and any custom privileged groups your environment uses. Use PowerShell or LDAP queries to enumerate group memberships for these accounts systematically. External domain accounts in privileged AD groups are your highest-risk findings. Next, audit service accounts. Service accounts used by vendor software often have vendor-associated names or descriptions, but the most dangerous ones are the generic ones with names like svc-monitoring or svc-backup that were created for a vendor tool and forgotten. Pull all service accounts, check their password last set date (accounts with passwords that have not changed in over a year are candidates for orphaned vendor accounts), and check what systems they are authenticating to. For cloud environments, enumerate IAM users and roles. In AWS, look for IAM users (as opposed to roles) with access keys that have not been rotated in over 90 days, and cross-reference against trust policies that allow external account principals. In Azure, check the External Identities section and B2B guest accounts, then check what role assignments those guest accounts hold across subscriptions. Review VPN and remote access gateway logs for connections from external IP ranges or user accounts with external email addresses. Correlate these against the account inventory to identify vendor accounts that are actively used for remote access to privileged systems.

Standing vendor access, meaning credentials that exist and work at all times, is the root problem. Just-in-time (JIT) access replaces standing credentials with a workflow: the vendor requests access, an approver authorizes it for a specific time window, credentials are provisioned automatically, and they expire when the window closes. The PAM workflow for JIT vendor access typically looks like this. The vendor logs into a self-service portal, describes what they need to do and on which systems, and selects a requested duration (one hour, four hours, one business day). The request routes to an internal approver, typically the business owner of the systems involved. The approver reviews the request and approves or denies it. Upon approval, the PAM platform creates a time-limited credential or issues a one-time password for the target system, and provisions a session through the jump server or PAM gateway. When the time window expires, the credential is automatically revoked. This model requires a PAM platform that supports JIT provisioning: CyberArk Privileged Access Manager, BeyondTrust Privileged Remote Access, Delinea Secret Server, and Sailpoint's AccessIQ all support variants of this workflow. The implementation challenge is that vendors who have had standing access for years will push back on the added friction. The counter to this is that support engagement frequency is usually low, and the added time for a JIT request is minutes, not hours. Configure automatic approval for pre-approved vendors during business hours with appropriate safeguards to reduce friction for routine support engagements while maintaining the time-limiting control.

Every privileged vendor session should be recorded. This is not primarily a gotcha control for catching malicious vendors. It is a forensic baseline that allows you to understand exactly what a vendor did during any given support engagement, distinguish between vendor-caused and application-caused incidents, meet contractual obligations to demonstrate oversight of privileged access, and detect behavioral anomalies when comparing sessions over time. PAM platforms record sessions at the protocol level. CyberArk records RDP sessions as video files and SSH sessions as keystroke logs with full command history. BeyondTrust's Privileged Remote Access product records screen activity and keyboard input for all session types. The recordings should be stored in immutable storage (S3 Object Lock in AWS, WORM storage on-premises) so they cannot be modified or deleted. Session recording has a specific value beyond security: when a vendor claims they did not make a change that caused an incident, the recording is the arbiter. Security teams that have implemented session recording consistently report that it changes vendor behavior. Vendors who know sessions are recorded are more careful about what they do during support engagements. The recording requirement should be in vendor contracts, not just in technical controls.

Shared accounts are incompatible with vendor accountability. When three contractors from the same vendor share a single account named vendor-support-admin, you cannot determine which individual was logged in when an action was taken, you cannot revoke access for one individual without revoking it for all, and you cannot detect behavioral anomalies because multiple individuals produce mixed behavioral signals. Eliminating shared accounts requires two steps: creating individual accounts for each vendor employee and removing the shared account. The friction point is that vendors often prefer shared accounts because they simplify their own access management. The counter to this is non-negotiable: shared accounts cannot be used for privileged access, full stop. Most modern PAM platforms support a model that reduces friction for vendors while eliminating shared accounts. Vendors authenticate to the PAM portal with their individual identity (optionally federated through their own IdP using SAML), and the PAM platform issues session credentials to the target system. The vendor never sees the underlying privileged credential. This model is actually preferable for vendors because they do not have to manage privileged credential rotation. When a vendor employee leaves their company, their individual account is deprovisioned and their access ends. The privileged credentials on your systems never need to change.

Jump servers and vendor VLANs are the network-layer equivalent of JIT access. Even if a vendor's credentials are compromised, network segmentation limits what those credentials can reach. The architectural principle is that vendor access should flow through a controlled chokepoint, not directly to production systems. A vendor-specific jump server sits in a DMZ with network access rules that permit connections only to the specific systems the vendor manages. The vendor connects to the jump server (via a PAM gateway, not directly), and from the jump server, can reach only the allowed destinations. This prevents lateral movement: even if the session is compromised or the vendor's machine is infected, the attacker cannot pivot from the jump server to systems the vendor has no business accessing. Vendor-specific VLANs extend this model for vendors who operate infrastructure within your environment (managed switches, storage systems, HVAC management, physical security systems). Each vendor's managed infrastructure lives in its own VLAN with explicit firewall rules governing what that VLAN can communicate with. The critical rule: vendor management VLANs must have no path to your critical data environments. SolarWinds Orion servers placed in the same flat network as domain controllers and file servers contributed directly to the blast radius of the SUNBURST compromise.

Technical controls are necessary but not sufficient. Contracts govern what happens when technical controls are bypassed, when a vendor employee goes rogue, and when a vendor's own environment is compromised in ways that affect your data. Effective vendor access contracts should specify MFA as a non-negotiable requirement for all privileged access, with the specific acceptable factor types (TOTP, hardware key, push notification) enumerated. Require background checks for vendor personnel who will be granted privileged access, and include a notification requirement when personnel with privileged access to your systems leave the vendor's employ. Include a right-to-audit clause that permits you to review the vendor's security practices, access logs, and personnel records related to access to your environment. The notification requirement for personnel changes is often the most operationally significant clause. Without it, vendor employees who are terminated still have active access credentials in your PAM system until someone notices. With it, the vendor is contractually obligated to notify you within 24 hours of a personnel separation, and you have a legal basis to hold them accountable if they fail to do so and an incident results.

Even with JIT access and session recording, behavioral anomaly detection on vendor accounts adds a detection layer that identifies abuse during an active session. The anomaly signals most relevant for vendor accounts are off-hours access (a vendor in a US business timezone accessing systems at 3 AM), unusual data volume (a support session that reads gigabytes of data when the issue was a configuration problem), access to systems outside the vendor's scope (a storage vendor's account accessing domain controllers), new tool execution (commands or binaries that have not appeared in previous sessions from this vendor), and geographic anomalies (a vendor whose sessions always originate from the US suddenly connecting from Eastern Europe). Your SIEM or UEBA platform can build baselines for each vendor account and alert on deviations. The challenge is that vendor accounts are lower frequency than employee accounts, so baselines require more time to establish. Compensate for this by using vendor-category baselines rather than individual account baselines: all accounts associated with the network monitoring vendor should exhibit similar behavioral patterns, and deviations from the category pattern are actionable even if the individual account baseline is thin.

Vendor engagement end is a defined lifecycle event that should trigger a documented offboarding checklist, not an informal communication that may or may not result in access revocation. The offboarding checklist should include disabling all individual accounts associated with the vendor, revoking shared secrets or API keys used by the vendor's software, removing the vendor's public SSH keys from authorized_keys files on any servers they accessed, rotating passwords on any shared accounts that could not be eliminated before offboarding, removing vendor-specific firewall rules and VLAN access, and archiving session recordings and access logs to long-term immutable storage before removing the account. The business driver for rigorous offboarding is that the accounts most likely to be exploited in supply chain attacks are dormant former-vendor accounts. They have credentials that work (no one thought to change them), they have the permissions that were granted during the active engagement (no one thought to review them), and they have no owner who would notice anomalous activity. The moment a vendor engagement ends is the highest-risk moment in the vendor relationship from an access control perspective.