How a Dash Cam Is Made: Sensors, Supercapacitors, GNSS and Privacy

A dash cam is made by bonding a lens to a CMOS image sensor, focusing and fixing that lens on a calibration rig, and wiring the module to a video system on chip that encodes footage onto a microSD card. A supercapacitor or small battery, a GNSS receiver, an accelerometer and often a Wi-Fi or LTE radio complete the device, and firmware decides what is recorded, what is locked after a jolt and where the footage goes next.

That makes a dash cam a privacy device as much as a camera. It films strangers, plates and sometimes conversations, carries a radio, and runs firmware you update from a file or an app. This post covers each part, how a factory builds it, how firmware handles loop recording and parking mode, what EU, UK and US rules say about footage, and a hands-on hardening routine. Makers keep bills of materials and yields private, so we describe process categories, cite standards and regulators in their own words, and label illustrative numbers as such.

For the sensor itself, read how camera image sensors are made. For data the car collects, read connected car data privacy explained. For cameras built to read plates, read automated license plate readers explained. For a sibling device with the same GNSS and firmware story, read how a drone is made.

Key takeaways

• A dash cam has seven blocks: optics and CMOS sensor, a video SoC with an image signal processor and encoder, removable flash storage, hold-up power (usually a supercapacitor), GNSS, an accelerometer (the G-sensor) and optional Wi-Fi, Bluetooth or LTE.
• A supercapacitor only has to hold the camera up for seconds so the last file closes cleanly, and it copes with a hot windscreen better than a lithium cell.
• Loop recording overwrites the oldest clip; a G-sensor trigger locks the current clip. 49 CFR Part 563 applies the same locking idea to a car's event data recorder, but its EDR definition excludes audio and video.
• The SD Association's Video Speed Class (V6 to V90) guarantees a minimum write speed, not endurance. Endurance is the card maker's rating.
• ETSI EN 303 645 V3.1.3 requires unique or user-set passwords, a secure update mechanism, and verification of network-delivered updates via a trust relationship such as a digital signature.
• The EDPB's Guidelines 3/2019 say a dash cam should not be constantly recording traffic and people near the road, and publishing footage online is not household activity.
• US federal law allows recording a conversation you are part of or with one party's consent; several states require every party's consent. Turn the microphone off with passengers.
• Safeguard does not inspect dash cams, their firmware or footage. Its fit is the software around a dash cam programme that your team builds.

From raw material to a mounted dash cam: the step table

Order varies by maker, and many parts arrive as finished modules from suppliers. Each row names the check, not a yield, because no maker we found publishes yields.

Three steps matter most to an owner. Step 3 decides whether a plate at the frame edge is readable, and software cannot fix it later. Step 7 decides whether the Wi-Fi password is unique to your unit or shared by every unit, the line ETSI EN 303 645 provision 5.1-1 draws. Step 9 decides whether your first job after unboxing is a firmware update.

A dated timeline of rules and standards that shape dash cams

Dash cams are rarely regulated as a category. They inherit rules from privacy law, product cyber security law, vehicle recorder rules and card and GNSS standards. Every date was checked against the source named.

What is inside a dash cam?

A single-channel windscreen camera holds two or three boards behind a lens. Dual-channel models add a rear camera on a cable; three-channel models add an interior camera, common in fleet use.

The lens and the CMOS image sensor

The optical path is a wide-angle lens, an infrared cut filter so daytime colours look right, and a CMOS image sensor. The sensor sends raw data to the SoC over a high-speed serial link, often MIPI CSI-2, whose current version on the MIPI Alliance page is v4.2 from December 2025. The details sit in the member specification. For how the sensor die is made, see our image sensor post.

The video SoC and image signal processor

The SoC's image signal processor turns raw sensor data into a picture: black level, demosaicing, white balance, noise reduction, tone mapping and lens shading correction. A hardware encoder, usually H.264 or H.265, compresses frames so hours of video fit on a card. A CPU core runs the operating system, often embedded Linux on connected models.

