Skip to content

Limit privileged access for third-party vendors without restricting their ability to get work done


Companies often work with outside experts, consultants, and other third-party vendors who need privileged access to corporate resources. You may be engaging with third-party vendors in a number of different ways, such as a remote contractor working on a time-limited project, an embedded contractor, or outsourced staff augmentation.

These third-party entities can’t do what they were hired to do if their access is too restrictive. However, you can’t maintain a strong security posture if access and oversight are too lax. Each situation is unique, and at first glance, it may seem like there isn’t a standard security playbook you can leverage to secure vendor access.

How do you, as a security professional, walk the line to provide just enough access and oversight so the vendor can do their job and you can secure critical assets? Read on to learn more about specific processes you can use, and how those strategies can be applied to some of the different types of vendor engagements you need to support.

Are your privileged access objectives aligned with your vendors’ access needs?

There are likely some inherent conflicts between your security goals and your vendors’ access needs:

  • You must work with third parties on some projects, but fear that granting them access could puncture the corporate security perimeter.
  • Vendors must have access to some internal systems. Without access, they may need to rely on insiders to get them the information they need, which quickly becomes inefficient, not to mention impossible to audit.
  • You want to make sure vendors don’t become a security risk. Vendors just want to get their job done and get out (usually).
  • You don’t trust anyone. Vendors cannot do what they were hired to do if their access is too restrictive.

Bottom line: You can’t maintain a strong security posture if access and oversight are too lax; vendors cannot reasonably work if access and oversight are too burdensome.

Expert’s Guide to Privileged Access Management (PAM) Success

Take your Privileged Access Management to the Next Level

Expert's Guide to Privileged Access Management (PAM) Success

What are some common privileged security challenges when working with third-party vendors?

There are many challenges for privileged security:

  • Each individual requires access to key corporate infrastructure and services, including internal applications and browser-based web applications.

  • Their employment agreement with the organization means they may have flexibility in how and where they perform their work, and in the control that the organization can have over the technology they use. They may use their own workstations, including laptops and mobile devices.

  • Vendors aren’t in your Active Directory and don’t have company email addresses. IT teams spend a lot of time manually setting up accounts to give third parties access.

  • Compliance and risk assessment teams often struggle with collecting data to prove they are in compliance with all remote access policies.

  • Because they are reporting to a specific group, that group may be responsible for on-boarding and off-boarding the contractor and may not have sufficient checks in place to ensure that these processes are fully followed.

Why is vendor off-boarding essential, yet so difficult to master?

Vendor security is important both while the third party is actively employed with your organization, and once the engagement is over. The latter case poses some common challenges:

  • When the engagement ends, the vendor’s privileged access may not be revoked, either due to lack of oversight or because of an expectation that they may have a future engagement with the company.

  • In the case where more than one person works for a vendor, those vendors may share privileged account credentials with their co-workers rather than have each individual apply for, and be granted their own unique credentials.

Without an airtight off-boarding procedure, it’s easy to lose track of vendor accounts

Without an airtight off-boarding procedure for third-party vendors, it’s remarkably easy to lose track of a vendor account. Every abandoned or unknown privileged account is an opportunity for unauthorized access, ranging from an ex-contractor continuing to access the account with benign intent, to a third-party vendor using the account to perform unauthorized tasks, to a hacker discovering an abandoned account and using it to gain access to sensitive information.

What are the policy-based best practices for vendor access management?

Consider the policy and process aspects related to granting and revoking privileged access to third-party providers, and how technology solutions like vendor Privileged Access Management (VPAM) can be used to define and enforce them.

Craft a process that is easy to follow and enforce your organization’s Privileged Access Management policy, then document it and make it available to all vendors.

