What Your MSP Built You, And Who Else Can Reach It

Part one was the sale. This is the estate.

The paperwork is signed, the invoice runs monthly, and there is kit. Some of it yours, some of it theirs, most of it picked before anybody asked what the business actually does between eight and six. What follows is the kit itself: what gets picked, what got left switched on inside it, and who else can reach the machines you paid for from a console you have never logged into.

Two of the failures here carry a regulator’s finding with a number attached. None of them happened to a customer — they happened to a provider, and the customers were downstream. Every claim has a link on it.

The Box They Will Not Be Talked Out Of

Now the awkward one. I want to do this with evidence rather than assertion, because it is the section where people reach for the word conspiracy — and reaching for that word is how the subject gets dropped without anybody having to look at it.

Cisco is the default recommendation across most of this industry. So look at what the vendor itself has published about undocumented access into its own kit.

In March 2018 they published an advisory for CVE-2018-0141: Prime Collaboration Provisioning could be logged into over SSH because of “a hard-coded account password on the system”. Eight months later, CVE-2018-15439 on the Small Business switches, where “the affected software enables a privileged user account without notifying administrators of the system”, with no fixed software available when it was published and a workaround offered instead. In October 2023, CVE-2023-20101: Emergency Responder shipped with a root account holding “default, static credentials that cannot be changed or deleted”, credentials “typically reserved for use during development”.

An account nobody was told about, that you cannot remove, with root on a box in your estate. Call it what you like. It is what the vendor’s own advisory describes.

Then there is the Snowden material, which is now more than a decade old and has never been retracted. In December 2013 Der Spiegel published the ANT catalogue, reporting that an NSA division “has burrowed its way into nearly all the security architecture made by the major players in the industry – including American global market leader Cisco and its Chinese competitor Huawei”. The same reporting described how kit gets there: shipments diverted to secret workshops in a process the NSA calls interdiction, where “at these so-called ’load stations,’ agents carefully open the package in order to load malware onto the electronics, or even install hardware components that can provide backdoor access”. An internal NSA newsletter from 2010, published in 2014 with the photographs, set out the process in the agency’s own words: devices “being delivered to our targets throughout the world are intercepted”, then “re-packaged and placed back into transit to the original destination”.

What the reporting does not show is complicity. Der Spiegel said plainly that nothing in the documents suggested the manufacturers knew or helped, and Cisco denied any involvement at the time, and in May 2014 its general counsel put it on the record: “as a matter of policy and practice, Cisco does not work with any government, including the United States Government, to weaken our products”. They complained to the President about it. On the face of it, they were a victim here too.

Take that at face value. It changes nothing about the box on your rack, because interdiction never needed the vendor’s help. And it is worth knowing what weight the denial carries, because Cisco’s word has been tested in court. In 2019 they settled False Claims Act proceedings for $8.6 million federally, plus $6 million across a group of states, over video surveillance software sold to government bodies with “flaws that would permit unauthorized access to the system, with the potential to control and otherwise manipulate security cameras and the recorded footage”. The New York Attorney General’s account is that Cisco knew about the flaws in 2009 and did not fix them until 2013, after the investigation had started. Settlements are not admissions of liability and I will not pretend otherwise. They are still four years of selling a product to police forces and public bodies with a known way in, and not saying so.

So the record is: undocumented root accounts by their own admission, a decade-old catalogue naming them, a shipping chain demonstrated to be compromisable, and a period where they knew about a hole and kept selling. Any single one of those you could shrug off. Together they are a pattern. A statement from an interested party does not settle a pattern.

The answer to that is controls, not a ban. The risk belongs in the design document with everything else, and the alternatives get priced instead of dismissed. Ask which competing kit was evaluated and what it cost. Ask what the firmware verification and update policy is, and who checks it. Ask how the kit is received and inspected, and by whom. Ask what happens on a serial number that does not match the purchase order.

And notice which vendors get this scrutiny in your sector and which do not. The same industry that put Huawei on a risk register over a capability nobody has produced in public will write Cisco into the low-level design without a line of justification, on the strength of a partner badge. I have written about what happens to that argument when you apply the standard evenly. A partner badge is a commercial relationship with targets attached. As such, it is not a security finding.

The Firewall Is The Way In

Widen that from one vendor to the category, because the firewall is the product an MSP sells hardest. It is the line item that justifies the security part of the contract.

