Only 2% of Camera Segments Are Camera-Only: Segmentation and Remote Access Lessons for Security Integrators

Two things came out last week that, read together, describe the job of a security integrator pretty well.
On September 22, 2026, Forescout’s Vedere Labs published an analysis of 47,700 network segments containing more than 2.5 million devices across 209 organizations. One number jumped out at me: of the 2,266 segments that contained IP cameras, only 2% contained cameras and nothing else.
Two days later, on September 24, CISA and the FBI released a fact sheet for critical infrastructure operators on working with third-party industrial control system (ICS) integrators. The advice: least-privilege access, security requirements in contracts, less internet exposure, and logging of remote access.
We’re a small MSP and physical/IP security integrator in Humboldt County. We install cameras, door and gate access control, and the networks they ride on. Both of these land squarely on us, so here’s how I read them.
What Forescout found about cameras
From the Forescout report:
- About 5% of all analyzed segments (2,266) contained IP cameras.
- Only 2% of those camera segments held cameras exclusively.
- In the mixed segments, 60% also had workstations, 47% had printers, and 37% had servers.
- Forescout’s summary: “In more than half of the cases where a threat actor compromises an IP camera, an IT workstation or server is present in the same segment.”
- They also documented more than 300 cases in 2026 of hacktivist groups gaining control of exposed IP cameras, including attacks by the pro-Russian group NoName057(16) against Estonian and Canadian targets in late August and early September.
So cameras are usually sitting next to the things that actually matter. A camera is a small Linux box that rarely gets updated and often has a web server on it. If it’s on the same flat network as the front-desk PC and the file server, a compromised camera is a foothold, not just a lost video feed.
What the CISA/FBI integrator fact sheet says
The fact sheet is written for critical infrastructure operators, but the recommendations translate directly to anyone who lets a vendor into their network. According to SecurityWeek’s coverage, the key points are:
- Grant users “only the minimum access necessary to perform their assigned tasks, and no more.”
- Put cybersecurity and supply chain requirements in contracts, covering data storage, remote access, and patch management.
- Know where devices are hosted and reduce public internet exposure.
- Monitor and log remote access, and prefer on-demand remote access over always-on.
The guidance references an FBI analysis of a March–April 2025 intrusion at an industrial automation company, where foreign actors staged nine archives containing 800 network schematics and customer details. That’s the uncomfortable part for integrators: we hold the drawings, the IP plans, and often the credentials for every site we’ve built. We are a target because of our customers.
How I isolate a camera network
Here’s the design I recommend for a small business camera system. It works whether the VMS is a UniFi Protect console, a Windows server running a VMS, or a standalone NVR.
- Put cameras on their own VLAN. Cameras only. No printers, no “temporary” laptop, no badge readers unless they’re part of the same system and you’ve thought it through.
- Default deny out of the camera VLAN. Cameras shouldn’t reach the office LAN, and in most cases shouldn’t reach the internet either.
- Allow only the recorder in. The NVR or VMS server is the only thing that talks to the cameras, on the ports the system actually uses.
- Give access control its own segment too. Door controllers and readers are a physical security system. Treat them at least as carefully as the cameras.
- Let people watch through the VMS, not the cameras. Staff and remote viewers connect to the recorder or its app. Nobody browses to a camera’s IP address day to day.
A simple policy table makes this easy to review with a client:
| From | To | Allow | Why |
|---|---|---|---|
| Recorder / VMS | Camera VLAN | Yes, required ports only | Recording and management |
| Camera VLAN | Recorder / VMS | Yes, established/related | Replies to the recorder |
| Camera VLAN | Office LAN | No | Stop lateral movement |
| Camera VLAN | Internet | No (or NTP only, if needed) | Cameras don’t need to phone home |
| Office LAN | Camera VLAN | No | View through the VMS instead |
| Admin workstation | Camera VLAN | Yes, during maintenance | Firmware and config work |
📝 Note: Some camera platforms need outbound access for cloud features or time sync. Open exactly what the vendor documents, not “any”.
Auditing an existing camera VLAN
Forescout’s point about “segmentation drift” is real. Networks start clean and then someone plugs in a printer. This is the check I’d run on a camera VLAN to find devices that don’t look like cameras. Only scan networks you’re responsible for.
# Scan the camera VLAN for common camera ports plus ports cameras usually don't have
nmap -n -p 22,80,139,443,445,554,3389,5900,9100 --open -oX camvlan.xml 10.20.30.0/24
Then parse the results and flag anything exposing Windows file sharing, RDP, VNC, or raw printing:
#!/usr/bin/env python3
"""Flag hosts on a camera VLAN that expose services cameras normally don't."""
import sys
import xml.etree.ElementTree as ET
SUSPECT = {
139: "NetBIOS",
445: "SMB file sharing",
3389: "RDP",
5900: "VNC",
9100: "raw printing",
}
def main(path: str) -> None:
root = ET.parse(path).getroot()
flagged = 0
for host in root.findall("host"):
addr = host.find("address").get("addr")
open_ports = {
int(p.get("portid"))
for p in host.findall("ports/port")
if p.find("state").get("state") == "open"
}
hits = [f"{port}/{SUSPECT[port]}" for port in sorted(open_ports) if port in SUSPECT]
if hits:
flagged += 1
print(f"{addr}: not camera-like -> {', '.join(hits)}")
print(f"{flagged} host(s) flagged for review.")
if __name__ == "__main__":
main(sys.argv[1] if len(sys.argv) > 1 else "camvlan.xml")
This won’t catch everything. A workstation with its firewall on won’t show those ports. But it catches the common mistakes quickly, and you can run it every quarter.
Keeping integrator remote access honest
This is the part that applies to us as a vendor, and to any MSP. The CISA/FBI advice boils down to: access should be minimal, on-demand, and logged. What I recommend:
- Separate accounts per technician. No shared “installer” login across sites.
- Separate credentials per site. One leaked password shouldn’t open every customer.
- On-demand access. Remote access is turned on for the work and off afterward, or requires the client to approve it.
- MFA on everything that supports it, including vendor portals and cloud consoles.
- Log every session, and review the log with the client. If you can’t tell a customer who connected to their system last month and why, you’re not ready for the question.
If you already track work in a database, logging sessions is not much extra. Here’s a minimal Microsoft SQL Server table and the monthly review query I’d start from:
CREATE TABLE dbo.RemoteAccessSession (
SessionId INT IDENTITY(1,1) PRIMARY KEY,
ClientName NVARCHAR(100) NOT NULL,
SiteName NVARCHAR(100) NOT NULL,
Technician NVARCHAR(100) NOT NULL,
SystemName NVARCHAR(100) NOT NULL, -- e.g. 'VMS server', 'Access controller'
StartedAtUtc DATETIME2(0) NOT NULL,
EndedAtUtc DATETIME2(0) NULL,
TicketNumber NVARCHAR(50) NULL,
Purpose NVARCHAR(400) NOT NULL
);
-- Last month's sessions per client, with sessions that have no ticket called out
DECLARE @MonthStart DATE = DATEADD(MONTH, DATEDIFF(MONTH, 0, SYSUTCDATETIME()) - 1, 0);
DECLARE @MonthEnd DATE = DATEADD(MONTH, 1, @MonthStart);
SELECT
ClientName,
COUNT(*) AS Sessions,
SUM(CASE WHEN TicketNumber IS NULL THEN 1 ELSE 0 END) AS SessionsWithoutTicket,
SUM(DATEDIFF(MINUTE, StartedAtUtc, COALESCE(EndedAtUtc, StartedAtUtc))) AS TotalMinutes
FROM dbo.RemoteAccessSession
WHERE StartedAtUtc >= @MonthStart
AND StartedAtUtc < @MonthEnd
GROUP BY ClientName
ORDER BY SessionsWithoutTicket DESC, Sessions DESC;
Any session without a ticket is a conversation to have. Usually it’s a tech who forgot to link the ticket. Occasionally it’s something you really want to know about.
What I tell clients
For a business owner, I keep it simple: “Your cameras live on their own network. They can record, you can watch them through the app, and if one of them ever gets compromised, it can’t reach your computers.” And: “When we connect remotely, it’s logged, and we can show you the log.”
For other integrators and MSPs, the Forescout numbers say most camera networks aren’t as separated as we think, and the CISA/FBI fact sheet says customers are going to start asking how we access their systems. Both are easier to answer before someone asks.
Sources
- What 47,700 Segments Reveal About Network Segmentation — Forescout Research – Vedere Labs, September 22, 2026
- Forescout finds network convergence across IT, OT, IoT and IoMT could increase lateral movement and cyberattack impact — Industrial Cyber, September 24, 2026
- OT Security Guidance: NIST Drafts Updated Guide, CISA, FBI Advise on ICS Integrators — SecurityWeek, September 24, 2026
- Considerations for Critical Infrastructure Operators Working with Third-Party ICS Integrators — CISA and FBI, September 24, 2026

