How an IP Security Camera Is Made: Image Pipeline, SoC and Firmware

An IP security camera is a lens and a CMOS image sensor feeding a vision system on chip (SoC) that cleans up the picture in an image signal processor (ISP), compresses it with an H.264 or H.265 encoder and sends it over Ethernet or Wi-Fi. That SoC runs a small embedded Linux built from the chip maker's software development kit (SDK), with a web interface, an RTSP server, ONVIF services and, on cloud models, an agent that keeps an outbound connection to the maker's relay servers. The camera is assembled around an actively aligned lens, tested for focus, infrared night vision and weather sealing, certified for sale, flashed with firmware and often given a unique device certificate on the production line.

This post goes one level deeper than our guides to how camera image sensors are made and the evolution from CCD to stacked CMOS. Those posts stop at the sensor. This one follows the whole camera: the optics and infrared parts, the SoC and its pipeline, the factory steps, the firmware image, the protocols that carry video to a recorder or a phone, and the rules that now apply to camera makers and buyers in the US, the UK and the EU. It ends with checks you can run on a camera you own and a design for a local-only recording network. Where camera makers keep numbers private, such as station yields or the size of their relay fleets, we say so instead of guessing.

Key takeaways

• A modern IP camera is a small Linux computer. The vision SoC carries CPU cores, an ISP, a video encoder and often a neural processing unit (NPU) for person and vehicle detection, with flash, RAM, an Ethernet PHY or Wi-Fi radio, and a microphone around it.
• The image pipeline runs in fixed order: raw sensor data, black level and defect correction, demosaicing, white balance, colour correction, tone mapping for wide dynamic range, noise reduction, sharpening, then the encoder. Night mode removes the infrared cut filter and switches on IR LEDs.
• H.264 was first approved by ITU-T in May 2003 and H.265 in April 2013. Most cameras offer both, and the choice changes storage cost more than any other setting.
• RTSP 2.0 (RFC 7826, December 2016) replaced RTSP 1.0 (RFC 2326, April 1998) on paper, but the RTSP servers in cameras still mostly speak 1.0. Video travels as RTP (RFC 3550). RTSP 2.0 defines an rtsps scheme for RTSP over TLS.
• ONVIF profiles are fixed feature sets for interoperability: S for basic streaming, T for H.264 and H.265 streaming with imaging and events, G for recording, M for analytics metadata. ONVIF deprecated Profile Q on 1 April 2022.
• Cloud remote viewing works because the camera opens outbound connections. Peer to peer viewing uses ICE (RFC 8445) to find a direct path and falls back to a TURN relay (RFC 8656) when NAT blocks it. WebRTC is a W3C Recommendation (current version dated 13 March 2025), and its security architecture (RFC 8827) requires encrypted media.
• In US federal procurement, Section 889 and FAR 52.204-25 bar certain video surveillance and telecommunications equipment, from 13 August 2019 for what agencies buy and from 13 August 2020 for what contractors use. The FCC added the named equipment to its Covered List on 12 March 2021 and, on 25 November 2022, barred new equipment authorizations for it.
• For consumer cameras, the UK has banned universal default passwords and required a published security update period since 29 April 2024. ETSI EN 303 645 sets the same baseline in more detail, the EU CRA's reporting duties started on 11 September 2026 and its main obligations apply from 11 December 2027.
• Camera firmware ages the way router firmware does: the SDK pins a kernel, a C library, BusyBox, a web server and OpenSSL or a similar TLS library at the versions the chip maker validated, often years before the camera ships.

Wafer and glass to mounted camera in one table

The table is the map for the rest of the post. It covers the parts that come from semiconductor fabs and optics plants, the camera assembly line, and the installer's work. Camera makers do not publish per-station yields, so the right column names the check rather than a percentage.

Two lines in that table decide most of the camera's security life. Step 10 is where the device gets the identity it will use for years, and where a maker either sets a unique credential or ships the same one in every box. Step 12 is where the owner decides whether the camera talks to the internet at all.

What is inside an IP camera?

Open any wired network camera and you find the same building blocks, in a bullet, dome or turret housing. Wi-Fi models add a radio module and antennas; battery models add a power management chip, a large cell and a low power motion sensor that wakes the main SoC.

The image sensor

The sensor is a CMOS chip with a colour filter array over its photodiodes, usually a Bayer pattern of red, green and blue. Security sensors are tuned for low light: larger pixels, high near infrared sensitivity and on-chip support for multi-exposure high dynamic range. Our image sensor post covers how the sensor itself is built. For the camera, what matters is the interface: the sensor sends raw data over a MIPI CSI-2 or similar serial link to the SoC, and the SoC configures it over a slow control bus at boot.

Lens, IR cut filter and IR LEDs

