Drone technologytechnical explainer

How Secure Are BVLOS Drone Communications? Encryption, Redundancy, and Link Risk

Assess BVLOS drone communications across encryption, authentication, integrity, availability, redundancy, shared dependencies, and recovery.

Drone flies above a field while an operator watches from below.
A participant flies a UAS during NIST's UAS 3.0 challenge. Photo: National Institute of Standards and Technology

There is no categorical security rating for beyond visual line of sight (BVLOS) drone communications. Security depends on the full path between aircraft and control station, including radios, modems, software, credentials, carrier or satellite service, backhaul, cloud components, updates, monitoring, and recovery. Encryption can protect information, but the word "encrypted" alone does not establish endpoint authentication, message integrity, availability, independent failover, or recoverability.

BVLOS describes an operation relative to direct visual observation. Beyond line of sight (BLOS) is often used for the communications path. The terms are related but not interchangeable. This guide uses command and control (C2) for the function used to manage the aircraft's flight.

The useful question is not "Is the link secure?" It is "Which security property must hold for each required function, against which failures, across which dependencies, with what evidence?" That structure keeps a strong cipher, a second modem, or a protected frequency assignment from becoming a claim about the security of an entire BVLOS operation.

Start with five separate security outcomes

The C2, telemetry, payload, and video functions are defined in the companion guide to drone data-link roles. Each function can have different consequences and security requirements. Begin by stating the outcome rather than naming a product feature.

Scroll horizontally to compare all columns.
Security outcomeQuestion for a BVLOS linkWhat does not prove it
ConfidentialityCan unauthorized parties read protected commands, state, credentials, mission data, or metadata?The presence of a lock icon without protocol, endpoint, and key evidence
AuthenticationCan each endpoint and authorized user establish who or what is communicating?A network connection or device serial number by itself
Integrity and freshnessCan unauthorized alteration, insertion, deletion, duplication, or replay be detected?Confidentiality alone, or a checksum not designed for adversarial change
AvailabilityIs the required service usable when and where the operation needs it, including during failures and transitions?Encryption, nominal coverage, or one successful flight
Recovery and resilienceCan the system detect, contain, restore, and reconstruct service without repeating the same failure?A backup that shares credentials, power, software, provider, or corrupted state

NIST SP 1800-26A defines confidentiality, integrity, and availability as separate pillars of information security. It also distinguishes identifying and protecting from detecting, responding, and recovering. The publication addresses general data integrity rather than UAS certification, but the definitions prevent one control from being used as evidence for a different property.

Authentication is called out separately here because command authority depends on endpoint and user identity. Integrity can show that a message has not been improperly changed, while authentication establishes the claimed source or entity under the chosen design. Implementations can combine properties, but an assessment still needs evidence for each required outcome.

Draw the end-to-end trust boundary

BVLOS communications often cross more components than the airborne radio and the pilot's controller. A 2024 NIST paper on cybersecurity risk for uncrewed systems describes increasingly connected systems and a risk surface that includes the aircraft, operator control unit, planning, maintenance and logistics, and external systems. It focuses particularly on public-safety applications and is not a link certification standard. Its durable point is architectural: a trusted air interface does not remove risk in connected endpoints and services.

An end-to-end diagram should identify at least:

  • aircraft flight-control and mission-computer boundaries;
  • onboard radios, modems, antennas, network interfaces, and power;
  • ground-control hardware, software, displays, and local networks;
  • users, roles, devices, credentials, keys, and administrative access;
  • terrestrial, satellite, or mixed communications providers;
  • handovers, gateways, backhaul, Internet, and routing dependencies;
  • cloud, identity, certificate, mapping, update, logging, and support services;
  • interfaces to payload, navigation, weather, traffic, DAA, or UTM information;
  • maintenance tools, configuration stores, and recovery media.