CISA keeps a catalogue of vulnerabilities known to be exploited in the wild — not theoretically dangerous, actually used against somebody. I pulled the catalogue and counted it by vendor. Version 2026.08.27 holds 1,685 entries. Cisco accounts for 96 of them, second only to Microsoft’s 386, and 42 of those sit on the firewall and edge lines. Fortinet has 29. Palo Alto Networks has 15. For scale, Ivanti has 35 and SonicWall 17.

Look at what the entries actually are, because the pattern never varies. It is the management interface or the VPN, which is to say the part deliberately exposed to the internet.

Palo Alto’s CVE-2024-3400 was a command injection in the GlobalProtect feature of PAN-OS, scoring 10.0, exploited as a zero-day. Later the same year CVE-2024-0012 let “an unauthenticated attacker with network access to the management web interface” straight past authentication at 9.8, and it was chained with a command injection in the same interface.

Fortinet’s CVE-2022-40684 was an “authentication bypass using an alternate path or channel” at 9.8. Its CVE-2018-13379, an SSL VPN path traversal, went into the catalogue in November 2021. Years after the patch existed, because boxes were still sat on the internet unpatched and being walked into.

Cisco’s CVE-2023-20198 in the IOS XE web UI scored 10.0. CVE-2025-20333, in the VPN web server of its Secure Firewall ASA and FTD software, scored 9.9 last September.

And then there is CVE-2026-20316, added to the catalogue on 29 July 2026. Cisco Secure Firewall Management Center, “use of hard-coded password”, letting “an unauthenticated, remote attacker to log in to an affected device”. A static credential, in the box that manages the firewalls, confirmed as being exploited, a month before this post. The same failure as 2018 and 2023 in the section above, on the machine that administers your perimeter.

Now the useful part, because “some vendors are worse than others” is not really the lesson. Every one of these has a public record and none of it appears in a proposal. More to the point, the vendor’s total is not the number that decides whether you get hurt. Your exposure is the gap between a vulnerability going into that catalogue and your box being patched. That gap is not the vendor’s to close. It belongs to whoever you pay to run the thing.

Which is the same measurement the ICO took at Capita. Alert at ten minutes, action at fifty-eight hours, target of one. Nobody is asking their provider for that number on firewall patching, and it is a number every provider has.

When The Basics Are The Thing You Bought

Part one was about the sale. This is what came after it, in two cases where a regulator did the investigating and published what it found.

In March 2025 the Information Commissioner fined Advanced Computer Software Group £3.07 million over a ransomware incident in August 2022. Advanced “provides IT and software services to organisations, including the NHS and other healthcare providers”. The attackers got in “via a customer account that did not have multi-factor authentication”. NHS 111 was disrupted, healthcare staff could not reach patient records, and the personal information of 79,404 people was taken. The ICO’s finding on the cause is worth reading slowly: “while Advanced had installed multi-factor authentication across many of its systems, the lack of complete coverage meant hackers could gain access”. It was also the first penalty the ICO has issued against a data processor rather than the organisation whose data it was.

In October 2025 the same regulator fined Capita £14 million over the 2023 attack that took the personal information of 6.6 million people. A malicious file landed on an employee device on 22 March 2023. A high priority alert fired within ten minutes. The device was not quarantined for 58 hours, against a target response time of one hour, and the ICO found that the Security Operations Centre “was understaffed, and in at least six months before the incident fell well below the target response times for responding to security alerts”, alongside inadequate penetration testing and risk assessment.

Read what those two findings have in common. Not a clever adversary. Not a zero-day. Not owt nobody could have seen. Multi-factor authentication that was bought but not finished, and an alert queue nobody had staffed. Both are line items somebody signed off and reported green.

And none of this crept up on the industry. On 11 May 2022, three months before the Advanced incident, the cyber security agencies of the UK, Australia, Canada, New Zealand and the United States put out a joint advisory on threats to managed service providers and their customers, because they were “aware of recent reports that observe an increase in malicious cyber activity targeting managed service providers”. The first tactical action on the list is to enforce multi-factor authentication on the MSP accounts that reach into the customer’s environment.

Five countries’ security agencies wrote it down, in public, and named the control. Three years later a regulator is still fining people for not finishing it.