The lens is a stack of glass or moulded plastic elements in a threaded or glued barrel. Fixed lenses are set at the factory. Varifocal lenses let the installer change the field of view, and motorised varifocal lenses do it with small stepper motors driven by the SoC.

Between the lens and the sensor sits an infrared cut filter on a small electromechanical shutter. By day the filter blocks near infrared light so colours look right. At night the camera swings the filter out of the light path, switches the image to monochrome and turns on infrared LEDs around the lens. Common LED wavelengths are around 850 nm, which shows a faint red glow, and around 940 nm, which is close to invisible but gives less range for the same power. Some cameras use white light LEDs instead to keep colour at night.

The vision SoC

The SoC is the camera. A typical camera SoC has one to four Arm CPU cores for Linux, an ISP, a hardware video encoder for H.264 and H.265 (and often JPEG for snapshots), an NPU for object detection, a DRAM controller, a flash controller, an Ethernet MAC, USB, an audio codec interface and a security block with a boot ROM, OTP fuses and a hardware random number generator. Many camera SoC makers sell the same chip to dozens of brands with a reference design and an SDK. That is why cameras from unrelated brands often have near-identical web interfaces, the same open source packages and the same bugs.

The NPU

On-device detection moved from server software into the camera in the last decade. The NPU runs a quantised neural network that labels each frame with boxes such as person, vehicle or animal. The camera then decides whether to raise an event, send a clip or draw a box in the app. Running detection on the camera means fewer false alerts and less video sent to a server, but it also means the camera ships a model file and an inference runtime that need updates like any other software.

Memory, storage and networking

Cameras use NOR or NAND flash, from 16 MB on small models to several hundred megabytes, and 64 MB to 1 GB of DRAM. A microSD slot holds local recordings on standalone models. The network side is either an Ethernet PHY with a Power over Ethernet (PoE) powered device controller and a small transformer, or a Wi-Fi module. PoE matters here because one cable carries power and data; a PoE switch or recorder can power cycle a camera remotely.

Audio and I/O

A microphone, sometimes a speaker for two-way talk, and on business models alarm inputs and relay outputs. Audio is a privacy decision as much as a feature: in some places recording audio has different legal rules from recording video.

Component comparison table

How does the image pipeline work from sensor to stream?

The ISP turns noisy raw sensor values into a picture people can watch, and the encoder turns that picture into a stream small enough to send and store. Both run in fixed function hardware because a CPU in a camera could not do the work at 25 or 30 frames per second.

The ISP stages, in order

Each stage has a tuning file, written by the chip maker or the camera maker, that sets its parameters for the specific sensor and lens. The order below is the usual one, though chip makers combine and reorder some steps.

1. Black level correction. Subtracts the offset every pixel reads in the dark.
2. Defect pixel correction. Replaces pixels known or detected to be stuck bright or dark.
3. Lens shading correction. Brightens the corners, which a lens naturally darkens, and corrects colour shift towards the edges.
4. Demosaicing. Builds a full colour value for each pixel from its single coloured neighbour values in the Bayer pattern.
5. White balance. Scales red, green and blue so a white object looks white under daylight, tungsten or LED light.
6. Colour correction matrix. Maps the sensor's colour response to a standard colour space.
7. Gamma and tone mapping. Compresses the brightness range so dark and bright areas both stay visible. This is where wide dynamic range (WDR) happens.
8. Noise reduction. Spatial noise reduction within a frame and temporal noise reduction across frames. Temporal filtering is powerful in low light but can smear moving objects, which matters for identifying a person.
9. Sharpening and edge enhancement.
10. Scaling and cropping. Produces the main stream, one or more sub streams and the frames the NPU sees.
11. Statistics. The ISP measures brightness and colour for the auto exposure, auto white balance and auto focus loops, which run in software and feed new settings back to the sensor and lens.

Wide dynamic range

A doorway with daylight behind it can be thousands of times brighter than the face in front of it. Cameras handle this by capturing two or three exposures of each frame, short for the bright parts and long for the dark parts, and merging them in the ISP before tone mapping. Some sensors do this inside one frame with split pixels or staggered readout. The cost is motion artefacts where something moves between exposures, and some loss of signal to noise in the merged image.

Night mode

When the light level falls below a threshold, the camera switches to night mode: the IR cut filter moves out, IR LEDs turn on, the ISP switches to monochrome and a different tuning set takes over with longer exposure and heavier noise reduction. Hysteresis stops the camera flapping between modes at dusk. Reflections from a nearby wall, cobwebs or an eave can blind the camera at night because the IR light bounces straight back.

H.264 and H.265 encoding

The encoder compresses video by predicting each block of a frame from blocks already sent, in the same frame (intra prediction) or earlier frames (inter prediction), then coding only the difference. Every so often it sends a full key frame (an I-frame) so a viewer can start decoding. The gap between key frames is the group of pictures (GOP) length.

