Third-party access costs rise when each vendor, contractor, or partner needs a VPN exception. Each also needs app links, service accounts, audit records, and support tickets.
A low-cost direct connection can become an unowned operating cost. Teams spend hours rotating secrets, proving access reviews, and removing access across separate systems.
Brokered access costs more at first. It can cut three-to-five-year total cost by centralizing policy, logs, removal, and external-user setup.
Direct integrations can win for a few stable apps. However, API upkeep, secrets, audit proof, and exceptions often become the larger cost.
The variables that decide third-party access cost
Five inputs drive cost: external users, protected apps, annual access changes, protocol types, and regions. A broker is a controlled middle layer that checks identity and policy before each session.
A direct integration links each app to an identity system separately. Think of it as giving each building its own guard desk.
A direct link can seem cheap when an app supports single sign-on (SSO). SSO lets a user sign in through Okta or Microsoft Entra ID.
That view misses ongoing work. Teams must maintain permissions, tokens, logs, exceptions, and removal in every app.
License price is not total cost: direct access spreads recurring work across teams, while brokered access concentrates it in platform costs and policy work.
Count change events, not just users
A contractor who stays 18 months creates less work than six contractors who each stay 30 days. Count joiners, role changes, expired projects, emergency sessions, and offboarding over 12 months.
Treat each access change as 15 to 45 minutes of labor. This assumes a ticket, approval, group change, test, and evidence capture.
Failed or unclear requests can take much longer. Those cases often drive help desk costs.
Change volume is usually the real cost driver.
Separate web apps from all other access
OpenID Connect and Security Assertion Markup Language let web apps trust an identity provider. They work well for browser apps.
They do not automatically protect SSH administration, RDP desktops, databases, APIs, file shares, or older apps. Each of those paths needs its own controls.
The most frequent error is treating SSO as a full access control system. Authentication proves who someone is.
Authorization decides what that person can do after signing in. Third-party access needs both checks.
Price the business impact of exposure
A broker can hide an internal service from the public internet. It acts as a policy enforcement point, where access rules are checked.
Direct API or SSO integration may still leave a VPN or admin portal exposed. Older services can remain reachable from outside.
NIST SP 800-207 defines Zero Trust Architecture as removing trust based on network location. The National Institute of Standards and Technology advises checking each request.
Network location alone should never grant trust.
Choose direct integration when you have fewer than three stable web apps, fewer than 25 external users, low turnover, and a named app owner. Choose brokered access when access spans several apps, privileged protocols, unmanaged devices, or more than 50 annual changes.
A zero trust architecture checks more than a username and MFA result. It also checks device health, location, session risk, requested protocol, and app sensitivity.
For example, a contractor on a managed laptop may get browser access to a project portal. The same person on a BYOD device may get read-only access.
The BYOD user may need browser isolation. SSH and RDP can also be blocked.
Adaptive policy reduces friction for low-risk work. It applies tighter checks to privileged or unusual access attempts.
Brokered vs direct: 1-, 3-, and 5-year TCO
A fair comparison includes build costs, operating labor, renewals, audit proof, and offboarding. The ranges below use a mid-sized U.S. deployment.
This model assumes 10 apps, 150 active external users, two regions, and 300 access changes yearly. Dollar ranges are planning estimates, not vendor quotes.
The table shows why year-one price can mislead. Direct integration often starts cheaper but can cost more after repeated app changes.
| Cost and outcome | Brokered access | Direct integration |
|---|
| Year-one platform and build | $75,000 to $180,000, including licenses, gateways, and policies | $35,000 to $120,000, including app engineering and federation |
| Annual recurring operation | $45,000 to $130,000 for licenses and policy work | $60,000 to $190,000 for apps, IAM, support, and evidence |
| Three-year TCO | $165,000 to $440,000 | $155,000 to $500,000 |
| Five-year TCO | $255,000 to $700,000 | $275,000 to $820,000 |
| Typical revocation time | Between 5 and 30 minutes with central policy | Between 1 and 3 business days across separate apps |
| Internet-exposed services | Can cut exposed services by 60% to 90% | Often unchanged unless each app is rebuilt |
Public list prices vary sharply. Entry tools may cost $7 to $12 per user each month.
Enterprise contracts may charge by user, app, gateway, session, or data volume. Ask which unit can grow before comparing quotes.
Brokered access has clear costs. These include platform subscriptions, gateway hosts, identity links, policy design, logs, and training.
A gateway sits near an app and creates an outbound connection. Think of it as a guarded side door.
Use two regional gateways when low delay matters or resilience needs a second location.
Budget for a security engineer or platform team. They manage policy, fix access issues, and review exceptions.
Direct integration includes API work, connector updates, OAuth secrets, schema changes, app tests, and log mapping. It also includes help desk work and audit proof.
A secret is a password-like value that lets one system call another. It must be stored, rotated, and revoked.
Most guidance misses one issue: direct costs need named owners before approval. Unowned token rotation or app-level logs become unbudgeted work.
TCO equals licenses, build, labor hours times loaded hourly cost, hosting, audit work, and renewal or upgrade costs.
Use an internal labor rate between $95 and $175 per hour. Use your finance rate when one is available.
For direct integration, multiply upkeep hours by every protected app. For brokered access, model shared policy work once.
Then add protocol gateways and license growth. This prevents a false comparison.
Build the model by cost owner, not only by technology. Identity teams may pay for federation and lifecycle rules.
App teams may pay for role mapping and tests. Security teams may pay for monitoring and audit work.
Direct application integration costs often grow with every app, connector, and access change. When assessing these costs, ask whether suppliers must fund named accounts or emergency support.
Direct integration for stable, simple access
Direct integration costs less when a small set of web apps supports federation. It also needs stable roles and a named owner for every app.
It is not a broad VPN replacement. It also does not fit privileged administration or older protocols without modern identity controls.
Pros
- Year-one spend can be 20% to 50% lower for one to three SaaS apps with native SSO.
- Users can keep familiar app sign-in flows without a new gateway.
- Vendor dependence is lower when SAML or OpenID Connect works cleanly.
Cons
- Each new app adds permission mapping, testing, logging, and offboarding work.
- API links create secrets, token scopes, and schema ties that need ongoing care.
- Audit proof often sits across app logs, identity logs, tickets, and VPN records.
For whom it fits
Direct integration fits a startup with one SaaS app and fewer than 25 contractors. It needs low turnover and no SSH, RDP, database, or admin access.
It also fits a partner portal with native business-to-business federation. The portal must have clear role controls.
For whom it does not fit
Direct integration does not fit firms that must remove access quickly across many systems. It also fails when external support needs temporary privileged access from unmanaged devices.
Choose this if: you have a small, stable external group, and each app proves least-privilege access, fast removal, and complete audit logs.
Brokered access for changing, high-risk access
Brokered access usually makes more financial sense for many third parties and frequent changes. It also fits privileged sessions and mixed protocols.
It costs more upfront. It avoids rebuilding identity, policy, and logging controls inside every app.
Pros
- One policy layer can enforce MFA, just-in-time access, session monitoring, and quick removal across many apps.
- Gateways can keep internal services off the public internet.
- Central logs make SOC 2, ISO/IEC 27001, HIPAA, GLBA, and PCI DSS evidence easier to collect.
Cons
- Licenses can rise fast when pricing uses active users, sessions, apps, or gateways.
- Some brokers poorly support databases, custom APIs, industrial systems, or older protocols.
- Gateway placement can add delay, especially for interactive RDP and engineering tools.
For whom it fits
Brokered access fits firms with 50 or more active third parties. It also fits more than five protected apps or over 50 annual changes.
It helps when vendor support needs privileged access management. It can also help during mergers before directories are combined.
For whom it does not fit
A broker cannot fix weak authorization inside an app. If approved users can export all customer records, the broker only protects the front door.
That is like locking a room where every cabinet stays open.
Choose this if: access changes often, crosses several apps or protocols, and your team needs common policy, session records, and removal within minutes.
Choose the path by operational load
Direct
1-3 web apps
Under 25 users
Low annual change
Hybrid
Stable SaaS stays direct
Admin and legacy use broker
Shared audit rules
Broker
5+ apps or protocols
50+ annual changes
Privileged or remote access
Measure access changes, not only identities. High rotation moves break-even toward a broker.
Contract traps that raise broker costs
A broker cuts labor only when its pricing and protocol coverage fit real access patterns. Test peak use, gateway needs, log exports, exit terms, and protected systems before signing.
A cheap broker can become costly when the contract counts the wrong unit. The contract should match how external users actually work.
Price the unit that can grow
Ask whether billing uses named users, monthly active users, concurrent users, apps, gateways, sessions, or data transfer. A contractor who signs in once may be cheap under concurrent pricing.
That same contractor may cost more under named-user pricing. Model seasonal support and incident response.
Test protocol and regional coverage
Run proof-of-value sessions for web apps, SSH, RDP, databases, APIs, and file transfer. Check delay from each U.S. region and overseas supplier location.
Test before moving production support work. Do not rely on a vendor demo.
A broker can work well in theory, but some brokers cover web apps while leaving old databases on VPN. Plan a hybrid design instead of forcing unsupported traffic through browser-focused tools.
Keep an exit path
Require exports of policy definitions, audit logs, user-to-app maps, and session records. Check whether you can replace gateways without changing every app.
Also check whether the identity provider remains portable. Your exit plan should work before contract renewal.
Zscaler, Palo Alto Networks, Google Cloud, Microsoft, Okta, and other providers differ in coverage and pricing. Compare the same workload, not feature checklists.
Govern access, evidence, and ownership
Architecture saves money only when people own identities, policies, connectors, exceptions, and audit proof. The CISA Zero Trust Maturity Model supports this shared operating model.
NIST Cybersecurity Framework guidance also connects identity, devices, apps, and logging. A tool cannot replace clear ownership.
Assign every recurring task
IAM should own identity lifecycle and federation. Application teams should own app roles and compatibility.
Security should own policy standards, session monitoring, and exposure reviews. The help desk should own approved requests and proof of completion.
Alan White, a Zero Trust specialist with over 12 years of cybersecurity experience, uses one practical control. No external access should exist without a sponsor, expiration date, and revocation owner.
That rule stops contractor access from becoming permanent by accident.
Measure ROI after deployment
Track provisioning time, revocation time, tickets per external user, and cost per active access. Also track access with audit proof and services removed from the internet.
Set a target of 30 minutes for privileged access removal. Set one business day for standard access removal.
A common case involves a vendor with VPN access to five internal tools after a short project. Central broker policy can reduce five removals to one identity action.
That result only occurs when all five tools sit behind the broker. Do not claim savings for systems outside its coverage.
Map controls to compliance needs
For PCI DSS, limit, log, and review access to cardholder data. For HIPAA, confirm unique identity, access controls, and audit trail needs.
For federal work, Executive Order 14028 and OMB Memorandum M-22-09 make Zero Trust planning more relevant. Map each control to the rule that applies.
Choose this if: you can assign an owner to every lifecycle and evidence task, then measure labor and exposure for 12 months.
Do not force this comparison if you have no external access. It also may not fit one low-turnover SaaS app with native SSO. A contract may require a named provider, private network, or fixed design. Do not buy a broker instead of fixing poor identity and authorization controls inside an app.
If renewal is within 90 days, build a five-year worksheet before accepting a license quote. Include finance, IAM, app owners, and security.
The worksheet should show each recurring cost owner. It should also show which access paths can be retired.
Human users are only part of the risk. A vendor tool or API client may keep running after a contractor leaves.
Good service account management gives every account a business owner and a stated purpose. It also limits each account to an app and token scope.
Give each account an expiration or review date. Direct designs may create separate credentials and rotation schedules in every app.
A brokered or central identity design can reduce repeated reviews. It still needs credential rotation, unused-account checks, and supplier machine identity removal.
Frequently asked questions
Is brokered access worth it for PCI compliance?
Yes, when it centralizes least-privilege rules, MFA, session logs, and fast removal for PCI systems. It does not replace PCI DSS controls inside the app or cardholder-data environment.
Does direct SSO integration cover vendor access?
No, SSO covers sign-in to supported apps. It may not cover privileged sessions, unmanaged devices, SSH, RDP, databases, or session recording.
What is the break-even point for a broker?
There is no universal user count. Broker economics often improve beyond five apps, 50 annual access changes, or mixed protocols.
Should a startup use brokered access or direct integration?
Use direct integration for one to three stable SaaS apps and fewer than 25 contractors. Use a broker when support needs SSH, RDP, admin rights, or frequent access changes.
Can a hybrid model lower third-party access costs?
Yes, a hybrid model can keep stable SaaS access direct and broker privileged paths. It works best when both paths share identity rules, audit retention, and a removal process.
Which option should you choose?
Choose direct integration if your external users are few, stable, and limited to standards-based web apps. You need a named owner for each app and proof that removal works quickly.
Choose brokered access if you manage more than five apps, mixed protocols, privileged work, or over 50 annual changes. Its higher first-year cost is usually justified when labor, audit proof, and exposure are shared problems.
My recommendation favors brokered access for most mid-sized and large U.S. organizations. The cost gap usually closes by year three when access changes, app count, and audit demands rise.
Use a hybrid design when neither option fits fully. Keep simple SaaS apps direct, but put privileged, legacy, and remote access behind the broker.
Avoid both choices as a shortcut for broken app permissions. Fix the app when it gives approved users more data or power than their job requires.
Related sources
These articles can help you explore the topic in more depth:
