At some point after your cameras went in, somebody asked whether you wanted to see them on your phone. You said yes, because everyone says yes. A few minutes later it worked.
The question worth asking, years later, is how it was made to work. There are two common answers, and they have very different consequences. One of them put your recorder on the public internet.
What port forwarding actually does
Your building has one public address on the internet, held by your router. Everything inside — recorder, cameras, workstations, the tablet in the break room — sits behind it on private addresses that the outside world cannot reach directly. That is not a security feature anyone designed for you. It is a side effect of how addresses are handed out, and for most small networks it has been doing a great deal of unearned security work for decades.
Port forwarding punches a hole through it. It tells the router: when a connection arrives from anywhere in the world on this particular numbered port, do not drop it — pass it to the recorder inside. That is the whole mechanism. It is why the app on your phone works from a hotel in another country, and it is also why the recorder is now answering the entire internet.
The distinction that gets lost is this: a forwarded port is not a private tunnel to you. It is a public door that you happen to know about. Everyone else can see it too. The lock on it is whatever login the recorder ships with.
The part most owners do not know
There is a category of search engine that does not index web pages. It indexes devices. It connects to addresses across the whole internet, records what answers, and makes the result searchable — by device type, by manufacturer, by software version, by city.
You do not have to take our word for this. CISA, the US government's cyber security agency, names these platforms in its own published guidance and recommends organizations use them to find their own exposure: "Thingful, Censys.io, Shodan, and Shadowserver are web-based search platforms designed to identify and manage internet-connected devices, including IoT/IIoT and industrial control systems."
Read that as the defensive advice it is, then read it a second time. If a defender can search for exposed devices by type and location, so can anyone else, using the same free tools and no special skill. Being unlisted was never the protection. Nothing about your building is obscure to a search index.
The same guidance is blunt about how this usually happens: "Many organizations unknowingly leave common vulnerabilities and weaknesses exposed to the internet, making them easy targets for exploitation. Misconfigured systems, default credentials, and outdated software are often publicly accessible through internet-based search and discovery platforms."
Every one of those three failure modes is ordinary in small-building CCTV. The recorder was configured once, at install. The password was set by whoever was on site. The firmware is whatever shipped in the box.
We are not going to walk through what someone does after finding a device, and you should be wary of anyone who offers to. The structural point is enough: an appliance that was designed to sit on a private network, running the software it shipped with, is answering the public internet, and finding it takes a search box.
Why the recorder is a bad thing to expose specifically
Anything you expose carries risk. A video recorder carries a particular kind.
It holds footage of the inside of your building, which is precisely the material you installed it to protect. It usually holds a list of user accounts, and those accounts are frequently reused elsewhere by the same people. It sits on your internal network by definition, so it is a foothold rather than an endpoint. And it is an appliance — it does not get patched on the cadence a laptop does, because nobody thinks of it as a computer. It is a computer.
There is also an ugly asymmetry in the failure. If someone reaches your recorder, you will usually not know. Nothing breaks. The cameras keep recording, the app keeps working, and the first sign of trouble arrives from somewhere else entirely, weeks later.
How to find out whether this was done to you
You do not need us to check, and you do not need to touch anything technical.
Ask whoever maintains your system one question, in writing: "Is remote viewing on our system set up using port forwarding, or through a cloud relay or VPN?"
The answer will be one of three things.
If it is cloud relay or manufacturer cloud service, the recorder makes an outbound connection to the vendor and no inbound door exists. That is the common modern answer and it is generally fine, with a caveat below.
If it is VPN, remote users connect into the network properly and the recorder is not exposed at all. That is the strongest answer.
If it is port forwarding, or if the answer is vague — "we opened a port", "it's on the static IP", "we set up DDNS" — then you have a public door and it should be closed. DDNS in particular is worth naming, because it is often described as though it were a security measure. It is a convenience that gives your changing public address a memorable name. It makes the door easier for you to find. It does not make it harder for anyone else.
A fourth answer, "I don't know", is common and is not a reason to distrust your installer. Remote access is often set up years before anyone thinks about it as a risk. It is a reason to find out.
What to do instead
CISA's guidance sets out the sequence plainly, and it applies as well to a strata as to a utility: "Determine which assets need to be internet-accessible for operational purposes. For those that do not need to be internet accessible, implement measures to remove or restrict access."
A video recorder essentially never needs to be internet-accessible. What needs to be accessible is you, to the video — and that is a different requirement, satisfied without a door.
A VPN into the site. Remote users authenticate to the network, then reach the recorder as though they were in the building. Nothing is exposed. This is the right answer for anyone with existing IT support, and CISA's guidance flags the obvious caveat: VPN software is itself software, and needs to be kept current.
A vendor cloud relay. The recorder dials out and holds the connection open; you connect to the vendor. There is no inbound port. The trade is that you have taken on the vendor's security posture as your own, so the vendor's track record is now part of your risk — which is an argument for choosing platforms that publish their security practices rather than the cheapest recorder on the shelf.
If something genuinely must stay exposed, the guidance names the minimum: change default passwords, keep the system patched, replace devices no longer receiving security support, put access behind a jump host, enable multifactor authentication where possible, and monitor the traffic in and out. That is a real programme of work, not a checkbox, and for most buildings it is more effort than simply closing the door.
The last item on CISA's list is the one that gets skipped: establish routine assessments. Exposure is not a state you fix once. Networks change, contractors come and go, and a port opened during a temporary problem in 2019 is still open now because closing it was never anybody's job.
The honest summary
Port forwarding is not incompetence, and an installer who set it up for you was almost certainly doing what the industry did as standard for years. The alternatives were worse or did not exist. What has changed is that scanning the entire internet became cheap and searchable, and the cost of a permanent open door went up while nobody's configuration changed.
If you take one thing from this: ask the question in writing, and keep the answer. A system where remote access runs over a VPN or a vendor relay is a system where this article does not apply to you. A system with a forwarded port is one decision away from being the same, and the decision is not expensive.