How Security Integrators Can Stop Managing Per-Client Port Forwarding

You install and service camera systems for a living. Hikvision, Dahua, Axis, Hanwha — whatever the client's budget allows. The installation itself is the easy part. The hard part is what comes after: "Can I see my cameras from my phone?" followed by a different router, a different ISP, a different network admin, and a different set of problems at every single site.

This article is for professional CCTV installers, MSPs, low-voltage contractors, and physical security consultants who manage camera systems across multiple client sites — and who are tired of the support overhead that comes with per-site port forwarding, DDNS, and vendor cloud apps.

The Integrator's Remote Access Problem

Picture this: you service 40 client sites. Each has 4–8 cameras. Currently, each site requires its own port forwarding rule, its own DDNS hostname, and you hold camera passwords for every single client in a spreadsheet somewhere. When a client changes their ISP or replaces their router, you get a support call. When you need to pull footage for an insurance claim, you are negotiating firewall access with whoever manages that client's network. When a camera goes offline, you do not know about it until the client calls you — and then you send a technician.

Multiply this by 40 sites. Then 60. Then 100.

The support overhead is not linear — it compounds. Every client has a different router brand, a different ISP with different NAT behavior, a different level of IT sophistication. Some clients have a dedicated IT person who changes firewall rules without telling you. Some are on cellular backup connections where port forwarding does not work at all. Some have moved to a new ISP that uses CGNAT, and the port forward you set up two years ago quietly stopped working.

This is not a technology problem. It is a scaling problem. And it is the reason most integrators cap their service capacity well below what their team could actually handle.

Why Standard Methods Break at Scale

Every common remote access method works fine for a single site. None of them work well when you are managing dozens.

Port forwarding

• One support call per IP change. Residential ISPs rotate IPs frequently. Every time a client's IP changes, their DDNS may lag or fail, and you get a "my cameras aren't working" call.
• Does not work behind CGNAT. Cellular-connected sites (fixed wireless, 4G/5G backup) increasingly use CGNAT. You simply cannot port forward behind it.
• Every camera is exposed to Shodan. Port-forwarded cameras appear in internet-wide scans within hours. Camera firmware CVEs are published regularly. You are personally liable if a client's network is compromised through a camera you port-forwarded.
• Each site needs manual router configuration. Different router brands, different firmware versions, different admin interfaces. There is no way to automate or standardize this.

VPN per client

• Requires a VPN client on every viewing device. Your client's office manager cannot just open a browser — they need Tailscale, WireGuard, or OpenVPN installed. On their phone, their laptop, their tablet. On the reception desk PC.
• Cannot hand a stream URL to a third party. When the client's lawyer needs footage, or their insurance adjuster needs a live view, you cannot send a URL. You have to set up VPN access for them.
• Blocked on corporate networks. If your client operates out of a managed office building, the building's IT team likely blocks VPN traffic. Your client's remote access stops working when they move offices.

Vendor cloud apps (Hik-Connect, DMSS)

• Locks the client into one manufacturer's app. If you install Hikvision at one site and Dahua at another, the client now needs two different apps. You cannot unify the viewing experience.
• No API access. You cannot pull a stream into a VMS, a custom dashboard, or an AI pipeline. The video is trapped inside the vendor's app.
• Privacy concerns. Video routes through the manufacturer's cloud servers. For clients in regulated industries (healthcare, finance, legal), this can be a compliance issue.

What Scales: The Relay-Per-Site Model

The architecture that actually works at scale is simple: one lightweight agent per client site, connecting outbound to cloud infrastructure, creating isolated endpoints for each site's cameras.

How it works

You drop a small agent onto any existing Windows or Linux machine already on-site — or a $40 mini-PC if there is nothing available. The agent connects outbound over HTTPS to TheRelay's cloud infrastructure. No inbound firewall rules. No port forwarding. No router configuration at all.

Once connected, the agent auto-discovers cameras on the LAN via ONVIF or you manually enter RTSP URLs. Each camera gets a set of cloud endpoints: WebRTC for browser viewing, RTSP for VMS integration, HLS for mobile embedding.

Why this matters for integrators specifically

• Camera credentials never leave the client's LAN. The agent pulls RTSP streams locally and tunnels them to the cloud. You are not holding a spreadsheet of camera passwords — the credentials live on the agent, on the client's network.
• Each client gets their own token namespace. A token compromise at one site does not affect any other client. You can revoke a single site's access without touching the rest of your deployment.
• CGNAT is a non-issue. The agent connects outbound. It works on fiber, cable, fixed wireless, 4G/5G cellular, satellite — anything with an internet connection.
• Works even when you do not have router access. This is common in commercial deployments. The tenant does not control the building's network infrastructure. With a relay agent, you do not need router access at all — just a machine on the same LAN as the cameras.
• Standardized across all sites. Whether the client has a Netgear, Ubiquiti, MikroTik, or ISP-provided router, your deployment process is identical. Install agent, discover cameras, generate tokens. Done.

