GL One® Network: Security and Privacy Architecture

Team
Utilities Team
Last Updated
September 21, 2026

GL One® Network: security and privacy architecture

This document is the public reading of the security and privacy architecture of the GL One® Network. It describes design decisions, threat model, defense in depth, boundaries and shared responsibility, in technical language accessible to corporate, legal and regulatory readers. The detailed technical specification — cryptographic primitives, message format, provisioning scheme and operational parameters — is not distributed as a copy. It is made available for on-site review, in a controlled environment, at GL One®'s office, under a prior NDA, to customers and partners with a legitimate need for verification.

I. Architectural premise

The GL One® Network is a collaborative industrial data-collection and telemetry network. It combines two classes of node. Physical sensors, embedded in field equipment (water meters, energy meters, telemetering equipment), operate by broadcast over BLE radio. Logical nodes, running as an SDK inside partner mobile applications, listen to the physical environment around the user's device, process the result and deliver it to the infrastructure. The network carries encrypted operational data between these two ends and makes measurements, events and context available to regulated customers (water, energy and gas utilities) and to the operators of the partner applications.

The architectural premise is explicit: security in a network is a property of the architecture, not of the radio or transmission protocol. Every telecommunications technology (BLE, WiFi, optical fiber, LoRa, NB-IoT, any other) carries vulnerabilities that have been published or are yet to be published. No security guarantee lives in the physical medium. What separates a fragile network from a resilient one is the architecture that uses that medium.

This premise is not decorative; it is the foundation of the GL One® Network's design. The architecture described in this text is the result of a careful assessment of the state of the art in industrial IoT, collaborative mesh networks and mobile SDKs — of their design decisions, their documented trade-offs and their known failures. The GL One® Network was designed from the lessons learned across that body of work.

The remainder of the document details this architecture, in technical language, without omitting its boundaries. Section II presents the threat model. Sections III to VI describe the two ends of the network (physical sensor and SDK inside a partner application), the defense in depth in cryptography, and the minimization of personal data. Sections VII to IX cover compliance with privacy and personal data protection (LGPD) and with regulation (ANATEL). Section X addresses ongoing operations. Section XI states the limits of what is promised. Section XII describes the evolutionary posture.

II. Adversaries and containment

The GL One® Network operates under a formal threat model, mapped onto STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. For each class, specific architectural decisions reduce or eliminate attack surface. The two ends of the network operate under distinct models, detailed separately in sections III (physical node) and IV (logical node).

The adversaries considered include the passive radio attacker (eavesdropping), the active proximity attacker (injection, replay, jamming), the network attacker with access to intermediate infrastructure, a malicious or compromised host application, a user device infected with malware, an insider with partial access to a tenant, and a supply chain attacker. What we explicitly do not defend against is a physical sensor handed to an adversary with unlimited time and a full laboratory, nor a user's smartphone under an adversary's total control (root, malicious jailbreak, malware with system privileges). Those scenarios are outside the scope defensible by the architectural layer described here. What we do defend is that compromising one sensor or one user device does not compromise the Network. The limits of that scope are detailed in section XI.

This principle — containment of the blast radius — is the foundation of the architecture.

III. The physical node: unidirectional edge and per-device cryptographic identity

The network's physical edge layer operates in unidirectional transmission, by broadcast. The sensor announces the event. There is no pairing, no interactive authentication, no return channel on the device side. The consequence is direct: the Bluetooth CVEs usually cited in superficial analyses (BlueBorne, KNOB, BLESA, BIAS, BLURtooth) all depend, without exception, on active pairing or on dynamic key exchange. In unidirectional broadcast mode, those classes of attack have no vector.

This decision has a cost. Operations on the device (including firmware updates and configuration changes) require physical proximity to the sensor and a controlled maintenance procedure. There is no remote channel operating at a distance over the fleet as a whole, nor any broadcast capable of changing sensor behavior simultaneously. The cost is accepted deliberately: it eliminates the most dangerous vector in industrial IoT, the remote attacker able to touch the entire fleet through a single path.

Each sensor in the network receives its own cryptographic material during factory provisioning. Revocation is supported and propagated to the validation infrastructure when required. This design answers a known class of problem in architectures with a shared key or cryptographic material replicable across devices, where extracting a single unit exposes the entire fleet. The GL One® Network's architectural direction is per-device cryptographic isolation, ensuring that each node holds a unique, non-exportable credential.

Along the same lines, sensor hardware is selected from microcontroller families with in-silicon security features, and configured in production to take advantage of them. After cryptographic provisioning, the chip's debug interface is irreversibly locked and program memory is protected against external reads, which prevents extraction of firmware and keys using standard bench tools.