ITU-T first approved H.264 in May 2003 and H.265 in April 2013; both have had many later editions, with ITU-T listing editions of each as recent as 2026. H.265 uses larger and more flexible block sizes and better prediction, so it usually needs fewer bits than H.264 for similar quality, at the cost of more processing and weaker support in some browsers and older recorders. Camera makers also offer proprietary "smart" encoding modes that lengthen the GOP and lower the bitrate when the scene is static. These save a lot of storage on quiet scenes and can make a sudden change look blocky for the first second.

The encoder outputs a main stream (full resolution, for recording) and one or two sub streams (low resolution, for live grids, phone viewing and analytics). The camera packs encoded frames into RTP packets for RTSP clients, into a fragmented MP4 or similar container for HTTP or WebRTC clients, and into files on the SD card.

Worked example 1: how much storage a camera needs

Bitrate, not resolution, decides storage. Take a 4 MP camera recording continuously with H.265 at a constant 4 Mbit/s.

• One day: 4,000,000 bits per second x 86,400 seconds = 345,600,000,000 bits.
• Divide by 8 for bytes: 43,200,000,000 bytes, or 43.2 GB per day.
• Thirty days: 43.2 x 30 = 1,296 GB, about 1.3 TB per camera.
• Eight cameras: 1,296 x 8 = 10,368 GB, about 10.4 TB before any RAID overhead.

Now record the same scene in H.264 at 6 Mbit/s, a plausible setting for similar visual quality: 6 / 4 = 1.5 times the storage, or about 15.6 TB for the same eight cameras and thirty days. Switch to motion-only recording that captures, say, 25 percent of the day and the H.265 figure drops to 10,368 x 0.25 = 2,592 GB. These are illustrations; real bitrates vary with scene, light, GOP length and encoder.

Worked example 2: what remote viewing costs your uplink

Remote viewing uses your upload bandwidth, not your download. Suppose a site has a 20 Mbit/s uplink and six cameras.

• Three people watch the 2 Mbit/s sub stream of one camera remotely. If each viewer gets a separate stream through a relay, that is 3 x 2 = 6 Mbit/s of upload.
• One person opens the 4 Mbit/s main stream of two cameras at once: another 8 Mbit/s, for 14 Mbit/s in total.
• If the cameras also upload event clips to a cloud service at an average of 1 Mbit/s each while busy, six busy cameras add 6 Mbit/s and the uplink is full at 20 Mbit/s.

A local recorder that serves one stream per camera to the remote app, instead of each camera serving each viewer, keeps that number flat as viewers grow. That is one practical reason sites with many cameras put a recorder in the middle.

How are cameras assembled, focused and tested?

Board assembly and first flash

The main board is built on a surface mount line like any other electronics: solder paste printing, pick and place, reflow, optical inspection and X-ray of ball grid array joints under the SoC and DRAM. Our post on how a home router is made covers this process in more detail; cameras use the same steps. A test fixture then boots the board, writes a bootloader and a factory test image, checks RAM and flash, brings up Ethernet and PoE, and writes the MAC address and serial number.

Lens active alignment

A fixed-focus camera has to put the sensor in the lens's focal plane within a few micrometres, and keep it there through heat and vibration. Mechanical tolerances alone cannot do that. In active alignment, the station powers the sensor board, streams live frames from it, and moves the lens barrel in several axes (in and out, sideways and tilt) while software scores sharpness on a target at the centre and corners. When the score peaks across the frame, an adhesive is cured with ultraviolet light and heat to lock the lens in place. Varifocal and motorised lenses are aligned less tightly at the factory because the installer or the motor sets final focus.

Image, low light and IR tests

Each unit or a sample of units is checked against colour charts and resolution targets, in a dark room for low light noise and IR range, and through the day/night switch to confirm the filter moves and the LEDs light. The ISP tuning file for the model was written earlier in development, in a lab, by measuring the sensor and lens combination under many light sources. Per-unit calibration, where it exists, is stored in its own flash area.

Weather sealing and IP ratings

Outdoor cameras are sealed with gaskets and cable glands and rated with an Ingress Protection code from IEC 60529. The first digit covers solids and the second covers water. IP66 means dust tight and protected against powerful water jets; IP67 adds protection against temporary immersion. The rating describes the tested design, not each unit, so lines use leak or pressure decay tests on sealed housings to catch a bad gasket. Many outdoor and vandal resistant models also quote an IK impact rating from IEC 62262.

FCC equipment authorization