The diagram should mark which organization controls each component, where information is decrypted or transformed, which functions share it, and what happens if it is unavailable. A carrier service can be outside the aircraft manufacturer's control while remaining essential to the claimed C2 service. A locally hosted ground station can reduce one external dependency while creating different maintenance and recovery responsibilities.

Map threat classes to the property they affect

This article stays at the threat-category and assurance level. It does not provide exploit steps, vulnerable endpoints, credentials, radio disruption instructions, or sensitive countermeasure configurations.

Scroll horizontally to compare all columns.
Threat or failure classPrimary security concernEvidence question
Unintentional interference or intentional jammingAvailability and continuityWhat degradation is detected, which functions remain, and what operation-specific contingency follows?
Spoofed, replayed, injected, or altered messagesAuthentication, integrity, and freshnessHow are endpoints, sequence or age, and message validity checked?
Stolen, shared, expired, or overprivileged credentialsAuthentication, authorization, and confidentialityHow are credentials issued, protected, rotated, revoked, and audited?
Software defect, malware, or unsafe updateIntegrity, availability, and recoveryHow are updates authorized, verified, staged, rolled back, and investigated?
Carrier, satellite, gateway, backhaul, cloud, or identity outageAvailability and common-mode resilienceWhich required functions depend on the service, and is the alternate truly independent?
Misconfiguration or unauthorized changeIntegrity, availability, and traceabilityWhich baseline is approved, who can change it, and what detects drift?
Vendor end-of-life or unsupported componentRecovery and sustained availabilityCan the operator patch, replace, export records, and recover without an abandoned dependency?
Compromised external dataIntegrity and operational decision qualityHow are map, navigation, traffic, weather, or other inputs authenticated, checked, and bounded?

The 2022 FAA BVLOS Aviation Rulemaking Committee report states that there is no one-size-fits-all cybersecurity posture and that the effect of C2 degradation or loss depends on operational risk and automation. It also discusses spoofing, replay, false-data injection, message authentication, cryptographic signing, and highly available C2. These are committee recommendations and observations, not current FAA rules. They support a risk-based matrix, not a claim that one listed control secures every operation.

Keep positioning and navigation threats in the correct box. GNSS jamming or spoofing affects a PNT dependency. C2 jamming or message spoofing affects a communications service. Either can change the operational risk, and the same aircraft may depend on both, but they are not the same failure.

Encryption is necessary in many cases, but the label is incomplete

Encryption can protect data confidentiality in transit or at rest. Some modern protocol designs can also provide authenticated encryption, which combines confidentiality with defined integrity and authenticity properties. The exact protocol, endpoint, key handling, implementation, and validation matter. It is therefore inaccurate to say either that encryption protects only confidentiality in every design or that an unspecified encrypted link is fully secure.

Ask what the encryption claim covers:

  1. Which traffic is protected, including commands, C2 telemetry, payload, metadata, logs, and management traffic?
  2. Where does protection begin and end, and where is data decrypted?
  3. How are aircraft, control stations, services, users, and administrators authenticated?
  4. How are keys or credentials provisioned, stored, rotated, revoked, backed up, and recovered?
  5. How are stale, duplicated, or replayed messages recognized?
  6. How are software and configuration updates authorized and verified?
  7. What happens when a key, certificate, clock, or identity service is unavailable?
  8. Which logs can demonstrate acceptance, rejection, change, and recovery?

The ARC report notes that encryption, message authentication, and signing use communications and processing resources. That does not argue against them. It means the protected implementation, including overhead and failure behavior, must be tested under representative load. A throughput result collected with security disabled does not establish protected-path performance.

The drone bandwidth requirements guide provides disclosed calculations for carrying overhead and peak demand into that protected-path test plan.

Encryption also does not create radio-frequency availability. An endpoint cannot decrypt a packet it never receives. Nor does it guarantee that a cloud service, carrier, ground application, account, or power source will remain available. Those properties need separate controls and evidence.

Availability is part of security, not an afterthought

