Drone Cybersecurity: Access Control, Firmware & Flight Logs

A public-agency drone cybersecurity audit prevents a wrong configuration or leaked key from compromising ground control stations, flight controllers, and archived telemetry logs.

DHS/CISA best practices state that devices used to download and install UAS software and firmware must not access the enterprise network.

CISA and FBI recommend isolating, air gapping, or segmenting networks using separate networks, virtual local area networks (VLANs), or virtual private networks (VPNs) to prevent malware or a breach from spreading to the enterprise network.

Use the defensive audit structure below to separate ground control station access control, offline firmware signature verification, and flight telemetry log retention across public-safety and municipal unmanned aircraft fleets. For radio-frequency interference, Global Navigation Satellite System spoofing, and link-loss failsafes, see UAS navigation and control protection.

Quick reference: three defensive audit layers

Audit layer	Operational control	Reference framework
Access and links	DHS/CISA best practices recommend using standalone UAS-associated mobile devices with no external connections, or disabling all connections between the Internet and the UAS and UAS-associated mobile devices during operations.	CISA and FBI cite NIST SP 800-172 (Enhanced Security Requirements for Protecting Controlled Unclassified Information) and NIST SP 800-207 (Zero Trust Architecture) in their UAS cybersecurity guidance endnotes.
Firmware provenance	CISA and FBI recommend ensuring critical UAS information and communication components undergo a software bill of materials (SBOM) and hardware bill of materials (HBOM) review as part of supply chain risk management.	CISA and FBI cite NIST SP 800-128 and ISO 10007:2017 for configuration management and NIST SP 800-53 Rev.5 for data-at-rest and data-in-transit security and privacy controls.
Log retention	CISA and FBI recommend performing periodic log analysis and compliance checks on UAS programs to determine if any anomalies exist and allow timely identification of unauthorized access attempts.	As reported by Lexipol citing Illinois statute 725 ILCS 167/20, Illinois requires law enforcement agencies to destroy all information gathered by a drone within 30 days, unless there is reasonable suspicion that the information contains evidence of criminal activity or is relevant to an ongoing investigation or pending criminal trial.

Operator access control and network segmentation

Start the ground control station audit by separating operator identity, network transport, and default device credentials before aircraft deployment.

CISA and FBI reference Executive Order 13981 (Protecting the United States from Certain UAS) and the Department of Defense Blue UAS Cleared List for identifying UAS compliant with federal cybersecurity policies.

Default credential findings on vetted fleets

Procurement clearance does not replace local credential reconfiguration on arrival.

The CNA final report on Securing UAS Fleets from Cyber Attacks was performed under Federal Aviation Administration Broad Agency Announcement Call 004, Contract: 697DCK-23-C-00292.

CNA and RIIS subjected five UAS systems compliant with either the DOD DIU Blue UAS List effort or the AUVSI Green UAS List effort to penetration testing techniques to identify exploitable vulnerabilities in default settings.

Across the analyzed UAS platforms, the three primary security misconfigurations identified were within the default SSID, default login credentials, and default root credentials.

Platform UAS: Wi-Fi (3) was excluded from the analysis because of its overall robust security, including that the default password was both randomized and included in the packaging of the device, requiring physical access prior to any flights.

Although sUAS on the DIU Blue UAS List and AUVSI Green List are vetted and deemed compliant with section 848 of the FY 2020 NDAA, Section 817 of the FY 2023 NDAA, and the American Security Drone Act, they still may have poor default security settings that require additional user reconfigurations.

While testing the UAS: RFD900 drone, changing the drone’s radio network disabled the GPS module because of the design of the components, showing that increasing security on a platform can conflict with system functionality if not tested.

When logging airframe and controller serial numbers during initial intake, pair the credential reconfiguration record with the Remote ID serial number fleet registration audit.

MAVLink command authentication and parameter lockdown

Open-architecture flight controllers require explicit command-link signing and parameter write protection so unauthorized ground stations cannot inject shell commands or overwrite failsafes.

