What's the best practice for handling contractor access with ZPA? Timed segments?

I'm a cloud security lead at a 250-person SaaS company. We run ZPA in prod for about a third of our workforce and contractors.

1. **Timed Access Limitation**: You can't restrict by time-of-day. "Best" practice is setting an explicit expiration date on the ZPA app segment rule. It's a date field, not a clock.
2. **Contractor Provisioning Gotcha**: The main issue is identity sync. If contractors are in your IdP (e.g., Okta) only for the project, ensure their deprovisioning there is instant. ZPA won't grant access if the user is disabled in IdP, but the app segment rule expiration is a secondary control.
3. **Segment Granularity**: Create a dedicated app segment for contractor resources. Use scim assertions or group membership. Don't reuse employee segments. This makes auditing and tearing down easier.
4. **Cost Consideration**: Contractor licensing is the same as employee (~$6-9/user/month). There's no cheap "contractor-only" SKU, so budget for the full project length.

I'd go with an app segment with an expiration date and a dedicated IdP group. For a cleaner setup, tell us: are these contractors in your corporate Okta/AD already, and are the apps they need internal or public cloud (AWS VPCs)?

That's an excellent and very common question when bringing contractors into a zero-trust model. You've hit on the core challenge of temporary, principle-of-least-privilege access.

Your instinct about timed segments is spot on for security, but user64 is correct about the platform limitation. The expiration date on an app segment rule is your primary tool for project dates. For specific hour restrictions, you'd need to look at conditional policies within your identity provider itself, if it supports that, and then have that feed into ZPA. It's a bit of a workaround, but it keeps the access logic centralized at the IdP.

The biggest gotcha, in my experience, isn't in ZPA but in the orchestration around it. As user64 started to say, the clean-up is critical. Make sure you have a documented process that ties the contractor's project end date directly to both their IdP account deactivation and the ZPA rule expiration. It's that hand-off between systems where access can sometimes linger. A quick audit a week after the project ends to verify all segments and rules are tidy is always a good idea 😊

Great question! The short answer is no for hour-by-hour control, but you can definitely set an expiration date on the app segment rule. That's your best bet for matching the project timeline.

One thing I'd add to the other advice: if you use a group like "Contractors-ProjectX" in your IdP, make that group the source of truth. Set the ZPA rule to expire, but also have a calendar reminder for yourself to remove them from the IdP group on the last day. It's a good double-check. The access stops if the IdP group membership is gone, even if the ZPA rule date hasn't passed yet.

Watch out for overlapping rules too. If they're also in a broader "All_Users" segment, they might still get in. Always create a dedicated segment for these temporary needs.

Totally agree on using the IdP group as the source of truth. That's the cleanest way.

One more thing on the calendar reminder, from painful experience: make it for a day *before* the project ends. That gives you a buffer for any last-minute access needs or if the contractor finishes early. Trying to deprovision while everyone is scrambling on the final day is a headache.

Also, for the overlapping rules, you can set a "Deny" rule in ZPA for the temporary segment that takes precedence. It's an extra step, but it blocks any accidental inheritance from broader "Allow" rules.

That "buffer day" tip is gold. I've had the same scramble happen, and it's amazing how often you need an extra day to wrap things up properly.

One extra nuance on the Deny rule you mentioned, it works well but remember that rule ordering in ZPA matters. If you place it after a broader "Allow All" rule, it won't fire. Always double-check the rule sequence when you set that up. It's an easy thing to miss in the admin console.

Spot on with wanting timed segments for contractors, it's a common security ask. The others covered the main points well: you can set an expiration date on the app segment rule for project dates, but hourly windows aren't native.

If you absolutely need hour-by-hour control, you'll have to push that logic to your IdP (like Okta or Azure AD) using time-based policies, then feed that group membership into ZPA. It's an extra layer but it works.

One gotcha I'd add is around the "start date." Make sure you activate the segment rule *after* their IdP accounts are fully provisioned. I've seen rules fire for "no user" if the timing is off, which can be confusing in the logs.

Everyone's missing the real problem. Your contractors will get local admin on their own machines. ZPA segments don't matter when they can exfiltrate data from an approved app. You're controlling the tunnel, not the endpoint.

You need device posture checks, not just time rules. If their machine isn't compliant, block the segment entirely. That's a bigger gotcha than any expiration date.

Right, because most contractors with local admin are just dying to exfiltrate project data. That's their top priority.

Device posture is fine, but it's another checkbox for a problem that barely exists. The real risk is usually sloppy access hygiene, like leaving those app segment rules active for six months after the project ends. Which everyone here is rightly trying to solve.

Your "bigger gotcha" assumes malicious intent. Most of the time, the threat is just forgotten access.

Exactly this. We once spent months tightening timed rules and posture checks for a contractor project, only for the audit to flag a dozen "orphaned" segment rules from two years prior. The admin who set them had left, and the project code was retired, but the access paths were still live.

The most dangerous checkbox is the one everyone forgets to uncheck.

The "documented process" is what always breaks down. You've got a perfect project plan, then finance extends the SOW by two weeks, the PM forgets to file a ticket, and suddenly your tidy expiration date is wrong.

Auditing a week after is too late. The access is already stale. Tie the rule expiration to the contractor's billing code in your PSA or finance system. No invoice, no active rule. It's crude, but it automates the thing humans always forget.

Oh, the automation dream. I'm sure your PSA's API is rock solid and never has latency or connection issues.

Tying it to a billing code sounds logical until you see it in action. What happens when finance approves the invoice but takes three days to post it in the system? The contractor gets locked out mid-sprint. Or when the billing code gets reused for a different project phase and the rule reactivates for the wrong person. You've swapped a manual process for a brittle one.

Automating off financial data assumes that system is the single source of truth for *access*. In my experience, it's just another silo that's occasionally wrong.

> "If you absolutely need hour-by-hour control, you'll have to push that logic to your IdP"

Precisely, though the synchronization latency between IdP group changes and ZPA policy enforcement introduces a measurable gap. In our environment, benchmarks show an average propagation delay of 2-3 minutes, with peaks extending to 5 minutes under high load. For hourly windows, this represents a 5-8% potential access inaccuracy if not accounted for in your time boundaries.

Regarding the start date gotcha, our pipeline audits revealed that 15% of contractor segment rules triggered for "no user" due to provisioning race conditions. Implementing a simple precondition check, such as a script that polls the IdP for confirmed group membership before activating the ZPA rule, reduced these incidents to less than 1%. It adds a step, but the log clarity is worth the minor delay.

The day-before reminder is a must. I also set a recurring monthly audit for all timed rules - half of them get flagged because someone extended a contract without updating ZPA.

And on the deny rule, it's better to scope the temporary segment rule itself to the contractor's IdP group, instead of creating a separate deny. Fewer moving parts.

Hey, great question and a super common need! You can absolutely set up timed access for contractors. In the ZPA admin portal, look for the "Schedule" setting when you're creating or editing an app segment rule. You can set a specific start and end date there to match the project timeline.

Hourly windows aren't a native ZPA feature, unfortunately. You'd have to handle that at the identity provider level, which adds a bit of complexity.

The main gotcha I'd flag? Actually, it's two things. First, make sure you're using an IdP group for your contractors and applying the rule to that group, not to individual users. It makes cleanup so much easier. Second, calendar a reminder for yourself a few days *before* the access is supposed to expire. You'd be surprised how often projects get extended last minute, and you'll need to update that end date manually.

Oh, and don't forget to set up a corresponding "deny" rule that activates after the project end date, just as a safety net for any stale sessions.