Major and Minor Values are numeric identifiers used with iBeacon to distinguish one beacon from another within the same UUID. They let a receiver narrow location or proximity detection to a specific site, zone, or device group without changing the underlying beacon identity.
How Major and Minor Values work
Major and Minor Values are the addressing layer that turns a shared iBeacon UUID into something operationally useful. The UUID says, “this belongs to the same beacon family,” while Major and Minor Values let receivers separate one site, zone, room, or device grouping from another without changing the broader beacon identity.
That structure matters because Bluetooth proximity systems often need both consistency and granularity. A single UUID can cover a deployment, but Major and Minor Values let administrators create a simple hierarchy for filtering, routing, and interpretation at the receiver side.
Why the two-value model exists
The practical purpose of Major and Minor Values is to reduce ambiguity at scale. When many beacons share the same UUID, a scanner still needs a way to distinguish a lobby from a warehouse aisle, or one branch office from another, without giving each beacon a completely unrelated identity.
In effect, the values act like numeric labels inside a larger namespace. A receiver can first match the UUID, then refine the match using Major and Minor Values to decide whether the signal is relevant to the current location, workflow, or application rule.
How receivers interpret Major and Minor Values
There is no universal meaning attached to the numbers themselves. Their significance comes from the deployment’s own mapping, so one organisation may use Major for buildings and Minor for rooms, while another may use Major for floors and Minor for individual beacons.
That flexibility is useful, but it also means the semantics are administrative rather than inherent. If the mapping is poorly documented, the same beacon signal can be interpreted differently by different apps, which is why the values should be managed as part of the environment’s location model.
Where they fit in beacon design and operations
Major and Minor Values are best understood as operational metadata, not as a security control. They help structure beacon deployments, support tighter filtering, and make proximity logic easier to maintain when the number of beacons grows.
They are also commonly used to support site-specific experiences, such as triggering content in a retail space or narrowing detection in a single facility. For a broader view of beacon implementation patterns, see NIST Cybersecurity Framework 2.0 for the general governance and operational context around digital systems, and NIST Privacy Framework when location-aware systems raise privacy and data-handling questions.
Risk and Threat Considerations
Major and Minor Values are not secrets, but they can still contribute to exposure if they are used as the only filter for access, presence detection, or location-based decisions. If an application trusts those values too much, a spoofed or replayed beacon can cause incorrect proximity results or misrouted location logic.
Failure mechanism: An attacker, or even an accidental misconfiguration, can clone the visible beacon identifiers and make a receiver accept the wrong site or zone mapping, especially where the UUID, Major, and Minor values are treated as sufficient proof of location.
Impact: The result can be false presence, broken geofencing, incorrect user experience, or downstream decisions made on the wrong physical context. In environments that tie beacon signals to operational actions, that can become a business integrity issue as much as a technical one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Beacon identifiers are used within a site-specific operational context. |
| ID.AM-01 — Physical Devices and Systems Inventoried | Beacon deployments depend on knowing which devices exist and where they are assigned. | |
| PR.DS-01 — Data-at-rest is protected | Location mappings and beacon records should be protected from unauthorized alteration. | |
| Recommendation — Document how UUID, Major, and Minor mappings support each location use case. Inventory beacon devices and keep their assigned Major and Minor values current. Protect beacon configuration data from unauthorized changes and drift. | ||
Practitioner Guidance
Governance implication: Treat Major and Minor Values as part of a controlled naming scheme, not as ad hoc device labels. The mapping between numbers and physical meaning should be documented, versioned, and owned so that application logic and field deployment stay aligned.
What to watch for: Look for duplicate assignments, undocumented reuse, or assumptions that a beacon signal alone proves an exact location. Those are the situations where proximity logic becomes fragile and where troubleshooting usually starts to expose the real operational model.
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org