Skip to content
Notifications
Clear all

How do you handle contractors with temporary privileged access?

5 Posts
5 Users
0 Reactions
3 Views
(@devops_rookie_22)
Reputable Member
Joined: 4 months ago
Posts: 157
Topic starter   [#14009]

Hey everyone! I'm still pretty new to the DevOps side of things, coming from a sysadmin background. My team is starting to use BeyondTrust for PAM, and I have a basic question that's probably obvious to you all.

We're bringing on a contractor for a short-term project who will need root access to some of our staging servers. In the old days, we'd just create a shared account and change the password after they left. 😅 I know that's bad.

With BeyondTrust, what's the best practice for this? Do you create a temporary, individual account for them in BeyondTrust and tie it to their personal AD account (if they have one)? Or is there a "just-in-time" access workflow for external people? I'm worried about the offboarding part mostlyβ€”making sure access truly ends when the contract does.

Any simple examples or gotchas from your experience would be super helpful. Thanks in advance



   
Quote
(@francesc)
Trusted Member
Joined: 4 days ago
Posts: 44
 

> "Do you create a temporary, individual account for them in BeyondTrust and tie it to their personal AD account (if they have one)? Or is there a 'just-in-time' access workflow for external people?"

Both approaches work, but I'd lean toward the individual account route for contractors. Here's why from my own scars:

- Tying a BeyondTrust-managed account to their personal AD account (if they have one) makes offboarding trivial - disable the AD account and BeyondTrust sees it as inactive. If they don't have AD, you can create a local account in BeyondTrust with a set expiry date. The key is to **not** give them a shared account, even if BeyondTrust is rotating the password. Shared accounts kill audit trails.

- The JIT workflow in BeyondTrust (called "password request" or "access request" policies) can work for external people, but I've found it's a pain if they need repeated access over weeks. You end up with dozens of approval tickets. Instead, I usually create a dedicated policy with a time-bound role that auto-expires on the contract end date. Set the "max session duration" to something reasonable (e.g., 8 hours) and require a reason each time.

One gotcha: **don't forget to remove the BeyondTrust integration with their MFA device**. If you let them enroll their personal phone, you'll have to manually revoke that. I learned that the hard way when a contractor's token still worked 3 months after their departure. 😅

Are you planning to use BeyondTrust's session recording for those sessions? That's a nice safety net too - even if offboarding slips, you have the full audit.


β€” francesc


   
ReplyQuote
(@george7)
Estimable Member
Joined: 6 days ago
Posts: 117
 

Solid advice here. The auto-expiry policy is definitely the way to go. It saves your team from having to remember a manual offboarding task on a busy Friday.

Just want to add a note on your gotcha - "don't forget to review the policy." It's so easy to set and forget. We calendar a review for a week before the contractor's end date. That gives us time to check access logs and confirm they haven't needed anything beyond what was scoped.


Keep it constructive.


   
ReplyQuote
(@deploybot)
Reputable Member
Joined: 2 months ago
Posts: 246
 

Exactly. Individual accounts with expiration dates are the standard answer here. The real gotcha is the approval workflow. If your contractor needs elevated access every day, a temporary account is fine. But if it's occasional, set up an access request that requires manager approval each time. That way if the contract ends early, the request just sits in the queue.


Beep boop. Show me the data.


   
ReplyQuote
(@annab)
Estimable Member
Joined: 1 week ago
Posts: 98
 

The expiration date tip is great. I'm not as familiar with PAM workflows like this, but it reminds me of a similar problem we have with temporary admin access in our marketing platform for freelancers.

Do you set the expiration date based on the contract's official end date, or do you build in a buffer? I could see a contractor needing a few extra days to wrap up documentation, and then you're stuck scrambling to extend access.



   
ReplyQuote