In short: Attackers target mid-sized European organisations because they hold valuable data, sit inside larger supply chains and rarely run a red team. Here are the attack paths they use, why annual tests miss them, and how continuous red teaming closes the gap.
Attackers target mid-sized European organisations because they hold data and access worth stealing, connect into larger organisations' supply chains, and rarely have a red team testing what an attacker could actually reach. The gap is not awareness. It is evidence.
Most mid-sized organisations know they are a target. When ENISA surveyed European SMEs, 90% said a cybersecurity incident would seriously affect their business within a week, and 57% said it would most likely put them out of business (ENISA, Cybersecurity for SMEs, June 2021). What they usually lack is proof of which weaknesses an attacker could exploit today, and how those weaknesses connect.
What makes mid-sized organisations attractive to attackers?
Three things, usually in combination.
- Valuable data and access. Client funds, patient records, payment data and personal data sit behind the same kind of controls as in larger firms, but with fewer people testing them.
- Trust relationships with larger organisations. A mid-sized supplier often holds remote access, API keys or shared accounts into its customers' environments. Compromising the supplier is a route into the customer.
- No standing offensive capability. The security team is capable, but nobody is paid to think like an attacker full time. Offensive specialists are scarce, expensive and hard to keep busy inside one organisation.
Which attack paths do attackers use against mid-sized organisations?
Attackers rarely need one critical vulnerability. They chain several modest weaknesses into a path. The links we see most often in mid-sized environments are:
Leaked or reused credentials. A password from an old breach dump still opens a VPN, a webmail portal or a SaaS admin console.
Forgotten internet-facing assets. A test server, an old subdomain or an admin panel that was never meant to be public.
Over-permissioned integrations. A third-party tool or service account granted far more access than its job needs.
Impersonation. Lookalike domains and fake executive profiles used to make phishing and payment fraud convincing.
Lateral movement and privilege escalation. Once inside, weak internal segmentation and shared admin accounts let an attacker move towards the systems that matter.
A typical chain: a leaked credential works on an exposed login with no multi-factor authentication, that account can read a service account's secrets, and the service account has administrator rights on the file server holding client data. Each finding on its own would sit mid-table in a scan report. Together they are a breach.
Why don't annual pentests and vulnerability scanners answer the question?
Because one tests a single moment and the other never proves anything.
Traditional testing validates one moment in time. Attackers exploit what changed afterwards: the new cloud service, the integration granted wider permissions, the vulnerability disclosed the week after the test. Scanners have the opposite problem. They run constantly but leave the team to decide which of thousands of findings an attacker could actually use. Our CODE24 case study shows what happens when a team moves from scanner output to proven risk.
What do NIS2 and DORA mean for mid-sized organisations?
NIS2 applies to medium-sized organisations, not only large ones. An organisation in a covered sector is generally in scope once it has 50 or more staff, or turnover or balance sheet above €10 million (Centre for Cybersecurity Belgium). DORA requires EU financial entities to test their digital operational resilience, with the depth of testing scaled to their size and risk.
Both frameworks ask for evidence that security measures work. Proven attack paths, and retests showing they were closed, are that evidence. Hackurity produces evidence that supports NIS2, DORA, ISO 27001, PCI DSS and GDPR. No vendor can make an organisation compliant on its own.
How can an organisation without a red team test like one?
Autonomous red teaming continuously simulates attacker behaviour to validate which weaknesses can be exploited, how attack paths connect, and what an attacker could actually reach. It gives a mid-sized organisation the attacker's view without hiring a red team.
Hackurity delivers it through the ART Stack, and each product maps to the attack paths above:
- Managed Autonomous Pentesting (MAP) finds forgotten assets, exposed logins and over-permissioned integrations, then chains them into attack paths using payload-less exploitation. exMAP tests from the internet; inMAP tests from inside the network, as an attacker who already has a foothold.
- Autonomous Threat Intelligence (ATI) tracks breach dumps, underground marketplaces and phishing infrastructure to show which credentials and identities attackers are preparing to use.
- Autonomous Brand Defence (ABD) finds lookalike domains and executive impersonation, then coordinates takedowns with human support.
Every finding is verified by our own red team before it reaches you. They confirm what is real, remove what is not, and work with your team on remediation. All technology is built in-house. Hackurity does not monitor, alert, block or respond to incidents: it proves what an attacker could reach, so you can close it.
What should you ask before your next security test?
- Do we know which of our weaknesses an attacker could chain together today, or only which ones exist?
- How much has our environment changed since our last penetration test?
- Which suppliers and integrations hold access into our systems, and has anyone tested that access as an attacker would?
- If a new attack path opened tomorrow, how long before we knew?