What Access Does Your IT Company Actually Have? The Questions Every Santa Clarita Practice Should Ask, Starting With Ours
There is a small piece of software running on every computer in your office that nobody in the practice remembers installing. It can see the screen, move files on and off the machine, install programs and run commands, usually at a higher privilege level than anyone who works there. It was put in place by the company you pay to keep you safe, and it is how they do the job.
That is not a scandal. It is how managed IT works and there is no version of the service without it. The problem is narrower and more awkward: it is the one piece of your security you have delegated completely, the company that would audit it is the company that holds it, and almost no practice has ever asked a single question about how it is governed.
Overview
Last week's piece walked the six documented routes ransomware takes into a business, taken from the joint federal #StopRansomware Guide. The sixth was third parties and managed service providers, and the guide does not soften it: MSPs have been an infection vector for ransomware impacting numerous client organizations, and criminals may target a provider precisely in order to reach the organizations it serves.
Five of those six routes a practice can inspect for itself. It can scan its own addresses, check its own multi factor coverage, look at its own endpoint console. This one it cannot, because the inspection would have to be performed by the party being inspected. The only instrument available is asking, and the quality of the answers is itself the finding.
There is a second reason this route deserves its own piece. The tooling involved is invisible to the defenses a practice has bought. The joint advisory from CISA, the NSA and MS-ISAC on malicious use of remote monitoring and management software states it plainly: the use of such software generally does not trigger antivirus or antimalware defenses. Your endpoint protection is not going to police this for you, because you told it not to.
The Challenge
The access is standing, privileged and quiet. Remote management agents are built to work without a person present, which is what makes the service economical: patching happens overnight, a fix lands before anyone notices the fault. The same properties mean the access does not announce itself, is rarely time limited, usually runs above the privilege of any employee, and frequently carries the ability to view a screen without asking. Every one of those is a feature. All of them together describe the most powerful account on your network, and it does not belong to anybody in your building.
Attackers do not need to break it, only to use it. The CISA advisory describes a campaign running since at least mid 2022 in which criminals sent help desk themed phishing emails, steered recipients to a malicious domain, and delivered portable copies of legitimate remote access software configured to call home to the attackers' own server. From there they walked a victim into their online banking while connected, altered what the screen showed to suggest an overpayment, and asked for a refund of the difference. The advisory notes that portable versions run without installation or administrator rights, slipping past controls that block unapproved software, and that this approach requires no custom malware at all.
The detail worth sitting with is who the targets were. That campaign was aimed at federal government staff, people with mandatory annual training and a security team. It worked because nothing about it looked like an attack. A trusted sounding request, a legitimate commercial tool, and software your defenses are configured to allow. Any practice that has decided its training is the answer here should notice that training did not settle it there.
The asymmetry is the part that makes it a business risk rather than a technical one. A provider is a single point that reaches every client at once, which is exactly why the guide lists them as a vector and why the advisory warns that illegitimate access can be sold on to other criminals. Your own posture can be sound and your exposure still runs through somebody else's console, somebody else's password policy, and somebody else's decision about whether a departing technician's account was closed on the day they left.
And the obligations never move. A practice in Valencia or Stevenson Ranch remains responsible for the protected information in its systems regardless of who was holding the keys when it was reached. Our piece on the HIPAA risk analysis makes the point in the regulator's own language, and the vendor relationship itself belongs inside that analysis, which is the ground our piece on third party vendor risk covers. Delegating the work never delegated the duty.
Why It Matters
This is the only control you cannot verify by looking. Everything else in your environment can be checked from inside the practice. Here the answer lives in another company's systems, and the only instrument you have is a question. That makes the willingness to answer part of the control itself.
Your defenses are configured to ignore it. The advisory's wording about antivirus is not a criticism of antivirus. It is a description of how allowlisting a legitimate tool works. The mechanism that makes managed IT efficient is the same mechanism that makes its abuse quiet, and nothing you buy for the endpoint changes that.
And the answers are a reliable read on the provider. Not because a wrong answer proves negligence, but because the six questions below are ordinary professional hygiene. A provider who can produce them without drama is running a practice with records. A provider who finds them insulting has told you how the inside of the operation looks, which is useful information to have before an incident rather than during one.
What Organizations Should Watch For
- Nobody in the practice can name the remote access tools on the machines. If the inventory does not exist on your side, you cannot tell an authorized agent from an unauthorized one, which is the first thing the advisory asks you to be able to do.
- Shared technician logins rather than named accounts. A shared credential cannot attribute an action to a person and does not end when an employment does.
- No multi factor authentication on the provider's own console. That console reaches every client at once, which makes it the highest value credential in the arrangement.
- No connection log you are able to see. If nobody can tell you who connected to your systems last Thursday and what they did, then the access is not being governed, it is being trusted.
- A contract that is silent on security. No notification obligation, no access standards, no statement of what happens at the end. The federal guide specifically recommends using contract language to formalize security requirements.
- Your documentation and backups living only in the provider's platform. If the primary copy is theirs, the relationship is harder to leave than the agreement suggests.
Recommended Actions
- Ask for the inventory of remote access software on your machines. Which tools, on which systems, authorized by whom. You cannot spot an extra one later without the list.
- Ask whether multi factor authentication is enforced on the provider's management console, and whether it is phishing resistant. Enforced is the operative word, not available.
- Ask whether technicians use named accounts and how access ends when somebody leaves. Then ask when that was last exercised, because a process nobody has run is a paragraph rather than a practice.
- Ask for connection logs on request. You do not need to read them weekly. You need them to exist, to be available to you, and for everyone to know they are.
- Ask what day one looks like after you part company. How access is removed, how you would confirm it, whether agents are uninstalled, and whether you hold the primary copy of your own documentation, licenses and backups.
- Put the answers in the contract rather than in a thread. An answer in email is a sentiment. The same answer in the agreement is an obligation, and the guide asks for exactly that.
The SecureLynx Perspective
Observe:
Across medical practices, accounting firms and law offices in the Santa Clarita Valley, this is the question nobody has asked and nobody has been asked. The relationship with an IT provider is built on trust, it usually predates whoever is now responsible for compliance, and raising it feels like an accusation. It is not one. The same six questions apply to a provider doing excellent work, and the practices with the best arrangements are usually the ones that asked early, when nothing was wrong and the conversation cost nothing.
Adapt:
The work on your side is small and it is mostly paper. Build or request the inventory of what has remote access to your machines. Get the provider's answers in writing and keep them with your compliance record, where they belong alongside the risk analysis, since a vendor with standing privileged access is part of the environment that analysis is supposed to describe. Put the security expectations into the agreement at the next renewal rather than waiting for a reason. And make sure the primary copy of your own documentation and backups sits where you control it, which on our side is the client portal, with the primary copy yours by design and not as a favor.
Protect:
We would rather be asked these six than not, so here are ours. The tooling is nameable: ManageEngine Endpoint Central for management, patching and disk encryption, and ESET PROTECT Elite for endpoint security, with managed detection and response added on the regulated tier. If you are our client you are entitled to know what is on your machines and why, and what each piece does is published rather than described on a call. Day one after we part is already written rather than promised: admin credentials and documentation are contractually handed over, licensing is vendor direct and stays yours, your data leaves in machine readable formats, there is a 15 day retrieval window, and the recovery fee is capped. And it is in the contract because it was in the contract before you asked. The offboarding terms live in the master services agreement, and the agreements are downloadable before you ever speak to us, alongside published pricing, which is the whole argument of our piece on how AI reads the fine print now. No provider owned firewalls, no hardware as a service lease backs, no buyout fees at exit, because an equipment lease is the quiet version of the same hostage problem. And the three that are operational rather than contractual, since you are entitled to those too: multi factor authentication is enforced on our own consoles rather than merely offered, every technician works under a named login rather than a shared one, and the connection activity on your systems reaches you in your monthly report rather than on request, which means you are not required to think to ask. Then the two honest notes. We are a small firm, so the sharper question for us is not an insider process failure but what happens if the person holding the keys is unavailable, and that is answered in the same clauses: easy to leave and survivable loss are the same mechanism, with a named technician for the aftermath. And no provider can promise its own access will never be abused, ours included. Any that does has answered the first of the six badly, and if you ask us all six and prefer somebody else's answers, that is a good outcome, because the risk does not care whose keys they are.
Common questions
What security questions should I ask my IT provider?
Six, and ask for the answers in writing rather than on a call. Which remote access and management tools are installed on our machines, and can you show us the inventory. Is multi factor authentication enforced on your own management console, the one that reaches all of your clients. Do your technicians use named individual accounts rather than a shared login, and how is access removed when somebody leaves your company. Can we see a log of connections into our systems on request, showing who connected, when, and what was done. What happens on the first day after we part company, how quickly is access removed, and do we hold the primary copy of our own documentation and backups. And finally, will you put those answers in the contract. A provider who answers all six readily has told you a great deal, and so has one who does not.
Can antivirus detect my IT provider's remote access software?
Generally not, and that is by design rather than by failure. A joint advisory from CISA, the NSA and MS-ISAC on the malicious use of remote monitoring and management software states that the use of such software generally does not trigger antivirus or antimalware defenses. The reason is that the software is legitimate, it is on your machines on purpose, and your security tools have been told to permit it. The advisory also notes that portable versions can run without installation or administrator rights, which lets them slip past controls that block installing unapproved programs, and that an attacker using them needs no custom malware at all. The practical consequence for a practice is that this particular access is not something your endpoint protection is going to police for you. It has to be governed by inventory, by restriction and by contract instead.
What happens to my IT provider's access when we switch providers?
Whatever the two of you agreed, which in most small practice arrangements is nothing written down. That is the gap worth closing before you need it. The questions to settle in advance are how quickly standing access is removed after notice, who confirms it has been removed and how you would know, whether the agents are uninstalled from your machines or merely disconnected, and whether you hold the primary copy of your own documentation, configurations, licenses and backups rather than a copy that lives in your provider's system. A practice that has those answers in the contract can change providers as a business decision. A practice that does not is negotiating during a transition, which is the worst possible time and the reason some arrangements are harder to leave than they look.