In the US, the FCC requires radio frequency devices to be authorized under 47 CFR part 2 before they are marketed or imported, through one of two procedures: certification or the Supplier's Declaration of Conformity (SDoC). A wired PoE camera with no radio is an unintentional radiator, a Class A or Class B digital device, and 47 CFR 15.101 lets it use either SDoC or certification. A Wi-Fi camera contains an intentional radiator, and 47 CFR 15.201(b) requires intentional radiators under Part 15 to be certified by a Telecommunication Certification Body. Certified products carry an FCC ID you can look up. Since November 2022, the FCC also refuses new authorizations for equipment on its Covered List, which we come back to below.

What firmware ships on a camera?

The firmware is a full Linux system in a single image. From the bottom up:

Boot ROM and secure boot

The SoC starts from code burnt into its boot ROM. If the maker has enabled secure boot, the ROM checks a signature on the first stage loader against a public key hash fused into OTP memory, and refuses to run unsigned code. That loader then verifies the next stage. Enabling it is the maker's choice, and it commits the maker to managing signing keys for the life of the product, so a camera can ship with secure boot available in silicon but switched off.

The bootloader

Most camera SoCs use U-Boot or a fork of it from the SDK. U-Boot's verified boot uses signed FIT images: the build signs a hash of the kernel, device tree and ramdisk with a private key, and U-Boot checks it with a public key built into its own device tree before booting. The U-Boot documentation is direct about what follows: the signature check only helps if the public key itself sits in memory an attacker cannot change. A bootloader with an open serial console and no password is a common way into cameras on a bench.

Kernel, root filesystem and the SDK

The kernel is the version the chip maker ported to the SoC, with out-of-tree drivers for the ISP, encoder, NPU and sensor. Those drivers are often binary modules that only load into that exact kernel. The root filesystem is usually a read-only SquashFS or similar image with BusyBox, a C library, a small init system, OpenSSL or another TLS library, and the maker's applications, plus a writable partition for configuration.

The SDK bundles all of this: the toolchain, kernel, bootloader, drivers, ISP tuning tools, encoder libraries, NPU runtime and sample applications. Brands build on the SDK and rarely move to a newer kernel once a product ships, because the binary drivers would need to be rebuilt by the chip maker.

The services

A typical camera runs:

• a web server and web UI for setup and live view, often with a CGI or API layer behind it;
• an RTSP server for video streams;
• ONVIF web services (SOAP over HTTP) for discovery, configuration, PTZ control, events and recording search;
• WS-Discovery on UDP so recorders can find it on the LAN;
• an NTP client, because recordings without accurate time are poor evidence;
• often UPnP or a vendor discovery protocol;
• on cloud models, a cloud agent and a peer to peer client;
• an update client;
• sometimes Telnet or SSH left over from development.

ETSI EN 303 645 provision 5.6-1 says all unused network interfaces and unused logical interfaces reachable through a network interface shall be disabled. Development shells are the obvious example.

Why camera images carry old open source components

Four forces push camera firmware towards old components:

1. SDK pinning. The kernel, drivers and libraries are fixed by the chip maker's validated SDK, often a year or two before the camera ships.
2. Binary drivers. Closed ISP, encoder and NPU drivers tie the camera to one kernel version.
3. Long product lives. Business cameras stay on walls for many years. A camera sold for five years and supported for five after that runs its SDK baseline for a decade.
4. Small flash. A 16 MB NOR part leaves no room for a modern TLS library and full userland, so makers keep small, old builds.

Our post on hardcoded credentials in firmware covers one result of the same forces: credentials baked into images that are hard to remove in the field.

Worked example 3: the support gap

Suppose a camera ships in mid 2026 on an SDK built around a Linux 5.10 kernel, and the maker promises security updates until mid 2031. kernel.org lists the projected end of life for 5.10 as December 2026. From January 2027 to mid 2031, about four and a half years, the maker must backport kernel fixes alone, or not at all. The same arithmetic applies to the C library, BusyBox and the TLS library.

How do cloud relay and peer to peer remote viewing work?

Home and small business cameras sit behind NAT on a private address. Nobody on the internet can open a connection to them, which is good. Remote viewing therefore depends on the camera reaching out.

Outbound connections

At boot, a cloud camera resolves its maker's service names, opens a TLS connection to a control server and keeps it alive. It authenticates with a per-device credential or certificate from step 10 of the factory table, and the maker's account system links the device to the owner's account during setup. Events, thumbnails and clips go up over this channel or to object storage. Commands such as "start live view" come down it.

Peer to peer with ICE

For live view, many systems try to connect the phone and the camera directly. Both sides gather candidate addresses: their local address, their public address as seen by a STUN server, and a relay address on a TURN server. ICE, specified in RFC 8445 (July 2018), which obsoletes RFC 5245, has the two sides exchange candidates through the signalling channel and test pairs until one works. If both sides are behind NATs that allow it, video flows directly. If not, it flows through a TURN relay, specified in RFC 8656 (February 2020), which forwards packets without needing to decode them.

