Here's the reality most vendors don't want to admit: scaling ZTNA for contractors is less about the ZTNA magic and more about your identity and lifecycle management being a total mess. You're swapping a network perimeter for an identity perimeter, and if your contractor onboarding/offboarding is a manual CSV file circus, you've just moved the bottleneck.
The core scaling problem is the agent. You have a contractor for a 3-week project. Do you really want to:
* Get them through your infosec team's agent approval process (good luck).
* Have them install a corporate agent on their personal device (never happening).
* Manage the revocation when the project ends, which it never does on time.
Agentless HTTP/S inspection is the only sane starting point for this group. But even that falls apart if you're trying to give them access to legacy crap that needs a TCP tunnel. Then you're back to square one.
The real architecture question is how you federate identity. If every contractor comes from a different staffing agency with their own IdP, you're in for a world of pain. You need a standard. Something like SCIM for just-in-time provisioning tied to a single identity provider (yours or a federated one). If I see one more "just use SAML" guide that ignores the deprovisioning lag, I'll scream.
The cost trap is next. Most ZTNA vendors price per user, per month. A contractor who needs access for 45 days costs you the same as a full-time employee for the quarter. You need a licensing model that accommodates ephemeral identities, and most don't. You end up building a complex, home-grown automation system to add and remove users from the ZTNA system just to avoid paying for dead accounts.
Just my 2 cents
Just my 2 cents
You're absolutely right about the identity federation being the core issue.
I've seen teams try to solve this by making their own IdP the "source of truth" for contractor access, using SAML just-in-time provisioning from the staffing agency's IdP. The catch is, you're then dependent on the agency's side actually being configured correctly, and many smaller ones just... aren't.
That's where the manual CSV circus creeps back in. You end up with a hybrid mess where some contractors federate cleanly and others are manual entries, which completely undermines the "zero trust" lifecycle management.
So the standard is only as good as your least capable partner's implementation. Have you found any vendors that handle this hybrid state gracefully, or is it still a home-rolled nightmare?
That hybrid state problem is real. We had the same issue last year when we onboarded a few marketing agencies.
Our bigger partners federated fine, but two smaller shops just sent us spreadsheets. It created this weird split where half the contractor accounts were managed automatically and half were a manual mess. Defeated the whole point.
Is the answer just to avoid smaller partners who can't handle SAML? That feels limiting.
The "just avoid small partners" approach is a non-starter if you're in a competitive market. You'd be ceding business to someone who's willing to accept a CSV.
The real solution is to treat the two tiers as separate identity domains and enforce a strict gateway between them. Federated partners get their own IdP and SAML JIT. For the small shops, you accept the spreadsheet but **automate the ingestion** via a scheduled job that parses the CSV, calls your SCIM endpoint, and sets a hard expiry date. The key is that the contractor's access token is tied to that expiry, not to any manual revocation step. If the spreadsheet isn't updated, the token dies on schedule.
That still leaves you with a human-in-the-loop for the initial upload, but at least the lifecycle is bounded. The really nasty part is when the agency sends an updated CSV with a new row for a contractor who already has a token -- you need an idempotent upsert that doesn't require a full re-onboarding.
I've seen teams wrap this in a small internal tool that also sends a Slack notification to the hiring manager when the expiry is within 48 hours, forcing them to confirm extension or let it die. It's not zero-touch, but it's a hell of a lot better than the "we forgot to revoke the VPN cert for six months" scenario.
What's your current policy for handling the transition when a contractor's device is moved from the "agentless" tier to the "full agent" tier after a project extension? That's where our hybrid model kept tripping.
brianh
Totally agree, especially on the agent part. We went the agentless route for contractors but hit the exact issue with legacy TCP apps. The "square one" feeling is real.
Our workaround was setting up a tiny, isolated bastion host with short-lived certificates. The contractor gets a one-time script that spins up a temporary SSH tunnel, and it auto-expires after X hours. It's not elegant, but it keeps the agent off their personal device. Definitely feels like a band-aid, though.
Have you looked at any ZTNA vendors that handle this TCP tunnel scenario gracefully without an agent? I've heard some are adding clientless RDP/SSH gateways for this niche.
Infrastructure as code is the only way
You're hitting the nail on the head about the identity federation pain. I've seen the "standard" approach crumble when a company has 20+ staffing agencies, each with a different IdP setup. Even with SCIM and a single provider on your side, you end up being an integration shop for their identity quirks.
That's why some of our teams have started pushing for a contractual requirement. If a partner wants to work with us, their IdP has to support SAML with specific attributes and a deprovisioning hook. It's harsh, but it forces the issue early and keeps the CSV circus at bay.
The agent problem is just a symptom of the messy identity layer. Once that's clean, the agent debate becomes a lot simpler - you can actually trust the lifecycle enough to consider temporary, containerized agents or clientless tunnels.
ship it
Contracts are contracts, not technical specifications. If you can actually get legal to put IdP requirements in a master service agreement, I'll be shocked. Procurement's goal is cheapest rate, period.
You're right about the integration shop hell, though. I once spent three weeks getting a "SAML-compliant" agency's IdP to send the right nameID format because their default was an email address that changed weekly. The clean identity layer is a fantasy when your source is a dozen different IT departments you don't control.
Clientless tunnels for the win, but only because they sidestep the whole identity mess you just described.
-- old school
Your story about the nameID format changing weekly is the perfect example of why "standards" are a joke in this context. That agency wasn't broken; their process was simply optimized for their own convenience, not yours. The fantasy is thinking any vendor's "graceful handling" of a hybrid state will fix that incentive mismatch.
I've actually seen legal put IdP requirements into an MSA, but you're right about the outcome. It becomes a checkbox. The agency signs it, then their overworked IT guy uses some free-tier IdP with the default settings. You win the contractual battle but lose the integration war, because now you're obligated to make it work with their mess.
Clientless tunnels sidestep the identity mess, sure, but they just create a different one: you're now authenticating to a network hop, not a person. It trades one set of management problems for another.
cg