Your IT Provider Is Part of Your Attack Surface: Third-Party Cyber Risk From Both Sides of the Contract

The short answer: Yes — your IT provider is part of your attack surface, because it holds privileged access into your systems. Verizon's 2026 Data Breach Investigations Report found third-party involvement in 48% of breaches, up from 30% a year earlier. A joint government advisory (AA22-131A) tells buyers what to require: MFA, least privilege, logging, supply-chain disclosure and contractual incident notification.

Most security reviews start with what a company runs itself: its laptops, its network, its cloud accounts. They treat the IT provider as a service that sits outside that picture. This report argues the opposite. A managed IT provider is one of the most privileged parties in your environment. It can usually reach your administrator accounts, your endpoint management console, your backups and your remote-access tooling. Whatever protects those things inside the provider is, in practical terms, part of your security perimeter.

That is true in both directions. The provider has its own exposure, because one compromised administrative tool can touch many clients at once. The buyer has its own, because a contract that says nothing about notification, access revocation or sub-contractors leaves the buyer discovering the provider's weaknesses at the worst possible moment.

This report sets out what government guidance, named breach data and US disclosure rules actually say about that relationship, and what a buyer and a provider should each do about it. It is a companion to our research on the rising cost of cybersecurity incidents, which asks what an incident costs. This piece asks a different question: how the provider relationship itself becomes the route in.

A disclosure. Brocent is a managed IT provider, so we are on the provider side of the contract this report examines, and we sell services that address some of the risks described. We have tried to handle that conflict by anchoring every claim in a named primary source, by labelling our own observations as ours, and by writing the buyer's checklist as something a buyer can apply to us as readily as to anyone else.

Key findings

• Third-party involvement in breaches has climbed sharply. Verizon's 2026 DBIR, published on 19 May 2026 and covering incidents from 1 November 2024 to 31 October 2025, reports that 48% of breaches involved a third party, up from 30% in the previous edition. Verizon describes that as a 60% increase "after already doubling the year before."
• That figure is not an MSP-only statistic. Verizon's third-party metric combines three kinds of relationship: a vendor in the software supply chain, a vendor hosting your data, and a vendor with a connection into your environment. A managed IT provider can fit the third kind, and often the second. It is not the whole of the number.
• Governments have already said what buyers should require. Joint advisory AA22-131A, issued on 11 May 2022 by agencies in the United States, United Kingdom, Australia, Canada and New Zealand, lists specific actions for MSP customers and for MSPs. Our check found one version, with no revision and no notice that it has been superseded.
• The common root causes are basic. Verizon traces many of the 2025 third-party incidents back to missing multifactor authentication, poor credential rotation or excessive privileges, not to exotic techniques.
• Fixing a third party's exposure is slow. In a dataset Verizon obtained from a third-party risk management research partner, the 50% survival point for third-party cloud MFA exposures was roughly a month, and only 23% of third-party organisations had fully remediated them. For password and excessive-permission exposures the fix took almost eight months, and 31% were fully remediated.
• The regulatory floor is rising, but it binds the buyer. US-listed companies must now disclose material cyber incidents within four business days of deciding they are material. That rule binds the registrant, not its provider, which is why the notification clock has to be written into the contract.
• There is no public figure we can cite for how many MSPs have been breached or how many fall short of the advisory. We looked for one and did not find a source that survives scrutiny. What we say about buyer questions in Hong Kong and Singapore is Brocent's own qualitative observation, labelled as such.

Why privileged access makes every provider a shared risk surface

A managed IT provider is useful because it can do things on your behalf. It can reset a password, push a patch to every laptop, restore a mailbox, open a remote session on a server and change a firewall rule. Each of those abilities is a form of privileged access, and each exists whether or not anyone is currently using it.

Three properties make that access different from an ordinary supplier relationship.