WebRTC packages this for browsers and apps. The W3C WebRTC API is a W3C Recommendation, in a current version dated 13 March 2025, and the IETF WebRTC security architecture in RFC 8827 (January 2021) requires implementations to support DTLS-SRTP and forbids sending media over plain, unencrypted RTP, so a TURN relay that only forwards packets cannot read the video. Proprietary peer to peer stacks in cameras follow the same pattern with their own signalling and encryption, and their properties depend on the maker.

Relay servers

When the direct path fails, or the maker always relays, video passes through the maker's servers. Whether the maker can see the video then depends on whether encryption ends at the relay or at the viewer. End-to-end encrypted designs keep the keys on the owner's devices; others decrypt on the server so they can transcode, run cloud analytics or store clips. The maker's documentation is the only place to learn which applies.

What data leaves the home or site

Even when you never open the app, a cloud camera usually sends:

• device identifiers, firmware version and health telemetry;
• account linkage and the public IP address seen by the server;
• event metadata such as "person detected at 14:02";
• thumbnails and event clips, if cloud recording or notifications with images are on;
• continuous video, if a cloud recording plan is active;
• audio, if enabled;
• crash logs and diagnostics.

A local-only design cuts this to nothing, at the cost of remote viewing or with remote viewing through your own VPN.

Cloud versus local comparison

What do ONVIF profiles and RTSP define?

RTSP and RTP

RTSP is a control protocol: a client asks a server to DESCRIBE a stream, SET UP transport, PLAY and TEARDOWN, much like remote control buttons. RTSP 1.0 is RFC 2326 from April 1998. RTSP 2.0 is RFC 7826 from December 2016, which obsoletes RFC 2326 but is not backwards compatible with it. RFC 7826 defines the rtsps URI scheme for RTSP over TLS and describes Basic and Digest authentication. Camera RTSP servers mostly still speak 1.0, commonly with Digest authentication over plain TCP.

The video itself travels as RTP packets, defined in RFC 3550 (July 2003), with RTCP carrying timing and reception reports. RTP can run over UDP, or interleaved inside the RTSP TCP connection, which is easier through firewalls. Plain RTP is not encrypted; SRTP (RFC 3711, March 2004) adds encryption and integrity, but few camera RTSP servers offer it.

ONVIF profiles

ONVIF is an industry forum that publishes interface specifications and conformance profiles. Its profile page puts it simply: a profile has a fixed set of features that a conformant device and client must support, plus conditional features that must be implemented the ONVIF way if the product supports them at all. A device can conform to more than one profile, for example T and G.

ONVIF also lists a Profile V and a Media Signing add-on as release candidates, and a TLS Configuration add-on. We describe them here only as the ONVIF site labels them.

Designing a local-only recording setup with an NVR

A local-only design keeps video on site and treats cameras as untrusted appliances. The pieces:

1. A camera VLAN. Put cameras on their own VLAN and subnet, served by a PoE switch that supports 802.1Q.
2. A recorder. An NVR appliance or a server running open source NVR software, with one interface or VLAN tag on the camera network and one on the main LAN.
3. No internet route for cameras. The router drops all traffic from the camera VLAN to the internet and to other VLANs, except to the recorder and to a local NTP server.
4. Local time. Run NTP on the router or recorder and point cameras at it, so timestamps are correct without internet access.
5. Local DNS that answers nothing useful. Cameras that cannot resolve their cloud names stop trying and log errors, which is harmless.
6. Remote access by VPN only. Users reach the recorder over a VPN to the router. Nothing is port forwarded.
7. Per-camera accounts. A unique admin password per camera, and a separate low privilege ONVIF or RTSP account for the recorder.
8. Firmware updates by hand. Download updates on a normal machine, check the hash or signature against the maker's page, and upload them through the camera's web UI or the recorder.

What do US procurement rules and consumer IoT laws require?

NDAA Section 889 and FAR 52.204-25

Section 889 of the John S. McCain National Defense Authorization Act for Fiscal Year 2019 is implemented in FAR clause 52.204-25. It defines covered telecommunications equipment and services to include telecommunications equipment from two named telecommunications makers, and video surveillance and telecommunications equipment from three named makers when used for public safety, security of government facilities, physical security surveillance of critical infrastructure and other national security purposes, along with their subsidiaries and affiliates.

The clause sets two prohibitions. From 13 August 2019, agencies may not procure equipment, systems or services that use covered equipment as a substantial or essential component or as critical technology. From 13 August 2020, agencies may not contract with an entity that uses such equipment, whether or not the use is in performance of a federal contract. A contractor that finds covered equipment during performance must report the contract number, supplier, brand, model number and item description within one business day, and further mitigation information within ten business days. The clause defines a substantial or essential component as any component necessary for the proper function or performance of a piece of equipment, system or service.