That operating system carries open source components: a kernel, a C library, a network stack, a Wi-Fi driver and access point daemon, a web or streaming server for the phone app, and often a TLS library for uploads. This is the part of a dash cam that behaves like any other software supply chain, and the part buyers cannot see.

Storage

Internal flash holds the bootloader, firmware and settings. The removable microSD card holds footage, is under the most stress and usually fails first.

Hold-up power

A dash cam runs from the car's 12 V supply. When the ignition turns off, it needs a moment of energy to stop the encoder, write the last frames and close the file so the clip plays. That is the job of the supercapacitor bank or small battery, covered below.

GNSS receiver

GNSS adds position, speed and time to each clip. GPS.gov lists the global systems: GPS, GLONASS, Galileo (Initial Services declared in 2016) and BeiDou (formally commissioned in 2020, 35 satellites in the operational system). Cameras write position as a data or subtitle track inside the video file or as a sidecar log. Video shows what happened; the track shows where you were, when and how fast, and shared clips often carry it even with the on-screen overlay off.

Accelerometer (G-sensor)

A three-axis accelerometer measures acceleration. Firmware compares it with a user-adjustable threshold to decide that an event happened: a hard brake, a collision or a knock while parked.

Radios

Wi-Fi models run an access point so a phone app can browse clips, download footage and change settings. LTE models add a modem for live view, alerts and cloud upload. Every radio adds a data path, an update path and an attack surface.

Why do dash cams use supercapacitors instead of lithium batteries?

Because a windscreen gets hot in a parked car, and the hold-up store only has to last seconds.

A lithium-ion cell stores energy chemically and ages faster when hot. A supercapacitor, or electric double layer capacitor, stores energy electrostatically at the boundary between a porous carbon electrode and an electrolyte, with no lithium plating chemistry. It holds far less energy per gram, which is fine for closing a file. The trade-off: a supercapacitor camera cannot run parking mode on its own store and needs a hardwire kit or external battery pack.

How are supercapacitors rated?

Data sheets give capacitance in farads, rated voltage per cell (makers put cells in series, with balancing, to reach a 5 V rail), equivalent series resistance, operating temperature range and rated life at a stated temperature and voltage. Life falls as temperature and voltage rise, so makers often run parts below rated voltage.

Worked example 1: supercapacitor hold-up time

A converter can only use the energy between the starting voltage and the lowest voltage it can regulate from:

E_usable = 0.5 x C x (V_start^2 - V_min^2)

Illustrative numbers, not from a specific product:

• Two 10 F cells in series give 5 F, charged to 5.0 V, usable down to 3.0 V.
• E_usable = 0.5 x 5 x (25.0 - 9.0) = 40 joules.
• At 2.5 W while closing the file, hold-up time = 40 / 2.5 = 16 seconds.
• Lose half the capacitance to years of heat and it drops to about 8 seconds.

That is why ageing matters: a camera that once closed files cleanly can start leaving the last clip corrupt.

Worked example 2: a small lithium cell

Illustrative again: a 3.7 V, 300 mAh cell.

• Energy = 3.7 x 0.300 = 1.11 watt hours = about 4,000 joules, roughly 100 times the bank above.
• But the cell needs temperature-aware charging and over-discharge protection, and most of its energy is never used for a clean shutdown.

Why heat speeds ageing is the Arrhenius behaviour worked through in the Arrhenius equation post.

How is a dash cam built?

Lens alignment and focus calibration

Fixed-focus modules are focused once in the factory. In passive alignment, the lens is screwed into a threaded holder until a chart looks sharp, then glued. In active alignment, a robot moves the lens over a powered sensor while it streams images of a target, scores sharpness across the field, then cures the adhesive to freeze the position. Active alignment corrects small tilts that would leave one corner soft, and on a wide dash cam frame that corner is where a plate may be.

PCB assembly

The main board follows the standard surface mount process: solder paste through a stencil, pick and place, reflow, automated optical inspection, X-ray for hidden joints under the SoC and DRAM, then in-circuit or flying probe test. Our printed circuit board post covers this in detail.