Before propagation, the payload is encrypted and authenticated by the device with its own cryptographic material. Encryption protects the confidentiality of the content: passive capture by an adversary with a receiver yields only an opaque packet. Authentication protects integrity and origin: attempts at injection, replay or packet alteration are rejected by the validation infrastructure, because they do not carry a valid signature from that sensor's unique key.

The identifier the device exposes over the air is distinct from the internal logical identifier used by the infrastructure. Even an observer who records the radio address (MAC or the BLE link equivalent) does not obtain the internal identifier needed to forge a reading, nor the cryptographic material that would sign it. Physical identity and logical identity are decoupled by design, in the same vein as the BLE address randomization adopted by iOS and Android.

The operational consequence is that compromising an isolated sensor gives the attacker only the ability to operate that sensor, and nothing more. There is no horizontal escalation. There is no access to the network. The blast radius is exactly one device, and revocation removes that device from the mesh immediately.

IV. The logical node: SDK in a partner application, opt-in and sandbox

The GL One® SDK is the other end of the collaborative network. It participates in the same asset, but operates under restrictions and a threat model entirely different from the physical sensor's.

Voluntary opt-in

The SDK is embedded in the applications of partner companies, which review all documentation and functionality and, by their own choice, opt to install it and are therefore responsible for informing their users about any connections with third-party applications or SDKs. Application users accept the terms of use at installation or when the feature is activated, and grant, through an affirmative act of acceptance, specific permissions (Bluetooth, location, notifications) that allow the SDK to run. There is no remote installation and no co-opting of third-party devices.

The GL One® Network grows through informed opt-in. There is no involuntary relaying by devices whose user has not installed a partner application and accepted the permissions. When the user uninstalls the application or revokes the permissions in the operating system, the node ceases to be part of the network from that moment on. In addition, GL One provides a "forget my device" mechanism for users who no longer wish to be part of the network: https://www.grouplinkone.com/esqueca-dispositivo.

What the SDK does, and what it does not do

The SDK runs inside the operating system's application sandbox (mandatory isolation), with the same restrictions and permissions as any other embedded third-party code. It has no elevated access. It has no system privileges. It does not execute outside the host application's context.

The SDK's function is to passively listen to BLE broadcasts in the physical environment around the device, process them locally where applicable, and transmit the contextualized result to the network's infrastructure over a secure channel. The SDK does not collect data from the host application. It does not access contacts, messages, photos, browsing history or any content stored by the user. It does not modify the behavior of other applications. It does not inject code outside its own scope.

This boundary is not a declaration of good will. It is a technical restriction imposed by the operating system's sandbox, and auditable through reverse engineering by any independent researcher.

Distribution, updates and auditability

The SDK is distributed through versioned package repositories, with a verifiable cryptographic hash. The code is integrated into the partner application at build time and goes through App Store and Google Play review processes like any other dependency. SDK updates require rebuilding and redistributing the host application, with a new review process. There is no mechanism for silently updating the SDK's code in the field.

This property has a cost (a slower update cycle than remote injection) and a benefit (there is no vector to force a mass change in SDK behavior without passing the scrutiny of the partner application and the app stores). It is one of the main elements underpinning the trust of partner application operators and of corporate security teams that assess the SDK before integrating it.

Authentication and per-application segregation

Each partner application that integrates the SDK receives its own credentials to authenticate against the GL One® infrastructure. One application's traffic is logically and cryptographically isolated from another's. An SDK running in application A shares no state, cache or identifiers with an SDK running in application B on the same device. There is no global user identity across partner applications.

Compromising one partner application does not compromise the network's other partner applications, and does not give the attacker visibility into the network as a whole.

Defenses specific to the logical node

Against a malicious host application, the SDK exposes no sensitive APIs and accepts no arbitrary commands from the host. Against malware on the device, communication with the backend is encrypted and authenticated using credentials protected by operating system mechanisms (iOS or Android).

Against network interception, TLS 1.2 or higher is mandatory, reinforced by mutual TLS (mTLS): client and server authenticate each other by certificate, so that an on-path attacker (positioned between client and server to intercept or modify the communication) cannot authenticate to either side, making the attack practically unfeasible. Against reverse engineering, the SDK uses obfuscation techniques so that inspecting the binary code exposes neither shared secrets nor structure useful for forging traffic at scale.

The blast radius of a compromised logical node is, by design, a single device running a single application. It does not cascade.

V. Cryptographic defense in depth

Cryptographic defense in depth means that every hop between two points in the network has its own cryptographic protection, and that breaking one hop does not compromise the others.