For a camera buyer, this means a federal contractor must know the original maker of every camera, recorder and module, including OEM and white label products sold under another brand name. The clause's model number field explicitly includes original equipment manufacturer and manufacturer part numbers.

The FCC Covered List and equipment authorization

The FCC's Covered List, maintained under the Secure and Trusted Communications Networks Act of 2019, includes the same video surveillance and telecommunications equipment, with a date of inclusion of 12 March 2021 for those entries. On 25 November 2022 the FCC released a Report and Order, implementing the Secure Equipment Act of 2021, that bars new equipment authorizations for equipment on the Covered List. Because nothing can be marketed in the US without authorization, that rule reaches consumer and business buyers too, not only federal ones.

UK PSTI

The UK Product Security and Telecommunications Infrastructure (Product Security) regime has applied since 29 April 2024 to UK consumer connectable products, which the government also calls smart products; a network camera sold to consumers is the kind of product it was written for. The regulations were signed into law on 14 September 2023. Its three requirements, as the UK government summarises them:

• passwords must be unique per product or set by the user, and not based on incremental counters, public information or serial numbers (unless derived with accepted cryptography), or otherwise easily guessable;
• the manufacturer must publish how to report security issues;
• the manufacturer must publish the minimum security update period, with an end date, in clear language, free of charge.

ETSI EN 303 645

ETSI EN 303 645 is the European baseline for consumer IoT security; the current version on ETSI's server is V3.1.3, published in September 2024. Provision 5.1-1 requires passwords that are unique per device or set by the user. Provision 5.3-1 says software components that are not immutable for security reasons should be securely updateable, and 5.3-13 requires the manufacturer to publish the defined support period. Provision 5.6-1 requires unused network and logical interfaces to be disabled, and 5.8-1 asks for best practice cryptography for personal data in transit between the device and associated services, which for a camera includes the video.

EU Cyber Resilience Act

The CRA entered into force on 10 December 2024 and applies to products with digital elements placed on the EU market, cameras included. Reporting obligations for actively exploited vulnerabilities and severe incidents in Article 14 apply from 11 September 2026; the regulation is fully applicable from 11 December 2027.

US consumer guidance: NIST IR 8425 and the Cyber Trust Mark

NIST IR 8425 (September 2022) is the consumer profile of NIST's IoT core baseline, written in response to Executive Order 14028. It phrases capabilities as outcomes for the whole product, including the companion app and cloud backend. The FCC's voluntary U.S. Cyber Trust Mark program applies to consumer wireless IoT products and lists internet-connected home security cameras as an example of an eligible product; wired devices are outside it.

CISA Secure by Design

CISA's Secure by Design programme asks manufacturers to take ownership of customer security outcomes. Companies that sign its pledge commit to a good-faith effort towards seven goals, which include reducing default passwords and increasing the installation of security patches.

Regulation comparison

How do you check a camera's firmware, exposed services and update channel?

The steps below are read-only checks on a camera you own or administer. Do not run scans against devices or networks you do not control.

Step 1: identify the camera

Read the label for the model, hardware revision, serial number and, for wireless models, the FCC ID. Look up the FCC ID in the FCC equipment authorization database to see the grantee and the test reports, which often show the internal board. For OEM and white label models, the grantee can tell you who actually made the camera, which matters for Section 889.

Step 2: find its address and read the firmware version

Find the camera's IP address in your router's DHCP lease table, then read the firmware version in the web UI under system or device information. If the camera speaks ONVIF and your recorder lists it, the recorder usually shows the same data from the ONVIF GetDeviceInformation call.

Step 3: list the services it exposes on the LAN

From a machine on the same network, scan only the camera's address:

# Replace with your camera's address
CAM=192.168.50.21

# TCP services with version detection
nmap -sV -p- --open "$CAM"

# Common UDP services: discovery, NTP, SSDP
sudo nmap -sU -p 123,1900,3702,5353 "$CAM"

Expect HTTP or HTTPS (80, 443), RTSP (554), and perhaps ONVIF on its own HTTP port. Telnet (23), SSH (22) or an unknown high port you did not enable are worth a support ticket.

Step 4: check the RTSP stream and its authentication

# Without credentials: the stream should refuse to play
ffprobe -v error -rtsp_transport tcp "rtsp://$CAM:554/"

# With your own read-only account, the stream should describe its codec
ffprobe -v error -rtsp_transport tcp -show_streams \
  "rtsp://viewer:YOUR_PASSWORD@$CAM:554/stream1" | grep -E 'codec_name|width|height'

The stream path varies by maker; the recorder or the camera's documentation lists it. If the first command returns stream details without credentials, the camera allows anonymous RTSP and you should turn that off.

Step 5: check the web UI's TLS

openssl s_client -connect "$CAM:443" -servername "$CAM" </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