Neither of those is a small business story. Here is one. On Friday 24 November 2023 the legal sector IT provider CTS went down in a cyber incident. The Law Society’s own paper reported that around 80 firms were unable to complete transactions, with systems offline and contracts stuck. These are conveyancing practices, most of them small firms, and their customers were people in the middle of moving house. One of those put it plainly: “This leaves us with so much uncertainty — with movers needing to be booked, days needing to be taken off work at potentially short notice and lives put on hold.” CTS could say only that it was “unable to give a precise timeline for full restoration”.

Nobody in that chain picked CTS. The firm picked it, and every client downstream of the firm inherited the decision without ever being asked.

That is what you are buying when you buy a managed service.

And How Would You Have Found Out?

Notice something about every incident in the section above. None of them happened to the customer. They happened to the provider, and the customers were sat downstream of somebody else’s bad week.

So put the question directly. If you are breached, do we hear it from you? And how fast?

There is a legal floor, and it is lower than people assume. Where they process personal data on your behalf, Article 33 says “the processor shall notify the controller without undue delay after becoming aware of a personal data breach”. No fixed number of hours. Meanwhile you, as the controller, have 72 hours to tell the Information Commissioner once you become aware. Read those two together. Every hour they spend deciding whether to tell you is an hour off a clock that runs against you, not them.

And that floor only covers personal data. An intrusion into their management console, with no evidence yet that anything of yours moved, may generate no duty to tell you at all — while the credentials that reach every machine you own sit in somebody else’s hands. That is the gap. It is not a small one.

Think about who gets told before you. Their lawyers, because privilege. Their insurer, because the policy says so. Their regulator, on the statutory clock. You are further down that list than you would like to be, and the incentive at every step is to say less until more is known.

Which leaves the alternatives, and they are all worse. You find out because your systems stop, which is how the conveyancing firms found out. You find out because a journalist rings. Or you find out because somebody spots the provider’s name on a ransomware crew’s leak site, which is not a notification process, it is an accident of somebody else’s marketing.

So contract for it, and be specific, because vague clauses default to the statutory floor. Notification of any material incident on their network within a stated number of hours, in writing, whether or not your data is confirmed to be involved. Notification if any credential with access to your systems may have been exposed. Notification if they appear on a leak site. A named contact on your side, not a general mailbox.

Then ask the question that tells you most, and ask it while they are still selling to you. Have you had an incident? What happened, when did customers find out, and how did they find out? A provider who has been through one and handled it properly will tell you about it. It is the best evidence they have. Somebody who says it has never happened is either very lucky, very small, or not counting owt.

The Tool That Reaches Every Customer At Once

No MSP makes money touching machines one at a time. The economics need one console that reaches everything, and that is what remote monitoring and management software is for. RMM sits on every machine under contract, running as system, and the provider drives the lot from a single login.

Turn that round and look at it from your side. There is software on your machines that you did not choose, probably cannot name, and have never seen the patching record for. As such, it can do anything, to any of them, at any time.

The record on those tools is not comforting. Start in 2021.

Kaseya, July 2021. CISA and the FBI described responding to ransomware “leveraging a vulnerability in the software of Kaseya VSA on-premises products — against managed service providers (MSPs) and their downstream customers”. Around fifty providers were hit, and up to 1,500 businesses sat underneath them, most of which had never heard of Kaseya and had no say in it being there.

In January 2023 CISA, the NSA and the MS-ISAC issued a joint advisory to “warn network defenders about malicious use of legitimate remote monitoring and management (RMM) software”, after a campaign the previous October in which attackers phished people into installing ScreenConnect and AnyDesk, then used them to run a refund scam against victims’ bank accounts. Nobody had to breach an MSP for that. The tool works exactly as well for them as it does for the provider.

In February 2024 ConnectWise ScreenConnect turned out to carry CVE-2024-1709, which “may allow an attacker direct access to confidential information or critical systems”. It scored 10.0. Note the weakness class on it: authentication bypass using an alternate path or channel, word for word the same category as the FortiOS bypass further up. Different vendor, different product, same mistake. Full marks, in the software that reaches every customer a provider has.

