A GATT characteristic is a Bluetooth Low Energy attribute that stores a value exposed by a device or peripheral. It is read, written, or notified through a GATT service and is used to present sensor data, configuration, or status.
Bluetooth Low Energy characteristic fundamentals
A gatt characteristic is the atomic data item a Bluetooth Low Energy peripheral exposes to a central device. It is the point where a sensor reading, status flag, or configuration value becomes readable, writable, or notifiable over the BLE attribute model.
This makes characteristics the practical interface between a device’s internal state and the application that consumes it. A characteristic may represent something simple, such as battery level, or something operationally sensitive, such as a lock state, pairing mode, or threshold setting.
How characteristics fit into the GATT model
GATT organizes BLE data into services and characteristics. A service groups related functionality, while a characteristic carries the actual value and the access behavior that determines whether a client can read it, write it, or subscribe to notifications and indications.
That structure matters because a BLE application usually interacts with a device by discovering services first, then locating the specific characteristic it needs. The characteristic is therefore both a data container and a contract about how that data can be handled.
Access methods and characteristic properties
Characteristic properties describe what the client is allowed to do with the value, while permissions and device policy determine whether those operations are actually accepted. A characteristic may be readable but not writable, writable only after pairing, or available only to authenticated sessions.
Notifications and indications are also important because they let the peripheral push changes instead of waiting for polling. That is useful for telemetry and real-time status, but it also means the characteristic can become a live signaling channel if the surrounding access controls are weak.
Why characteristics matter in device communication
Because characteristics often represent the state or control surface of the peripheral, their design influences interoperability, user experience, and security posture. A poorly scoped characteristic can expose more device behavior than intended, while an overly broad one can make it difficult to enforce least privilege at the application layer.
In practice, the important question is not just what the characteristic stores, but who can observe it, modify it, and receive updates from it. That is why characteristic design is part of the device trust boundary, not just a naming convention in the BLE profile.
Risk and Threat Considerations
Characteristics can expose sensitive device state or allow unsafe configuration changes if their read, write, or notify behavior is not tightly constrained. The same interface that powers useful telemetry can also leak operational data or give an attacker a path to alter device behavior.
Failure mechanism: Weak authorization, insecure pairing, or permissive characteristic design allows an unauthorised client to read confidential values, write unsafe settings, or subscribe to sensitive notifications.
Impact: Exposure can range from privacy leakage and device tampering to denial of service, unsafe actuation, or persistence of insecure configuration after a compromised session ends.
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 | AC-3 — Access Enforcement | BLE characteristic access depends on enforced read and write permissions. |
| IA-2 — Identification and Authentication (Organizational Users) | Authenticated sessions are often required before sensitive characteristics can be used. | |
| SC-7 — Boundary Protection | A peripheral characteristic is an exposed interface across a trust boundary. | |
| Recommendation — Enforce characteristic-level access rules before allowing reads, writes, or subscriptions. Require strong authentication before exposing sensitive BLE characteristic operations. Segment BLE exposure and restrict characteristic access at the device boundary. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Characteristic permissions are an access-control decision over device functionality. |
| Recommendation — Apply least privilege to every BLE characteristic that can be read or written. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management Policy, Processes, and Procedures | Characteristic access should follow defined policy and approved access behavior. |
| Recommendation — Document and enforce policy for who may read, write, or subscribe to each characteristic. | ||
Practitioner Guidance
Why practitioners should care: The security of a BLE device is often decided at the characteristic level, because this is where policy becomes concrete. Treat each exposed value as a deliberate interface choice, not just a payload field.
What to watch for: Review whether a characteristic is actually intended to be public, whether write access should require authentication, and whether notifications reveal more than the application needs. If a value is operationally sensitive, the characteristic should reflect that sensitivity in its access model.
Practitioner takeaway: A well-designed GATT characteristic is specific, minimally exposed, and aligned to the device’s trust boundaries, so the BLE profile does not become an accidental control plane.
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