This three-part series explores why and how device OEMs, systems integrators, and their customers should take a holistic view of the full connectivity stack: antenna, module, network, cloud, and data flow. This final installment focuses on securing data in transit to and from the cloud, as well as thwarting the jamming and spoofing attacks that are increasingly common in civilian and defense GNSS applications.
Part 1 discussed when and how to minimize uplink and downlink data to help maximize the battery life of IoT devices. That means when data is transferred, it’s valuable, which makes it an attractive target for hackers, industrial espionage, rogue nation-states, and other bad actors.
Encryption is an obvious solution, but there are three key caveats:
The good news is that all three can be addressed. For example, session resumption (TLS 1.3 0-RTT/session tickets) and hardware-accelerated crypto eliminate the need for — and power drain of — renegotiating a full handshake on every uplink.
LPWAN technologies have their own link-layer security, such as AES-128 session keys in the case of LoRaWAN. Even so, it’s wise to add transport-layer encryption: TLS 1.3 or DTLS 1.3 for UDP/CoAP on constrained links. Some more best practices:
Authentication should be mutual rather than one way. When security depends entirely on the device trusting the server, it leaves the door open for rogue devices to flood the backend.
Always use per-device certificates or keys so a compromised device can be revoked individually without disabling the entire installed base. During manufacturing, have each device provisioned with a unique cryptographic identity. Per-device identity and keys ensure that one extracted key doesn’t give the bad actor access to the entire installed base.
Each device should store its key in hardware rather than flash, where it’s vulnerable to extraction. Use a secure element/secure enclave/TPM, or an integrated iSIM/eSIM with an EAL5+ certified enclave, so private keys are generated on chip and never leave it. This is exactly why security certification on the module matters: A documented hardware root of trust is something that can be required and demonstrated in a conformity audit.
Use secure boots and cryptographically signed OTA firmware updates to prevent attacks that replace firmware. Rollback protection provides an additional layer of protection by preventing attacks that force a downgrade to a vulnerable version.
Use the device’s expected service life to design its crypto-agility. A device shipping today may still be in the field in 2040. Ensure that its algorithms and keys can be updated in the field and that credentials can be revoked and rotated remotely.
Minimize the attack surface. Disable unused ports, debug/JTAG interfaces, and services before shipping. Every open interface on a device that can’t be physically monitored is a liability and vulnerability.
Implement defense in depth. Assume any single layer can fail. By combining transport encryption, device authentication, secure storage, and secure boot, a single weakness can’t compromise the whole system.
Suppliers play a crucial role in developing and executing a data-in-motion security strategy. But systems integrators and end users such as enterprises also must play their part by ensuring suppliers have a clear baseline of expectations. Three examples are ETSI EN 303 645 (consumer IoT baseline), NIST IR 8259/SP 800-213 (IoT device cybersecurity), and the EU Cyber Resilience Act (CRA)/IEC 62443-4-1 for the secure development lifecycle. The CRA in particular is moving these from “nice to have” to a legal requirement for products sold in the EU. (For a deeper dive, see “Navigating the New EU Cybersecurity Requirements and Compliance Options.”)
When comparing suppliers, focus on their security posture because connected devices inherit the security — or vulnerability — of their supply chain. A perfectly designed device can still be compromised if a vendor’s engineering network is breached, keys are mishandled during provisioning, or malicious code enters via a compromised build system (the SolarWinds pattern). Here are two highly recommended certification requirements:
ISO/IEC 27001:2022: The 2022 revision specifically added controls relevant to modern connected products, including threat intelligence, secure coding, data masking, and cloud-service security. 27001:2022 certification demonstrates, with third-party proof, that a supplier manages information security as an ongoing process, not a one-time effort.
Cybersecurity Maturity Model Certification (CMMC) Level 2: This aligns with the 110 security requirements of NIST SP 800-171 and exists to protect Controlled Unclassified Information (CUI) in the U.S. defense supply chain. That rigor and use cases don’t mean CMMC Level 2 is overkill for enterprises, utilities, and smart cities. If it’s good enough for defense applications, then it’s good enough for mission-critical and confidential business applications, too. A CMMC Level 2-ready supplier has demonstrably invested in access control, incident response, configuration management, and supply-chain risk practices that most purely commercial vendors lack.
It’s also smart to ask suppliers about:
Many IoT applications rely on GNSS for positioning, navigation, and timing (PNT) data. That reliance is why GNSS jamming and spoofing are now rampant not only in defense applications, but also civilian ones such as asset trackinf.
“The sharp rise in cargo crime that was observed in 2025 was accompanied by a noticeable increase in the sophistication of coordinated theft operations,” the National Motor Freight Traffic Association says in its 2026 Transportation Industry Cybersecurity Trends Report. “A prevalent technique used was GPS spoofing, where criminals manipulate location data of trucks or trailers to conceal unauthorized route changes or to mislead tracking systems during load thefts.”
Jamming uses strong signals in either the GPS band or adjacent bands to interfere with the GPS signal, to the point that it’s unusable. These attacks are relatively unsophisticated and use low-cost equipment.
Spoofing uses fake signals to fool the GNSS receiver into believing it’s in a different location or at a different point in time. Spoofing is more sophisticated and difficult to detect than jamming.
“GNSS Jamming and Spoofing Targets Trucking” and “Countering GNSS Jamming and Spoofing for Aerospace and Defense Applications” focus on specific verticals, but the attack vectors and vulnerabilities they explore apply to just about every type of GNSS use case, fixed and mobile — making both blog posts must reads. The common denominator is that whether PNT data drives a decision or time stamps a transaction, GNSS is always an untrusted input. That is a security property of the data pipeline, which maps cleanly onto the aforementioned CRA thinking.
Follow these tips to leverage antennas to mitigate jamming and spoofing:
For more insights and tips, see:
Get in touch for orders or any queries: sales@rfdesign.co.za / +27 21 555 8400
Courtesy of Taoglas
