Who Really Has Access to Your Security System?

Not all cloud connectivity creates the same security or privacy concern.

When physical security systems are designed, we spend a lot of time talking about cameras, resolution, analytics, storage, cybersecurity, and remote access.

But there's another question we believe deserves just as much attention:

Where does your security data go, and who has the opportunity to see it once it leaves your system?

At Pro Video Engineering, we've long preferred a local-first approach to physical security.

That doesn't mean we're anti-cloud. Many of the systems we design use cloud-assisted services, peer-to-peer connectivity, professional monitoring, and other Internet-based technologies.

But not all cloud connectivity creates the same security or privacy concern.

There is an important difference between using an Internet service to establish a secure connection between your locally hosted security system and a user you authorized, versus surveillance data leaving your environment for notification, processing, or review outside of your direct administrative control.

Local doesn't mean disconnected

For professional video surveillance, we typically steer customers toward locally hosted, OS-based VMS platforms or purpose-built embedded NVR solutions, where recording and core surveillance functions remain on premises and under the customer's control.

These systems can still provide remote access.

In a typical remote-access model, an authorized user connects back to the customer's on-premises surveillance system. The customer determines who has an account, which cameras that person can access, what permissions they receive, and when that access should be revoked.

The Internet may provide the connection, but the customer remains in control of who is authorized to access the surveillance system.

That's a different trust model from sensitive surveillance information being exported into another workflow, service, or administrative domain.

Every additional path matters

Consider a locally hosted surveillance platform that performs its recording and video analytics on premises but also offers cloud-assisted event notifications.

Those notifications can be incredibly useful. A locally generated event can immediately reach the appropriate person, sometimes including an image or thumbnail showing what caused the event.

But that creates another path for surveillance data.

There have been real-world, user-reported cases involving this type of architecture where event notifications delivered camera thumbnails to users who reportedly were not authorized to access the cameras that generated them.

The underlying permissions still prevented those users from opening the camera or viewing its recordings.

But the notification had already exposed the image.

That doesn't necessarily mean the surveillance platform itself is insecure. It illustrates something much broader:

A locally secured piece of information can become exposed through an ancillary service even when the permissions protecting the original system are working correctly.

Every additional path sensitive surveillance data takes creates another place where access controls and privacy protections have to work correctly.

And depending on the environment, the consequences can be significant.

A camera covering a parking lot is one thing.

A camera inside a private residence, hospital, behavioral-health facility, school, corporate facility, or other sensitive environment is another.

AI gun detection provides another example

Now consider two different approaches to AI-based firearm detection.

In one architecture, the AI processing occurs locally. Continuous video remains inside the customer's network.

When the AI identifies a potential firearm, however, images associated with that detection leave the customer's environment and are transmitted to an outside monitoring center, where employees of the service provider perform human verification before the event is escalated.

There is a legitimate reason for this.

Human verification is an important safeguard against an AI false positive unnecessarily triggering an emergency response.

But it also means people employed by another organization become part of the security workflow.

Another architecture can still provide human verification but gives the customer more control over who performs it.

The organization may choose professional monitoring, its own Security Operations Center, designated internal security personnel, or another trusted monitoring provider.

Both approaches can accomplish the same important objective of putting a human between an AI detection and an emergency response.

The difference is who controls the decision about who gets to see and verify that security information.

That's important to us.

So is the cloud insecure?

No. That's not really the point.

Cloud services, remote connectivity, professional monitoring, and outside verification can provide tremendous value. Sometimes the benefit they provide absolutely justifies the additional connection or trust relationship.

But those relationships are not security-neutral.

Every additional path sensitive surveillance data takes creates another place where access controls must work correctly.

Every additional system handling that information becomes another system that must remain secure.

And every outside organization entrusted with that information introduces people, policies, infrastructure, and security practices that the customer does not directly control.

That's why one of the questions we believe should be asked when designing any physical security system is remarkably simple:

Does this information actually need to leave the customer's control?

Sometimes the answer is yes.

But it should be a deliberate security decision, made because the service provides enough value to justify the additional trust relationship, not simply because connecting everything to the cloud has become the default.

On-premises doesn't automatically mean secure.

A local system still needs strong credentials, network segmentation, firewalls, updates, physical security, responsible remote-access configuration, and proper user management.

But all else being equal, a system with fewer external paths and fewer outside trust relationships presents fewer external paths and trust relationships that can be compromised.

That's why PVE continues to believe strongly in local-first physical security, while using cloud services where they provide enough value to justify the additional trust relationship.

Sometimes the safest connection is the one you never needed to create.

Pro Video Engineering Securing the Shore Since 1994