A security drone that depends on the cloud stops being a security system when the connection does. Local-first (or offline-first) means the site has everything it needs to fly, see, detect and record on its own edge hardware. The cloud, if used at all, adds remote viewing, storage or fleet management on top, and switching it off does not switch off security.
- Resilience: patrols, alarm response and recording continue through internet outages and vendor incidents.
- Data control: video and detections stay on site by default, which helps with GDPR data minimisation and storage limitation.
- Governance: remote access becomes an explicit, logged decision rather than a permanent open door.
- Regulated sites: NIS2 and the CER Directive ask essential and critical entities to manage supply-chain risk, incidents and continuity; local-first architecture can support that work.
- No architecture makes an operator compliant on its own. It changes how much risk the operator has to manage.
What does cloud-dependent drone security mean in practice?
Many drone and video security products route mission control, user login, video or analytics through the vendor's servers. That creates dependencies a buyer should see clearly:
- Connectivity loss. If the site's internet link fails, or is cut deliberately, a cloud-controlled drone may not launch, may lose its video path, or may lose its operators exactly when an intruder is on site.
- Vendor outage. A failure, expired certificate or maintenance window at the vendor's cloud can affect every customer at once.
- Data leaving the site. Video of people is personal data. Every copy sent to a third party is another processor, another retention policy and another place it can leak.
- Lock-in. When footage, logs and configuration live only in a vendor's platform, changing supplier or meeting a retention rule can depend on the vendor's export features and contract terms.
- Foreign jurisdiction. When data is stored or processed by a provider subject to the laws of a non-EU country, authorities there may be able to request access. GDPR Chapter V sets conditions for transfers of personal data to third countries, which the controller must assess.
What does local-first mean architecturally?
In a local-first design, an edge node (a computer installed at the site) runs the full platform: telemetry and command handling, mission planning, geofencing, live video, AI detection, recording, user accounts and the audit log. Operators connect to it over the site network with a browser. The drone and its dock talk to the edge node, not to the internet.
The cloud becomes an opt-in extension: remote viewing for a control room off site, remote control under strict policy, long-term video storage, analytics, or managing several sites together. If the cloud link drops, the site keeps working and the local log continues.
Cloud-first vs local-first: a comparison
| Cloud-first | Local-first | |
|---|---|---|
| Internet outage | Functions that run in the cloud stop | Site keeps flying, viewing and recording |
| Where video lives | Vendor's cloud by default | On site by default; off-site upload is a choice |
| Remote access | Usually always on | Off until enabled, governed by policy |
| Latency to operators on site | Via the internet round trip | Over the local network |
| Audit trail | Held by the vendor | Held and exportable by the operator |
| Multi-site management | Built in | Needs the optional cloud layer |
| Updates | Pushed centrally | Need planned rollout to each site |
Cloud-first has real advantages for fleet management and updates; local-first trades some of that for autonomy at each site.
GDPR and drone surveillance: how local-first helps
A security drone recording people processes personal data, so the GDPR (Regulation (EU) 2016/679) applies. The principles that architecture affects most:
- Data minimisation (Art. 5(1)(c)) and storage limitation (Art. 5(1)(e)). The EDPB's Guidelines 3/2019 on processing of personal data through video devices say footage should in most cases be erased, ideally automatically, after a few days, and that the longer the storage period (especially beyond 72 hours), the more justification is needed. A local ring buffer with automatic overwrite, and off-site upload disabled by default, make that easier to implement.
- Data protection by design and by default (Art. 25) requires appropriate technical and organisational measures from the moment the means of processing are chosen. The EDPB guidelines apply this to video surveillance planning.
- Data protection impact assessment (Art. 35) is required for systematic monitoring of a publicly accessible area on a large scale (Art. 35(3)(c)), and may be needed in other high-risk cases. A drone that can see beyond the fence line deserves a careful DPIA. Geofences and planned routes help limit what is filmed.
- Transfers (Chapter V). Keeping footage on site in the EU avoids third-country transfers by default.
A local-first design helps an operator meet these duties; it does not make anyone compliant. The controller still needs a lawful basis, signage and information, retention rules, access controls and, where required, a DPIA.
NIS2 and CER: resilience for essential and critical entities
The NIS2 Directive (EU) 2022/2555 (transposition deadline 17 October 2024) requires essential and important entities, in sectors including energy, transport and water, to take cybersecurity risk-management measures. Article 21(2) lists, among others, incident handling; business continuity, such as backup management and disaster recovery; and supply chain security, including relationships with direct suppliers. Article 23 sets reporting deadlines for significant incidents, with an early warning within 24 hours.
The Critical Entities Resilience (CER) Directive (EU) 2022/2557 covers physical resilience. Article 13 asks critical entities to ensure adequate physical protection of their premises, duly considering, for example, fencing, barriers, perimeter monitoring tools and routines, detection equipment and access controls. Member States had to identify critical entities by 17 July 2026.
For these organisations a security drone is both a protective tool and a connected system in their supply chain. Questions that matter: does it fail safe if the vendor is unreachable, can it be audited, who can control it remotely, and where do its components and software come from. A local-first architecture with logged, policy-gated remote access can support these assessments. National implementation varies, so check the rules in your Member State; in Czechia, NÚKIB is the national cybersecurity authority.
Sites with poor connectivity
Many sites that need perimeter security have the weakest internet: solar parks and wind farms, remote substations, quarries and construction sites. Mobile coverage is patchy and streaming continuous drone video to the cloud over it is impractical. A local-first system keeps full-quality video on site and sends only what the operator chooses, such as alerts or selected clips, over a thin link.
How should remote access be governed?
Remote control of a flying machine is a high-impact capability. A sound design treats it as an exception:
- Remote access disabled by default, enabled only by an administrator who must re-authenticate.
- Policy modes: local-only, remote-view, remote-control.
- Further limits: local confirmation of remote commands, emergency-only mode, time windows, rate limits and restrictions based on drone state.
- Roles (admin, operator, viewer) with least privilege.
- Audit of every enablement, command and configuration change, exportable for review.
Encrypted link with mutual pairing
The radio link between drone and ground station carries video, telemetry and commands. If it is unencrypted or loosely paired, someone nearby could watch the feed or interfere with control. Ask whether every packet is encrypted and authenticated, and whether the drone will talk only to its own paired ground station.
AI detection without biometric identification
Detecting that a person or vehicle is present is different from recognising who someone is. The EU AI Act (Regulation (EU) 2024/1689) defines biometric identification as automated recognition of human features to establish a person's identity. It prohibits certain biometric practices, such as real-time remote biometric identification in publicly accessible spaces for law enforcement purposes (with narrow exceptions), from February 2025, and lists remote biometric identification among high-risk uses; the Commission states that rules for these Annex III areas apply from 2 December 2027. Class-level detection that does not identify individuals is generally outside those biometric categories, but the classification of any AI system depends on its use. Verify your own case with legal advice.
Questions to ask any security drone vendor
- With the internet disconnected, can the drone still launch, patrol, respond to alarms, stream video and log every action? Show me.
- Where are video, detections and logs stored by default, and who at your company can access them?
- Is uploading recordings off site on or off by default? Can retention be set to a few days with automatic deletion?
- Is remote control off by default? What re-authentication, policies and logs apply when it is on?
- Can I export the full audit trail in an open format?
- Is the radio link encrypted and authenticated per packet, and how is pairing done?
- Does the AI identify individuals, or only detect object classes? Where does it run?
- Where are the critical components and firmware made, and how are updates signed and delivered?
- What happens to my data and my ability to operate if your company or cloud service stops?
This page is general information, not legal advice.
How Nestua implements local-first
Nestua is built around these principles. Status: the software platform is functional in development builds; the drone and the base station hardware are still being built. There are no deployments yet.
- Edge node runs everything. One edge node controls one drone and runs the browser cockpit, live map, mission editor, geofences, video, AI and audit, with no internet required. Fleets are several edge nodes linked through the optional cloud.
- Video stays local. Low-latency WebRTC video in the browser (HLS/LL-HLS as an alternative), local recording to a ring buffer with clip export, and off-site upload of recordings disabled by default. Telemetry history retention is configurable by the admin.
- Edge AI on an NPU. YOLO detection of person and vehicle classes on the NPU of an NXP i.MX 8M Plus edge computer. AI rules can notify, record, hover or return to launch, always within safety policy and geofences, rate-limited and audited. No face recognition or identification of individuals.
- Safety policy engine. Local and remote modes, admin re-authentication, local approval of remote commands, emergency-only mode, rate limits, time windows and drone-state gates. Commands count as done only after the drone's MAVLink acknowledgement; critical ones need typed confirmation.
- Own encrypted link. Nestua's digital radio link, written in Zig, uses per-packet AES-256-GCM or ChaCha20-Poly1305 encryption with X25519 key agreement and hard mutual pairing: the drone sends nothing in the clear before it is paired with its own ground station.
- Optional cloud, governed. Remote monitoring and command dispatch over a WireGuard tunnel with per-node HMAC-signed commands, MFA and optional SSO for cloud users.
- Audit and operations. Event journal, command log, configuration change tracking, device enrollment logs, weather monitoring, watchdog-supervised services and a system health page.
- Supply chain. Critical components from European and US manufacturers; the Nestua H743 flight controller is designed and built in Europe.
Nestua is designed to support operators' GDPR, NIS2 and CER work; it is not a certification. New to the concept? Start with what a drone-in-a-box is, or request a demo.
Sources
- Regulation (EU) 2016/679 (GDPR), Art. 5, 25, 35 and Chapter V: eur-lex.europa.eu/eli/reg/2016/679/oj
- EDPB, Guidelines 3/2019 on processing of personal data through video devices, version 2.0: edpb.europa.eu
- Directive (EU) 2022/2555 (NIS2), Art. 21 and 23: eur-lex.europa.eu/eli/dir/2022/2555/oj
- European Commission, NIS2 Directive overview: digital-strategy.ec.europa.eu/en/policies/nis2-directive
- Directive (EU) 2022/2557 (CER), Art. 6 and 13: eur-lex.europa.eu/eli/dir/2022/2557/oj
- Regulation (EU) 2024/1689 (AI Act), Art. 3(35), Art. 5, Annex III: eur-lex.europa.eu/eli/reg/2024/1689/oj
- European Commission, AI Act regulatory framework and timeline: digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- NÚKIB, National Cyber and Information Security Agency (Czechia): nukib.gov.cz