Alright, let's cut through the usual vendor hype. Everyone touts ZPA's "zero trust" for internal apps, but the real chaos (and hidden cost) is third-party vendor access. You're sold on replacing clunky VPNs with slick policy rules, but then you have a contractor who needs 90-day access to a single dev environment.
So you create a ZPA app segment, tie it to an IdP group, and onboard them. Great. Now, how do you *actually* ensure that access is revoked on day 91? Not by policy, but in practice. Do you have a foolproof de-provisioning workflow that doesn't rely on someone remembering to check a spreadsheet? Or does this just become another "set it and forget it" policy, quietly accruing risk (and potentially license cost if you're on a per-user model)?
I'm deeply skeptical of any "automated" solution that requires manual ticket creation to trigger removal. What are you all *actually* doing that's both secure and doesn't create an administrative black hole?
- Are you using SCIM with your IdP to automatically deprovision after a date attribute passes? If so, I'd love to see the real-world breakdown of that setup's failure points.
- Are you eating the cost and using short-lived, just-in-time access via some custom portal? That sounds elegant but I've yet to see the billing data that proves it's cheaper than the manual overhead.
- Or is the truth that most shops are just letting these exceptions pile up, turning their zero-trust network into a Swiss cheese of stale permissions?
The sales pitch always glosses over the lifecycle management. Let's talk about the operational reality and the hard numbers.
- cost_observer_42
cost_observer_42
The manual ticket creation failure point you mentioned is real, but it's often a process issue, not a ZPA limitation. If you're already using SCIM, you can tie access to a custom attribute like `contract_end_date` in your IdP. The failure point is usually in the HR or procurement system feeding that date accurately into the IdP profile.
For a pure ZPA approach without perfect HR data, we use access policy conditions with a maximum session duration. It's not as clean as SCIM deprovisioning, but it forces re-evaluation. The user's connection will be severed at the policy limit, and they can't reconnect without a valid, active session policy.
That said, you're right to be skeptical. The administrative black hole appears when the business unit doesn't communicate the contract end, leaving the IdP attribute stale. Automation only works with reliable source data.
null