• It is broad. A help-desk technician with administrative rights in a directory service can affect every account in it. A remote management agent on every endpoint can run commands on every endpoint.
• It is persistent. The access is standing access, not a one-off visit. Accounts, agents and remote-access links stay in place between tickets, which means they can be abused between tickets.
• It is shared. The provider's tooling is typically multi-tenant. The same platform, and often the same operator accounts, serve many clients. A compromise of the provider's tooling is therefore a potential compromise of every client reachable through it.

The last point is what makes the provider a distinct category of risk. A company that gets its own security right can still be exposed through a party whose controls it cannot see. That is the basic logic of third-party cyber risk, and it is why the same question has to be asked from both sides of the contract: what is the provider doing to protect the access it holds, and what has the buyer done to limit what that access can reach?

What the joint government advisory actually tells buyers to require

The most useful single document on this subject is a government one. Advisory AA22-131A, "Protecting Against Cyber Threats to Managed Service Providers and their Customers," was released on 11 May 2022. It was issued jointly by the US Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA) and the FBI, and co-sealed by the United Kingdom's National Cyber Security Centre, the Australian Cyber Security Centre, the Canadian Centre for Cyber Security and New Zealand's National Cyber Security Centre.

We opened the advisory page on the day this report was drafted. Its revision log lists a single entry, "May 11, 2022: Initial version," and the page carries no notice that it has been replaced. It remains the reference text. It is also now several years old, so we use it for the control expectations it sets out, not for any claim about current threat activity.

The advisory is organised as two parallel lists of recommended actions: one for MSP customers and one for MSPs. Reading the customer list as a buyer's contract checklist is the quickest way to see what it asks for. In the advisory's own terms, the headline customer actions are these.

• Enforce multifactor authentication. Require MFA on the services you receive and on all MSP accounts that access your environment, and review MFA configurations for "fail open" and re-enrollment weaknesses.
• Apply least privilege. Ensure the provider applies least privilege in its own environment and in yours, so that MSP accounts can reach only the resources the MSP actually manages.
• Segregate the connection. Use a dedicated secure connection for MSP access and limit provider traffic to it. Contracts should prohibit reusing administrator credentials across customers.
• Keep logs and require visibility. Keep critical logs for at least six months. Where the provider monitors your systems, contracts should require comprehensive event monitoring, visibility into the provider's own activity, and notification of suspected incidents.
• Retire access that is no longer needed. Disable provider accounts when they no longer manage infrastructure, a step that is easy to overlook when a contract terminates. Do not assign provider accounts to your internal administrator groups.
• Understand the provider's supply chain. Know which vendors and sub-contractors the provider relies on, and what access they have to your network and data. Contracts should state which party owns hardening, detection and incident response.
• Pin down notification. Contracts should specify how and when the provider tells you about incidents.
• Plan for recovery. Require automatic, continuous backups of critical data and configurations that are easy to retrieve or kept air-gapped, and test response and recovery plans regularly.

The advisory also lists three summary tactical actions. They are the shortest version of the whole document: identify and disable accounts that are no longer in use, enforce MFA on provider accounts that access the customer environment, and ensure contracts clearly state who owns ICT security roles and responsibilities.

For most controls the advisory sets out parallel actions for the provider and the customer, including treating any account with access to customer environments as privileged and not reusing administrator credentials across customers. A buyer who asks for these things is therefore not making an unusual demand; it is asking the provider to meet a published expectation set by seven national agencies.

What the named breach data shows about third-party involvement

The best-known statistical source on this question is Verizon's annual Data Breach Investigations Report. Because the third-party figure is widely quoted without an edition, we state the edition every time and do not mix figures across editions.

The 2026 edition

Verizon's 2026 DBIR was released on 19 May 2026 and covers incidents from 1 November 2024 to 31 October 2025. The report says it analyses more than 31,000 real-world security incidents, of which more than 22,000 were confirmed data breaches involving organisations in 145 countries. On third parties, it reports:

