Remote IT Support Without Losing Control: A Hong Kong Wealth Manager's Story

In short: Remote IT support is normal. Remote IT support that nobody can account for afterwards is a problem — especially for a licensed Hong Kong firm. The fix is not trusting your vendor more; it is making every remote session an event with a record: consented before it starts, visible while it runs, logged afterwards, and revocable on demand.

Why does remote IT support make a Hong Kong financial firm nervous?

Almost every small financial services firm in Hong Kong runs on remote IT support, whether or not anyone has ever called it that. A trade will not book because a market data terminal has lost its licence file. An analyst's laptop refuses to open the shared drive an hour before a client meeting. Someone in operations calls the IT vendor, the vendor asks them to click "allow" on something, and ten minutes later it works again. That loop repeats a few times a week and, for the most part, it works.

What makes it uncomfortable in a licensed firm is not the loop itself. It is the question that eventually gets asked about it. A boutique asset manager, a family office, an SFC-licensed advisory business — these are organisations where a small number of people handle client identity documents, portfolio positions, subscription and redemption instructions, and bank details. Access to a workstation is access to all of that. And in a firm of thirty to sixty people, the workstation is often where the sensitive material actually lives, not in some hardened system somebody designed on purpose.

So sooner or later, someone whose job is to ask uncomfortable questions asks one: who has been connecting to our machines, how often, and what were they doing? In our experience the firm's honest answer is usually some version of "our IT company, when we ask them to." That answer is true. It is also completely unverifiable, and unverifiable is the specific thing that causes trouble in a regulated environment. Nobody is accusing the vendor of anything. The problem is that the firm has no way to demonstrate that nothing happened, which is a different and harder thing than nothing having happened.

Brocent has run managed IT for financial services clients in Hong Kong since we opened the office here in 2016, and this pattern is consistent across firm sizes. The larger the firm, the earlier the question gets asked — but it always gets asked. Usually by a compliance officer, sometimes by an external auditor, occasionally by a prospective institutional investor doing operational due diligence before allocating capital.

The blocked ticket: a composite scenario

Here is a scenario we have seen versions of many times. The details below are illustrative — a composite drawn from how firms of this size and type actually operate, not one named client.

A Hong Kong wealth manager, about forty-five people across an office in Central and a small back-office floor, licensed and audited annually. Two of those people are the operations team, and one of them handles what everybody calls "IT" — meaning she is the person who calls the IT vendor. The vendor is competent, has supported the firm for six years, and knows the environment well. When something breaks, someone messages the vendor's group chat, an engineer picks it up, connects, and fixes it. Nobody has ever had a bad experience.

Then the firm's compliance officer, preparing for the annual internal control review, blocks a routine ticket. Not because he suspects anything. Because the review asks him to describe the firm's controls over third-party access to systems holding client data, and when he sat down to write that description he realised he could not. He could not say how many remote sessions had occurred in the previous quarter. He could not say which engineers had connected. He could not say whether any of those sessions touched a machine that held client onboarding documents. He asked the vendor for a log and received a helpful, good-faith email that said, in effect: we connect when you ask us to.

That is the moment the firm stops treating remote support as a utility and starts treating it as a control. And it is a genuinely awkward moment, because the vendor has done nothing wrong. The firm is not looking for a new supplier. It is looking for evidence, and the tool the supplier uses was never designed to produce any.

What "we have always just let them remote in" actually costs

The costs are not dramatic. They are the slow kind, and they surface at inconvenient moments.

There is no answer to the retrospective question. "Did anyone external access the machine holding client KYC files last quarter?" is a question with only two acceptable answers: a documented no, or a documented yes with detail. "Probably not" is not one of them. Once a firm realises it can only offer the third answer, the gap tends to move quickly up the priority list — because the same question will be asked again next year, and by then it will be a repeat finding rather than a new one.

The relationship is built on trust rather than evidence, and trust does not transfer. The current engineers are known and liked. But engineers change jobs. Vendors hire. The person who connected last Tuesday may be someone the firm has never met, and there is no mechanism that would tell them either way. What the firm actually relies on is the vendor's internal hiring and supervision, which is invisible to them and which they have never assessed.

The annual review has nothing to point at. Control descriptions in a review document need artifacts — a policy, a log, a report, a screenshot of a setting. "We use a reputable IT vendor" is a statement about intent. Reviewers want something they can attach to the file.

Staff start quietly opting out. This one surprises people. In several firms we have worked with, the first sign of a problem was not a compliance finding but a behavioural one: someone in the front office had begun declining remote sessions, preferring to wait for an on-site visit or to work around the issue themselves, because they were uneasy about someone watching their screen while client positions were open on it. That instinct is completely reasonable. It is also expensive — it turns a ten-minute fix into a half-day of degraded work, and it means the firm's IT problems stop being reported accurately.

Offboarding is undefined. When a service agreement ends, what happens to the access? In an ad-hoc arrangement, usually nothing formal. The tool is uninstalled from machines somebody remembers, the account stays valid, and nobody writes anything down. Firms discover this when they change vendors and realise they cannot confirm the previous one no longer has a path in.