![Cryptographic defense in depth — four independent layers from sensor to disk](/img/defesa-criptografica.png)

Layer 1, device to SDK (BLE radio). The packet announced by the sensor carries two simultaneous ciphers, with different purposes. The transport cipher protects frame integrity and minimal protocol validation, with a key that rotates on a short window over the public parts — just enough for the SDK to confirm that the packet belongs to the network without needing to open the content. The payload cipher protects the useful data end to end, from the device to the application, and the SDK never opens it. In other words, the logical node works as an encrypted repeater: it validates provenance and forwards opaque content.

Layer 2, SDK to cloud. The channel uses HTTPS over TLS 1.2 or higher, reinforced by mutual TLS. The server requires a valid client certificate, issued for that partner application, and the client requires a valid server certificate. An on-path attacker positioned between the SDK and the cloud, even with control of the intermediate network, cannot authenticate to either side. The known trade-off of mTLS shows up in corporate networks with traffic inspection proxies: by design, mTLS prevents such a proxy from establishing the connection on the client's behalf — which is precisely the property that makes the on-path attack unfeasible, and operation in a corporate environment occasionally more complex.

Layer 3, inside the cloud. Between microservices, virtual machines and platform components, every connection uses HTTPS over TLS. Client credentials, API keys and operational secrets live in a dedicated vault, with audited access and periodic rotation, and never appear in code, in a repository or in an environment variable in clear text.

Layer 4, cloud to physical storage. Storage at rest uses AES with a unique key per physical disk, managed by the cloud provider. It is worth being explicit about what this means in threat-model terms: from GL One®'s standpoint, data entering the database has already been decrypted by the provider at the block layer, and logical segregation between customers happens in the application, not in the disk key. This does not weaken the posture: the vector that disk encryption closes is physical theft of hardware from the datacenter, not logical isolation between tenants, which is guaranteed by other layers.

The operational consequence is direct. Interception at the radio layer yields an opaque packet. Interception on the SDK-to-cloud path fails mutual authentication. Interception inside the cloud runs into internal TLS and the vault. Physical access to the storage hardware runs into disk encryption. Breaking one layer does not break the others. That is the literal meaning of defense in depth.

This section describes the four layers at architectural granularity, intentionally. The detailed specification of the primitives in use (algorithms, modes of operation, key sizes, rotation windows, packet format, derivation scheme, provisioning and revocation processes) is not distributed as a copy. It is made available for on-site review, in a controlled environment, at GL One®'s office, under a prior NDA, to customers and partners with a legitimate need for verification. This format follows established practice in comparable architectures, where the public whitepaper carries the design argument and the closed technical specification carries adversarial verification, without a copy of the material leaving GL One®'s perimeter of control.

VI. Privacy and Personal Data Protection guidelines in the GL One® Network

The GL One® Network's architecture was designed to meet the principles and strict criteria of personal data legislation and regulation, particularly Brazil's General Data Protection Law (LGPD).

The GL One® Network was built so as not to collect or process identifiable personal data such as name, taxpayer ID (CPF), address, e-mail or phone number. In line with the minimization principle, the data traveling through the radio layer carries only what is strictly necessary for the Network to function: an opaque equipment identifier and the metric of interest, both encrypted. The data is therefore pseudonymized at source, and GL One does not hold reasonable means to reverse the pseudonymization or to perform any cross-referencing for re-identification. In addition, there is logical isolation and dissociation among the Network's actors — that is, each actor in the ecosystem accesses only the fraction of data corresponding to its own activities, with no single point of data aggregation.

Even without direct personal data in transit, GL acts preventively by establishing and periodically reviewing its Privacy Program, which meets the requirements of international frameworks such as NIST and ISO 27701/2019.

Within its Privacy Program, built on strategic governance pillars, GL works on privacy acculturation, the definition of personal data processing rules in internal policies and standards, the mapping of internal and external personal data processing, third-party management, and the assessment of initiatives under privacy by design and privacy by default methodologies.

Concern for personal data processing practices has been the subject of internal and external studies[^1] which attested, through technical analyses and Data Protection Impact Assessments (DPIAs), to the regularity of the operation and to the mitigating measures needed to prevent improper processing and personal data incidents.

In the Network's architecture, the roles of the processing agents are clearly defined, contextually. In the activities of maintaining and expanding the Network, GL acts as Personal Data Controller, determining the purpose, means and form of processing. The legal basis is legitimate interest (art. 7, IX, LGPD), supported by a balancing test that verifies the proportionality between the lawful interest of enabling the Network's infrastructure and the rights of data subjects. The contracting party (for example, public utility concessionaires) acts as Personal Data Controller for its own processing of personal data, which must be explicitly and transparently set out in its privacy policies and notices.