For BVLOS operations, losing required communications can become an immediate operational contingency. Availability analysis should cover the end-to-end service, not just signal level. Relevant measures can include message age, delivery success, latency distribution, path transition, coverage, provider state, and the time to detect and recover from a defined failure. The required values remain operation-specific.

Current NIST UAS communications research models licensed LTE and 5G services, unlicensed 900 MHz, 2.4 GHz, and 5.8 GHz links, mesh behavior, interference, latency, packet loss, and robustness for public-safety use. That work does not certify any medium. It shows the range of variables that sit behind a generic claim such as "cellular," "mesh," or "radio."

The RF, LTE, satellite, and mesh comparison separates bearer properties from topology, while the Starlink and LEO guide examines the technical, contractual, and operational limits of one satellite-service family.

The 2024 FCC UAS spectrum order created an initial Part 88 framework for coordinated assignments in a portion of the 5030 to 5091 MHz band and connected that work to reliable control-related communications. A protected or coordinated assignment can address part of the spectrum-sharing problem. It is not evidence of application security, endpoint authentication, safe installation, carrier independence, route coverage, or suitability for a specific operation.

When availability degrades into loss, the operational consequences belong in a mission-specific UAS lost-link procedure. Cybersecurity controls and aircraft contingencies should be connected in the safety case, but neither replaces the other.

Redundancy is a claim about failure coverage

A primary and backup modem can still share an antenna, power rail, onboard computer, account, provider core, gateway, ground network, identity service, software process, or corrupted configuration. Redundancy should therefore name the failure it covers and the dependencies it does not.

Scroll horizontally to compare all columns.
Redundancy questionEvidence to request
What triggers transition?Defined state criteria, persistence, false-transition analysis, and crew indication
Which C2 messages survive?Message-level mapping, priority behavior, and protected-path performance
Is the alternate independent?Component and service dependency map across air and ground segments
What performance remains?Latency, freshness, availability, throughput, and coverage under alternate conditions
Can both paths fail together?Common-cause analysis for power, antenna, software, credentials, provider, and recovery services
What happens when the primary returns?Reauthentication, state reconciliation, command authority, and recovery-transition evidence
Can the operator diagnose the state?Human-interface evaluation and synchronized logs from aircraft, control station, and services

A NASA memorandum on UAS flight-demonstration best practices describes a secondary link that may provide less capacity and higher latency than the primary. It recommends prioritizing C2 over payload traffic when both share the degraded path. This is research guidance, not a universal design rule. It demonstrates why failover must be evaluated at the information-flow level. A connected alternate that is saturated by video may not preserve the required C2 performance.

Independent paths can reduce common failures while adding complexity, new credentials, and more transition logic. The objective is not the largest path count. It is controlled behavior through the credible failures identified for the operation.

Use procurement questions that demand evidence

The NIST CSAIRM workshop outcomes publish a preliminary set of questions developed with public-safety, management, academic, and developer participants. They ask about attack surface, stress testing, breach notification, data protection in transit and at rest, who can decrypt or modify information, processing location, external input authentication, interference, jamming, spoofing, continuity, and whether recovery shares the compromised system.

Those workshop questions are not a standard or a certification checklist. They are useful prompts for a claim-and-evidence record. The UAS C2 interface contract guide shows how to turn those endpoint and dependency questions into controlled message, state, timing, electrical, and recovery boundaries. A BVLOS communications review can ask vendors and integrators for:

  • a controlled architecture and data-flow diagram;
  • a role and privilege model for operators, maintainers, services, and vendors;
  • protocol and endpoint scope, without exposing secret keys;
  • credential and key lifecycle procedures;
  • software inventory, update policy, support period, and end-of-life plan;
  • security and communications test scope, configuration, conditions, and results;
  • known limitations, open findings, and remediation ownership;
  • primary, alternate, and common-dependency evidence;
  • alert, logging, time-synchronization, incident-response, and recovery behavior;
  • notification and evidence-preservation responsibilities after an event.

