1. Overview & System Purpose #

The BEX Multi-Device Concurrency Protocol ensures that users can seamlessly operate their subscription across multiple personal devices (such as smartphones, laptops, and tablets) while maintaining account security and enforcing plan seat limits. Rather than relying on simple IP tracking or session counting, BEX utilizes cryptographic Hardware Identifiers (HWIDs) to accurately verify concurrent device slots during the initial handshake phase.

2. Hardware ID (HWID) Generation & Fingerprinting #

To identify authorized devices without collecting personally identifiable information (PII), the BEX client generates a unique, one-way cryptographic hash during installation:

• Anonymized Hardware Hash: The client engine hashes non-sensitive local system parameters (such as OS build identifiers and CPU architecture tokens) into a fixed 256-bit Hardware ID string.
• Privacy-Preserving Architecture: Hardware IDs cannot be reversed to discover individual system specifications or user personal data.
• Device Seat Registry: The control plane maps active HWID hashes directly to the primary user account vault.

3. Concurrent Handshake & Seat Verification Workflow #

When a client device initiates a VPN tunnel, the control plane executes a multi-step authorization process:

1. Handshake Initiation: The client sends an encrypted authentication request containing the account session token and the local Hardware ID hash.
2. Subscription Verification: The control plane verifies that the subscription is in an Active or Grace state and retrieves the maximum allowed concurrent device limit (e.g., 5 concurrent seats).
3. Hardware Registry Lookup: The system checks the active session registry against the provided Hardware ID:
   • Existing Registered Device: If the HWID is already active within an open seat slot, tunnel access is granted immediately.
   • New Device within Seat Limit: If the HWID is new but total active hardware seats are less than the plan limit, the new HWID is bound to an open seat and connection is granted.
   • Seat Limit Reached: If total active hardware seats equal the plan limit, connection is denied with a MAX_CONCURRENT_DEVICES_EXCEEDED error response.
4. Active Session Heartbeat: Connected nodes send lightweight keep-alive signals every 60 seconds to maintain active seat reservation in the registry.

4. Device Unbinding & Administrative Controls #

• No Automatic Eviction Policy: User devices are never automatically deleted or displaced upon connecting a new device.
• Manual Device Management: Users retain full administrative control to manually review bound hardware seats and remote-terminate active sessions directly from the BEX account dashboard.
• Manual Key Revocation Protocol: When a user explicitly revokes a device from the control plane dashboard, its active encryption keys across all edge gateways/nodes are immediately invalidated, instantly dropping the session.
• Inactive Seat Reclamation: If a device remains completely offline for more than 72 hours, its reserved concurrent seat slot is automatically recycled back into the available pool, without deleting the user’s saved device record.

5. Key Strategic Benefits #

• Cross-Platform Convenience: Seamless transition between desktop and mobile environments under a single plan.
• Account Credential Protection: Prevents unauthorized credential sharing while permitting legitimate multi-device usage.
• Granular Session Visibility: Clear administrative oversight over active connections with instant user-initiated remote unbind capabilities.