• 48% of breaches involved a third party, "up from 30% last year," which the report describes as a 60% increase "after already doubling the year before."
• The metric covers three relationship types. A vendor in an organisation's software supply chain; a vendor hosting an organisation's data in its own environment; and a vendor with a connection into an organisation's environment, whether a literal network connection or credentials held by the vendor.
• Named public examples are given for each type. Verizon cites SolarWinds for the software supply chain, a Snowflake-related campaign for the hosted-data case, a network connection to a vendor in the Target breach for the connected-vendor case, and a campaign involving the Salesloft Drift application and stolen OAuth tokens as an example where two types combined. Verizon attributes these to publicly disclosed information, not to its own investigations.
• Root causes are mostly fundamentals. Verizon says a good number of the cloud-based third-party incidents highlighted in the media in 2025 "boil down to insecure authentication (absence of MFA, improper credential rotation) or lack of least privilege enforcement."

The 2025 edition, based on more than 22,000 incidents including 12,195 confirmed breaches, reported third-party involvement at 30%, which the 2026 report treats as double the edition before. We cite each as its own edition because the datasets differ in size and composition.

How to read the number

A figure like 48% invites misuse, so three limits are worth stating plainly.

• It is involvement, not blame. A third party being involved does not mean the third party was negligent, or that it was the cause. It means the third party was part of the route in or the place the data was held.
• It is not specific to IT providers. The metric includes software vendors, SaaS platforms and hosted-data custodians. A managed IT provider is one case of the third archetype and sometimes of the second. We found no Verizon figure that isolates MSPs, and we do not present one.
• It is not a random sample. The DBIR draws on contributing organisations' cases, and Verizon notes that some regional patterns reflect who contributes data. It is a strong indicator of direction and mechanism, not a census.

What the regional data adds, and what it does not

The 2026 report's regional summary table covers Asia-Pacific with 5,229 incidents, 2,855 of them confirmed breaches, and lists third-party involvement at 69% of APAC breaches in its dataset. We report that figure because readers in Hong Kong and Singapore will look for it, but we do not lean on it. Verizon says some of the APAC pattern reflects who contributes data (it makes that point about hacking, malware and state-affiliated activity), and the APAC grouping is far wider than Hong Kong or Singapore. Nothing in the report measures those two markets on their own. The defensible reading is that the third-party pattern is not confined to North America and Europe, not that a Hong Kong firm has a 69% chance of anything.

The slow-remediation finding

One of the more useful results in the 2026 report comes from a dataset supplied by a new research partner focused on third-party cyber risk management. It measured how long exposures inside third-party cloud environments took to fix. Verizon reports that fixing poor password practices and excessive access permissions took almost eight months, and only 31% were fully remediated. For missing or improperly secured MFA, the 50% survival point was about a month, the tail converged to roughly 32% of lingering issues, and about 23% of organisations fully remediated it.

The sample for the MFA analysis was 7,513 exposures and for the authentication and privilege analysis 354, so the second number rests on a much smaller base. Neither is a measurement of MSPs specifically. What they do show is a pattern buyers should plan around: a weakness in a third party's environment is not fixed on the buyer's timetable, and the buyer's contract is often the only lever for changing that.

The provider's side: what defending a multi-tenant estate actually requires

Providers sometimes treat the advisory's MSP list as marketing language. It is better read as an engineering specification, because each item answers a specific failure mode of running many clients from shared tooling.

• Privileged access is segregated by client. The advisory tells providers to separate customer data sets and services from each other and not to reuse administrator credentials across customers. The failure it addresses is the one in which a single stolen credential opens every tenant.
• Administrative tooling is held to a higher standard than the clients' own. Accounts that can reach customer environments are to be treated as privileged and covered by MFA. A provider whose own technicians log in with passwords alone has built its clients' security on the weakest control in its business.
• The attack surface is reviewed, not assumed. Unused accounts, systems and services on the provider's own internet-facing footprint are to be disabled periodically. This is routine housekeeping.
• Backups survive the incident they are for. Offline copies encrypted with separate offline keys are a direct response to attackers who reach the backup system first.
• Sub-contractors are inside the boundary. A provider's own vendors and sub-contractors are part of its supply chain, and the advisory asks providers to manage the cascading risk to customers. In our experience, regional IT delivery often relies on local partners for hands-on work, so this is an ordinary feature of the market.
• Responsibilities are written down. The advisory asks that contracts state who owns detection, hardening and response, which closes the gap where each side assumes the other is watching.