Thermal design and mount

The SoC heats the case from inside while the sun heats it from outside. Designers move heat to the shell with thermal pads and spreaders, and firmware throttles or shuts down when too hot. The mount is an adhesive pad or a suction cup.

Factory test

End of line tests record to a test card, check the image against a chart, test microphone, buttons, G-sensor, GNSS lock and radios. On connected models the factory writes per-device identity: serial, MAC address, Wi-Fi password and cloud credentials. Whether that password is unique per unit is a design choice the buyer cannot see until they check.

How does dash cam firmware record, lock and park?

Loop recording

The camera records short segments, commonly one, three or five minutes, and deletes the oldest unlocked segment when space runs out. Short segments limit loss from a corrupt file. Each segment is usually MP4 or MOV with video, optional audio and often a GNSS and G-sensor data track. MP4 players need the file's index; if power fails before it is written, the clip may not play, which is what the supercapacitor protects against.

Event locking on G-sensor triggers

When the accelerometer crosses its threshold, firmware moves the current segment, often with the previous one, into a protected folder the loop skips. Most cameras add a manual lock button.

49 CFR Part 563 applies the same idea to car event data recorders. It defines a trigger threshold as a change in vehicle velocity of 8 km/h or more within 150 ms, and requires airbag deployment event memory to be locked against overwriting. But its EDR definition says the event data "do not include audio and video data", so your dash cam is not an EDR under that rule. The eCFR text now shows a 20 second pre-crash window at 10 samples per second for speed, throttle and brake, phased in from 1 September 2028; vehicles made before 1 September 2031 outside the phase-in keep 5 seconds at 2 samples per second.

Parking mode

Parking mode needs constant power from a hardwire kit with a low voltage cut-off or an external battery pack. Modes include motion detection (the ISP compares frames), impact detection (the G-sensor wakes the camera), time lapse and low bitrate recording. It is also the setting with the most privacy reach: hours of a public car park are close to the EDPB's "constantly recording" example.

File systems

The SD Association's capacity table pairs SDHC cards (over 2 GB up to 32 GB) with FAT32 and SDXC cards (over 32 GB up to 2 TB) with exFAT. FAT32 limits files to 4 GB, which short segments stay under. Microsoft's published exFAT specification says the format uses 64 bits for file size and allows clusters as large as 32 MB, which suits large sequential video files. Many makers ask you to format the card in the camera so it builds the layout the firmware expects.

Why do microSD cards wear out in dash cams?

NAND flash blocks tolerate a limited number of program and erase cycles. The card controller spreads writes and keeps spare blocks, but a dash cam rewrites the whole card over and over. When spares run out, the card goes read-only, returns errors or silently corrupts files.

Speed and endurance are different promises. The SD Association defines Speed Class, UHS Speed Class (U1, U3), Video Speed Class (V6, V10, V30, V60, V90) and SD Express Speed Class (E150 to E600); the number is a minimum write speed in megabytes per second. Application Performance Class (A1, A2) rates random operations per second for apps. None of these says how long a card survives rewriting. Endurance cards are a maker category rated in hours or terabytes written, so compare data sheets, not logos.

Worked example 3: how fast does a dash cam cycle a card?

Illustrative numbers for a dual-channel camera:

• Front 20 Mbit/s plus rear 8 Mbit/s = 28 Mbit/s.
• Per hour: 28 x 3600 = 100,800 megabits = about 12.6 GB.
• A 128 GB card is fully overwritten every 128 / 12.6, about 10 hours.
• Two hours of driving plus 8 hours of parking mode at a quarter rate (about 3.2 GB per hour) writes 25.2 + 25.6 = 50.8 GB a day.
• That is a full overwrite every two and a half days, about 145 a year.

Run that against the card maker's endurance rating and replace cards before they fail.

How are dash cam firmware updates delivered?

SD card file. You copy the maker's file to the card root and power on; the bootloader checks it and writes internal flash. Security depends entirely on what the bootloader checks. A name and checksum check accepts anything with the right name and a matching checksum.