Then SimpleHelp. CISA’s advisory of June 2025 describes ransomware actors “leveraging unpatched instances of a vulnerability in SimpleHelp Remote Monitoring and Management (RMM) to compromise customers of a utility billing software provider”, reaching “downstream customers” for double extortion. The flaw underneath it, CVE-2024-57727, lets an unauthenticated attacker pull “server configuration files containing various secrets and hashed user passwords” straight off the host.

Notice where the loss lands every time. Not on the vendor. Not really on the provider either. On the customers underneath, who never bought the tool, were never told which one it was, and had no say whatever in when it got patched.

A caveat on those sources, because it matters. They are American advisories, and that is because CISA publishes incident detail while the NCSC generally does not name. That is a difference in disclosure, not in conduct. The tooling is the same tooling, out of the same catalogue, and a small IT support firm in this country is running ScreenConnect or SimpleHelp or one of their competitors on your machines this afternoon.

So ask which one it is. Ask what version, when it was last patched, who can log into the console, whether every account on it has multi-factor authentication, and what the plan is the next time one of these ships a ten.

Then ask one more, because the answer tells you something the others do not. Does it work over IPv6?

It is a fair question in 2026 and it lands harder than it looks. If the management tool only speaks IPv4, then IPv4 is what your network has to keep — not because your business needs it, but because their tooling does. That is the addressing plan being set by a supplier’s software rather than by your requirements, and you are paying monthly for the addresses that make it possible. A remote worker on a mobile connection may well be on an IPv6-only network already, in which case the whole arrangement is leaning on translation somebody else maintains.

And if the answer is that they have never checked, you have learned the thing you were actually asking about.

A plainer one first, which gets forgotten in all the security talk. What load does the agent put on the machine, and where is the evidence?

The answer you will get is “negligible”. That is an adjective. What you want is a number, measured on hardware like yours rather than lifted off a datasheet — average and peak CPU, resident memory, disk activity during an inventory sweep or a patch scan, and daily network. Taken on the oldest machine in the estate rather than the newest.

And measure the whole stack, not one agent on its own. Remote management, antivirus, endpoint detection, the backup client, monitoring, asset tracking. Every vendor says under one per cent, there are six of them, and the person who actually has to work on that laptop is the one who finds out what six of them add up to. Near zero is the right target. Evidence is the only way to establish it.

Ask for the figures before rollout, and ask to take your own afterwards on a machine you pick. A provider confident in their tooling offers both without being pushed.

One more on the tool itself, and it is the one people find strangest until they think it through. Do you get told when the agent updates on your machines?

The agent is the highest-privilege software on your estate. It runs as system, on everything, and it changes version whenever the provider or the vendor decides it should. Software is being installed across your entire company by a third party, silently, and on most contracts nobody tells you it happened.

Now put that next to what actually went wrong at Kaseya. A malicious update pushed down a trusted management channel to every machine at once. From where you sit, on the day, that is indistinguishable from a routine agent update — same channel, same privilege, same silence. The only difference is intent. Intent is not something you can observe.

So ask for version-change notifications, ask who approves an agent update and whether it is tested anywhere before it reaches you, and ask the one that matters most: what would tell you that a push had happened which should not have? If the honest answer is nothing, then the control you are relying on is the provider’s own vigilance, which is the thing this whole section is about.

And The Keys That Open It

Then there is what opens the console. That gets even less attention than the console does.

An MSP holds administrative credentials for every customer on its books. That is the job — it is the whole product. So the standard applied to its own credentials ought to be higher than the one it sets for yours, and in practice it is routinely lower. Shared accounts, because individual logins for twelve engineers across two hundred tenants is a faff. Passwords in a vault the whole service desk can read. SSH keys with no passphrase sat on laptops that go home on the train. Break-glass accounts nobody has touched since the person who made them left the company.

“We use MFA” is where that conversation normally stops, and it should not, because the forms of it are not equal. CISA ranks them strongest to weakest: FIDO/WebAuthn and PKI-based at the top, which it calls “the gold standard”; app-based one-time passwords and push notifications below that, “vulnerable to push bombing attacks as well as user error”; and SMS at the bottom, which “should only be used as a last resort MFA option”. Only the top row is phishing-resistant. Everything under it can be relayed, fatigued or intercepted while the person approving it believes they are logging in as normal.

The attackers have read that document too. CISA’s advisory on Scattered Spider says the group “targets large companies and their contracted information technology (IT) help desks”. Not the customer. The help desk that can reset the customer’s credentials. That is a great deal easier, and it gets you everybody at once.