One caution: an advisory describes good practice, not whether a particular provider follows it. A provider's description of its own controls is a claim, not evidence.

The buyer's side: due diligence that goes beyond a security questionnaire

A buyer's own contribution to the risk is easy to overlook, because it is mostly a matter of what the buyer has granted and not watched. NIST's *Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations* (SP 800-161 Rev. 1, with Update 1 dated 1 November 2024, which NIST lists as the current final version) is the US federal framework that treats this as a discipline: identifying, assessing and reducing supply-chain cybersecurity risk at every organisational level and building it into broader risk management. It is US federal guidance and is not a requirement on a private buyer in Hong Kong or Singapore. It is useful as a vocabulary and a structure, and for the principle that supplier risk is managed continuously, not once at onboarding.

Applied to an IT provider, the buyer's side comes down to a short list of questions that a questionnaire alone cannot settle.

• What can the provider actually reach? Maintain a list of every provider account, remote-access tool and network connection into your environment, and who owns each. If you cannot produce it, you cannot say what the provider's compromise would expose.
• Is the access limited to what the provider manages? The advisory's least-privilege point applies on your side too: provider accounts should not sit in your general administrator groups, and their reach should be limited to the systems in scope.
• Do you see the provider's activity? Logs that show what provider accounts did in your environment, kept long enough to be useful, are the difference between investigating an incident and guessing at one.
• Who is behind the provider? Know which sub-contractors and tool vendors touch your environment or data, and whether a change in them requires your notice.
• What happens at the end? Access that outlives the contract is a standing exposure. Offboarding a provider needs the same discipline as offboarding an employee.

How the regulatory floor is rising in the US, Hong Kong and Singapore

Regulation does not make a provider safe, but it changes what a buyer has to be able to say about its providers. This section is deliberately short.

United States: the SEC disclosure rules

In 2023 the US Securities and Exchange Commission adopted cybersecurity disclosure rules for public companies. Two parts matter here.

• Form 8-K Item 1.05 requires a registrant to disclose a cybersecurity incident it determines to be material. The filing is generally due four business days after that determination. It must describe the nature, scope and timing of the incident and its material or reasonably likely material impact. Disclosure may be delayed if the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety.
• Regulation S-K Item 106 requires annual disclosure, in the Form 10-K, of the registrant's processes for assessing, identifying and managing material cybersecurity risks, and of board oversight and management's role. Foreign private issuers make comparable disclosures on Forms 6-K and 20-F.

Annual-report disclosures began for fiscal years ending on or after 15 December 2023, and the Form 8-K requirement began on 18 December 2023 for most registrants, with smaller reporting companies receiving an additional 180 days.

The rules bind registrants, not providers. That is the point for this report. A listed company cannot hand its disclosure clock to a supplier. If an incident starts inside a provider's environment, the buyer's four business days begin when the buyer determines the incident is material, but it can only make that determination once it has been told something. A contract that gives the provider an open-ended window to notify is a contract that shortens the buyer's real time to comply. The rules do not require any particular notification period from a provider; they make it commercially sensible to ask for one.

Hong Kong and Singapore: a pointer, not a comparison

Regulators in both markets set expectations for how regulated institutions manage outsourced technology. The Hong Kong Monetary Authority's Supervisory Policy Manual module SA-2 on outsourcing and the Monetary Authority of Singapore's Guidelines on Outsourcing are the main reference points for banks. They bind the regulated institution, not the provider, and they apply to licensed financial institutions rather than to general-enterprise buyers.

