When Does Product Proximity Become a Permission?
See when UWB, Bluetooth or other proximity evidence can safely inform a product action, why proximity is not permission and what Digital Key proves in production.
A phone, key, tool or product can be close enough for software to measure. That does not mean the nearby person or device is allowed to do anything. The useful architecture separates authentication, ranging, context and operation-specific authorisation before an action is permitted.
Direct answer
Proximity is evidence, not permission.
A trustworthy proximity-conditioned action normally needs several separate checks. The system authenticates the credential or peer, obtains ranging evidence suited to the threat model, adds context such as side, direction or user intent where the operation needs it, then checks whether that credential is entitled to perform that specific action on that specific product. Only then does policy permit or deny the operation.
That composition is already deployed in automotive Digital Key systems. The same building blocks are available beyond cars, but the broad horizontal pattern is still composable, not an established cross-industry product standard. Being nearby by itself does not prove identity, ownership, legal authority, intent or that an action is safe.
This is the proximity-specific part of the wider ActivateLabs question: what may software do once identity, evidence and state are available?
Navigate this page
- Overview
- Direct answer
- Near is not allowed
- Digital Key is the deployed reference architecture
- FiRa makes the same separation explicit
- Aliro shows the pattern moving beyond cars
- Bluetooth Channel Sounding improves BLE ranging, not authori
- Secure ranging is a system property, not a radio-brand claim
- What proximity does not prove
- Build the policy around the operation, not around the radio
- Maturity as at 6 September 2026
- What to build, test and watch
- What would change this page
- Keep exploring
- Sources
Near is not allowed
It is easy to collapse four different questions into one:
| Question | What it establishes | What it does not establish |
|---|---|---|
| Discovery | Which product, service or endpoint is relevant | That the caller is trusted or allowed to use it |
| Authentication | That a credential, device or peer is the one the system expects | That it is physically close enough or entitled to this operation |
| Ranging | Evidence about physical distance, and sometimes direction or relative position | Ownership, authority, intent or permission |
| Authorisation | Whether this authenticated actor may perform this operation under current policy | That every other safety or state condition has been satisfied |
The distinction matters because each layer can pass while the next one should still fail. A valid credential can belong to someone who is not currently authorised. A device can be authenticated but relayed from farther away. A device can be genuinely close but on the wrong side of a door. An authorised user can be close to a machine while the machine is in a state where the requested action should not run.
Generic service discovery and action contracts belong with Product as an API Endpoint: Why Discovery Is Not Permission. The broader difference between identification, authentication and ownership belongs with The code proves the record. It does not prove the product.. This page owns the physical-ranging evidence and the policy boundary around using it.
Digital Key is the deployed reference architecture
The clearest deployed example is the Car Connectivity Consortium's Digital Key architecture.
In the current Digital Key model, a phone or other device does not simply appear near a car and gain access. The ecosystem separates credential and key validity from the secure ranging used for passive entry. Operation entitlement is checked separately, and the requested operation can depend on where the device is relative to the vehicle.
That is the important part for product architecture. The radio measurement is one input into a larger decision.
Current certified vehicles and modules, together with consumer implementations such as Samsung Digital Key, establish that this composition exists in production automotive systems. They do not establish that arbitrary products, service tools or industrial assets already use the same pattern at scale.
Automotive therefore gives us a deployed reference, not a licence to describe the whole horizontal product market as deployed.
FiRa makes the same separation explicit
FiRa's UWB access architecture is useful because it separates the layers in plain technical terms. Secure ranging can support proof of presence and, depending on the implementation, evidence of approach or position. Authentication and authorisation remain separate system functions.
That separation is stronger than treating UWB as a magic permission signal.
UWB can measure time of flight with very fine resolution, and secure-ranging designs add protections intended to make distance manipulation harder. FiRa also treats ranging security as an engineering problem with attack classes, receiver behaviour and performance trade-offs. The radio technology therefore improves the quality of the proximity evidence. It does not remove the need for a policy decision.
A useful design sequence is:
authenticated credential or peer → secure ranging evidence → context or intent where needed → entitlement and operation policy → permit or deny → audit, revoke and recover
The final decision still belongs to the application. A warehouse tool may allow a diagnostic read while denying a firmware change. A rental asset may allow unlock during an active booking but not after the booking ends. A service action may require both proximity and a technician credential. The same distance can therefore lead to different outcomes for different operations.
Aliro shows the pattern moving beyond cars
The Connectivity Standards Alliance released Aliro 1.0 in February 2026 for digital access credentials across home and commercial access. It supports NFC, Bluetooth Low Energy and hands-free BLE plus UWB paths.
There is already early product evidence. The CSA lists certified Aliro products including the Last Lock C100 and Aqara Smart Lock U400. Schlage's current Sense Pro material also shows why distance alone is often not enough: its UWB implementation combines distance with direction and approach intent before hands-free unlocking.
That evidence matters, but the maturity boundary is equally important. A released standard and early certified products establish a real ecosystem. They do not yet establish broad multi-vendor prevalence across homes, offices, hotels, campuses and general product-service interactions.
So the non-automotive direction is emerging. The horizontal architecture is credible and composable, but the market evidence is not yet comparable with automotive Digital Key.
Bluetooth Channel Sounding improves BLE ranging, not authorisation
Older BLE proximity systems often inferred nearness from received signal strength, connection behaviour or timing. That can be useful for rough presence, but it is a weak basis for a security-critical distance claim. NCC Group demonstrated practical relay attacks against BLE proximity authentication systems built on those older mechanisms.
Bluetooth Channel Sounding changes the technical options. Introduced in Bluetooth Core 6.0 and still part of the current Core 6.3 specification at the 6 September 2026 cut-off, Channel Sounding adds fine-ranging methods based on phase measurements and round-trip timing.
That is strong evidence that Channel Sounding is a real current component capability.
It is not evidence that a Bluetooth distance result should directly unlock, start, pay, configure or approve. Channel Sounding still needs the application to decide what distance threshold matters, what credential is being used, whether that credential is entitled to the requested operation and what happens when the measurement is uncertain or unavailable.
Broad end-use deployment of Channel Sounding for secure access is still emerging compared with UWB Digital Key.
Secure ranging is a system property, not a radio-brand claim
No current evidence supports saying UWB or Bluetooth Channel Sounding is attack-proof.
Three boundaries matter.
Relay and distance manipulation still belong in the threat model
A relay attack tries to make a remote credential appear locally usable. Older BLE proximity approaches show why connectivity, encryption and rough signal strength are not enough by themselves for security-critical presence.
UWB secure ranging was designed to make this class of attack harder, but research such as Ghost Peak has demonstrated practical distance-reduction attacks against particular HRP UWB implementations. Other work shows that appropriate secure timestamp sequences and receiver design can improve resistance. The fair conclusion is not that UWB is broken or invulnerable. It is that implementation and configuration matter.
Application policy can fail even when ranging works
A sound distance measurement cannot fix weak credential lifecycle, poor revocation, unsafe fallback behaviour or an application that grants too much authority to one signal.
Fallback paths deserve the same scrutiny as the primary radio. If the system falls back from secure ranging to a weaker proximity mechanism, the policy must say which operations remain allowed. Recovery, delegation and revocation also need explicit rules. Otherwise the strongest ranging mode can be bypassed by the least controlled path.
Context can matter as much as distance
For some actions, “within one metre” is not enough context. The system may need to know whether the credential is inside or outside, approaching or moving away, associated with the intended user, or being presented during an explicit interaction.
Direction and intent logic can reduce accidental actions. They do not prove legal authority. They are additional evidence inputs into the policy decision.
What proximity does not prove
A reliable range estimate can support a statement such as “the authenticated device appears to be within the policy's allowed range, with the stated confidence and context”. It should not silently become a stronger claim.
Proximity does not, by itself, prove:
- who owns the product;
- who owns or controls the nearby phone or credential at that moment;
- that the person has legal authority to act;
- that the credential has not been revoked or delegated beyond its intended scope;
- that the person intends the action;
- that the product is authentic simply because an expected device is nearby;
- that the requested operation is safe in the product's current state.
Cryptographic credentials can strengthen the identity and provenance side of the decision, but a valid credential still does not make every claim inside it true. That boundary is covered in What Does a Verifiable Credential Actually Prove?.
The practical rule is simple: record what each layer actually established. Do not let a green proximity result stand in for authentication, entitlement or safety.
Build the policy around the operation, not around the radio
A business considering proximity-conditioned action should start with the action it wants to control.
For each operation, define:
- Who or what must authenticate? A user credential, service tool, device key, organisational credential or combination.
- What proximity evidence is proportionate? Rough presence may be enough for low-consequence discovery. Unlocking, starting or changing configuration may justify secure ranging.
- What context matters? Side of a boundary, approach direction, explicit user gesture, product state or an active service session.
- What entitlement is required? Ownership, booking, subscription, technician role, delegated authority or another operation-specific grant.
- What must still block the action? Revocation, expired entitlement, unsafe state, inconsistent evidence or an uncertain range result.
- What is the fallback? The alternative path should have its own allowed operations rather than quietly inheriting the strongest permissions.
- What gets recorded? The system should be able to explain which credential, ranging result, policy and product state led to the decision.
This is where proximity becomes useful. It is not a universal permission bit. It is a bounded piece of evidence that can make an already authenticated and governed action safer or more convenient.
The neighbouring scanless observation question is broader: how automatic observations become governed events at all. Proximity is one observation mode inside that layer. Likewise, a product-history anomaly can inform risk policy, but an anomaly is not permission or proof on its own.
Maturity as at 6 September 2026
| Capability or composition | Maturity | What the evidence supports |
|---|---|---|
| CCC Digital Key credential + ranging + operation entitlement | DEPLOYED | Certified automotive products and current consumer implementations show the composed system in production |
| UWB secure ranging as a component | DEPLOYED | Standards, certified components and production access systems exist |
| FiRa access architecture | COMPOSABLE | It explicitly separates presence/ranging, authentication and authorisation, while enterprise policy remains implementation-specific |
| Aliro 1.0 standard | DEPLOYED as a released standard | The standard is released and certified end products exist |
| Broader non-automotive Aliro ecosystem | EMERGING | Early certified locks exist, but broad prevalence is not established |
| Bluetooth Channel Sounding specification | DEPLOYED as a component capability | Channel Sounding is part of the current Bluetooth Core 6.3 specification |
| Broad Channel Sounding secure-access deployment | EMERGING | The capability is current, but broad end-use secure-access deployment is not established |
| Generic product proximity-conditioned action | COMPOSABLE | The components and bounded reference systems fit together, but cross-industry deployment is limited |
| Proximity alone as identity, ownership or permission | NOT_SUPPORTED | Deployed architectures consistently add credentials, policy and context rather than treating nearness as sufficient |
The key maturity mistake would be to promote a deployed component into a deployed horizontal system.
What to build, test and watch
If the action has material consequences, test the complete decision path rather than the headline radio range.
Build the entitlement and revocation model before tuning the distance threshold. Test relay and distance-manipulation assumptions against the actual hardware and configuration. Test inside/outside and approach cases where direction matters. Deliberately remove the preferred ranging path and see what the fallback allows. Test expired, revoked and delegated credentials. Record enough evidence to explain why an action was permitted or denied.
For products where the action is low consequence, the answer may be simpler. A rough proximity signal can be useful for discovery or user-interface convenience when a mistaken reading does not create a meaningful security or safety problem. The assurance level should follow the consequence of getting the decision wrong.
What would change this page
The horizontal maturity rating would change if repeated multi-vendor deployments showed the same proximity-conditioned action pattern across non-automotive product categories, not just access-control examples.
The security assessment should be revisited when Bluetooth or UWB specifications materially change secure-ranging protections, when new practical relay or distance-reduction research changes the threat model, or when certification profiles begin testing more of the end-to-end authorisation composition rather than only the radio layer.
The central principle is unlikely to change: better ranging can strengthen evidence of physical proximity, but permission remains an operation-specific policy decision.
Keep exploring
The questions this page usually raises next.
- Another angleNext questionDoes a Product Passport Prove a Product Is Genuine?A passport proves a record exists and is reachable. It does not bind that record to a physical object and it does not record who…
- What to do nextNext questionProduct as an API Endpoint: Why Discovery Is Not PermissionProduct identity can make a service discoverable. It cannot make the call authorised.
Sources
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.