So the question is narrower than whether they use MFA. Is every account that can reach your systems on a hardware token — a token, not an app — and what happens when somebody rings the service desk at eleven at night saying they are an engineer who has locked themselves out?

The fix here is unusually simple, which is what makes the absence of it hard to forgive. Google told KrebsOnSecurity in 2018 that it “has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017”, when it began requiring physical security keys instead of passwords and one-time codes. Not fewer incidents. None. The same article notes the basic key retailed at twenty dollars.

Now scale that to a managed service provider. They do not need to issue keys to your staff. They need to issue them to their own engineers, and there are perhaps a dozen of those holding the credentials that reach every customer on the books. A dozen keys, bought once, against a blast radius that covers every business they touch. Twenty quid each. When somebody tells you hardware tokens are impractical, ask how many people would actually need one.

And there is a related question you should ask about your own estate, because most customers have never thought to. Who holds the break-glass account for your systems? On a great many contracts the honest answer is that the provider does, and you do not have a set at all. You cannot get into your own infrastructure without ringing them. That is not a security control, it is a dependency. It bites on the worst days rather than the ordinary ones. The day you give notice. The day they are bought by somebody you did not choose. The day they are the ones who have been compromised and you need to act without them.

You should hold your own break-glass credentials, sealed, written into the contract, and tested on a date somebody can point at. If your provider is reluctant, the reluctance itself has told you something.

The same question runs all the way down to the desk, and this is the one that gets forgotten completely. Every laptop and desktop they built for you has a BIOS administrator password on it, set during the build by somebody at their end. You own the machine. They hold the key to it.

Think about what that password actually governs. Boot order. Secure boot. Whether the thing will start off a USB stick at all. Which is to say whether you can reinstall a machine you own, recover one that will not boot, hand a batch to somebody else, or wipe them properly before they go out of the door. On a laptop it may also be what stands between a thief and the disk. None of that is exotic. It is the ordinary business of owning computers, and on a great many estates the owner cannot do any of it without ringing the supplier.

Ask for the lot. Every laptop, every desktop, every server — the BIOS or firmware password, the BMC login on anything that has one, and the bootloader password on anything where GRUB or its equivalent has been locked down, which is the same lock one layer up and is what stands between you and a rescue boot on a server that will not start. If they are the same password on all of them, that is worth knowing too. And if the answer is no, ask why not, because the reasons on offer are thin: the honest one is that it makes their build easier, and the rest is dressed up as security. A password you are not allowed to have is not protecting you from anybody. It is protecting them from you leaving.

Then there is the account you actually log in with to fix a machine. Local administrator on every Windows box, root on every Linux one, and something equivalent on every switch, firewall and hypervisor in the building. Two questions cover the lot, and they cover the firmware and bootloader passwords above as well. Are they different on every machine, and whose password management system holds them — yours, or theirs?

Different matters more than people expect. One local administrator password across two hundred machines is not two hundred passwords, it is one, and it is sat on the least defended laptop in the company as well as on the finance server. That is not a theoretical weakness, it is the standard move — get onto anything, read the password, walk to everything. Microsoft ships the answer in the box. Windows LAPS sets a different password on every machine, rotates it on a schedule, and backs it up into Active Directory or your own Entra tenancy. Microsoft’s own page lists the benefit first as “protection against pass-the-hash and lateral-traversal attacks”, and the feature is free on every supported version of Windows, with nothing further to pay to store the passwords in your own directory. So if the answer is one password everywhere, it is not a licensing problem and it is not a tooling problem. Somebody never turned it on.

Whose system is the one to press on, and notice where LAPS puts the password by default: in your directory, under your access control, with your record of who read it. That is the shape you want on everything. The credential to your machine lives in something you own, and your provider is granted access to it — access you can see, and withdraw on a Tuesday afternoon without asking permission.

The other shape is the common one. The passwords sit in their password manager, or in the privileged access vault bolted onto their remote management tool, and you have no login for it. Then every administrative password in your company is held by a company you have no account with, the log of who read one is theirs, and on the day the relationship sours you are asking nicely for the keys to machines you own.