We deliberately stop there. A proper comparison of the financial-sector regimes, including Mainland China's, is a different research question and will be its own report. For readers who want practical guidance in the meantime, we have published a checklist for assessing outsourced IT under the MAS technology risk guidelines. The practical consequence for a general-enterprise buyer is that the more regulated your customers and counterparties are, the more likely you are to be asked to evidence your own provider controls to them.

Questionnaire answers vs. evidence vs. contractual commitment

A security questionnaire is where most buyers start and where many stop. It is useful, and it has a ceiling. The more helpful distinction is between three levels of assurance, each stronger than the one before.

• Questionnaire answer: the provider states that it enforces MFA on administrative accounts. Cost to the buyer is low and so is the assurance, because the answer is a claim made once, at a point in time, in the provider's own words.
• Evidence: the provider shows something that can be checked. That might be a screenshot of the conditional-access policy covering technician accounts, an extract of the access-review log for the buyer's tenant, a current third-party audit report that covers the relevant scope, or a walkthrough of how the buyer's data is separated from other clients'. Assurance is higher because the buyer can test the claim, though it is still a snapshot.
• Contractual commitment: the requirement is written into the agreement with an owner, a standard and a consequence. Notification within a stated period, a right to receive or inspect specified evidence, a duty to tell the buyer about changes in sub-contractors, and a requirement to revoke access on exit are commitments the provider can be held to after the sale.

None of these replaces the others. The questionnaire finds the obvious gaps cheaply, evidence confirms the claims that matter most, and the contract is what remains when the first two have gone stale. The pattern to avoid is a buyer that collects strong questionnaire answers but weak contract terms, and so holds a record of what was promised with no way to enforce it.

What to put in the contract, not the questionnaire

The advisory repeatedly points at the contract as the place where responsibility is fixed. The following terms follow its customer list and are written so a buyer can adapt them. They are a starting point for discussion with counsel, not legal advice.

Notification