GL is continuously establishing and improving its data processing practices, which seek to preserve the privacy and protection of personal data — whether of its customers, employees or related third parties.

Data subjects or the Brazilian National Data Protection Authority (ANPD) may contact GL's Data Protection Officer directly at [email protected]. To disconnect a device from the GL® Network, simply go to https://www.grouplinkone.com/esquecer-dispositivo and provide the device_ID.

VIII. Formal standards and audits

The network's technical posture is self-assessed and progressively certified against the applicable international standards. The NIST Cybersecurity for IoT Program and the NISTIR 8259 series inform the manufacturer and integrator baseline. ETSI EN 303 645 covers the consumer IoT profile at the ends that touch applications. OWASP IoT Top 10 and OWASP Mobile Top 10 are used as implementation vulnerability checklists for the physical and logical nodes, respectively. ISA/IEC 62443 addresses the OT contexts in water, energy and gas, where the network operates alongside industrial control systems.

This posture is not an internal declaration. It is publicly exposed in GL One®'s trust center at https://trust.grouplinkone.com, operated via Oneleet, with continuous control monitoring, audit evidence, the status of certifications in progress, and a pen test report available under NDA. The trust center is updated automatically as each control is verified, replacing the static snapshot typical of a PDF certificate with a live state, verifiable by any interested customer, partner or researcher.

Every component of the network has a documented and revisited threat model. External pen testing is part of the cycle, for both the infrastructure and the SDK distributed in partner applications. Responsible disclosure is the preferred channel for any researcher who identifies a vulnerability, with a public reporting channel available in the trust center itself. When a flaw is discovered, it will be fixed and communicated. That commitment matters as much as the preventive posture.

IX. ANATEL certification

The operation of GL One® sensors in Brazilian territory falls under two distinct ANATEL regulatory layers, which need to be separated to avoid the recurring confusion found in poorly informed opinions about IoT.

The first layer is spectrum use. GL One® sensors operate on Bluetooth Low Energy in the 2.4 GHz ISM band, classified by ANATEL as restricted radiation. Restricted radiation requires neither an operating grant nor spectrum licensing. It is a lawful and fully regulated regime, identical to that of the unlicensed bands used by LoRaWAN, Sigfox, ZigBee and the Open Metering System, all accepted in Brazilian public telemetering tenders.

The second layer is product certification. Even restricted-radiation devices require technical certification and ANATEL homologation before commercialization or volume operation in Brazil. Homologation is issued by ANATEL based on a Technical Conformity Certificate (CCT) produced by a Designated Certification Body (OCD), and attests conformity with the applicable technical requirements: radiated power limits, emission mask, spurious emissions, electrical safety, and a visible identification mark on the product. The standard validity cycle is 24 months, with periodic renewal.

GL One® maintains a certified portfolio under the Restricted Radiation Transceiver category, registered to Group Link Network S.A. (CNPJ 10.664.687/0001-13). The status consolidated from an ANATEL query on 05/07/2026 lists ten models currently in the field:

  • GL-MDV208 (NCC 26048/24)
  • GL-MLV202 (NCC 26938/24)
  • GL-MSV207 (NCC 26939/24)
  • GL-WGV210 (NCC 26990/24)
  • GL-EMV203P (NCC 27028/25)
  • GL-EMV203R (NCC 27028/25)
  • GL-WGV210XL (NCC 27117/25)
  • GL-MIV204 (NCC 27118/25)
  • GL-SLV203 (NCC 27138/25)
  • GL-SLV208 (NCC 28157/25)

Earlier-generation models (Safe Button SB01, GLPlug, GLTag, GLUtilities Energy, GLUtilities Water, GLUtilities Energy L3, GLStation, GL-WGV102, GL-WGV208) have been superseded by current products and had their homologation ended by expiry of the 24-month regulatory cycle, as is standard practice. Discontinuing a homologation does not represent an irregularity: it represents the normal portfolio evolution cycle in industrial IoT.

Hardware engineering keeps an active renewal calendar and an anechoic-chamber test cycle for validating new families, with technical coordination led by the Engineering department. For products intended for gas contexts and potentially explosive atmospheres, EX certification (Inmetro/IEC 60079) complements ANATEL homologation and is required operationally by customers in that sector. The GL-WGV210XL model, for example, is subject to this dual regime.

ANATEL homologation is a mandatory regulatory instrument, not a competitive differentiator. Operating at volume in Brazil without a certified portfolio is, by definition, irregular operation. The GL One® Network's differentiator lies in the layers that come before homologation (architecture, segregation, per-device cryptography, described in sections III to V) and in those that come after (continuous operation, portfolio evolution, defense in depth, described in sections X and XI). Homologation attests compliance with the regulatory minimum. The rest of this document describes what lies above the minimum.

