Most conversations about least privilege access happen in IT departments, not security control rooms. That’s a problem because physical security deployments are increasingly networked, increasingly cloud-connected, and increasingly vulnerable to the same threats that keep IT teams up at night. Integrators who treat identity and access management as someone else’s responsibility are leaving their customers exposed.
What Least Privilege Access Actually Means and Why Physical Security Can’t Ignore It
Least privilege access is a cybersecurity principle that gives every user, application, device, or service exactly the permissions it needs to perform its specific function and nothing more. It’s closely related to zero trust, and at its core, it’s about limiting what can go wrong when any single credential or device is compromised.
A useful analogy: if you hire a plumber to fix a pipe in your office, you give him access to that specific cabinet under that specific sink. You don’t hand him a master key to the entire facility. The same logic applies to the users, devices, and software running on your security network.
In practice, this means security guards should access live video, not archived footage, not system configuration. Administrators may need video review access. Only super administrators should have the ability to export recordings. Each boundary you draw is one fewer vector an attacker can exploit if they ever get in.
How Often Does Physical Security Actually Follow These Principles?
Not often enough. In a recent visit to an end user, I found every security guard logging into the VMS with the same shared username and password. No individual user accounts. No role separation. No ability to trace who accessed what, or when.
That’s not an edge case, it’s the norm in a lot of installations, especially those where technicians are focused on getting cameras online and moving to the next job. If the camera is recording and the live view works, the job is considered done.
User management, access group configuration, and privilege scoping get attention when they’re explicitly written into the scope of work, and that is often not the case. The result is that customers are running systems that would fail a SOC 2 or ISO compliance audit. Some of them don’t find out until the auditor shows up.
The Real Cost of Getting This Wrong
Compliance failures and regulatory fines are real consequences. But they’re not the worst outcome.
It’s important to be clear about responsibility here: from a compliance and liability standpoint, the organization, not the integrator, owns the outcome of how access is configured.
The worst outcome is ransomware.
Here’s what that looks like in practice. In one real-world case, an organization allowed a third-party integrator to deploy a separate camera system, roughly 100 cameras and several appliances directly onto its network. The system introduced had known vulnerabilities, including backdoor access, exploitable through a mobile application. Attackers exploited those vulnerabilities, gained a foothold in the network, and moved laterally across systems. The result was a full ransomware event that locked the organization out of critical infrastructure. Operations were disrupted, systems went offline, and access to key data was lost.
“That’s not hypothetical. I’ve seen the aftermath of exactly this kind of failure firsthand. And the root cause wasn’t just a bad camera brand it was a failure to apply least privilege principles to a network-connected device that was given far more access than it ever needed.”
Four distinct failures made that attack possible:
- Network segmentation failure. The camera system was deployed on the broader network without proper isolation. A set of devices that should have been contained was given a pathway into critical systems.
- Device-level privilege failure. The cameras and supporting software were granted more access than necessary to function. These devices didn’t need visibility beyond their role, but they had it.
- Vendor and system vetting failure. A third-party system with known risks was introduced without being evaluated against the organization’s security standards.
- Identity and access control failure. There were no meaningful restrictions in place to limit what those systems or anyone accessing them could reach. Once inside, the attacker wasn’t contained.
Least privilege isn’t just about user logins inside a VMS. It applies to every device, system, and integration connected to the network. When these principles are enforced, isolating the system, restricting what it could communicate with, and limiting access at every level, attacks can be contained or prevented entirely.
Identity Management Is Not an IT Problem, It’s an Integration Problem
Some integrators genuinely believe that network security and identity management are IT’s responsibility. They’re wrong and the consequences show up on their projects.
I’ve seen deployments where the IT department was barely consulted during system design. The installation crew showed up and discovered the organization ran multiple separate networks. The system couldn’t be deployed as designed. Weeks of rework followed. The customer’s confidence in their integrator took a hit.
IT departments and security departments have historically been siloed. That must change. Every stakeholder needs to be at the table when a security solution is being designed, not brought in after the fact to clean up problems. If an IT team refuses to be involved, the security system should run on its own dedicated network, isolated from the broader enterprise infrastructure. That’s not ideal, but it’s far better than deploying on a shared network without proper access controls in place.
How to Configure CompleteView for Least Privilege
When deploying CompleteView or any VMS, integrators should think carefully about user group structure from day one. The goal is to match each role’s access level to exactly what that role requires.
A practical tiered model looks like this:
- Security guards — live video access only
- Line supervisors / operators — recorded footage review and playback
- Administrators — camera and configuration management within their defined scope
- Super administrators — full system access, including video export
This structure also scales. A deployment with 50 cameras and 10 users can run on the same role architecture as one with 5,000 cameras and 200 users the tiers don’t change, only the number of people in them. Organizations that skip proper role design at the start almost always face a painful access audit when they grow, because permissions that were manageable at small scale become nearly impossible to untangle at enterprise scale.
This isn’t just about security, it’s about accountability. When an incident occurs and you need to investigate, you need to know who accessed what footage, when, and what actions they took. Shared credentials make that investigation nearly impossible.
Where possible, the VMS should integrate with existing identity platforms such as Active Directory or single sign-on to maintain consistency across the organization. This is an area where open platform VMS architectures have a meaningful advantage over proprietary systems, a closed platform that doesn’t support native AD or SSO integration forces organizations to manage security identities in two separate places, which is exactly the kind of inconsistency that creates gaps. Temporary users and third-party vendors should be limited to time-bound access that expires when it is no longer needed.
This approach requires more planning upfront, but the tradeoff is clear. The cost of poor access design isn’t just a security risk, it’s an operational cost. Rework after a failed audit, incident investigations that stall because of shared credentials, ransomware recovery, weeks of re-deployment when IT discovers the system wasn’t designed to their standards: these are all line items that a proper access design eliminates before they happen. A small investment in design reduces long-term risk, improves accountability, and results in a deployment that is easier to manage and defend.
Starting the Conversation With Customers Who Haven’t Thought About This
Most customers haven’t done a formal access audit and many don’t know they need one. The integrator’s job is to open that conversation. Start by asking how the organization’s security operations are structured:
- How many users interact with the system?
- Who monitors vs. reviews footage?
- Who administers the system?
- What compliance requirements exist?
From there, help them map their existing staff to an appropriate access tier structure. Most organizations discover quickly that they’ve been running with either everyone having full access, or access so inconsistently configured that no one is sure who can do what.
“Someone recently asked me what I did. My honest answer was: I’m in education. I spend my time teaching integrators, consultants, and end users what today’s technology is capable of and how to implement it correctly. A lot of integrators have stopped doing that kind of teaching. The ones who start doing it again will stand out.”
What Integrators Can Do Right Now
The most immediate step any integrator can take is to bring IT into the conversation before the system design is finalized.
When talking to a prospect or customer about a VMS deployment, ask who manages their network security. Ask what compliance frameworks they operate under. Ask whether they have an identity management policy for other enterprise software, and if they do, apply the same logic to the security system. Access control should be addressed during the design phase, with clearly defined roles and permissions documented as part of the scope of work.
Physical security is part of the enterprise now. It runs on the same networks, shares infrastructure with the same devices, and is subject to the same regulatory scrutiny as every other IT system. The integrators who understand that and who can speak the language of access governance will be the ones customers trust with their most critical infrastructure.
Key Takeaways
- Least privilege access limits breach exposure. When any user account or device is compromised, limited permissions mean limited damage — attackers can only access what that account could access.
- Shared credentials are a compliance and forensics failure. A single login for multiple users makes audits impossible and incident investigations nearly impossible.
- VMS deployments need user group structure from day one. Guards, operators, administrators, and super administrators each need scoped access. This should be part of every installation scope of work.
- Ransomware is a real, documented risk. Networked physical security devices with poor access controls have been used as entry points for attacks on critical infrastructure, including healthcare organizations.
- IT and security teams need to work together from the start. Siloed deployments create gaps. If IT won’t engage, the security system needs its own isolated network.
- The integrator’s role is to educate. Most customers haven’t thought through their access structure. Help them build one.