• A defined notification trigger and period. State what the provider must report (suspected as well as confirmed incidents, or incidents affecting the buyer's data or access) and within what time. The period should be short enough to be useful for any disclosure clock the buyer is subject to, such as the SEC four-business-day rule for a US registrant.

Audit and inspection

• A right to evidence. The ability to receive named evidence, such as the provider's current independent audit report, penetration-test summary or access-review output for the buyer's scope, on a stated schedule and after an incident.
• Log access. The advisory's six-month log retention point can be turned into a commitment about what activity of provider accounts the buyer can see and for how long.

Sub-processors and sub-contractors

• Disclosure. A list of sub-contractors and tool vendors that touch the buyer's environment or data, kept current.
• Notice of change. Advance notice when the list changes, with a right to object where the change is material.
• Flow-down. The provider's security obligations applied to its sub-contractors, with the provider remaining responsible for them.

Access and exit

• Dedicated, separated access. The dedicated-connection and no-shared-credentials points from the advisory.
• Access revocation on exit. A defined time within which all provider access, accounts and remote-access agents are removed on termination, with confirmation. The advisory asks buyers to disable provider accounts that are no longer managing infrastructure, and warns that this is easily overlooked when a contract terminates.

Responsibilities

• Who owns what. A clear statement of which party owns hardening, detection and incident response for each part of the environment. This is a point the advisory makes explicitly, and one that is easy to leave implicit.

For readers who want to see what a service-level framework looks like in practice, Brocent's service levels page sets out how we describe response and resolution commitments. A buyer evaluating any provider can use the same structure to ask where security notification sits relative to service response.

What buyers now ask providers to evidence — Brocent's own observation

This section is Brocent's own operational observation, drawn from onboarding conversations and security reviews with clients in Hong Kong, Singapore and other markets we serve. It is qualitative. We do not publish counts or percentages from it, and it should not be read as a survey.

In onboarding conversations, buyers ask for specifics about how provider access works, beyond whether a provider holds certifications.

• Separation between clients. Buyers ask how technician access to their environment is kept distinct from access to other clients', and whether credentials are ever shared across tenants.
• Who else is involved. They ask which sub-contractors and tool vendors would touch their environment or data, and whether they will be told if that changes.
• Protection of the provider's own tooling. They ask whether MFA and conditional access cover the provider's administrative tools, not just the clients' accounts.
• What happens when something goes wrong. They ask for the incident-notification timeline to be written into the contract and not merely described in a presentation.

In our experience, buyers in regulated or customer-audited sectors ask these questions in more detail. We cannot quantify that and do not try to. Our own services in this area are described on our cybersecurity services page and our managed IT security services page, and an independent view of an existing provider's controls is the kind of work covered by our IT assessment and audit service.

What this report does not claim

• It does not claim most IT providers are insecure. Neither the advisory nor the DBIR supports that, and we found no source that measures it.
• It does not isolate MSPs in the breach data. The 48% covers all third-party relationships.
• It does not describe current threat-actor activity. The advisory is from 2022, and we use it for control expectations.
• It does not establish that Hong Kong or Singapore buyers face a particular rate of third-party breach. The APAC figure is regional and subject to contributor bias.
• It is not legal advice. The SEC summary is a plain-language description of public rules, and contract terms should be reviewed by counsel in the relevant jurisdiction.
• It does not evaluate any named provider, including Brocent, against these controls. Verifying a provider's claims is the buyer's job, and the framework above is meant to make that easier for us as much as for anyone else.

Frequently asked questions

Is my IT provider really part of my attack surface?

Yes, to the extent it holds accounts, remote-management tools or network connections that reach your systems, or stores your data. Those routes exist whether or not you operate them. The advisory AA22-131A is written on that premise, and tells both customers and providers what to do about it.

How common are third-party breaches?

In Verizon's 2026 DBIR, 48% of breaches involved a third party, up from 30% in the 2025 edition. The metric covers software vendors, data-hosting vendors and connected vendors, so it is wider than IT providers alone.

What is joint advisory AA22-131A?

It is a May 2022 advisory titled "Protecting Against Cyber Threats to Managed Service Providers and their Customers," issued by CISA, the NSA and the FBI and co-sealed by the national cyber agencies of the United Kingdom, Australia, Canada and New Zealand. It lists recommended actions for MSP customers and for MSPs, including MFA, least privilege, logging, supply-chain awareness and contractual clarity on incident notification.

What should I ask an IT provider about security before signing?

Ask what the provider can reach, how technician access is separated between clients, whether MFA covers its administrative tooling, which sub-contractors are involved, how quickly it will notify you of an incident, and how access is removed on exit. Then ask for evidence for the two or three answers that matter most, and put the notification and exit terms in the contract.

Do Hong Kong and Singapore have equivalent rules?

Both have regulator expectations for outsourcing by financial institutions, such as HKMA's SPM module SA-2 and MAS's Guidelines on Outsourcing. These bind the regulated institution and apply to licensed financial institutions, not to buyers generally. This report points to them but does not compare them.

How should a provider respond to these expectations?

By treating the advisory's MSP list as a specification: segregate client access, protect administrative tooling with MFA, review and shrink its own attack surface, keep recoverable offline backups, manage sub-contractors and state responsibilities in writing. The standard is the same one a buyer is told to ask for.

Sources used

• CISA, NSA, FBI, NCSC-UK, ACSC, CCCS and NCSC-NZ, *Protecting Against Cyber Threats to Managed Service Providers and their Customers*, Advisory AA22-131A, 11 May 2022 (cisa.gov).
• Verizon, *2026 Data Breach Investigations Report*, published 19 May 2026, and Verizon's accompanying news release (verizon.com).
• Verizon, *2025 Data Breach Investigations Report* news release (verizon.com).
• NIST, *Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations*, SP 800-161 Rev. 1, Update 1, 1 November 2024 (csrc.nist.gov).
• US Securities and Exchange Commission, 2023 cybersecurity risk management, strategy, governance and incident disclosure rules: press release 2023-139 (sec.gov).
• Brocent's own operational observation, labelled as such in the section above.