Security model
Security starts with a precise claim about what the signal proves.
NearID is designed to make large-scale forgery, stale replay, and untrusted receiver submissions harder. It does not claim perfect resistance to every radio relay, compromised device, or operational mistake.
Core controls
Token privacy
No stable identity in BLE broadcasts.
Anti-replay
Short time windows and duplicate checks.
Receiver trust
Provisioned credentials and authenticated reports.
Access control
Roles and scoped operational capabilities.
Defence layers
Rotating BLE tokens
Short-lived payloads reduce the value of captured broadcasts and avoid transmitting a stable user identity.
Linked-device validation
Backend validation binds accepted token material to device-linking and organization context.
Receiver authentication
A receiver needs valid organization, receiver, and secret context to submit accepted reports.
Timing and replay checks
Strict token windows, bounded clock drift, and duplicate suppression constrain captured-token reuse.
Scoped staff access
Capabilities, session controls, and approval workflows restrict sensitive platform operations.
Operational records
Presence, configuration, receiver, and staff activity can be reviewed during support or investigation.
Threat boundaries
What NearID is designed to resist.
Passive BLE sniffing
Broadcasts do not expose a stable user identity or reusable long-lived credential.
Stale replay
Captured payloads are constrained by short time windows and replay rules.
Arbitrary receiver submissions
Unprovisioned scanners lack the receiver credentials expected by the backend.
Known limitations
What no passive BLE system should promise.
Perfect relay resistance
Sophisticated real-time RF relay or wormhole attacks cannot be fully eliminated.
Exact distance
BLE signal strength is environmental evidence, not centimetre-accurate ranging.
Identity or legal truth
Identity binding, legal admissibility, and final business decisions require separate controls.