Your IT provider may need to connect to your computer to troubleshoot a problem, install software, or perform maintenance. But can someone at that provider connect without your knowledge—and without your permission?
For financial advisors and firms handling sensitive client information, that question deserves attention.
An IT relationship does not automatically justify permanent, unrestricted access to every device. The ability to provide support should not become an open invitation to view client records, control a desktop, or work inside an employee’s signed-in session.
The risk extends beyond the technician you trust
Unattended remote access allows a technician to connect without someone at the device approving the session. It can serve legitimate purposes, including after-hours maintenance and initial device setup. The risk arises when that access is broader than necessary or lacks adequate controls.
Depending on the tool and permissions, someone connecting remotely could potentially:
- View client information displayed on the screen.
- Open or copy sensitive files.
- Interact with applications already signed in as the user.
- Install software or change security settings.
The concern is not simply whether your usual technician is trustworthy. What happens if the technician’s account is compromised? What if a former employee retains access? What if the provider’s remote-management platform is breached?
The same access that makes support convenient can give an unauthorized person a path into your firm.
Local IT support still requires vendor scrutiny
An advisor may select an IT provider because the company is nearby, responsive, or recommended by another business. Those qualities do not establish whether the provider can adequately protect financial-services client information.
A provider with access to sensitive systems belongs in the firm’s vendor-risk review. That review should examine its access controls, technician authentication, employee offboarding, incident procedures, and ability to produce records of its activity.
Requiring user approval is one safeguard—not a substitute for vendor due diligence or evidence that the provider meets applicable obligations. FCI’s guide to choosing a cybersecurity provider offers questions to help structure that review.
A safer default: ask before taking control
For routine interactive support on a computer someone is using, the safer default is straightforward:
The technician requests access. The user approves it. The session is visible.
The approval prompt should identify the technician or support organization and make clear what access is being requested. The user should be expecting the support session, be able to watch the work, and have a way to end the connection.
A notification alone is not enough. “Someone has connected” is different from “Do you authorize this connection?”
The system should also deny access if the user does not respond—not silently grant access after a countdown.
User approval does not replace technician authentication. The provider should use individually assigned accounts and multifactor authentication for remote access, whether or not someone is present to approve the session.
What if nobody is logged in?
When nobody is logged in, there is no user available to approve a connection. Any permitted unattended access therefore needs a separately authorized, tightly controlled process.
That means restricting which technicians can connect, which devices they can reach, what they can do, and when access is allowed. Strong MFA—preferably phishing-resistant—helps verify the technician’s identity. Session and activity logs provide accountability.
But MFA does not establish that every action is authorized, and a logged-out computer can still contain sensitive client data. A locked screen is not an empty device, either.
Initial setup of a new computer may justify temporary unattended access. That access should be reviewed before the device enters everyday use, rather than remaining enabled indefinitely.
Protect the computer login—not just the remote-support account
Requiring permission before a technician connects protects an active user session. Another layer protects the computer login itself: operating-system multifactor authentication, or OS MFA.
With OS MFA enforced, a username and password alone are not enough to complete a protected computer login. The person signing in must also complete an additional authentication step. FCI enforces MFA at the operating-system level, extending protection beyond email and cloud applications to the device itself.
This is particularly important when nobody is logged in to approve a support request. Remote connectivity should not automatically grant access to the desktop: the computer’s protected login should still require MFA.
These safeguards serve different purposes:
- Remote-access MFA: Authenticates the technician accessing the support platform.
- OS MFA: Protects sign-in to the computer.
- User approval: Authorizes a technician to enter an existing user session.
None replaces the others. OS MFA does not necessarily stop a remote tool from controlling an already authenticated session or performing background administrative actions. Those capabilities still require separate restrictions, authorization, and logging. Firms should verify which local and remote sign-in methods their OS MFA configuration actually covers.
Together, these controls help ensure that knowing a password—or having a remote-support tool installed—is not enough to gain unrestricted access to client information.
Check more than the screen-sharing settings
Some remote-management tools can transfer files, execute commands, or install software in the background without opening a visible desktop session.
Consequently, an approval prompt for screen sharing does not necessarily prevent other forms of unattended access.
Firms should ask their providers:
- Can you view or control an active desktop without approval?
- Does a missed approval prompt deny the connection?
- Can you access files or run commands without notifying the user?
- Does every technician use an individual account protected by MFA?
- Is MFA enforced at the computer login, including the remote sign-in methods you use?
- Are access permissions limited, reviewed, and promptly revoked?
- Can you provide logs showing who accessed a device and what they did?
Ask for evidence that the controls operate, not just a statement that the tool supports them.
Support should not mean unrestricted access
Remote support and strong security can coexist. The goal is not to prevent legitimate IT work. It is to make access deliberate, limited, authenticated, and accountable.
For computers holding client information, “our IT provider can connect whenever they want” should trigger a review—not be accepted as the default.
This article provides practical cybersecurity guidance, not legal advice. Applicable obligations depend on the firm, its activities, and the information involved. User approval and MFA alone do not establish regulatory compliance.