So ask the follow-up, and ask it now rather than at the exit meeting. How do these get into our system? There are three honest answers. Move the escrow into our directory or our vault, and take delegated access to it. Or give us read access to yours today, with an export we can run ourselves, in a format our own vault will swallow. Or hand us a sealed copy on a schedule, dated, that we open and test. “It is all in our system and you can have it when you leave” is not on the list, because the day you leave is the day they have the least reason to be quick about anything.

And ask what happens to those passwords afterwards. A credential their engineers have known for four years is not made safe by an email saying it is gone. Every one of them needs rotating on the way out, by you, on machines you now hold the firmware password for.

And then the live version of all of it. Do you get told when a password to one of your systems is read?

Not a log they keep and could show you if you asked. A message that arrives at your end: which credential, which engineer, which ticket, and when. The capability is not in doubt anywhere — every vault worth the name records a checkout, and Microsoft’s own escrow does it in your own tenancy, where recovering a password is written to the Entra audit log as “Recover device local administrator password” against the account that did it. So the only real question is whether the record points anywhere you can see.

Ask, and if the answer is no, ask why not. There is an honest no in here somewhere — an alert on every checkout in a busy estate would fire forty times a day and you would stop reading it by Wednesday. That has an answer rather than being the end of the conversation. Alert on the ones that ought to be rare: the domain administrator account, the break-glass credentials, the firmware and bootloader passwords, the recovery keys. And alert on any read with no ticket number attached to it, because that is either sloppy record-keeping or precisely the thing you want to hear about, and neither of those is well served by finding out at the quarterly review.

What They Can Do Once They Are In

One more, and it is the one that most often gets a blank look. Do you get told when one of their engineers goes into your systems?

Not a log they keep. A notification you receive — who went in, when, for how long, and against which ticket. Ask for it, and if the answer is no, ask why not.

There is a precedent, and it is sitting inside the products they resell you. Microsoft’s Customer Lockbox makes a Microsoft engineer request your explicit approval before they can reach your content in a support case. Google publishes Access Transparency logs of its own staff touching your data, and Access Approval makes them ask first. So the largest suppliers on earth, with far narrower access than your provider holds, have built approval workflows and access logs for their own employees, and hand you the record.

Your MSP has domain administrator. Ask what they hand you.

And there is a harder reason than accountability. A notification that arrives at your end is the only independent sign you will ever get that their credentials are being used by somebody who is not them. If an attacker walks in through a service desk, every log that would show it sits inside the organisation that has just been compromised. One that lands in your inbox sits outside it.

One level down from that again, at the machine itself. Can the remote tool connect to somebody’s desktop without that person agreeing to it?

For a server at three in the morning, unattended access is the entire point and nobody sensible objects. For a machine somebody is sat at, with their mail open and their work on the screen, it is a different act. Every serious remote management product can be set to prompt before connecting, to show a visible indicator while a session is live, and to let the person decline. Whether yours does any of that is a configuration setting, and the setting was chosen by the people it suits.

So ask three things, and keep them separate. Can your engineers reach a staff desktop with no prompt? Does the person sat at it see anything at all while somebody is connected? Can they refuse?

If the first is yes and the other two are no, that is not a technical constraint. It is a default nobody revisited, on a product bought by the party it favours. It is also worth putting in front of whoever carries data protection in your organisation, because somebody watching an employee’s screen without their knowledge is a decision that ought to have a name against it.

Then the question that decides whether any of this is provable afterwards. Are their engineers recorded while they are working on your systems?

Session recording is not exotic and it is not a big ask. It is a headline feature of every privileged access product on the market, which means your provider is quite possibly paying for it already and has never switched it on. A recorded session gives you a video, or a keystroke and command log, or both, tied to a named engineer and a ticket number. That is what accountability looks like when it is real rather than promised — not an assurance that engineers behave, but a record that would show it if one did not.

So ask whether it is on, and then ask how you get at them, because a recording you cannot obtain is not evidence, it is a rumour. There are three answers worth having, in descending order. The recordings land in storage you own, written as they are made. Or you have read access to their system today, with an export you can run yourself. Or there is a request route with a stated turnaround — hours, in writing, in the contract — that you have tested at least once on an ordinary session rather than for the first time during an argument.

What you do not want is the common arrangement: recordings held only by the provider, retention set by the provider, deletion in the provider’s gift. That is a control that works perfectly until the day it is needed against the provider. So ask who can shorten the retention, who can delete one, and whether watching a recording is itself logged. And ask what happens to the lot on the day you leave.