A self-signed certificate is normal on a LAN camera. A certificate that expired years ago, or a web UI that only offers HTTP, tells you how old the firmware's TLS stack is.

Step 6: watch what it talks to

On a Linux router or a machine on a mirrored switch port, watch the camera's DNS lookups and outbound connections for an hour:

sudo tcpdump -ni eth0 "host $CAM and (port 53 or tcp[tcpflags] & tcp-syn != 0)"

The DNS names show which cloud, update and NTP services the camera uses. Compare them with the maker's documentation.

Step 7: find the update channel and support period

Check whether the camera updates automatically, whether the maker publishes release notes and hashes, and whether a support end date is published, as the UK PSTI regime and ETSI EN 303 645 provision 5.3-13 expect. Note the date in your asset list.

Step 8: move it to its own VLAN

On a Linux router using nftables, a camera VLAN that can only reach the recorder and local NTP looks like this. Adjust interface names and addresses to your network:

# Camera VLAN 50 on interface br0.50, recorder at 192.168.10.5, router NTP at 192.168.50.1
sudo nft add table inet cams
sudo nft add chain inet cams fwd '{ type filter hook forward priority 0; policy accept; }'
sudo nft add rule inet cams fwd iifname "br0.50" ct state established,related accept
sudo nft add rule inet cams fwd iifname "br0.50" ip daddr 192.168.10.5 tcp dport '{ 554, 80, 443 }' accept
sudo nft add rule inet cams fwd iifname "br0.50" drop
sudo nft add chain inet cams in '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet cams in iifname "br0.50" udp dport '{ 53, 67, 123 }' accept
sudo nft add rule inet cams in iifname "br0.50" drop

The recorder opens connections to the cameras, and the forward chain's default policy accepts that; if your router's default forward policy is drop, add an explicit rule that lets the recorder's address reach VLAN 50 on the RTSP and web ports. Test that live view and recording still work, then confirm with tcpdump that nothing from VLAN 50 leaves for the internet.

Step 9: record what you found

Keep a simple table per camera: model, hardware revision, original maker, firmware version, last update date, support end date, exposed services, VLAN, accounts. That table is the inventory both Section 889 reporting and an incident response need.

Common mistakes

• Port forwarding the camera. It exposes the web UI, RTSP and any leftover services to constant internet scanning. Use a VPN to a recorder instead.
• Keeping the setup password. Many cameras now force a unique password, but older ones and some recorders still accept a well known default on secondary accounts or ONVIF.
• Using one admin account everywhere. The recorder needs a low privilege stream account, not the camera admin password.
• Leaving UPnP on. A camera or recorder can open its own port forwards on routers that allow it.
• Trusting the brand on the box. OEM and white label cameras carry another maker's hardware and firmware. Federal contractors need the original maker; everyone needs the firmware source for updates.
• Assuming "local" means local. Some cameras keep a cloud agent running even when you never create an account. Watch the DNS traffic.
• Ignoring time. Cameras without correct time produce footage that is hard to use. Give them local NTP.
• Never updating. The SDK baseline is old on day one; skipped updates make it older.
• Forgetting the recorder. The NVR runs the same kind of embedded Linux, often with more services and its own cloud agent, and it holds every camera's credentials.
• Aiming without thinking. A camera that covers a neighbour's garden or a public pavement raises legal questions in some places. Check local rules before mounting.

FAQ

What chip is inside an IP security camera?

A vision system on chip that combines Arm CPU cores, an image signal processor, a hardware H.264 and H.265 encoder and, on newer models, a neural processing unit for detection. Camera SoC makers sell the same chips, reference designs and SDKs to many brands, which is why unrelated brands often share software.

How does an IP camera see at night?

It moves its infrared cut filter out of the light path, switches to monochrome and lights the scene with infrared LEDs, usually around 850 nm or 940 nm. The sensor is sensitive to near infrared even though your eyes are not. Some cameras use white light or very sensitive sensors to keep colour at night instead.

Is H.265 better than H.264 for security cameras?

H.265 usually needs fewer bits for similar quality, which cuts storage and upload use, but needs more processing to decode and has weaker support in some browsers and older recorders. If your recorder and viewing apps support H.265, it is usually the better choice for recording; keep H.264 for any sub stream a browser must play.

What is the difference between RTSP and ONVIF?

RTSP is a protocol for starting, stopping and controlling a media stream, with the video itself carried as RTP. ONVIF is a set of interface specifications and conformance profiles that cover discovery, configuration, events, PTZ, recording and analytics, and that point clients to the camera's RTSP streams. A recorder typically uses ONVIF to find and configure a camera and RTSP to pull its video.

Can an IP camera work without the internet?

Yes, if it supports RTSP or ONVIF and a local recorder or app. Put it on a VLAN without an internet route, give it local NTP for time, and view it through the recorder or a VPN. Some cloud-only models stop working, or lose features, without their cloud service, so check before you buy.