Token Model for Multi-Client Isolation

When you are managing 20, 50, or 100 client sites through a single integrator account, token architecture matters. You need clean isolation between clients, different access levels for different people, and the ability to revoke access instantly.

How to structure it

One account, separate token groups per client. Your TheRelay account is the master. Under it, you create token groups scoped to each client site. A token group defines which streams are accessible and what operations are allowed.

• Client-facing tokens: View-only access to that client's cameras. You hand the client a URL with their token embedded. They open it in a browser — no app install, no account creation. They see their cameras and nothing else.
• Integrator service tokens: Your internal tokens with broader access — ability to view all streams across all clients, pull RTSP endpoints for diagnostics, access ONVIF controls for PTZ if needed.
• Temporary access tokens: Time-limited tokens for third parties. Insurance adjuster needs a live view for a claim? Generate a token that expires in 48 hours. Lawyer needs footage access during a case? Same approach.

Revoking access on contract end

When a client relationship ends, you revoke their token group. Their stream URLs stop working immediately. You do not need to touch the cameras, change passwords, or visit the site. The cameras continue operating normally on the local network — you have simply removed the remote access bridge. This is clean, instant, and does not affect any other client.

Security implications

Because each client's tokens are scoped independently, a compromised token at Site A cannot access streams from Site B. There is no shared secret, no shared credential, no lateral movement path. This is fundamentally more secure than the common integrator practice of using the same camera password across all client sites (which we all know happens).

Onboarding a New Client Site in Under 10 Minutes

Here is the concrete walkthrough for deploying remote access at a new client site:

1 Drop a mini-PC or use an existing machine

Any Windows or Linux machine on the client's camera LAN works. A $40 mini-PC (Intel N100 or similar) is more than sufficient. If the client already has a server, NVR with Windows, or always-on PC, use that. The agent uses minimal resources — under 100MB RAM per stream.

2 Install the agent

Run the installation command. No router access needed, no firewall rules to configure.

3 Auto-discover cameras via ONVIF

The agent scans the LAN for ONVIF-compatible cameras and lists them in the dashboard. Click to add each camera. For cameras that do not support ONVIF (or if you prefer), enter the RTSP URL manually. Most Hikvision, Dahua, Axis, and Hanwha cameras are discovered automatically.

4 Generate tokens

Create a client-facing token scoped to this site's streams. Create an integrator service token for your own access. Both are done from the dashboard in seconds.

5 Hand the client their stream access

The client creates a TheRelay account and you share the stream access with them. They can then view their cameras via WebRTC in Chrome, Safari, Firefox, or Edge — on their phone, laptop, or tablet. No app to install.

Frequently Asked Questions for Integrators

What happens to my client's access if I cancel my TheRelay account?

If you cancel your account, all tokens under that account are revoked and cloud endpoints stop working. The cameras themselves are completely unaffected — nothing is installed on the cameras, and the agent does not modify camera configuration. Your client's cameras continue recording locally as before. You simply lose the remote access bridge. This is an important contractual point: make it clear to clients that remote access is a managed service you provide, tied to your infrastructure — not a one-time installation.

Does this work with Milestone, Genetec, Nx Witness, or Blue Iris?

Yes. TheRelay provides standard RTSP endpoints in the cloud. Any VMS that can ingest an RTSP source — Milestone XProtect, Genetec Security Center, Nx Witness, Blue Iris, Shinobi, ZoneMinder, and others — can pull a stream from a TheRelay cloud endpoint exactly like it would from a local camera. This means you can centralize recording from multiple client sites into a single VMS instance if needed, or let each client's local VMS pull their own streams for redundant cloud recording.

How do I handle a client who already has Hik-Connect set up?

Hik-Connect and TheRelay do not conflict. Hik-Connect uses Hikvision's P2P cloud protocol, while TheRelay's agent pulls RTSP streams locally on the LAN. Both can run simultaneously on the same camera. You can set up the relay agent alongside existing Hik-Connect without disabling it. Over time, you can migrate the client to relay-only access and disable Hik-Connect if desired — this removes the dependency on Hikvision's cloud servers and gives you full control over access tokens and stream distribution.

What if the client's internet goes down?

If the site loses internet connectivity, the relay agent cannot reach the cloud — so remote viewing stops until the connection is restored. Local recording on the NVR or camera SD card continues unaffected. When the connection comes back, the agent automatically reconnects. There is no manual intervention required. This is identical behavior to every other remote access method — port forwarding, VPN, and vendor apps all stop working without internet too.

Can I monitor which client sites are online?

Yes. The TheRelay dashboard shows connection status for every agent across all your client sites. You can see at a glance which sites are online, which cameras are streaming, and which have gone offline. This makes proactive monitoring possible — you can reach out to a client about a connectivity issue before they even notice it.