In the MAVLink message signing specification, a signed packet sets the 0x01 bit (MAVLINK_IFLAG_SIGNED) of the incompatibility flag field and appends 13 bytes consisting of an 8 bits linkID, a 48 bits timestamp in 10 microsecond units since 1st January 2015 GMT (unix epoch offset 1420070400 seconds), and a 48 bit (6 byte) signature computed as the first 48 bits of a SHA-256 hash over the 32 bytes secret key concatenated with the packet and timestamp.

The MAVLink signing specification requires discarding a signed packet if its timestamp is older than the previous packet from the same (SystemID, ComponentID, LinkID) stream, if the 48 bit signature does not match, or if the timestamp is more than 1 minute (6,000,000) behind the local system’s timestamp; to avoid leaking the secret key in logs, systems should omit SETUP_SIGNING messages from logs (or replace the secret with 32 0xFF bytes) and remove the signature block before logging.

The OWASP Drone Security Cheat Sheet cites CVE-2026-1579 (PX4, CVSS 9.8, CISA ICSA-26-090-02, CWE-306, where disabled MAVLink 2 message signing allows unauthenticated SERIAL_CONTROL shell access) and CVE-2026-38971 (ArduPilot ArduPlane <= 4.6.3, CVSS 9.1, CWE-125, an out-of-bounds read in GCS_serial_control.cpp) as evidence of the risk of unauthenticated MAVLink links.

The OWASP Drone Security Cheat Sheet notes that DroneCAN’s multi-frame cyclic redundancy check (CRC) is an unkeyed checksum rather than a message authentication code, and recommends WPA3 encryption and 802.11w Management Frame Protection (MFP) for Wi-Fi links.

Control area	First stack	Second stack
Packet signing	In ArduPilot MAVLink2 signing, packet signing does not encrypt telemetry data; when active, any non-USB serial port using MAVLink2 (option = 2) can be configured to respond to MAVLink commands only if signed with the passkey, while USB connections remain unaffected and can disable or change the passkey.	In PX4 MAVLink Security Hardening, once a 32-byte signing key is provisioned via SETUP_SIGNING, signing is enforced automatically on all links including USB, signing changes are rejected while the vehicle is armed, and the signing key is stored on the SD card at /mavlink/mavlink-signing-key.bin.
Runtime protection	ArduPilot's parameter lockdown feature uses the param-lockdown.lua applet (requiring SCR_ENABLE = 1 on an autopilot with a fast CPU and sufficient memory such as STM32H7), but ArduPilot notes it is not an iron-clad security feature because ground stations like Mission Planner allow users to stop and start scripts; alternatively, parameters can be marked @READONLY in defaults.parm.	PX4 Log Encryption (not enabled by default) encrypts ULog files into a .ulge file using XChaCha20 as the default encryption algorithm and RSA2048-OAEP as the default wrapping algorithm.

Drone firmware signature verification and offline updates

Verify software and firmware provenance on an isolated workstation before connecting any flight controller or hand controller.

DHS/CISA best practices state that operators should properly verify interactions with UAS vendor and third-party websites and ensure file integrity monitoring processes are in place before downloading or installing files.

DHS/CISA best practices advise running all downloaded UAS files through an up-to-date antivirus platform before installation and verifying that a firewall is enabled on the computer or mobile device.

DHS/CISA best practices state that during UAS software installation operators should not follow default install options and should disable automatic software updates.

Bootloader cryptographic signature verification across open-source autopilots

Bootloader-enforced signature checks prevent unsigned or altered firmware images from executing at power-on.