Be fair about the other side of it, because there is one. A recording of an engineer fixing a laptop is also a recording of whatever your staff had on that screen, and now and again of a credential typed in plain sight. The recordings are sensitive in their own right and want the same handling as the vault: encrypted, access controlled, logged when viewed, kept for a stated period and no longer. A provider who raises that with you before you raise it with them has thought about the problem. One who has never considered it has told you something as well.

The same tool almost certainly moves files, in both directions. Ask whether it does, and then ask what has been put around it.

Outbound is the one nobody prices. A transfer over the management channel is encrypted, trusted, and sits outside every control you have already paid for — the data loss prevention, the egress monitoring, the policy about USB sticks. Anybody with console access can take a copy of anything on any machine, and on most deployments there is no record of it that you will ever be shown.

Inbound is how the incidents earlier in this post actually happened. Pushing a file to every endpoint at once is not a flaw in these products, it is the headline feature. Ransomware simply used it the way it was built to be used.

So ask whether file transfer is enabled at all, whether it can be turned off on the machines that never need it, whether every transfer is logged with the file, the direction, the machine and the engineer — and whether that log comes to you, or joins the others in their inbox.

And last on this, because it is the one nobody thinks to ask at all. What is the agent actually collecting, and what happens to it?

These tools gather a great deal more than a patch level. Hardware and software inventory, event logs, performance telemetry, often session recordings and screenshots, sometimes a good deal more depending on what is switched on. That is a detailed picture of how your business works and what your staff do all day. It is leaving your premises continuously.

So ask what is collected, where it is stored and under whose jurisdiction, how long it is kept, and who can see it — because the answer is usually the provider and the tool’s vendor, which is a second company you never chose and have no contract with. Ask whether any of it is used for anything beyond supporting you: product analytics, benchmarking, model training. Ask what happens to all of it on the day the contract ends, and get that in writing rather than in a conversation.

And note whose data it is. Records about your staff and your systems, held by somebody processing on your behalf, is a phrase with obligations attached, and they are yours rather than theirs.

The Chip That Answers When The Machine Is Off

There is one more layer beneath all of that, and it is worth asking about by name. Are they using Intel vPro, or the Active Management Technology underneath it?

If you have not met it, the short version is that management firmware runs on a separate controller inside the chipset, with its own network stack. It answers while the machine is powered down, provided there is mains and a cable. It can power the box on, change BIOS settings, mount a remote image and reinstall, and on the right configuration take the screen and keyboard at hardware level — before the operating system has loaded, and whether or not it ever does.

There are real reasons to want that. A machine that will not boot, a BIOS setting on a device three hundred miles away, a reimage without sending anybody out. In a large spread-out estate it is useful and I would not pretend otherwise.

But look at where it sits. Underneath the operating system, which means underneath every control you have bought. Your endpoint protection cannot see it, because it is not running in the operating system. Your host firewall does not filter it, because the traffic never reaches the operating system’s network stack — it is handled on its own ports before anything else gets a look. Your logging does not cover it. Nothing you have installed can tell you a session took place.

The security record is not reassuring either. CVE-2017-5689 scored 9.8, and the description is worth reading slowly: “an unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs”. CISA issued an alert and CERT/CC a vulnerability note. Note that word “provisioned” — dormant it is not a route in, and switched on it is one. And the firmware carrying it does not update through the normal patching you are paying for. It comes from the machine’s manufacturer, on their timetable.

Then there is the part that ought to concern anybody responsible for staff rather than servers. Hardware-level screen control means somebody can watch a display while the operating system has no idea. Ask whether the user consent prompt is enforced and whether the visible session indicator is switched on, because both are configuration and both can be turned off by whoever provisioned it.

So the questions are short. Is it provisioned on our machines, and who did that, and when — was it part of a build nobody mentioned? What specific jobs need it, and how many machines actually need those jobs? Which network can reach the management ports, and is that segmented from everything else? Is consent enforced, is the indicator on, and where is the audit trail? And can it be unprovisioned on every machine that does not need it?

If the answer to the first is “we do not know”, that is worth knowing on its own, because it means the capability is sat there configured by somebody and watched by nobody.

The Risk Went In For Free