Phone app over Wi-Fi. The app downloads firmware over HTTPS and pushes it over the camera's hotspot. Security depends on the download, the local link and the camera's own verification.

Over the air through LTE. Cloud models pull updates directly, which keeps fleets current and puts the most weight on signing, because one release changes thousands of cameras.

What does a signed update path look like?

ETSI EN 303 645 V3.1.3 provision 5.3-2 says a device shall have a secure update mechanism, 5.3-7 that it shall use best practice cryptography for it, 5.3-9 that it should verify update authenticity and integrity, and 5.3-10 that network-delivered updates shall be verified via a trust relationship, with digital signature verification listed as one example. NIST IR 8259A lists software update as one of six core device capabilities, alongside device identification, device configuration, data protection, logical access to interfaces and cybersecurity state awareness. RFC 9019 (April 2021) describes a signed manifest naming which firmware applies to which device, with a digest of the image, verified before install.

A good dash cam update path therefore has:

1. A signing key held offline or in a hardware security module.
2. A signed manifest per release naming model, version, image digest and minimum allowed version.
3. Bootloader verification against a public key in read-only or fused storage.
4. Rollback protection. The Update Framework's specification describes rollback and freeze attacks on update systems and how version and expiry metadata stop them.
5. A/B partitions or a recovery image so a failed write does not brick the device.
6. A published support period, which ETSI EN 303 645 provision 5.3-13 says the maker shall publish clearly.

Ask the maker whether firmware is signed, whether downgrades are blocked and how long updates will last. The EU's Cyber Resilience Act, which the Commission says requires devices and software to be designed, updated and maintained to protect users, applies its main obligations from 11 December 2027, with reporting of actively exploited vulnerabilities from 11 September 2026.

Where does dash cam footage go?

Card only. Footage stays on the card. Nobody reaches it remotely, but anyone who opens the car can take the card.

Phone app over Wi-Fi. The phone joins the camera's hotspot and downloads clips, which then go wherever the phone sends them, including automatic photo backups. The hotspot is a local network anyone in range can try to join, so a default password is a real exposure in a car park.

Cloud with LTE. Event clips, live view, location and alerts go to the maker's servers, under that party's retention rules and access controls. A maker breach or misconfigured storage exposes footage that was never on your phone.

What privacy rules apply to recording people and plates?

This is a map, not legal advice. Confirm national rules where you drive.

The EU: EDPB Guidelines 3/2019

The EDPB's Guidelines 3/2019 on processing of personal data through video devices (version 2.0, adopted 29 January 2020) make four points that apply to dash cams.

• Scope. A car camera built or adjusted so it collects no information about people, such as plates or passers-by, is outside the GDPR. A road-facing dash cam does not meet that bar.
• The household exemption is narrow. Citing the Court of Justice in Lindqvist (2003) and Ryneš (11 December 2014), the EDPB says internet publication to an indefinite number of people is not household activity, and a camera covering even partially a public space cannot be purely personal.
• Constant recording is hard to justify. For a dash cam installed to collect accident evidence, "it is important to ensure that this camera is not constantly recording traffic", because evidence for the more theoretical case of an accident cannot justify that interference.
• Retention and minimisation. Footage should in most cases be erased, ideally automatically, after a few days; beyond 72 hours needs more justification. Functions that are not necessary, including radio transmission and audio recording, must be deactivated, and irreversible blurring counts as erasure.

The EDPB notes national legislation may add requirements, and member states differ widely on dash cams.

The UK

The ICO's guidance on domestic CCTV says a camera that catches beyond a private boundary brings duties, with the example of a home camera covering part of a street where the owner must show their interests outweigh others' privacy. That page is about home CCTV, so check the ICO's current position on vehicle cameras.

The US

Federal law at 18 U.S.C. 2511(2)(d) makes it lawful for a person not acting under color of law to intercept a communication they are party to, or where one party has given prior consent, unless the purpose is criminal or tortious. Several states require every party's consent, so recording passengers can breach state law. Interior fleet cameras add workplace monitoring rules.

