Security Before the Network: Why Camera Cybersecurity Starts at the Factory

By the time a security camera connects to your network, many of the decisions that affect its cybersecurity have already been made. The components inside it, the software used to build its firmware, and the controls applied during manufacturing all influence the device you are about to trust.

That trust also has to hold up through installation, configuration changes, and years of service.

At the 2026 Security Technology Forum, David Brent, Cyber Technical Specialist at Chesapeake & Midlantic Marketing, joined Rafael Coelho Lamas, Senior Product Manager of Camera Firmware Platform at IQSIGHT, for Security Before the Network: Building Trust from Factory to Field. Their discussion followed the life of an IQSIGHT camera from its earliest design decisions to the ongoing work required to keep it secure in the field.

For security directors, IT teams, integrators, and consultants, the session offered a practical way to evaluate the processes and support behind the equipment they specify.

Security starts with the blueprint

Rafael described cyber security work beginning before a physical product sample exists. At that stage, the manufacturer is selecting hardware, choosing development tools, and deciding which software components will become part of the device.

Those software decisions deserve close attention. Camera firmware may incorporate third-party libraries, and a vulnerability in one of those components can affect the finished product. Rafael explained that IQSIGHT scans its software libraries during development builds to identify problematic components before a release reaches customers.

The discussion also covered independent penetration testing and third-party evaluation. These practices bring additional scrutiny to the development process and help manufacturers identify weaknesses.

For a buyer, this creates a useful line of inquiry: how does the manufacturer evaluate the hardware, software, and tools behind the camera? Asking about that process adds substance to a conversation that may otherwise focus on image quality, analytics, and price.

Manufacturing gives the camera a verifiable identity

The next step is confirming that the intended components make it into the finished device. Rafael described verification during production, including scanning components and using X-ray inspection for some devices. The purpose is to check that the parts being installed are the parts the manufacturer expects.

He then compared the camera’s device certificate to a passport. A certificate issued during production gives the device an identity that can be checked against the manufacturer’s chain of trust.

Dedicated security hardware, such as a secure element, helps protect the private keys used in that process. Together, the certificate and protected keys give compatible systems a way to verify the camera’s identity.

That identity also fits into a broader approach to network access. With the appropriate certificates, network infrastructure, and configuration, a camera can participate in certificate-based authentication such as 802.1X. This helps an organization verify a device before granting it access to the network.

Commissioning establishes the operating standard

When the camera reaches the customer, the security work moves into installation and integration. The team needs to establish how the camera communicates, which systems can access it, and who can change its configuration.

David and Rafael discussed encrypted communications, certificate management, and a zero trust approach in which devices must prove their identity. These capabilities depend on the camera and the surrounding infrastructure working together, making early coordination between physical security and IT especially useful.

One practical example was software sealing. After commissioning, a software seal can help reveal changes to the camera’s configuration. Rafael explained that a change can generate an alert even when the person making it has valid credentials. That makes the feature useful for detecting accidental changes as well as deliberate interference.

A seal-break notification gives the responsible team a reason to investigate what changed and why. The notification and monitoring arrangements need to be part of the deployment. IQSIGHT’s Cybersecurity Guidebook provides additional guidance on configuration sealing and alert forwarding.

The session also covered stealth mode. On supported platforms, it reduces discovery visibility by disabling discovery responses and ping replies while allowing continued access by IP address. Network security tools can still scan the device. Its use belongs within a planned configuration that accounts for ongoing management and access controls. On the documented platforms, turning it off requires a factory reset.

Maintenance is the longest security commitment

A camera can be installed in a few days and remain in service for years. Rafael identified that maintenance period as a major responsibility for manufacturers and the organizations operating their equipment.

A security scan performed at installation reflects what is known at that time. A vulnerability discovered later can create a new requirement to investigate, mitigate, or update a device that has been working normally.

This is where a software bill of materials, or SBOM, becomes useful. An SBOM identifies software components within a product. When a vulnerability is disclosed, that information helps an IT or security team determine whether an affected component may be present and what to investigate next. The manufacturer’s advisory and the deployed firmware version help establish the appropriate response.

Rafael also discussed the Product Security Incident Response Team, or PSIRT. IQSIGHT’s Product Security and Advisory Center publishes information about identified vulnerabilities, their potential impact, and recommended updates or mitigations. Owners should know where to find that information and who is responsible for acting on it.

The session included an announcement about the direction of firmware support. Rafael described plans for separate development paths: one focused on maintaining an existing firmware branch with security and bug fixes, and another introducing new features.

The intended benefit is easier maintenance for systems with established integrations. A customer could receive fixes on a supported branch while planning a broader feature upgrade around compatibility and operational needs. For a specific project, the supported versions, maintenance period, and release availability should be confirmed with the manufacturer. David Brent and Raphael Transcr…

Plan for the years the camera will remain in service

The discussion of post-quantum cryptography brought the expected service life of a camera into focus. Devices purchased today may still be operating well into the 2030s, so manufacturers need to consider how cryptographic requirements could change during that period.

Rafael outlined planned work to strengthen protection for firmware against future quantum threats. The relevant objective is preserving the ability to verify that firmware updates are authentic and have not been altered as cryptographic capabilities evolve. NIST’s post-quantum digital signature standard addresses that type of protection.

The audience discussion also raised a practical issue: the rest of the system must be able to support the changes. Cameras, video management software, certificate infrastructure, and operating procedures need a coordinated transition.

For owners and integrators, a useful purchasing question is how the manufacturer’s security roadmap fits the expected life of the installation. That conversation can begin while equipment is being selected.

Questions to bring to your next camera project

The session gives project teams several specific questions to bring into product selection and system planning:

How does the manufacturer verify hardware components, software libraries, and the processes used to build the device?
How does the camera prove its identity, and how are its private keys protected?
Which security capabilities are supported by the proposed model and firmware, and which require configuration?
How will the team detect and investigate changes after commissioning?
Where can the owner obtain software component information, security advisories, and mitigation guidance?
How long will the device receive security support, and how will updates be managed alongside existing integrations?

These questions help connect the purchasing decision to the responsibilities that follow installation.

Bring the full project team into the conversation

David also connected the discussion to the organizations supporting a security project. He described MidChes’ work to strengthen its own cybersecurity practices and protect information exchanged along the supply chain. Manufacturers, representatives, integrators, and customers each influence how a project is delivered and supported.

At MidChes, we help security professionals bring these considerations into product selection and system design. That includes understanding the capabilities available, the requirements of the customer’s environment, and the support needed over the life of the system.