Turn the whole of this part the other way up and it says one thing. Every capability in it arrived as a convenience and was priced as one. The agent that patches a thousand machines is the thing that can put a file on a thousand machines. The chip that saves a two-hundred-mile drive answers when the machine is off and tells your logging nothing. The convenience was quoted, itemised and signed off. The capability came along in the same box, unpriced. It appears on no document you have ever been shown.

None of that is an argument for going without any of it. Estates need patching, and somebody has to be able to reach a dead machine. It is an argument for knowing what is in the building, who can reach it, from where, and what it would take for the person holding that reach to be somebody other than the firm currently holding it. An invoice will never tell you, because an invoice is a list of what you are paying for. It is not a list of what you are exposed to. Nobody in this arrangement has ever been asked to produce the second one.

Part three is what happens when one of them goes off. What the contract actually promises, who ends up carrying the loss, what the excuses sound like, and what it costs to leave when you have finally had enough.

Sources

Retrieved 28 August 2026.

Training and skills.

• National Vulnerability Database — CVE publication counts by year, summed per quarter: 6,595 in 2015 against 49,972 in 2025.

The kit.

• CVE-2018-0141 — hard-coded account password, Cisco Prime Collaboration Provisioning, March 2018.
• CVE-2018-15439 — Small Business Switches, a privileged account enabled without notifying administrators, November 2018.
• CVE-2023-20101 — Cisco Emergency Responder, static root credentials that cannot be changed or deleted, October 2023.
• Der Spiegel, 29 December 2013 — the ANT catalogue, naming Cisco and Huawei among others, from the Snowden documents.
• Der Spiegel, 29 December 2013 — inside TAO: interdiction, load stations, and what happens to a diverted shipment.
• Ars Technica, 14 May 2014 — the 2010 NSA internal newsletter and photographs of a Cisco router being implanted, published in Glenn Greenwald’s No Place to Hide.
• Cisco, 13 May 2014 — the company’s response, in its own words.
• New York Attorney General, 2019 — the multistate settlement over video surveillance software sold to government bodies, and the 2009 to 2013 timeline.

The perimeter kit.

• CISA Known Exploited Vulnerabilities catalogue — version 2026.08.27, 1,685 entries; the per-vendor counts in this post are my own tally of that file.
• CVE-2024-3400, CVE-2024-0012 — PAN-OS, GlobalProtect and the management web interface.
• CVE-2022-40684, CVE-2018-13379 — FortiOS authentication bypass and SSL VPN path traversal.
• CVE-2023-20198, CVE-2025-20333, CVE-2026-20316 — Cisco IOS XE web UI, the ASA VPN web server, and a hard-coded password in Secure Firewall Management Center.
• CISA, Implementing Phishing-Resistant MFA — the ranking of MFA forms, strongest to weakest.
• KrebsOnSecurity, July 2018 — Google on 85,000+ employees and no successful phishing after mandating physical security keys.
• Joint advisory AA23-320A — Scattered Spider, and its targeting of contracted IT help desks.
• Windows LAPS overview — a different local administrator password per machine, rotated and backed up to your own Active Directory or Entra tenancy; free on every supported version of Windows.

When it goes wrong.

• ICO, March 2025 — Advanced Computer Software Group fined GBP 3.07 million, the regulator’s first penalty against a data processor. The enforcement page carries the detail.
• ICO, October 2025 — Capita fined GBP 14 million over the 2023 breach: the ten-minute alert, the 58-hour response against a one-hour target, and the understaffed Security Operations Centre.
• Law Society Gazette, 28 November 2023 — around 80 conveyancing firms unable to complete transactions after their IT provider went down.
• CISA and the FBI on the Kaseya VSA attack, July 2021 — ransomware against managed service providers and their downstream customers.
• Joint advisory AA23-025A, 25 January 2023 — CISA, the NSA and the MS-ISAC on malicious use of legitimate RMM software.
• CVE-2024-1709 — ConnectWise ScreenConnect authentication bypass, CVSS 10.0, February 2024.
• CISA advisory AA25-163A, June 2025 and CVE-2024-57727 — ransomware actors reaching downstream customers through unpatched SimpleHelp RMM.
• Joint advisory AA22-131A, 11 May 2022 — the UK, Australian, Canadian, New Zealand and US agencies on threats to managed service providers and their customers.