X. Secure operations

Security does not end at design; it continues in operations. The network runs under formal Site Reliability Engineering practices, with SLIs and SLOs defined for critical services, explicit error budgets, documented incident management and a blameless postmortem after every relevant event. This is not improvisation. It is infrastructure that must meet the contractual SLA of a large regulated customer.

The topology is distributed, with presence in more than one region, for geographic resilience and independence from a single provider. Backups are automatic, encrypted and tested by real restores, not merely declared in a spreadsheet. The event-level audit trail is retained for multiple years and indexed for forensic investigation.

Operational hardening includes segregation of duties, the principle of least privilege, mandatory multi-factor authentication for any administrative access, and periodic access reviews with automatic revocation when a role expires.

XI. Limits and shared responsibility

There are limits, and it is important to state them. Security manifestos that omit their limits lose technical credibility.

We do not promise immunity. No network is immune. We promise defense in depth, containment of the blast radius and honest disclosure.

We do not promise that a physical sensor handed to an adversary with unlimited time and a full laboratory will hold out indefinitely, even with the in-silicon protections described in section III. We promise that compromising an isolated device does not compromise the Network.

We do not promise to defend a user's smartphone under an adversary's total control (root, malicious jailbreak, malware with system privileges). That scenario, in any SDK architecture in the world, is beyond the scope defensible at the application layer. We promise that a compromised device is contained, and does not become an attack vector against the entire network.

We do not promise zero vulnerabilities. Vulnerabilities will appear, as they do in every serious piece of infrastructure in the world. We promise that the architecture tolerates a local vulnerability without global collapse, and that the remediation process is structured and auditable.

Finally, the network's security operates under a shared responsibility model. GL One® is responsible for the network design, for the SDK and firmware code, for the ingestion and storage infrastructure, and for the operational controls exposed in the trust center. The partner application operator is responsible for integrating the SDK into its build cycle, for protecting the credentials it receives and for updating the application distributed to its users. The operating customer is responsible for configuring its tenant, for controlling its teams' access and for the responsible use of the data it receives from the network. Each layer is necessary. None of the three alone is sufficient.

XII. Position: an evolutionary posture

Security is not a state. It is a process.

The architecture described here is where the network stands today, not where it will stop. Threat modeling is a continuous exercise, revisited at every relevant change in surface. External pen testing is recurring. The trust center at https://trust.grouplinkone.com exposes the live state of the controls, and is updated as each one is verified, not according to a commercial calendar.

Security is also not the property of one team. It is the property of GL One®'s entire engineering organization. Design decisions go through threat review before coding. New code goes through static analysis and peer review with a security checklist applied. Every incident, of any severity, produces a documented and reviewed blameless postmortem, to the same standard recommended by Building Secure & Reliable Systems.

External engagement is an explicit part of this posture. Independent security researchers have a direct reporting channel, with an initial-response SLA published in the trust center, and public acknowledgment where applicable. Customers and partners have access to control evidence, to the pen test report under NDA, and to a technical channel for security questionnaires. This open flow is what separates a manifesto from a real security operation.

Annex: External references

The references gathered below are public and widely recognized by the technical communities of networking, cryptography, IoT, privacy and reliability engineering. They support the architectural decisions described in this document and give the reader the material to verify, in primary sources, each of the stated choices. This list does not constitute a statement of compliance. It is recommended reading for anyone who wants to understand the state of the art in industrial IoT, collaborative BLE networks, secure transport and privacy by design, and to assess, on their own terms, the architectural decisions of the GL One® Network.

A. IoT, OT and mobile security standards

B. Transport, cryptography and identity protocols (IETF and W3C)

C. Bluetooth Low Energy, mesh and radio privacy

D. Threat modeling, reliability engineering and privacy by design

[^1]: GL One® commissioned an independent legal opinion from Laura Schertel Mendes Advocacia e Consultoria on the compliance of the Utilities IoT Network with the General Data Protection Law. The author is Professor of Civil Law at the University of Brasília (UnB) and at the Brazilian Institute of Education, Development and Research (IDP), holds a post-doctorate from Goethe University (Frankfurt am Main) and a doctorate in Private Law from Humboldt University (Berlin). She is a recognized authority on personal data protection in Brazil, and part of the reference literature on the LGPD as applied to emerging technologies. That opinion is confidential and may only be made available to customers and/or partners under a signed NDA or contract, upon request sent to [email protected].