Breached through your supplier: what to ask, what NIS2 requires and what to test

TL;DR

• Three recent incidents in Belgium and the Netherlands started at a supplier of the victim.
• NIS2 puts supply chain security on your list of measures. Your supplier does not carry that duty for you.
• Asking suppliers the right questions helps. The access and integrations on your side are yours to test.
• Start with a list: who has access, through which route, and how you shut it off when something goes wrong.

At the end of October, residents of several Belgian municipalities were warned about phishing. The municipalities themselves had not been hacked. A module from their software supplier had. That pattern kept coming back this year: the attacker goes through the party that is already allowed in. This post covers the routes that takes, what NIS2 expects and which part you can have tested yourself. That last part is usually a network pentest on supplier access, or an API pentest on the integrations between your systems and theirs.

Three incidents, one pattern

A signing module used by local governments

On 27 October 2026, Vanden Broele reported that an attacker had access to eSignFlow on 22 and 23 October. Local governments use the module to have documents signed digitally, including through the C-Smart and Cipal packages. What was taken was mostly metadata: the name of the person who signed, sometimes with the document title. Vanden Broele reported the incident to the Centre for Cybersecurity Belgium and the Belgian Data Protection Authority, closed the access and replaced all keys and connections.

A name and a document title sound harmless. In a phishing email they are exactly what makes the message believable. 'Your document is still waiting for your signature' works best when it is true.

A management platform for work phones

In June 2026, the Belgian State Security Service was hit through Ivanti Endpoint Manager Mobile, the platform used to manage work phones. According to press reports, the software ran at an external partner. Names, phone numbers and email addresses of staff were taken.

A patient record system and a VPN that had to be cut

In April 2026, ChipSoft was hit by ransomware. An estimated 70 to 75 percent of Dutch hospitals run on its software. Several hospitals cut their VPN connections to ChipSoft's systems so the attack could not spread into their own networks. At least eleven hospitals took their patient portals offline on advice from Z-CERT and the NCSC.

That detail matters most of the three stories. Those hospitals knew which connection existed and could shut it. That is less obvious than it sounds.

Four ways a supplier becomes your way in

Software that runs on your side or holds your data

A package on your own servers, or a SaaS service that stores your data. When the supplier is hit, the weakness sits in software you do not patch yourself and may not even see running.

Remote management access

Your IT partner manages your environment through an RMM tool, a VPN or its own admin account. That is normal and often necessary. It also means one compromised account at that partner is a key to your network. So check how that account is set up: with MFA, with only the rights it needs, and removed as soon as the contract ends.

Integrations and API keys

Your accounting talks to your bank, your CRM to your email platform, your web shop to your logistics partner. Every integration runs on a key or token. If that key has broad rights or has never been rotated, whoever gets hold of it is in without ever logging in. There is a reason Vanden Broele replaced every key and connection after the incident.

Data that sits with the supplier

Sometimes no network access is needed at all. Data about your organisation held by a supplier can be enough to build a convincing phishing email. The eSignFlow incident is a textbook case: no passwords, plenty of context.

What NIS2 actually asks

NIS2 lists supply chain security explicitly as one of the measures you have to take (Article 21, paragraph 2, point d). It covers the security aspects of your relationship with direct suppliers and service providers. Paragraph 3 adds that you take into account the vulnerabilities specific to each supplier and the overall quality of their products and security practices, including how securely they develop.

Two things stand out. The duty sits with you, the organisation that falls under NIS2. And it is about your direct suppliers, not your supplier's supplier.

In Belgium, the CCB works this out through the CyberFundamentals framework. In the Netherlands, the national implementation is the Cyberbeveiligingswet. What an inspection asks per sector differs and is still evolving. What you can show: that you know who has access, that you asked about it and that you tested what sits on your side. Our NIS2 penetration testing checklist covers what that evidence looks like.

Questions to ask a supplier

A forty-page questionnaire mostly produces a completed questionnaire. Four questions tell you more:

• Who on your side has access to our environment, through which route, and with MFA?
• How quickly do we hear about an incident, and from whom?
• When was your product or platform last tested, and what was fixed afterwards?
• Which of our data do you keep, and for how long?

Pay attention to how concrete the answer is. 'We take security very seriously' does not answer the first question.

What to have tested yourself

The connection on your side

Supplier VPN access, admin accounts, API keys and the rights an integration gets in your environment. That is your side of the relationship, and you can test it. A network pentest looks at access and rights in your network; an API pentest looks at the integrations and keys between systems.

What an attacker can do once the supplier is in

The more useful question: what can someone do with your IT partner's account or an integration key? How far do they get, what can they see, and would you notice? You test that scenario with an internal test from the supplier's position, or more broadly with a red team exercise.

What you do not test yourself

You do not test your supplier's own platform without their written permission. That certainly applies to SaaS services running on the supplier's infrastructure. If you do want that portal tested, ask for permission first. A web application pentest is then possible, with clear agreements on scope and test environment.

Where to start this week

• List the suppliers with access to your environment or an integration with your systems, with an owner for each line.
• Write down for each line how you shut that access off when something goes wrong. That is what the hospitals had to do at short notice with ChipSoft.
• Remove access for suppliers you no longer work with.
• Add an incident contact for each supplier to your incident response plan.

Conclusion

Your supplier is usually not the weak party. It does have access, and access is what an attacker is after. Work out the list together with your IT partner. Know who is allowed in, ask how that access is secured and test what sits on your side. Then an incident at a supplier stays a nuisance instead of becoming a breach at your company.

Frequently Asked Questions

Am I responsible if my supplier gets hacked?

Not for the incident at your supplier. You are responsible for what you should have arranged yourself: who has access, how that access is secured and how you respond. If your organisation falls under NIS2, supply chain security is part of your own measures.

What exactly does NIS2 require about suppliers?

Article 21 requires measures for supply chain security, covering your direct suppliers and service providers. You take into account the vulnerabilities of each supplier and the quality of their products and security practices. How this is checked per sector differs by country.

Can I have my supplier's systems pentested?

Not without their written permission. What sits on your side, such as VPN access, admin accounts and API keys, you can have tested with a network pentest or an API pentest.

Is my supplier's ISO 27001 certificate enough?

It is a good sign: the supplier runs an information security management system. Do check what falls within the scope of the certificate. It says little about the access the supplier has to your environment or about the connection between your systems. That side remains yours.

What should I do when my supplier reports a data breach?

Ask which data and which access are involved. Replace the keys and passwords of integrations with that supplier and warn your people about phishing that uses the leaked data. If your organisation falls under NIS2 or personal data is involved, check whether you have a reporting duty yourself.

How often should I review supplier access?

At least once a year, and always when a contract ends or you change IT partner. Access for a supplier that left years ago rarely appears on anyone's list.

Does this also apply to my own IT partner?

Yes. Your IT partner often has the broadest access of all. That is no reason for distrust, but it is a reason to agree together how that access is secured and how you respond when something goes wrong.

Related services and resources

If you want to know how far someone gets with a supplier's access, start with a network pentest or, for integrations between systems, an API pentest. If you also need that evidence for NIS2, an audit-ready pentest helps, and our page on NIS2 compliance covers the other measures. To play out the scenario of a supplier that is already inside, a red team exercise is the right format. Further reading: the NIS2 penetration testing checklist, the incident response plan for the first hours after an incident, external or internal pentest on which test comes first, and agentic AI supply chain security for the variant where the supplier is a plugin or skill of your AI agent.