Plates

A plate is personal data in the EU when it can be linked to a person, which is why the EDPB names it. Blurring plates and faces before sharing turns footage about strangers into evidence of an event. Our ALPR post covers cameras built to read plates at scale.

Card only, Wi-Fi app and cloud connected dash cams compared

Step by step: harden a dash cam, update it, set retention and share footage safely

Menu names vary by maker. Commands assume Linux or macOS with a card reader.

1. Record the firmware version

Note the version in the camera's system menu, compare it with the maker's support page for your model, and look for a stated security support period.

2. Change the default Wi-Fi name and password

Set a hotspot password of at least 12 random characters and a network name that does not reveal the model. Turn Wi-Fi off if you do not use the app. Choose WPA3, the Wi-Fi Alliance's newer security generation, if camera and phone support it.

3. Verify and install firmware

Download only from the maker's site and verify the published checksum.

shasum -a 256 ~/Downloads/firmware.bin   # macOS
sha256sum ~/Downloads/firmware.bin       # Linux

If the maker publishes a signature and public key, verify that too:

openssl dgst -sha256 -verify maker_public_key.pem \
  -signature firmware.bin.sig ~/Downloads/firmware.bin

Anything other than Verified OK means stop. Copy the file to the card root and keep power stable while the camera updates.

4. Check the card is genuine and healthy

Counterfeit cards report more capacity than they hold. Warning: later commands in this routine overwrite data. Back up footage first and confirm the device path before every command.

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINT   # Linux
diskutil list                              # macOS

Confirm the size and transport match the card, then run the open source f3 tools against its mount point:

f3write /media/$USER/DASHCAM
f3read /media/$USER/DASHCAM

If f3read reports corrupted or lost sectors, replace the card.

5. Format the card in the camera

Use the camera's format option. If you must format on a computer, use exFAT for cards above 32 GB. Warning: this erases the card. Re-run lsblk or diskutil list immediately before and confirm the path and size are the card's.

sudo mkfs.exfat -n DASHCAM /dev/sdX1

6. Set retention, sensitivity and parking mode

Use one or three minute segments and medium G-sensor sensitivity. If you need parking mode, prefer impact detection, which records less of the street. On cloud models, set retention to the shortest period that meets your purpose; the EDPB points towards days, not months.

7. Turn audio off by default

Disable the microphone and tell passengers if you turn it on.

8. Inspect and redact footage before sharing

List the streams first; clips often carry GNSS data or subtitle tracks.

ffprobe -hide_banner FILE0001.MP4

Then copy the clip with audio, data, subtitle streams and metadata removed and a region blurred. The boxblur filter is documented in the FFmpeg filters manual; -map_metadata -1 drops global metadata and -an, -dn and -sn drop audio, data and subtitle streams.

ffmpeg -i FILE0001.MP4 \
  -filter_complex "[0:v]crop=220:80:900:620,boxblur=12[blur];[0:v][blur]overlay=900:620[out]" \
  -map "[out]" -an -dn -sn -map_metadata -1 \
  -c:v libx264 -crf 20 shared_clip.mp4

crop=220:80:900:620 takes a 220 by 80 pixel box 900 pixels from the left and 620 from the top, blurs it and lays it back. For moving plates use an editor with tracking. Keep the original untouched for an insurer or court and share the redacted copy.

Common mistakes

• Leaving audio on. It can breach state all-party consent laws and is among the functions the EDPB says to deactivate when not necessary.
• Keeping the default Wi-Fi password. Anyone in range can browse and download clips. Change it on day one.
• Sharing unredacted footage online. It leaves the household exemption in the EU, exposes plates and faces, and often carries your GNSS track. Redact and strip data tracks first.
• Using a non-endurance card. A fast card is not a durable card. Check the endurance rating and replace on a schedule.
• Never checking recordings. Cards fail silently. Play a random clip every few weeks.
• Installing firmware from a forum mirror. Use the maker's site and verify checksums.
• Forgetting the cloud copy. Deleting from the card does not delete an uploaded clip.