None of these is a breach. All of them are the absence of a record, which is the thing that turns an ordinary operational practice into an audit finding.

Our view: the fix is not "trust your vendor more"

When firms raise this with us, the instinctive first response — theirs, not ours — is to look for a more trustworthy vendor, or to restrict remote support altogether and demand on-site attendance. Neither works. On-site-only support is slower and more expensive and does not actually produce a record; an engineer sitting at the desk is no more logged than one connecting from Kwun Tong. And "more trustworthy" is not a property you can verify from the outside.

The useful reframe is this: remote access should be an event, not a state. Right now, in most small firms, vendor access is a state. It exists in the background, permanently, and is exercised invisibly. What should exist instead is a series of discrete events, each of which is named in advance, visible while it happens, written down afterwards, and capable of being switched off.

That is a design problem, not a trust problem — and it is solvable with the right tooling. Four properties are what matter.

The four properties that make remote access accountable

• Consented — A session on a staff device should not begin silently. The person at the keyboard should see who is asking to connect, by name, and should be the one who allows it.
• Visible — While a session is running, it should be obvious. Not buried in a settings panel; obvious, on screen, for the duration.
• Logged — Every connection should write a record at the moment it starts: who connected, to which device, when, in what mode, and against which support request. The log should be exportable by the customer, not merely viewable by the vendor.
• Revocable — The customer should be able to end the vendor's access, for one device or the whole fleet, by asking — and should get confirmation that it was done. When the relationship ends, offboarding should be automatic and reviewed by a person, not dependent on someone remembering.

This is also why we draw a hard line between the two things a support agent can do. Watching a machine's security health and taking action on a machine are different activities with different risk profiles, and they should not share a permission model. Continuous monitoring should be read-only by construction — it reports what it sees and cannot execute anything. Hands-on work should happen only through the consented, visible, logged channel described above. Collapsing the two into one agent that can do everything all the time is convenient for the vendor and bad for the customer.

What consent-first, visible and revocable looks like on screen

We built these properties into BCS Beam, the endpoint client that Brocent's managed IT customers run, precisely because the alternative — a generic remote-control tool with an invisible permission surface — kept failing this test in client conversations. Concretely, on a device running it:

A consent prompt names the engineer before a screen session starts. On consent-enabled devices, no screen session begins until the person at the keyboard approves it, and the prompt says who is asking. This is the control that most directly answers the "someone could be watching me" worry, because the answer becomes: not without you clicking yes.

An on-screen banner stays up for the whole session. Not a notification that disappears after five seconds. A persistent indicator, for the duration.

A tray icon shows session status in real time. The Beam tray assistant displays how many remote sessions are active and which account is connected. This turns "they can access my computer" from an invisible background fact into something any user can check in one glance, at any time, without asking anyone.

Every connection is written to an audit ledger the moment it starts. Who connected, to which device, when, in what mode, and against which support ticket. Invitations that were issued but never used are recorded too, which matters — an unused invitation is still an access grant. Your account manager can export the full history to a spreadsheet on request. Sessions may also be recorded for quality and audit purposes, and recordings are encrypted before they are archived.

The infrastructure is Brocent's own, in Hong Kong. The remote-support server, the audit platform and the session records all run on our servers here. There is no third-party remote-control cloud sitting between your devices and our engineers, which means one data-handling policy and one audit trail rather than a chain of vendors each with their own.

Each customer's devices are isolated. Your fleet sits in its own environment with its own enrollment identity, and engineer access is enforced server-side. Ask us to revoke access for a device or for everything, and it is done. When an agreement ends, offboarding is triggered automatically and confirmed by an engineer.

The security-audit half never touches anything. It is read-only by design. It reads device facts — disk encryption, antivirus and firewall state, system-update status, installed software names and versions — and checks them against CIS-aligned benchmarks, matching installed software daily against the global CVE catalogue and prioritising findings by real-world exploit risk using CVSS, EPSS and the CISA KEV list. It flags unauthorised remote-access tools, file-sharing clients and end-of-life software. It produces a per-device risk score in a report your management can read. It cannot execute anything on the machine, and it never captures file contents, keystrokes or screens.

There is one more detail worth naming, because it is the part people forget until they need it: the installer itself. Each customer's package is built individually, digitally signed, and delivered through a managed deployment channel rather than a public download link. Agent traffic is outbound over TLS only, so there are no inbound ports to open and no firewall exceptions to justify to whoever reviews your network configuration.

For the wealth manager in the scenario, this changes the compliance officer's problem from an unanswerable question into a document request. He asks for the connection ledger for the quarter. He gets a spreadsheet listing every session with engineer, device, timestamp, mode and ticket reference. That spreadsheet is the artifact his review needed, and producing it takes one email.

Ad-hoc access vs a generic remote tool vs an audited support channel

These three are often treated as the same thing. They are not, and the difference only becomes visible when someone asks for evidence.

How the three models compare