Structure processes to mirror your internal access policies:

  1. Is there an established process for how third-party vendors are granted privileged access?
  2. Does the process require that the individual granting privileged access have sufficient rights and authority to do so? Is senior-level or executive-level authorization required for access to highly sensitive data or infrastructure?
  3. Is the process automated, so any actions taken are auditable and trackable?
  4. How do you ensure that vendors are only granted the minimum level of access needed to get their jobs done?
  5. Can you record sessions without any software needing to be installed on the vendor’s machines?
  6. Does the process include regular audits to ensure privileged vendor accounts are still in use, and that they remain configured with the least privilege posture relative to the vendor’s actual needs?
  7. How is vendor off-boarding handled?

Incorporate and address vendor use cases in your documented comprehensive PAM policy:

  1. Is there a clearly articulated policy for how vendors are granted access to internal resources?
  2. Is the access policy based on standards set by external governing bodies, such as NIST, ISO, PCI-DSS, HIPAA, or GDPR?
  3. Can you ensure that remote vendors are using multi-factor authentication?
  4. Does the access policy include enough detail so it can be uniformly implemented?
  5. Is the policy flexible enough to accommodate different usage scenarios?
  6. Does the policy assess and segment vendors by their risk profile, based on the nature of the engagement, the systems to which they will need access, and the vendor itself?
  7. How are exceptions handled?
  8. Is there a version of the policy that is available to third parties and vendors, so they are aware of their rights and responsibilities, plus any consequences should they be out of compliance at any time?
  9. Is the vendor access policy documented and easily accessible to anyone within the organization who should have access to it?

How can VPAM contain and mitigate the risks of third-party access?

Fortunately, smartly applied VPAM solutions can help contain risk, manage privileged access, and provide an audit trail to hold everyone accountable.

  • Workflow tools: Imagine the lifecycle of a vendor’s access: Authorize, Provision, Retain / Reclassify, Decommission… and at the end of the cycle, the account could be renewed, re-approved, disabled, or expired. With PAM, you can create a standard, automated workflow to be used whenever a third party needs access to specific resources.

    By automating the workflow, you ensure that all contractors and vendors provide any requisite information, confirm that they are aware of acceptable use policies (and have signed off on them), and also receive management approval to grant them privileged access. All of this could be done in a central portal to keep track of all vendors and systems, even if they don’t have a company-issued computer or email address.

  • Policy-based roles and least privilege access: The first step when granting access is to ensure the vendor is given an appropriate level of access and no more. You can use role-based access control (RBAC) to configure baseline and default access. This defines which systems the vendor can access and their rights within each system.  You can even determine what actions they can take, such as which button can be clicked, which text can be read, which forms can be filled, and much more. You can place a time limit on each account, automatically revoking access unless it is reviewed and extended.

  • Monitoring: With advanced PAM, you can track each vendor’s privileged account activity, including which systems they access and actions taken within those systems. Risk-based scoring can show who has what level of access to which resources, so you can prioritize high-risk access. Depending on their level of privileged access, the sensitivity of their work, and the overall risk profile of the engagement, consider using tools for session monitoring, session recording, and keystroke logging.

  • Anomalous behavior detection: In conjunction with session monitoring, you can enable anomalous behavior detection. Is the vendor accessing systems to which they should not have access? Is there a sudden increase in account access by certain users or systems? Is there atypical access to certain privileged accounts? Are accounts accessed at odd times of the day or from unexpected locations? Automated monitoring coupled with deep reporting tools helps identify risks to privileged accounts so you can take appropriate action.

  • Discovery: You can use privileged account discovery tools to periodically check for unused or unknown accounts and make sure they are included in your central portal. Only current third-party vendors in good standing should retain access.
Privileged Access Management Checklist

Need a step-by-step guide for planning your strategic journey to privileged access security?

Start with our free, customizable PAM Checklist.

How does vendor access management play out in the real world?

Imagine a few common scenarios of how vendors might work with your organization, and how you can set them up to be productive.

Scenario 1: A remote contractor working on a time-limited project:

The marketing department brings on a third party—perhaps a market research contractor—to work on a specific project for a defined amount of time. The contractor will be working offsite and needs remote access to internal data repositories, communication tools (such as internal discussion boards), and shared drives. The contractor uses her own laptop.