FAQ

What is inside a dash cam?

A lens and infrared cut filter, a CMOS sensor, a video SoC with image processing and an encoder, a microSD slot, a supercapacitor or small battery, a G-sensor, usually GNSS, often Wi-Fi and sometimes LTE.

Why do dash cams use supercapacitors instead of batteries?

They cope with a hot windscreen better than lithium cells, and the camera only needs seconds of power to close the last file.

Do dash cams record when the car is off?

Only in parking mode, which needs a hardwire kit or external battery pack.

How long does a microSD card last in a dash cam?

It depends on capacity, bitrate, hours recorded and the maker's endurance rating. A dual-channel camera can overwrite a 128 GB card every few days.

What does V30 mean on a microSD card?

Video Speed Class 30: a minimum sustained write speed of 30 MB per second. It says nothing about endurance.

Is it legal to use a dash cam in Europe?

It depends on the country. The EDPB says dash cams should not constantly record traffic and passers-by, and online publication is not household use.

Is it legal to record audio with a dash cam in the US?

Federally, yes if you are a party or one party consents, but several states require all parties to consent.

Is a dash cam the same as a car's black box?

No. A US car's event data recorder under 49 CFR Part 563 records data such as speed and braking around a crash and by definition excludes audio and video.

Where Safeguard fits, honestly

Safeguard does not inspect dash cams, scan their firmware images, analyse their hardware or look at footage. For drivers, the steps above are what protect you.

The fit is for teams that build software around a dash cam programme: a maker's companion app and upload service, a fleet video portal, or an insurer's footage intake. Those are ordinary repositories and container images built on open source. Safeguard scans them (safeguard scan --dir ., --image <name>, or --sbom <file> for an SBOM a supplier gives you), matches components against vulnerability databases, ranks findings with reachability analysis, shows which projects contain a given component and version, and evaluates policies and gates. Autonomous remediation can open fix pull requests and ships switched off. A firmware SBOM from the maker can be loaded to track known issues in the listed components, but fixes inside the device still come from the maker.

A dash cam programme rebuilds its companion app, upload service and fleet portal every release, and each rebuild pulls open source dependencies again. Firmware on the device also ships open source components such as kernels, Wi-Fi stacks and TLS libraries, but those are fixed by the maker, so the steps below apply to the software your team builds and ships around the camera.

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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 asked to fix a lodash CVE: it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits a dash cam companion app's web dashboard or a footage upload 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 scans from the terminal. That suits a fleet video team that builds its portal and ingest containers on its own hosts and wants scans to run next to that build.

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 shows how you choose which tools Claude can use. An engineer reviewing the footage service can ask about its findings in a chat while keeping control over what the assistant is allowed to call.

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

• EDPB, Guidelines 3/2019 on processing of personal data through video devices (page)
• EDPB, Guidelines 3/2019 version 2.0 (PDF)
• eCFR, 49 CFR Part 563, Event Data Recorders
• NIST, IR 8259A, IoT Device Cybersecurity Capability Core Baseline
• NIST, IR 8259A (PDF)
• ETSI, EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements (PDF)
• RFC Editor, RFC 9019, A Firmware Update Architecture for Internet of Things
• The Update Framework, specification
• European Commission, Cyber Resilience Act
• European Commission, Radio Equipment Directive
• GPS.gov, Other Global Navigation Satellite Systems
• GPS.gov, Systems
• SD Association, Speed Class
• SD Association, Application Performance Class
• SD Association, SD Standard Overview
• SD Association, Capacity (SD, SDHC, SDXC, SDUC)
• Microsoft, exFAT file system specification
• MIPI Alliance, MIPI CSI-2
• Wi-Fi Alliance, Wi-Fi security
• LII, 18 U.S.C. 2511, Interception and disclosure of communications
• ICO, Domestic CCTV systems
• FFmpeg, Filters documentation
• FFmpeg, ffmpeg documentation
• f3, Fight Flash Fraud documentation

Last reviewed: 25 October 2026.