A Bluetooth GATT Characteristic is a data value exposed by a Bluetooth Low Energy device through the Generic Attribute Profile. It is identified by a UUID and can be read, written, or notified depending on the permissions and properties set by the peripheral.
Bluetooth GATT Characteristic in the Bluetooth Low Energy data model
A gatt characteristic is the unit of data that a Bluetooth Low Energy peripheral exposes to a central device. It is not just a value, but a value plus metadata that determines how it can be discovered, interpreted, and accessed.
In practice, the characteristic is the place where sensor readings, state flags, device settings, and control inputs are surfaced. Its UUID identifies the attribute, while its properties define whether the data can be read, written, or delivered asynchronously through notifications or indications.
How characteristics are organised and discovered
Characteristics live inside services, which group related capabilities into a coherent interface. That structure matters because consumers typically do not interact with the device as a flat list of values, they traverse services, then locate the specific characteristic they need.
Discovery is usually UUID-driven, which means the same logical capability can be exposed consistently across different devices even when implementations differ. This makes characteristics a useful interoperability boundary, especially for mobile apps, wearables, industrial sensors, and embedded controllers.
Properties, permissions, and access behaviour
The security and behaviour of a characteristic are governed by its properties and permissions. Properties describe what the characteristic supports, while permissions constrain who can access it and under what conditions. A value may be readable but not writable, or writable only after pairing, depending on the peripheral’s policy.
Notifications and indications are also operationally important. They allow a peripheral to push updates without polling, but they depend on a correctly configured client subscription and, in many deployments, on an authenticated and trusted BLE link.
Why GATT characteristics matter in device integration
Characteristics are often the main contract between a BLE device and the software that controls it. If the UUID, data format, or access rules are misunderstood, integrations break silently: values can be misread, writes can fail, or application logic can act on stale or malformed data.
Because characteristics are both functional and policy-bearing, they sit at the point where interoperability, device state management, and access control meet. That makes them a core concept in BLE application design, even though they are small in technical scope.
Risk and Threat Considerations
Misconfigured characteristics can expose sensitive device state, accept unauthorised writes, or leak operational data through readable attributes and unsolicited updates. In BLE systems, the risk is often less about the term itself and more about how the characteristic’s permissions, pairing requirements, and data semantics are implemented.
Failure mechanism: An attacker or unauthorised client discovers an exposed characteristic, reads data that should have been protected, or writes values that change device behaviour without proper validation or trust enforcement.
Impact: This can lead to privacy leakage, device misuse, configuration tampering, or unsafe control actions, especially when the characteristic governs settings, telemetry, or actuation logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | BLE characteristic access may depend on authenticated clients and trust decisions. |
| IA-3 — Device Identification and Authentication | BLE peripherals and clients often rely on device-level trust to gate characteristic access. | |
| AC-6 — Least Privilege | Characteristic permissions should expose only the minimum read/write/notify capability needed. | |
| Recommendation — Require authenticated access before allowing sensitive characteristic reads or writes. Authenticate devices before accepting control writes or privileged characteristic subscriptions. Restrict each characteristic to the minimum access needed for its function. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Characteristic permissions are an access-control surface that must be managed intentionally. |
| Recommendation — Review and limit characteristic access paths to only approved clients and roles. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | BLE characteristic exposure depends on correct identity and access enforcement at the device boundary. |
| Recommendation — Enforce authentication and access control before permitting sensitive characteristic operations. | ||
Practitioner Guidance
Why practitioners should care: Treat each characteristic as an explicit interface contract, not just a field on a device. The UUID, properties, permissions, and payload format should be reviewed together, because each one affects how the characteristic behaves in real deployments.
What to watch for: Pay close attention to characteristics that are writable, notify on change, or expose operational state. Those are the ones most likely to create integration defects or security exposure when a BLE peripheral is reused across products or environments.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org