How should third-party remote access be controlled?

Named individuals at the supplier rather than a shared account, access scoped and time-bound to the engagement, the same session logging you apply internally, and withdrawal built into contract closure.

What evidence do examiners look for?

Who holds access and why, how they authenticate, what each session recorded, how long records are kept, who reviewed access and when, and demonstrable removal of access for leavers and ended contracts.

How does remote support relate to operational resilience?

It is part of how important business services keep running during disruption. If support can only be delivered from one location, that is a single point of failure, and it should be tested rather than assumed.

Sector guides · 7 min read

Remote IT support in financial services and regulated firms

Written for: IT and operational risk teams in banks, brokers, insurers, wealth managers and other regulated financial firms.

In short

In a regulated financial firm the question is rarely whether remote support is secure, but whether you can evidence that it is. Regulators and auditors ask who can access what, how it is authorised, what is recorded and how access ends. A remote access deployment that cannot answer those questions with records is a finding waiting to happen.

Key takeaways

Remote access to production systems is privileged access, and should sit inside your privileged access controls rather than beside them.
Third-party and outsourced provider access is the area examiners probe hardest, and where most firms have gaps.
Market hours constrain change windows more tightly than most sectors realise, and remote access is what makes narrow windows usable.
Evidence beats assertion. Exportable logs, documented reviews and demonstrable offboarding are what stand up in an examination.
Operational resilience expectations mean you must show remote support still functions during a disruption, not only on a normal day.

Treat it as privileged access

Remote access into production systems gives an operator the ability to observe and change them, which places it squarely within privileged access management. The controls should therefore match the ones you already apply there: named accounts, multi-factor authentication, approval before elevated sessions, time limits, and full recording.

Firms that manage remote support as a helpdesk tool rather than a privileged access channel tend to discover the mismatch during an examination, when the two sets of records fail to reconcile.

Named operator accounts integrated with the firm's identity platform
Multi-factor authentication enforced without exception
Approval and time limits for elevated or production access
Session records exported to independent, tamper-evident storage

Third-party access is the hard part

Outsourced IT providers, software vendors and specialist contractors all need access at some point, and vendor access is consistently one of the weakest areas in practice. The failure modes are familiar: a shared vendor account, access granted for a project and never withdrawn, and no record of which individual at the supplier connected.

Insist on named individuals at the supplier, time-bound access tied to the engagement, and the same logging you apply internally. Make withdrawal part of contract closure rather than a task somebody remembers.

Change control and market hours

Trading and settlement timetables leave narrow windows for change, and the consequences of overrunning them are regulatory as well as operational. Remote access does not create a window, but it removes the setup and travel time that makes a narrow window unusable, and it lets a change be backed out quickly if it goes wrong.

Support activity that changes configuration during a session is a change, whatever the ticket says. Make sure the support process feeds the change record rather than sitting outside it.

Demonstrating resilience

Operational resilience expectations focus on important business services continuing through disruption. Remote support is part of that story: if your technicians can only work from one office, a site-level disruption removes your ability to fix anything else.

Test it rather than asserting it. A periodic exercise where support is delivered entirely from outside the office, including out-of-hours access to production, produces evidence and usually finds at least one dependency nobody had documented.

Bringing remote access into a regulated control framework

1. Classify remote access as privileged access
Bring it under the existing framework rather than running a parallel set of controls that will not reconcile.
2. Integrate operator accounts with identity management
Provisioning and deprovisioning should follow the same joiners, movers and leavers process as everything else.
3. Name every third-party individual
No shared vendor accounts. Time-bound access tied to the engagement, withdrawn at contract closure.
4. Export session records independently
Logs held only in the tool being audited are weak evidence. Forward them to central, tamper-evident storage.
5. Connect support activity to change control
A configuration change made during a support session is still a change and needs the corresponding record.
6. Run a documented access review
Periodic re-justification of every operator and every reachable production system, with the outcome recorded.
7. Exercise off-site support
Prove support continues when the office does not, and document what the exercise found.

Common mistakes

Managing remote support outside the privileged access framework, so the two record sets never reconcile.
A shared account for an outsourced provider, which makes individual attribution impossible.
Project access to production that was never withdrawn when the project closed.
Configuration changes made in support sessions that never reach the change record.
Asserting resilience of the support function without ever exercising it.

Frequently asked questions

Is remote desktop access acceptable in a regulated financial firm?: Yes, and it is widespread. What matters is that it is governed as privileged access: named accounts, multi-factor authentication, approval for production access, complete exportable logs and evidenced periodic review.
How should third-party remote access be controlled?: Named individuals at the supplier rather than a shared account, access scoped and time-bound to the engagement, the same session logging you apply internally, and withdrawal built into contract closure.
What evidence do examiners look for?: Who holds access and why, how they authenticate, what each session recorded, how long records are kept, who reviewed access and when, and demonstrable removal of access for leavers and ended contracts.
How does remote support relate to operational resilience?: It is part of how important business services keep running during disruption. If support can only be delivered from one location, that is a single point of failure, and it should be tested rather than assumed.

How this works in 247connect

247connect provides the underlying controls this framework needs: zero-trust access, AES-256 encryption, two-factor authentication and per-session audit logging against named operator accounts.

Start a 14-day free trial See the feature list