Bootloader check	First stack	Second stack
Key verification	ArduPilot secure boot installs a bootloader with up to 10 public keys included and signs the ArduPilot vehicle firmware with one private key; the bootloader refuses to boot the firmware if its signature does not match any of the public keys in the bootloader.	PX4 Bootloader Secure Boot uses ed25519 signatures via monocypher with a 32 bytes signing key and a 64 bytes signature, fitting within a 128 KB bootloader sector, and holds the device in the bootloader screen without starting the PX4 flight stack if an image is unsigned, tampered, or signed by the wrong key.
Upload tooling	Generating an ArduPilot secure boot key pair requires pymonocypher==3.1.3.2 and running Tools/scripts/signing/generate_keys.py NAME, which creates NAME_private_key.dat and NAME_public_key.dat.	On PX4 (px4_fmu-v6x example), the firmware Table of Contents (TOC) defined in src/include/image_toc.h declares BOOT and SIG1 entries, and Tools/px4_uploader.py asks the bootloader to verify the signature before reboot via the VERIFY_SIG opcode.
Hardware limits	By default, ArduPilot's build_bootloaders.py script includes the 3 ArduPilot signing keys in addition to the vendor's public key unless the --omit-ardupilot-keys option is passed.	ArduPilot secure boot is only supported on flight controller boards with at least 32k of flash space for the bootloader, which includes all boards based on the STM32H7 and STM32F7, and a flight controller running a secure bootloader will refuse a switch to DFU mode.

Commercial platform security assessments and vendor architectures

When evaluating proprietary enterprise aircraft, record the published scope of third-party audits and vendor-stated cryptographic features separately in the procurement file.

According to DroneXL’s May 29, 2026 report on an independent security assessment conducted by OnDefend (October 2025 to March 2026) on DJI Air 3S with RC 2 controller and Matrice 4E with RC Plus 2 Enterprise controller (procured from retail outlets and dealer stock), the assessment produced zero critical, high, or medium risk findings and identified ten low and thirteen observations, while controllers resisted jailbreak and firmware modification attempts.

Skydio states that its X10 drone uses Secure Boot (ensuring only code signed by Skydio can run on the X10), AES-256 bit encryption through Skydio Connect SL between the drone and controller, TLS 1.2/1.3 to Skydio Cloud, AES-256 for customer data at rest, and external audits for ISO27001:2022 and SoC2 Type II.

Public safety drone flight log retention and storage encryption

Post-flight log handling must protect data at rest on the aircraft while preserving an auditable record for incident reconstruction and public-records requests.

CISA and FBI recommend verifying current software and firmware versions prior to operational use, deleting collected imagery, Global Positioning System (GPS) history, and flight telemetry data from the UAS after transfer and storage, and removing and securing portable storage such as secure digital (SD) cards prior to storage.

Onboard log encryption and circular buffer rotation

Configure autopilot logging parameters and companion storage encryption so pre-incident telemetry is neither exposed on a lost airframe nor overwritten during post-incident initialization.

• For onboard data-at-rest protection on companion computers and storage media, the OWASP Drone Security Cheat Sheet recommends block-level encryption (LUKS), filesystem-in-userspace encryption (gocryptfs), or file encryption (age), and storing encryption keys and credentials in RAM to be cleared after use.
• A PX4 encrypted .ulge log file begins with a 22 bytes header starting with the magic string “ULogEnc”, with the wrapped symmetric key section starting at byte offset 22 and the encrypted log data section at offset 22 + key_size + nonce_size.
• In ArduPilot DataFlash logging, LOG_BACKEND_TYPE uses values 0 to disable logging, 1 to log to SD card file, 2 to stream over MAVLink, and 4 to log to board dataflash memory; LOG_FILE_MB_FREE defaults to 500MB (deleting older logs during initialization if unavailable), and LOG_MAX_FILES has a maximum limit of 500 logs.
• ArduPilot boards without SD card interfaces typically have 16MB of on-board dataflash that operates as a circular buffer, overwriting the oldest log file once the flash is filled (or stopping logging if there is only one file).

Statutory and departmental flight log retention schedules

Public agencies must separate retention rules for non-evidentiary media, criminal evidence, and flight telemetry logs.

Under Illinois statute 725 ILCS 167/20, law enforcement agencies must destroy all information gathered by a drone within the statutory timeframe, except when there is reasonable suspicion of evidence of criminal activity, relevance to an ongoing investigation or pending criminal trial, exclusive training use with all PII removed, or the information contains only flight path data, metadata, or telemetry information of the UAS.

