BCS Beam · Self-Hosted · Private Deployment
Remote support, on infrastructure you control
BCS Beam is the remote support platform Brocent builds and operates itself — one unified device registry, two connection engines split by scenario: everyday assistance runs on in-person consent, unattended access runs on strong identity verification. Built to replace traditional subscription remote-support SaaS with a stack customers can audit, self-host, and license per seat instead of per subscription.
TL;DR: BCS Beam is Brocent's own remote support platform, delivered with Brocent Managed IT — session data never leaves the region the customer designates. This page walks through the full capability set: the dual-engine architecture (in-person consent vs. strong-identity unattended), four independent authorization channels, device binding plus a per-connection one-time code, policy-driven session recording and audit trails, a three-region self-hosted relay network, UI previews, and the complete lifecycle of both connection types.
156
Endpoints running the resident agent
4
Unattended authorization channels
3
Self-hosted relay regions (HK/SG/CN)
100%
Connections need consent or a per-session code
Why not a traditional subscription remote-support SaaS
Structural differences, not a feature-list difference
Matching features line by line is only the starting point. The real differences are: who owns the relay infrastructure, who can read session data, and what the cost model of every single connection looks like.
Data sovereignty
Self-hosted relays — no third-party servers in the path
Identity model
Zero trust: device binding + a per-connection one-time code
Pricing model
Licensed per seat — no year-on-year subscription creep
Internal-system integration
Direct links to tickets / contracts / customer master data
Brand & presentation
Fully white-labeled — customers only ever see their own brand
Overall architecture
One device registry, two connection engines split by scenario
This is not two unrelated tools glued together — every endpoint shares a single device identity across both engines from first install, and the system decides which authorization logic applies based on whether the device owner is present.
Daily Assist Engine
Scenario: routine support with the owner present
The resident agent deploys silently at install; the support team connects straight from the browser to view and operate — built for always-reachable, fleet-visible daily operations. Before control is established, the endpoint itself must show a confirmation prompt that the user explicitly allows.
- · Direct browser connection — no dedicated client needed
- · Concurrent multi-viewer sessions with handover
- · Auto-grouped by customer, live device-tree status
- · One-time share links for account-free ad-hoc collaboration
Strong-Identity Unattended Engine
Scenario: owner absent / high-compliance access
Built for support that must work with nobody at the keyboard — after a one-time hardware binding, every single connection still requires its own one-time dynamic code and must clear one of four authorization channels.
- · Four independent authorization channels, from approval flows to admin direct-connect
- · Policy-matched sessions are force-recorded; playback goes through a separately authenticated proxy
- · Access windows + IP allow-lists — out-of-window connections are refused outright
- · View-only observer mode that disables all control capabilities
Core capabilities
More than screen sharing — every connection is decided, filtered, and logged
Each capability below is tagged with the engine it belongs to:
Strong-Identity Engine Daily Assist Engine Shared by bothDevice trusteeship
Personal and company-asset devices get a one-time, hardware-level binding for unattended access — yet every connection still requires a per-session code.
Four independent authorization channels
Engineer request-and-approve, email fallback verification, admin direct-connect, and view-only mode — none substitutes for another; each covers a different real-world scenario.
In-person user consent
Daily assistance assumes someone is present: the endpoint shows a confirmation prompt before control is established, and a refusal terminates the connection immediately.
Forced session recording
Sessions matching a customer's compliance policy are force-recorded and stream-archived, auto-purged at retention expiry, with playback through a separately authenticated proxy.
Server-side session recording
Daily-assist sessions can also be recorded server-side on demand — independent of whether the engineer's own machine has recording on.
Access windows & IP policy
Connection windows set per customer time zone plus IP allow-lists — out-of-window attempts are refused before a session ever forms.
View-only / observer mode
Blocks keyboard, mouse, clipboard, file transfer, audio capture, and remote reboot — while the target machine shows a system notification.
Grouping by customer
Devices are grouped automatically on enrollment — support sees a structured customer → device hierarchy, not a flat list.
Cross-engine device recognition
The paired strong-identity client ID on the same endpoint is auto-detected, so raising a high-compliance session never involves copying IDs by hand.
Multi-viewer / session handover
Multiple engineers can view and collaborate on the same target device concurrently, with control handover that never drops the connection.
Install-free ad-hoc support
An install-free applet for one-off support scenarios — the backend never touches the real connection secret.
Offboarding review queue
Devices are never silently purged when a contract ends — they enter a human review queue, and agent removal only executes after confirmation.
Seat license management
Seats allocated per device, per user, or by concurrency — usage computed in real time, exportable to CSV.
Identity & unattended access
First question: who is present? Two completely different verification paths
Unattended does not mean weakly verified — device binding answers "is this an authorized machine", and the per-connection dynamic code answers "is this specific connection an authorized person". When someone is present, the verifying party simply becomes the end user themselves.
Daily assistance: the end user decides, in person
Denial means termination — no gray zone
- ✓ There is no “connect first, ask later” intermediate state
- ✓ With nobody present, the flow switches to the Strong-Identity Engine — it never bypasses on-device consent
- ✓ Every Allow / Deny choice is itself written to the operations log
Strong-identity unattended: four channels for four real-world scenarios
Channel 01
Engineer request & approval
With the owner away, the engineer files an access request; the system emails the device's registered contact, who can approve via link or release the session with a 6-digit confirmation code.
Channel 02
Email fallback verification
When a staff member's phone authenticator is unavailable, the system issues a one-time email code as the substitute credential.
Channel 03
Admin direct-connect
A customer-portal administrator may connect without user confirmation only where the contract explicitly authorizes it — gated by admin role + MFA + a per-session code, with two-way notification afterwards.
Channel 04
View-only observer
Once the session is up, keyboard / clipboard / files / audio / remote reboot are all force-disabled, and the target machine shows a system-level notification.
Recording & audit compliance
Recording is the outcome of a policy match — not a switch anyone can flip off
Each engine's recording mechanism writes into the same traceable session record — the customer receives one coherent audit thread, not two logs that don't reconcile.
Forced recording (Strong-Identity Engine)
Policy-matched sessions are stream-recorded end to end into object storage — no reliance on local files, and the initiating party cannot switch it off mid-session.
Server-side recording (Daily Assist Engine)
Recording happens on the server, independent of the engineer's machine — no “forgot to record” and no “turned it off halfway”.
Retention with auto-purge
Recordings and logs are purged automatically on the retention schedule agreed with each customer — audit-ready without unbounded archives.
Separately authenticated playback
Playback goes through its own proxy and permission check — viewing a recording is itself a logged access event.
Operation event log
Connect, disconnect, consent / denial, file transfer, and other key events carry their own timestamps, searchable independently of the recording.
Genuine connection evidence
Every connection's start/end time, duration, verification method, and view-only status are recorded — not weak evidence like “a link was sent once”.
Global relay network
Three self-hosted relay regions — connections never touch third-party servers
The relay keys are held and signed by Brocent itself — this is not a public relay. Screen content and file transfers from both engines only ever traverse infrastructure the customer has approved.
Why not a public relay
Whose servers your screen content and files pass through decides who holds data sovereignty. Running our own relay services means:
- · Relay keys are self-held — no third-party server can decrypt any relayed content
- · Online-presence state uses shared multi-node storage, so multiple nodes are genuinely live at once
- · A self-hosted update-check service — client updates never depend on a third-party distribution channel
Device grouping & operations
Organized by customer — not one flat device list
Devices joining the Daily Assist Engine are grouped under their customer immediately; a contract ending never silently purges devices — they enter a human review queue, and agent removal only executes after confirmation, so in-use devices are never deleted by mistake.
Device groups (sample data)
UI preview
One brand and visual language, from client to admin console
The mockups below use sample data to illustrate the information structure the product presents — they are not screenshots of a real customer environment.
This device ID
823 456 719
One-time password ready — awaiting remote connection request
Support engineer L. Wei requests to view and control this device's screen for ticket #TCK-58231. Allow?
Seat license allocation
+ New allocationThe full lifecycle of both connection types
From request to archived audit trail
The steps below cycle in real processing order (an animated illustration in place of a screen recording).
Daily Assist Engine Routine support with the owner present
01
Select device
Pick an online endpoint under its customer group
02
Initiate
Engineer clicks Connect to raise the request
03
Endpoint prompt
The device shows an Allow / Deny confirmation
04
User consents
Clicking Allow releases remote control
05
Session runs
Screen control, file transfer, recording where required
06
Disconnect & archive
Connection ends; the event log is written to the trail
Strong-Identity Engine Unattended / high-compliance access
01
Raise request
Engineer initiates the remote request from a ticket
02
Verify identity
Obtain the per-session code / email fallback code
03
Authorize
Access window + IP allow-list + channel permission checks
04
Connect
Session established via the self-hosted relay nodes
05
Policy applies
A recording-policy match starts streaming capture
06
Close & archive
Audit trail written; recording stored until retention expiry
Put remote support on infrastructure you can audit
BCS Beam is delivered with Brocent Managed IT — endpoint rollout, authorization policy, and recording retention are all configured to your compliance requirements. Contact us for a demo or a scoping conversation.
All interfaces and data on this page are illustrative, anonymized samples — no real customer information is shown.