Avoid binary answers. "Uses AES," "uses VPN," "dual carrier," or "penetration tested" leaves scope, configuration, findings, and operational consequence unknown. The useful record says what was evaluated, under which conditions, against which requirement, with what result, and what remains outside the claim.

Secure operation is a lifecycle

The accepted configuration needs change control. Track aircraft and ground hardware, modem and radio firmware, applications, operating systems, certificates, keys, accounts, provider services, routing, payload interfaces, and recovery material. Define which updates or provider changes require retesting. Preserve the evidence needed to compare an event with the approved baseline.

Monitoring should distinguish C2 message freshness, endpoint authentication, path state, payload-service state, and ground-application health. A single green indicator should not hide an expired certificate, a stale downlink, an alternate path, or a local display problem. Alerts need a named meaning and an operator response tied to the operating plan.

Recovery should assume that a primary system and its backups may share the same bad state. Protect clean configuration records and logs, define who can revoke and reissue credentials, and test restoration at an appropriate controlled level. This article does not recommend deliberate disruption of an operational aircraft, radio interference, or exploit testing outside an authorized and contained program.

Keep proposed rules separate from current requirements

The FAA's 2025 BVLOS notice of proposed rulemaking would add Part 108 and includes proposed requirements addressing unauthorized electronic interaction with UAS equipment, systems, and networks. That document is a proposal, not current law.

As of this article's 2026-09-01 review, the FAA's recently published rulemaking page does not list a Part 108 final rule. Readers should verify the current Federal Register and eCFR status before relying on any regulatory statement. The ARC report, proposed Part 108 text, FCC spectrum order, NIST guidance, and NASA research each have a different authority and purpose.

A defensible answer is specific and bounded

"How secure are BVLOS drone communications?" can be answered only for a named system, configuration, route, operation, and time. A defensible assessment states which C2 and data functions are required, maps every material dependency, defines confidentiality, authentication, integrity, availability, and recovery outcomes, and ties each claim to evidence.

Encryption is one control. Redundancy is one resilience strategy. Protected spectrum is one availability measure. Onboard contingency logic is one response to communications loss. None is the whole security case, and none should be described as unhackable or jam-proof. The strongest conclusion is the narrowest one the architecture, test record, operating controls, and current regulatory record can actually support.

Claim record

Sources

Reviewed

  1. Cybersecurity and AI Risk Management for Uncrewed Systems: Challenges and Opportunities Using the NIST FrameworksNational Institute of Standards and Technology · research · accessed Sep 1, 2026
  2. NIST SP 1800-26A: Data Integrity, Detecting and Responding to Ransomware and Other Destructive EventsNational Cybersecurity Center of Excellence · government · accessed Sep 1, 2026
  3. NIST SP 800-38D: Galois/Counter Mode (GCM) and GMACNational Institute of Standards and Technology · standard · accessed Sep 1, 2026
  4. CSAIRM February 2024 Workshop OutcomesNational Institute of Standards and Technology · government · accessed Sep 1, 2026
  5. UAS Beyond Visual Line of Sight Aviation Rulemaking Committee ReportFederal Aviation Administration · government · accessed Sep 1, 2026
  6. Best Practices Identified Through Completion of UAS Flight DemonstrationsNASA Technical Reports Server · research · accessed Sep 1, 2026
  7. FCC 24-91: Spectrum Rules and Policies for UAS OperationsFederal Communications Commission · regulator · accessed Sep 1, 2026
  8. Uncrewed Aircraft Systems Research PortfolioNational Institute of Standards and Technology · government · accessed Sep 1, 2026
  9. Beyond Visual Line of Sight Operations Proposed RuleFederal Aviation Administration · regulator · accessed Sep 1, 2026
  10. Recently Published Rulemaking DocumentsFederal Aviation Administration · regulator · accessed Sep 1, 2026