Drones are entering a new phase of adoption. What began primarily as a technology for imaging, surveying and relatively isolated operations is increasingly becoming part of the operational infrastructure used across logistics, energy, public safety, defense and industrial environments. The European Commission has estimated that the European drone services market could reach €14.5 billion and support 145,000 jobs by 2030, while regulatory frameworks continue to evolve to accommodate increasingly sophisticated and higher-risk operations. In Europe, for example, EASA’s June 2026 revision of the UAS rules incorporated SORA 2.5 for operations in the Specific Category. As organizations place more operational responsibility on unmanned systems, one question therefore becomes increasingly important: are their security architectures evolving at the same speed?
Drone security is a system problem
There is no single “drone cybersecurity” vulnerability. A modern unmanned aircraft system is an interconnected environment comprising the aircraft itself, sensors, navigation systems, Command & Control links, ground stations, software, wireless interfaces and, increasingly, cloud, edge and fleet-management infrastructure. Each component presents different risks and requires different defensive mechanisms. GNSS signals may be spoofed or jammed; communication links may be intercepted or disrupted; poorly protected wireless protocols can create unauthorized access points; firmware can contain exploitable weaknesses; credentials can be stolen; and devices can potentially be impersonated. Securing the overall system therefore requires defense in depth rather than reliance on any individual technology.
This distinction is important because different threats require different countermeasures. Navigation resilience must be addressed through navigation-specific mechanisms such as resilient PNT, anti-spoofing capabilities or sensor fusion. RF jamming requires an appropriate communications architecture. Firmware needs secure development, signing, secure boot and controlled update mechanisms. Access must be managed, devices and operators must be authenticated, and sensitive communications need to be protected. Cryptography is consequently one part of a much broader security architecture, but it is also a particularly important one because it supports several security functions at the same time.
Following security down to its cryptographic foundation
Consider some of the operations that a secure drone ecosystem may need to perform. A ground station may need to authenticate an aircraft before allowing it onto a mission network; a drone may need to establish an encrypted channel before receiving commands; an OEM may need to provision unique cryptographic credentials during manufacturing; autonomous aircraft may need to authenticate one another before exchanging information; and fleet infrastructure may need to generate new keys as devices, missions and trust relationships change. The implementation will vary from platform to platform, but these functions share a fundamental dependency: cryptographic material must be securely generated somewhere.
The security properties of an encryption algorithm or authentication protocol therefore depend not only on the algorithm itself, but also on the keys and random values used by it. If cryptographic material is generated from insufficiently unpredictable randomness, weaknesses can be introduced below an otherwise well-designed security architecture. This is why entropy should not simply be considered an invisible operating-system resource. NIST SP 800-90B formally defines design and validation requirements for entropy sources used by Random Bit Generators, while SP 800-90C, finalized in September 2025, defines constructions that combine these entropy sources with deterministic random bit generator mechanisms.
The dependency can therefore be understood as a chain: trusted hardware → entropy and cryptographic processing → keys and identities → secure operations. Quside operates at this foundational layer, combining hardware-rooted cryptographic technologies with high-quality, verifiable entropy.
From assumed randomness to verifiable entropy
Randomness is usually consumed deep inside the technology stack, which makes it easy for organizations to regard it as an assumption. An operating system, hardware component or security application supplies random numbers and downstream applications simply trust that they are sufficiently unpredictable. For systems moving into more security-sensitive environments, however, this raises questions that deserve greater attention: Where does the entropy originate? How unpredictable is the source? Can its quality be measured? And can the organization consuming it determine whether the source continues to behave as expected during operation?
Quside addresses this part of the architecture by generating entropy from physical quantum processes and combining that generation with Randomness Metrology designed to provide visibility into the quality of the source. Rather than treating randomness as an opaque input, Quside’s approach makes entropy observable so that its quality can be monitored. This is the principle behind LOVE™ — Locally Verified Entropy: generate entropy where it is needed and provide evidence about the quality of that entropy at its source.
This does not replace the rest of the drone security stack, nor should it be presented as a solution to threats such as GNSS spoofing, RF jamming or insecure firmware. Instead, it strengthens one of the foundational resources used by cryptographic systems. That distinction is particularly important in security-sensitive markets, where credibility depends on understanding exactly what each component of an architecture can — and cannot — protect.
Where can quantum entropy fit in a drone architecture?
There is no universal drone architecture, so there is also no single way to deploy an entropy source. One of the most straightforward approaches is to introduce verifiable entropy at the ground-infrastructure level. In this model, Quside technology can provide entropy to the HSM, KMS, PKI or other security infrastructure responsible for generating and provisioning cryptographic material. Keys or credentials can then be generated using that controlled source and provisioned to an aircraft before deployment. This architecture can strengthen control over key-generation entropy without requiring an entropy source to be integrated into every individual drone.
Quside has already demonstrated this infrastructure model in other security environments through its verified integration with Thales Luna HSMs, where SP 800-90B-compliant quantum-derived entropy is delivered directly into existing cryptographic infrastructure used for key generation and related processes. For drone OEMs and operators, the same architectural principle can be relevant to device enrollment, mission-key generation, credential provisioning or centralized fleet-security infrastructure.
A second possibility is to move entropy generation closer to the aircraft itself. Quside’s Ruby™ family provides semiconductor QRNG technology designed for embedded environments. Ruby™ N1 generates up to 1 Gbit/s of quantum entropy in a 5 × 5 mm² footprint, with a power consumption of 0.3 W, and is NIST SP 800-90B certified. Ruby™ S1 provides a lower-power alternative with 50 Mbit/s entropy generation, a 5 × 4 mm² footprint and a standard SPI interface. Whether a particular device is suitable for integration into an aircraft would of course need to be assessed against the platform’s environmental, interface, certification, SWaP and engineering requirements, but the architecture illustrates an important possibility: generating entropy locally where cryptographic operations occur.
The third model becomes especially interesting as fleets scale. Large drone ecosystems may involve PKI infrastructure, KMS platforms, ground stations, edge environments and applications that all require cryptographic material. Quside Entropy Core provides centralized, standardized access to quantum-generated entropy through REST APIs and can serve multiple applications from a controlled infrastructure layer. In a fleet environment, that enables a model in which verified entropy feeds identity, provisioning, key-management and security services across a distributed operation rather than leaving each individual application to depend exclusively on its own local randomness.
Regulation is raising cybersecurity expectations
The technical discussion is becoming more relevant as regulatory expectations around connected products and UAS continue to mature. In Europe, EASA’s current UAS framework now incorporates SORA 2.5 for Specific Category operations. Separately, the EU Cyber Resilience Act establishes lifecycle cybersecurity requirements for products with digital elements that fall within its scope. Reporting obligations begin to apply on 11 September 2026, while its main obligations apply from 11 December 2027. These developments do not mean that European regulators mandate quantum entropy for drones, and that is not a claim Quside should make. They do, however, demonstrate a broader movement toward secure-by-design products, vulnerability management, lifecycle security and greater scrutiny of the technologies on which digital trust depends.
For manufacturers and operators, this means security increasingly needs to be considered architecturally rather than as a collection of features added at the end of development. Encryption, authentication or signed firmware are not meaningful simply because they are present; organizations also need confidence in the systems that generate, protect and manage the cryptographic material behind them. Entropy is one of those underlying dependencies.
Post-quantum migration does not remove the randomness question
The issue becomes even more relevant for platforms expected to remain operational for many years. Government, defense and critical-infrastructure organizations are already preparing for the transition toward post-quantum cryptography. That migration will change the algorithms used to establish keys and produce digital signatures, but it does not eliminate the requirement for high-quality random material. Post-quantum cryptographic implementations still need appropriately generated randomness for key generation and other cryptographic operations.
For drone manufacturers, fleet operators and security architects, the goal should therefore be broader than replacing one algorithm with another. Long-lived systems need crypto-agility, robust key management and a trustworthy entropy layer capable of supporting the cryptographic technologies adopted throughout the lifecycle of the platform.
Building trust from the bottom up
Drone cybersecurity will never be solved by a single component. Secure navigation, communication resilience, software assurance, access control, identity, cryptography and operational processes all have distinct roles to play. The objective should be to understand what each layer protects and ensure that the level of assurance at every layer matches the importance of the mission.
Quside focuses on the trusted hardware and cryptographic foundations beneath these systems. This includes generating high-quality entropy locally and making its quality measurable and verifiable, but the broader objective is to strengthen the physical layer on which cryptographic trust is built — supporting secure key generation, device identity, provisioning, cryptographic operations and secure communications.
As unmanned systems become more autonomous, distributed and mission-critical, trust cannot exist only at the software or algorithmic layer. The hardware beneath those systems increasingly matters too.
The foundation of digital trust should be rooted in hardware that organizations can trust, observe and verify.
Talk to Quside about the trusted hardware foundation of your drone security architecture here.