Lewis University Police Department Policy requires protocols ensuring evidentiary UAS data are accessed, maintained, stored, and retrieved with integrity including strict chain-of-custody adherence, and electronic trails including encryption, authenticity certificates, and date and time stamping shall be used as appropriate, while available records of drone usage (flight path data, metadata, telemetry information of specific flights) may be disclosed under the Illinois Freedom of Information Act (5 ILCS 140/1 et seq., 725 ILCS 167/25).

On the Montgomery County Police Department DFR FAQ, DFR video is treated as evidence with the same retention periods as police body worn camera system (BWCS) and in-car mobile video system (MVS) video evidence (without printing a day count on the FAQ page), a Lieutenant program manager periodically audits the program, and flights are published after every flight on its transparency website.

George Mason University Police posts a public UAS flight log listing the date, location, flight duration, and purpose for each operational flight, and requires all operational and training flights to comply with Title 14 CFR and Part 107.

To assign departmental ownership for each retention and review rule, use the drone-as-first-responder policy review matrix.

UAS fleet cybersecurity checklist for public agencies

Copy the audit rows below into the agency maintenance logbook and record the verified artifact for each aircraft and ground control station.

Checklist domain	Verification step	Audit record
Network isolation	Verify that software download terminals, removable media readers, and ground controllers do not bridge into the enterprise network.	Network diagram, VLAN or air-gap assignment, and standalone workstation asset tag.
Account access	Assign individual operator accounts with phishing-resistant multifactor authentication and revoke shared administrator logins.	Operator account roster, multifactor token serial, and role revocation log.
Default credentials	Reconfigure out-of-the-box SSIDs, login passwords, and root credentials, then flight-test radio and navigation modules together.	Pre-deployment configuration sheet and post-change functional flight check log.
Command signing	Enable MAVLink packet signing across serial and telemetry links and lock critical flight controller parameters against runtime edits.	Key provisioning date, parameter file hash, and USB port physical security note.
Firmware verification	Download firmware packages on an isolated terminal, verify cryptographic signatures before upload, and disable automatic updates.	Firmware version, bootloader public-key fingerprint, and antivirus scan log.
Log retention	Offload flight logs on a standalone computer, sanitize signing secrets, remove SD cards before storage, and separate telemetry from video retention.	Offload timestamp, media wipe confirmation, and statutory retention schedule class.

For historical context on how public-safety autonomy, data links, and navigation resilience were evaluated in federal prize competitions, read the First Responder UAS Triple Challenge archive.

Sources

• DHS/CISA — Cybersecurity Best Practices for Operating Commercial Unmanned Aircraft Systems (UASs)
• CISA & FBI — Cybersecurity Guidance: Chinese-Manufactured UAS (January 17, 2024)
• FAA / CNA — Securing UAS Fleets from Cyber Attacks Final Report (August 2024)
• ArduPilot Dev Team — Tools/scripts/signing/README.md
• ArduPilot Dev Documentation — MAVLink2 Signing
• ArduPilot Dev Documentation — Parameter Lockdown
• ArduPilot Copter Documentation — Downloading and Analyzing Data Logs in Mission Planner
• PX4 Autopilot User Guide — Bootloader Secure Boot
• PX4 Autopilot User Guide — Log Encryption
• PX4 Autopilot User Guide — MAVLink Security Hardening for Production Deployments
• MAVLink Guide — Message Signing (Authentication)
• OWASP Cheat Sheet Series — Drone Security Cheat Sheet
• Lewis University Police Department — Unmanned Aerial System Policy
• Lexipol — Key Considerations for a Law Enforcement Drone Policy (February 23, 2024)
• Montgomery County Police Department — Drone as First Responder Program FAQ
• George Mason University Police and Public Safety — UAS (Drone) Flight Log
• DroneXL — DJI Clears an Independent U.S. Cybersecurity Audit (May 29, 2026)
• Skydio — Skydio’s Commitment to Drone Cybersecurity | FBI & CISA Aligned (February 21, 2024)