Enterprise security. Built for what’s next.
Antara Secure Access / Bluetooth proximity access

Bluetooth proximity network access. Presence becomes policy.

A signature capability of the Antara enterprise client: use a registered Bluetooth companion as a continuous condition for access to corporate resources.

Technical edition · Updated 7 September 2026 · 3 min read

Keep access connected to the person using it

A login establishes identity at one moment. Work continues long after that moment, including when someone leaves a laptop at a shared desk. Antara brings Bluetooth proximity into the client’s access context so a registered companion can help determine whether a protected session should remain available.

This is network access control inside the enterprise client. A proximity condition works alongside identity, device posture, and application entitlement. A nearby phone does not grant access on its own, and proximity does not replace post-quantum tunnel protection.

From presence to protected access
  1. 01Register

    Associate the approved companion with the user and managed client.

  2. 02Evaluate

    Combine companion presence with identity and device health.

  3. 03Enforce

    Keep access within the application’s active policy.

  4. 04Reassess

    Restrict access or require verification when presence changes.

What happens when someone steps away?

The client supplies proximity context to the access decision. When the companion becomes unavailable or moves outside the configured condition, sensitive work should follow the organization’s restriction or re-verification policy. When the user returns, identity and device checks still apply before work resumes.

Proximity as part of the access lifecycle
CompanionAntara clientAccess policyCorporate app1. Registered companionpresent2. Identity, posture, andproximity context3. Authorize the permittedresource scope4. Access through the protected connection5. Companion no longersatisfies presence policy6. Restrict scope or requirere-verification
Read the sequence as text
  1. CompanionAntara client: Registered companion present
  2. Antara clientAccess policy: Identity, posture, and proximity context
  3. Access policyAntara client: Authorize the permitted resource scope
  4. Antara clientCorporate app: Access through the protected connection
  5. Antara clientAccess policy: Companion no longer satisfies presence policy
  6. Access policyAntara client: Restrict scope or require re-verification

The Live Lab lets you vary the companion signal, enrollment, and identity state. It illustrates the policy decision; it does not turn the visitor’s browser into a Bluetooth scanner.

Fit proximity into the network you already operate

  • Start with a managed client pilot and a defined companion enrollment process.
  • Retain your identity provider, MFA policy, private application connectors, and device management.
  • Choose the applications where presence should be an additional access condition, such as administration consoles and sensitive internal tools.
  • Define the response to absence, the recovery process, and approved accessibility or operational exceptions.
  • Validate operating-system permissions, Bluetooth availability, device sleep behavior, and endpoint security compatibility before expanding the rollout.
SituationAccess policy consideration
Companion present; identity and device compliantAllow only the applications the user is entitled to access.
Companion absent or Bluetooth disabledApply the absence policy and present a clear recovery path.
Nearby but unregistered deviceDo not treat it as an approved companion.
User returns after access restrictionRe-evaluate the full policy before restoring access.
Lost or replaced companionRevoke the old association and enroll the replacement.

Measure the complete walk-away and return experience

Bluetooth signal strength is affected by walls, bodies, interference, and hardware. Treat it as a proximity signal, not an exact distance measurement or independent proof of identity. Evaluate how the deployment handles signal loss, spoofing and relay attempts, and stale companion state.

  • Record the interval from a presence change to the enforced access decision.
  • Test shared desks, adjacent rooms, sleep and wake, radio interference, and low battery.
  • Verify that compromised devices and revoked identities cannot regain access just by bringing a companion nearby.
  • Review the decision reason with support staff so users can recover without weakening policy.
  • Confirm which applications and existing connections are restricted in your deployment, rather than assuming all protocols behave identically.

For teams adopting zero trust alongside an existing VPN estate, this adds another useful condition to a familiar client workflow: who is requesting access, whether the device is healthy, and whether the registered companion is still present.