How does a cloud camera stream to my phone without port forwarding?

The camera keeps an outbound TLS connection to the maker's servers. When you open live view, the app and the camera exchange connection candidates through that channel, and ICE picks a direct path through both NATs if one exists. If not, video goes through a relay server.

Are security cameras covered by the NDAA ban?

Section 889 of the FY2019 NDAA, implemented in FAR 52.204-25, bars federal agencies from buying, and from contracting with entities that use, video surveillance and telecommunications equipment from named makers for the listed security purposes, including their subsidiaries and affiliates. It applies to federal procurement and contractors. Separately, the FCC has barred new equipment authorizations for equipment on its Covered List since its November 2022 order.

How long will my camera get security updates?

Only as long as the maker says. In the UK, makers of consumer connectable products must publish a minimum security update period with an end date, and ETSI EN 303 645 asks for the same. Check the product page or support site, and note the date when you buy.

Should I put my security cameras on a separate VLAN?

Yes. A camera VLAN that can reach only your recorder and local time and DNS services limits what a compromised camera can reach, and stops cloud traffic you did not choose. Test live view and recording after the change.

Do security cameras use open source software?

Almost always. The bootloader, Linux kernel, BusyBox, C library, TLS library and web server in most camera firmware are open source, usually at the versions in the chip maker's SDK. A GPL source release from the maker, where one exists, is the most complete list of what is inside.

Where Safeguard fits, honestly

Safeguard does not analyse cameras, scan firmware images, generate hardware bills of materials or manage devices. The fit is indirect and sits in the software around the camera. Teams that build a video management system, a recorder application, a companion app, a cloud relay or the services behind a camera account ship ordinary open source dependencies and container images, and Safeguard scans those: repositories with safeguard scan --dir ., container images with --image, and SBOM files with --sbom. If a camera maker hands you an SBOM for its firmware, Safeguard can read that SBOM file like any other; it does not unpack or inspect the firmware image itself. The fix for a vulnerable component inside a camera still has to come from the camera maker.

A camera is a closed appliance, but the recorder software, apps and cloud services that make cameras useful are built from the same open source packages and container images as any other product, and they are rebuilt and redeployed often. Keeping those dependencies current is the part of camera system security that the people building the software actually control.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow fits a video management web UI, a camera companion app backend or a provisioning service your team maintains.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a team that builds recorder software or relay services on its own build hosts and wants scans to run where the build runs, against a source tree, a container image or an SBOM file it already produces.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. If your team already uses Claude for engineering questions, this is how the same conversation can look up which of your projects carry a vulnerable component when an advisory names one used in your camera software.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• ONVIF, Profiles overview
• ONVIF, Profile S
• ONVIF, Profile T
• ONVIF, Profile G
• ONVIF, Profile M
• ONVIF, Profile A
• ONVIF, Profile C
• ONVIF, Profile D
• IETF, RFC 7826, Real-Time Streaming Protocol Version 2.0 (December 2016)
• IETF, RFC 2326, Real Time Streaming Protocol (April 1998)
• IETF, RFC 3550, RTP: A Transport Protocol for Real-Time Applications (July 2003)
• IETF, RFC 3711, The Secure Real-time Transport Protocol (March 2004)
• IETF, RFC 8445, Interactive Connectivity Establishment (July 2018)
• IETF, RFC 8656, Traversal Using Relays around NAT (February 2020)
• IETF, RFC 8827, WebRTC Security Architecture (January 2021)
• IETF, RFC 8835, Transports for WebRTC
• W3C, WebRTC: Real-Time Communication in Browsers, Recommendation 13 March 2025
• ITU-T, Recommendation H.264, editions
• ITU-T, Recommendation H.265, editions
• U-Boot documentation, U-Boot verified boot
• The Linux Kernel Archives, Releases
• Acquisition.gov, FAR 52.204-25, Prohibition on Contracting for Certain Telecommunications and Video Surveillance Services or Equipment
• FCC, List of Equipment and Services Covered by Section 2 of the Secure Networks Act
• FCC, FCC Bans Authorizations for Devices That Pose National Security Threat (released 25 November 2022)
• FCC, Equipment Authorization
• eCFR, 47 CFR 15.101, Equipment authorization of unintentional radiators
• eCFR, 47 CFR 15.201, Equipment authorization requirement
• FCC, U.S. Cyber Trust Mark
• NIST, IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (September 2022)
• ETSI, EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
• GOV.UK, The UK Product Security and Telecommunications Infrastructure (Product Security) regime
• European Commission, Cyber Resilience Act: summary of the legislative text
• CISA, Secure by Design
• CISA, Secure by Design Pledge

Last reviewed: 24 October 2026.