Risk mitigation approach:

  • Assign appropriate roles and privileges: Do not create a custom role or custom permissions for each contractor. As much as possible, define and apply standard roles for contractors. This makes it easier to manage permissions across all contractors, including modifying and updating access rules. It also ensures policies will be universally applied and enforced.

  • Restrict access: Take the time to ensure the contractor is only granted access to the resources they need and no more. You can also set the vendor’s working hours, restricting the times when they are permitted to access privileged resources.

  • Monitor usage: Periodically review access, and flag anomalous behavior.

  • Set an expiration date: Align access with the remote vendor’s project duration. Set an automatic expiration date once the contract is expected to expire. It is better to set an end date, and extend it if needed, rather than leave the engagement open-ended.

  • Post-mortem audit: Establish an off-boarding policy that requires a periodic, regularly scheduled audit of all expired vendor accounts to ensure that the account was decommissioned and there has been no unauthorized access (or attempted access) once the remote vendor’s assignment has ended.

Scenario 2: Embedded contractor:

The Support team hires a Customer Service representative to a long-term consulting contract, and he works alongside full-time employees. The contractor works onsite at the corporate headquarters, entirely within the corporate infrastructure, using a shared, company-issued computer.

Risk mitigation approach:

  • Assign appropriate roles and privileges: Embedded contractors, while serving alongside full-time employees, are rarely entitled to the same level of access. Assign them a role and permissions that reflect their restricted role.

  • Restrict access: Embedded contractors often should not have broad-based access in the way that an employee may. Limit access to only those resources the contractor must use.

  • Secure the endpoint: Since the embedded contractor is using a company-issued device, you have more flexibility to lock down the device itself, including installing monitoring agents, anti-virus software, and restricting what they are able to do on the laptop.

  • Monitor usage: Audit usage as you would for an employee, paying additional attention to usage outside of normal business hours, and attempts to access restricted or sensitive resources.

  • Set an expiration date: If the embedded contractor is working on a fixed-term contract, set their account and access to automatically expire on the last day of the contract.

Scenarios 3: Outsourced staff augmentation:

All software development is outsourced to a remote third-party development team. The team is working on a critical project and requires access to internal tools, systems, and privileged accounts. While the number of people on the development team remains constant, there is frequent turnover with some members leaving and others joining. The team works offsite, using their own sandboxed equipment, with secure remote access to critical corporate systems.

Risk mitigation approach:

  • Assign appropriate roles and privileges: In addition to creating and assigning standard roles are permissions, ensure that each user uses their own account and that accounts are not shared or passed off from one person to the next, especially if there is churn among the outsourced staff.

  • Restrict access: Maintain a strict least privilege posture, especially if the vendor requires access to critical systems.

  • Secure the endpoint: Provide secure access and, if possible, install agents on any endpoints the vendor uses to access your corporate systems. This is especially critical if the vendor is working with multiple clients to avoid any cross-contamination between projects.

  • Monitor usage: Audit usage as you would for an employee, paying additional attention to usage outside of normal business hours, and attempts to access restricted or sensitive resources.

  • Set an expiration date: If the contract is not open-ended, set it to automatically expire at the end of the contract term. Even for open-ended contracts, setting an expiration date will reduce the risk of the vendor having access after their work is completed.

In each scenario, the nature of the work is different: different duration, different privileges, different ownership of privileged accounts, different responsibilities. Yet there are common techniques and processes—authentication, authorization, auditing—which are universally applicable. And they can be applied to internal resources as well as web- and cloud-based ones.

Remote vendor access management needn’t be overwhelming 

With a structured approach to managing vendor security, you can reduce the risk associated with granting privileged access to critical systems, while effectively monitoring and auditing what the vendor is actually doing with that access. 

Secret Server Cloud Trial

PAM in the Cloud. Powerful. Secure.

Try the only feature-complete, enterprise-class CLOUD PAM solution in the world.