• Ad-hoc vendor access ("call them, they connect") — Fastest to set up and genuinely effective at fixing problems. But there is no consent record, no session log, no way to enumerate who has access, and no defined offboarding. The firm's control is the vendor's goodwill. Fine until someone asks for evidence; then there is nothing to produce.
• A generic remote-support tool (screen share, consumer or SMB grade) — Better: sessions usually require the user to share a code, so there is at least a moment of consent. But the audit trail, where one exists, lives in the vendor's account and is not designed to be handed to the customer. Access is typically account-based rather than fleet-scoped, so "who can reach our machines" is not a question the customer can answer independently. Session data often traverses a third-party cloud, adding a party to your data-handling chain that never appears in your vendor register.
• An audited support channel (what BCS Beam is built to be) — Consent prompt naming the engineer, persistent on-screen banner, live tray-icon status, a ledger entry written at session start, customer-exportable history, per-customer isolated tenancy, revoke on request, automatic reviewed offboarding, and a strictly read-only monitoring half that cannot act. Slower to set up, because it requires a real onboarding. Produces evidence as a by-product of normal operation, which is the entire point.

The honest trade-off is that the third model costs more to run than the first. Someone has to build and operate the audit platform, prepare a signed per-customer installer, and staff the offboarding review. If your firm genuinely has no external obligation to demonstrate control over third-party access, the first model is not irrational. Most licensed Hong Kong firms do have that obligation, and discover it at review time.

Where this fits in a managed IT relationship

Auditable remote access is not a product you buy on its own; it is a property of how your IT is run. It sits inside a managed IT service alongside the things that make it useful — a helpdesk with actual response commitments, patching, backup, and the endpoint security work that the read-only audit half feeds into. On its own, a well-kept connection ledger tells you that nothing went wrong. Combined with managed IT security services, it becomes part of a posture you can describe to a reviewer in a paragraph, with artifacts attached.

For firms sizing this up, our per-market service plans and what is included at each tier are set out on our pricing page. BCS Beam is included in Brocent's managed IT plans rather than sold separately, because an audit trail that only some of your devices produce is not an audit trail.

Brocent has operated in Asia since 2007, with our Hong Kong office since 2016 and our headquarters in Singapore since 2021. Financial services firms have been a core part of that work throughout, which is why this particular problem — support that has to be fast and accountable at the same time — is one we have thought about carefully rather than one we discovered recently.

Frequently asked questions

What can an IT vendor actually see when they remote into our systems?

During a screen session, an engineer sees your screen as you see it, which is exactly why the session should be consented and visible. Outside of a session, it depends entirely on what else the vendor's agent is permitted to do. In BCS Beam's case the answer is deliberately narrow: the monitoring half reads device facts only — security settings, installed software names and versions, update status — and never file contents, keystrokes or screen images. If a vendor cannot give you a crisp answer to this question, that is itself the answer.

How do we prove to an auditor that remote access was appropriate?

With a ledger, not a policy. A policy states what should happen; a ledger shows what did. What a reviewer typically wants is a list of sessions for the period covering who connected, to which device, when, and why — with the "why" linked to a support ticket so the business reason is traceable. If your current arrangement cannot produce that list, that is the gap to close, regardless of which vendor you use.

What is the difference between remote support and continuous monitoring?

Remote support is episodic and interactive: a human connects to fix something, with your consent, and disconnects. Continuous monitoring is passive and constant: an agent reports the device's security state on a schedule and takes no action. Conflating them is common and unhelpful, because they warrant different controls. Monitoring should be read-only and needs no consent prompt, since it cannot do anything. Support can change your machine, so it should require one every time.

Can we revoke a vendor's access immediately if we need to?

You should be able to, and you should test it rather than assume it. With BCS Beam, access revocation — for a single device or the entire fleet — is a request to your account manager that is executed and confirmed, and new-device enrollment is revoked at the same time. When an agreement ends, offboarding is triggered automatically and reviewed by an engineer rather than left to memory. Ask any prospective vendor how revocation works and how long it takes; the quality of the answer is diagnostic.

Does this replace our existing antivirus or EDR?

No, and you should be suspicious of anything claiming it does. The audit half verifies that your protections are actually installed, enabled and healthy, watches for vulnerabilities in software those tools do not cover, and puts the evidence in one report. It coexists with your existing security stack rather than displacing it. Think of it as the instrument that tells you whether your controls are working, not a replacement control.

What happens to our data if we end the contract?

Two separate things need to happen, and both should be defined in advance. Access ends — enrollment is revoked, engineer access to your environment is removed, and the agent uninstalls cleanly like any standard application. And retained records — session logs and any archived recordings — are handled per the retention terms in your service agreement. Ask for both to be written down before you sign, not after you leave.

We are a small firm. Is this level of control overkill for us?

The size of the firm does not change the sensitivity of what is on the machines. A forty-person wealth manager may hold client identity documents, bank details and portfolio positions on a handful of laptops — a smaller estate than a bank's, but not less sensitive per device. What changes with size is the resource available to manage it, which is an argument for the control being built into the service rather than assembled by the firm. If your remote support already produces a ledger you can export, the marginal cost of being auditable is close to zero.

If your firm cannot currently answer "who connected to our machines last quarter," that is a solvable problem and usually a short conversation. Get in touch and we will walk you through what your existing arrangement can and cannot evidence, whether or not you end up working with us.