If you run an offshore or remote team that does real work inside other companies' systems (payer and insurer portals, vendor and customer systems, bank and government sites), you have a problem the usual IT tools weren't built for. You are accountable for every one of those sessions. You need to know who reached what, keep personal browsing out of it, present a consistent U.S. address to the portals, and cut access off the moment someone leaves. Here are the four ways teams handle it, and what each one costs you.
The four options
1. Shared logins and consumer VPNs
The default when nobody has decided. Workers use a shared VPN account or a consumer VPN to appear in the U.S., and often share portal logins too. It works until it doesn't: there is no record of who reached what, no clean way to cut one person off, and the portal owners have no way to tell your workers from anyone else on that VPN's address pool. Many portals now block consumer VPN ranges outright.
2. A full company VPN
Sending all of a worker's traffic through your company network is the traditional answer. It gives you one address and a log, but it also pulls in everything the worker does: personal email, banking, streaming. It is slow for them, costly for you, and a liability you don't need, because now their personal traffic is on your systems.
3. U.S.-hosted virtual desktops
Give each worker a Windows desktop in a U.S. data centre and have them do portal work inside it. This is the most locked-down option and the most expensive per seat, and every portal session is slower because it is happening on a remote screen. Teams tolerate it for a while and then start looking for shortcuts.
4. A portal-only gateway
The newer approach sits in between. Workers install a small app and press Connect. Only the exact portal domains you have approved are reached through a fixed U.S. address your company owns; everything else (email, banking, personal browsing) uses the worker's own connection. Every request through the gateway is tied to a named worker and logged, and the gateway never decrypts the traffic, so it cannot read, store or cache what is on the page.
That is the model Portal Hound is built on.
What to require from a gateway
If you evaluate this category, these are the properties that separate a real control from a rebadged proxy:
- Blocked by default. Nothing is reachable until you approve the domain. The product should suggest the domains a portal needs, because modern portals pull from several.
- End-to-end encryption preserved. The gateway must not terminate TLS. If it can read the page, you have created a new place for sensitive data to leak.
- One identity per worker, tied to their machine. Credentials created on and bound to the worker's own computer, so revoking one person is instant and affects nobody else. Approve each new computer before it can connect.
- A record of requests, not content. Which worker reached which site and whether it was allowed. No page contents, form data or full web addresses.
- One known, company-owned exit. A single fixed U.S. address you control, so access is consistent, attributable, and straightforward to describe to the companies whose portals you use.
- Dedicated, not shared. Your own gateway, sign-in pool and access records, never pooled with another customer. For regulated work, the option to run it in your own cloud account.
- Operational controls. See who's connected, tell "offline" apart from "revoked", reset a worker's access without anyone handling passwords or keys, and an emergency lockdown that cuts every worker off at once and restores access when you're ready.
A note for healthcare teams
Offshore billing and credentialing teams live in payer portals, and the portal owners increasingly check where sessions come from. A fixed, company-owned U.S. address that you can name in a vendor questionnaire is easier to defend than "a VPN". Keep the gateway narrow (portals only), keep the log (who reached what), and keep page content out of it.
Quick answers
Is a portal gateway a VPN?
No. A VPN routes all of a device's traffic. A portal gateway routes only the approved portal domains through your company's address and leaves everything else on the worker's own connection. It also cannot be used for general browsing.
Can the gateway see what workers type into a portal?
Not if it preserves end-to-end encryption, which it should. Portal Hound's gateway doesn't read, store or cache page content; its record is which worker reached which site and whether it was allowed.
What happens when a worker leaves?
Revoke that one person. Their credentials are tied to their own computer, so nothing else changes. For an incident, lock everyone out at once and restore when ready.
Will portals block our gateway address?
A single fixed address owned by your company, used only by your named workers, is the opposite of the consumer VPN pools portals block. It is also the address you can disclose to the portal owner when asked.