Enterprise environments don't become complicated overnight. Usually, the complexity builds gradually, one perfectly reasonable decision at a time. A team adopts a cloud service because it solves a problem. Another connects an API so two applications can work together. An acquisition brings its own systems and identities. 

A supplier needs access to something. Somebody creates a service account for an automated process. Infrastructure changes, applications start depending on other applications and permissions that were temporary somehow become permanent. Look at each decision on its own and there may be nothing particularly alarming about it.

Look at how they connect, and the picture can change very quickly. An exposed service might not provide much useful access by itself. Neither might an account with slightly more privilege than it needs. A weak configuration could sit unnoticed for months without causing a problem. 

em360tech image

But if that exposed service leads to the overprivileged account, which can access the misconfigured workload, which connects to something far more sensitive, an attacker doesn't see four manageable security findings. They see a route. That distinction is becoming increasingly important as cybersecurity complexity grows. 

Palo Alto Networks' 2026 Unit 42 Global Incident Response Report found that 87 per cent of attacks investigated involved multiple attack surfaces, while identity weaknesses played a material role in almost 90 per cent of its investigations. Modern cyber attacks don't always depend on finding one catastrophic weakness anymore. 

Sometimes, the real opportunity sits in what several smaller weaknesses become when they're connected. Complexity isn't a vulnerability by itself. But give an attacker enough useful combinations, and it can become something they know how to use.

Complexity Isn't The Same As Vulnerability

Complicated doesn't automatically mean insecure. Large enterprises have complicated technology environments because they have complicated businesses. They operate across countries, business units and regulatory environments. They use multiple clouds and hundreds of applications. 

They work with suppliers, contractors and partners. People, applications, devices and increasingly AI agents all need different levels of access to different things. Trying to all of that down to a beautifully simple architecture might look lovely on a diagram. Running an actual global business tends to get in the way.

The security problem is more specific. A cybersecurity vulnerability is a weakness that can potentially be exploited. Complexity creates something different: more opportunities for separate systems, identities, permissions, dependencies and weaknesses to interact.

When several of those conditions become more dangerous together than they appear individually, we can think of the result as combinatorial risk. Imagine an internet-facing service with a known vulnerability. That vulnerability gives an attacker limited access to an account with excessive privileges. 

Weak network segmentation then allows that account to reach a sensitive workload. On their own, each problem might sit in a different queue with a different owner and a different level of urgency. Together, they form an attack path, which is simply the route an attacker can follow from an initial point of access towards something more valuable.

This isn't an unusual collection of cloud security problems either. The Cloud Security Alliance's Top Threats to Cloud Computing Survey Report 2026 ranks inadequate identity and access management first among current cloud threats, followed by AI-enhanced attacks, insecure third-party resources, insecure interfaces and APIs, misconfiguration and inadequate change control, and AI system compromise. 

CSA's researchers describe a wider shift away from infrastructure-centric concerns towards problems created by identities, interconnected ecosystems, third parties and increasingly autonomous systems. None of those risks exists in a neat little box once an attack starts. Unfortunately for defenders, attackers aren't required to respect the boxes either.

Attackers Don't Have To Respect Security Boundaries

Enterprise security has to divide responsibility somehow. Identity teams manage identities and access. Cloud teams manage cloud environments. Application security teams worry about software. Security operations teams monitor suspicious activity. Infrastructure teams keep services running. 

Suppliers and managed service providers may control entire pieces of the technology environment. There's good reason for all of that specialisation. Nobody can sensibly become an expert in everything. An attacker doesn't have the same organisational problem.

They can begin with a vulnerable public-facing application, use it to obtain credentials, use those credentials to gain additional privileges, move into a cloud environment and eventually access data sitting somewhere that the application team responsible for the original vulnerability may never have been thinking about.

The attack has crossed several security domains. From the attacker's perspective, though, it's still one attack. Unit 42's findings make that disconnect particularly clear. Alongside finding that 87 per cent of attacks crossed multiple attack surfaces, its 2026 research found identity weaknesses involved in 89 per cent of investigations. 

Attackers were often using stolen credentials and tokens to escalate privileges and move laterally through fragmented environments. This creates an awkward problem for enterprise cybersecurity. A security team can correctly identify every weakness involved in an eventual breach. 

Each owner can assess their individual problem properly. The organisation can even remediate large numbers of findings and still leave the route itself intact. Because categorising a weakness tells you what it is. It doesn't necessarily tell you where it can take someone.

Small Weaknesses Can Create Bigger Attack Paths

Security teams already spend an enormous amount of time dealing with things that aren't quite right. There are accounts with broader permissions than they really need. Old integrations nobody wants to switch off because somebody, somewhere, might still depend on them. 

Third parties with access to several systems. Service accounts created for projects that finished two years ago. Applications running packages that need updating. Firewall rules that made sense when they were created and somehow survived three infrastructure redesigns. Not every one of those is an emergency.

That's partly what makes the problem difficult. Consider a third-party account with more access than its current role requires. By itself, there may be little reason to treat it as a critical threat. But if those permissions allow the account to reach a sensitive cloud workload, its importance changes. 

Add another exploitable weakness somewhere along that route and the risk changes again. Machine identities make this especially interesting. These are accounts used by applications, services, automated workloads and other non-human systems rather than people. 

Tenable's 2026 Cloud and AI Security Risk Report found that 52 per cent of non-human identities in its research had critical excessive permissions, compared with 37 per cent of human identities. The same research found considerable third-party exposure across cloud environments, including external accounts capable of assuming risky permissions.

Again, this doesn't mean every overprivileged machine identity or external account is waiting to become a breach. It means you can't judge the real cybersecurity risk of that identity from its permissions alone. You also need to know what it can reach, what trusts it, what other weaknesses exist along the way and what an attacker could do next.

Once risk starts behaving like that, simply sorting individual findings from most severe to least severe becomes a little less useful.

Why Severity Doesn't Always Tell You What An Attacker Sees

Security teams need prioritisation. Without it, they'd be trying to fix everything at once, which usually means fixing very little particularly well. Vulnerability severity gives teams a consistent way to understand how serious a technical weakness could be. 

Organisations can then add other information such as whether exploitation is known to be happening, how critical the affected asset is and how exposed it is. None of that suddenly stops being useful because attack paths exist. The problem appears when individual severity gets treated as the same thing as contextual risk.

A severe vulnerability on an isolated system that contains nothing particularly valuable and can't reach anything else may still require remediation. But it may pose less immediate business risk than three moderate weaknesses that connect an internet-facing service to a privileged identity and then to sensitive customer data.

The attacker is interested in the destination as much as the individual weakness. That means security teams need both views.

Severity asks how bad the weakness is

Traditional vulnerability management helps organisations answer several important questions. 

  • How technically serious is this vulnerability? 
  • Is it easy to exploit? 
  • Is there evidence attackers are already using it? 
  • Which system does it affect, and how important is that system to the business?

Those questions help turn thousands of findings into something teams can actually work with. They also remain increasingly urgent. Verizon's 2026 Data Breach Investigations Report found exploitation of vulnerabilities had become the most common initial access vector in its breach dataset, accounting for 31 per cent of breaches. 

Credential abuse, previously the leading route, fell to 13 per cent. So the answer clearly isn't to care less about vulnerabilities. It's to ask one more question after you've found them.

Attack paths ask what the weakness can lead to

Attack path analysis looks at what could happen after a weakness is exploited. 

The distinction is fairly simple: Severity measures the danger of a weakness. Attack path analysis examines what an attacker could reach by using it. That changes remediation from a conversation about isolated scores into one about relationships, reachability and business consequence.

The difficulty, of course, is scale. Finding one dangerous chain through an environment is manageable. Doing the same thing continuously across a modern enterprise is another problem entirely.

Complexity Is Growing Faster Than Manual Analysis

Adding one new service to an enterprise doesn't always create one new security relationship. It might create several. The service needs an identity. That identity needs permissions. The application connects to an API. Data moves to another platform. 

An automated process gets access to it. A supplier might support it. Logs go somewhere else. The service depends on third-party software, which depends on its own components. One new thing has now interacted with a collection of things that were already there.

Repeat that process across cloud workloads, SaaS applications, APIs, machine identities, AI agents, suppliers and software dependencies, and enterprise complexity doesn't grow in a tidy straight line. The possible relationships multiply too. This is particularly visible as organisations start creating identities for autonomous and AI-enabled systems. 

A 2026 Cloud Security Alliance survey found fewer than a quarter of surveyed organisations had formally adopted policies governing the creation or removal of AI identities, while more than 16 per cent weren't tracking the creation of new AI-related identities at all. Only 12 per cent reported high confidence in their ability to prevent attacks involving non-human identities.

The challenge here isn't simply whether somebody can draw a perfect diagram of the entire architecture. It's whether the security team can identify which combinations currently create a usable attack path, then keep doing that as the environment changes. Manual analysis struggles once the number of relationships becomes large enough. 

Even if every team understands the systems it owns, no individual analyst can continuously test every possible combination of permissions, vulnerabilities, network routes and dependencies across a major enterprise. Attackers don't need to test every combination either. They only need to find one that works. And they're getting considerably faster at doing it.

Attack Speed Makes Complexity More Valuable

There has always been a gap between a vulnerability appearing and organisations fixing it. For years, patching programmes have been built around reducing that window as much as reasonably possible. The window is now becoming uncomfortable in a completely different way.

Google Cloud's M-Trends research estimates that mean time to exploit fell from 63 days in 2018 to minus seven days in 2025. A negative figure means attackers were, on average, exploiting vulnerabilities before a patch had been released. Attackers are also getting faster at working together.

M-Trends 2026 found that the median hand-off time between an initial access actor and a secondary threat actor fell from more than eight hours to just 22 seconds over three years. Twenty-two seconds doesn't leave much room for an organisation to admire how nicely its security responsibilities have been divided between departments.

IBM X-Force has seen the same acceleration from another direction. Its 2026 research recorded a 44 per cent year-on-year increase in attacks beginning with exploitation of public-facing applications, with IBM pointing to both persistent security gaps and AI-assisted vulnerability discovery as contributing factors.

This is where AI becomes relevant without needing to become the whole story. AI can help adversaries perform reconnaissance, identify weaknesses, analyse code and automate parts of an attack more quickly. IBM's 2026 Cost of a Data Breach research found one in four malicious breaches in its study were AI-enabled, a 56 per cent increase from the previous year.

But AI doesn't need to create the underlying security problem to make it more useful to attackers. The vulnerable application, excessive permission, forgotten account and weak network boundary may have existed already. Faster analysis simply makes it cheaper and easier to find combinations worth pursuing.

Which leaves defenders with an uncomfortable asymmetry. They have to maintain enough control across a complicated environment to stop dangerous combinations from forming. An attacker needs one route.

Reducing Risk Doesn't Always Mean Removing Complexity

At this point, “make everything simpler” sounds like an appealing answer. It's also not a particularly useful one. 

Enterprises aren't going to abandon cloud computing, stop using APIs, remove every supplier, consolidate every application onto one platform and tell half their automated workloads they no longer get an identity because the security architecture would look cleaner. Some complexity is the cost of running a modern business.

But not all complexity earns its keep. The more practical goal is to remove the connections and conditions that create unnecessary risk. That changes the question from:

How many weaknesses do we have?

to:

Which combinations give an attacker somewhere useful to go?

Sometimes the answer will still be patching a vulnerability. Elsewhere, it may be removing a permission that nobody needs anymore, restricting third-party access, disabling a dormant service account or segmenting systems so limited access can't turn into lateral movement. 

Are you enjoying the content so far?

Organisations can also look for controls that sit across several possible routes. If one overprivileged identity appears in five viable attack paths, reducing its permissions may eliminate all five at once. That's a different way of thinking about cyber risk reduction. The goal isn't to reach zero vulnerabilities before you can meaningfully improve security. 

That's not a realistic target for most large environments anyway. It's to understand where one change can make the environment substantially harder to navigate. And that gives security leaders a useful way to test whether their existing programme is really prioritising risk, or simply prioritising findings.

Are You Managing Findings Or Attack Paths?

Most mature security programmes are very good at finding problems. The harder question is whether those problems are being connected well enough to show what an attacker can actually do with them. A few questions can reveal the difference.

Can you see how weaknesses connect?

A vulnerability scanner can tell you there's a problem with an application. An identity platform can tell you an account has excessive permissions. A cloud security tool might identify a misconfigured workload. But can your teams see what happens when those three findings belong to the same route?

Useful exposure management needs context across traditional security domains. Teams need to be able to connect vulnerabilities with identities, permissions, reachable assets, third-party access and business-critical systems. Several low or moderate findings may deserve much more attention once that relationship is visible.

Do your priorities change when context changes?

Risk isn't fixed simply because the vulnerability itself hasn't changed. A new permission can make an existing weakness more useful. Connecting an application to another workload can change what becomes reachable. Removing a security control can turn a previously blocked attack path into a viable one.

So remediation priorities need some ability to change with the environment. A vulnerability that sat halfway down yesterday's queue may deserve a very different position today if its blast radius has suddenly expanded. This is where continuous exposure management becomes more useful than occasional assessments. 

The aim isn't merely to rescan the same environment more often. It's to reassess what the current relationships mean as conditions change.

Can you identify the weakest link in an attack path?

Once an attack path is visible, the most severe vulnerability in it isn't automatically the best place to intervene. There may be a permission that can safely be removed. A network connection that doesn't need to exist. A dormant identity that can be deleted. A supplier account that can be restricted to one system instead of five.

Breaking any one of those links may make the rest of the path useless. That is where attack-path thinking can change remediation economics. Instead of asking teams to fix everything everywhere, leaders can look for changes that remove the greatest number of viable routes with the least operational disruption.

The result isn't a smaller list of security problems because somebody filtered the dashboard more aggressively. It's an environment with fewer useful options for the attacker.

Security Has To Think In Systems

Cybersecurity became specialised for good reason. Cloud security is complicated. Identity is complicated. Application security is complicated. Infrastructure, endpoints, networks, software supply chains and third-party risk all require their own expertise. Trying to undo that specialisation would solve very little.

The bigger risk appears when the organisation's understanding of security becomes as fragmented as the teams responsible for protecting it. Attackers can connect an application vulnerability to a stolen identity, a cloud permission and a third-party service because those things already interact in the real environment. 

The fact that four different teams manage them doesn't create four different realities. Security decisions need enough shared context to follow those relationships too. This doesn't require another promise that organisations will achieve perfect visibility, eliminate every vulnerability or somehow maintain flawless control over thousands of constantly changing systems.

It means developing a security model capable of asking better questions. 

  • What can connect to what? 
  • What can lead where? 
  • Which combinations create unacceptable business risk?

Those questions pull vulnerability management, identity security, security architecture and attack path management into the same conversation without pretending they need to become the same discipline. And they change what enterprise security is ultimately trying to manage.

Because complexity becomes dangerous when the organisation manages the pieces while the attacker uses the system.

Final Thoughts: Attackers Exploit The Path, Not The Pieces

Most of the complexity inside an enterprise arrived for a reason. The cloud platform made something faster. The API connected two systems that needed to share information. The supplier brought specialist expertise. The service account automated work nobody wanted an employee doing manually at three in the morning.

Very few of those decisions look like security failures when they're made. But they don't stay isolated. Permissions connect to identities. Identities connect to workloads. Applications depend on third parties. Vulnerabilities exist inside networks where one compromised system can sometimes reach another.

That's how ordinary complexity can begin creating extraordinary risk. Complexity becomes an attack vector when individually manageable weaknesses combine into a route an attacker can use. Once you look at cybersecurity from that perspective, finding more problems isn't necessarily the same thing as understanding more risk. 

Severity still has a place. So do inventories, scanners, identity controls and all the other tools security teams already depend on. But the relationship between those findings increasingly deserves the same attention as the findings themselves. 

As enterprise environments become more connected, automated and dependent on third parties, those relationships are likely to multiply. The organisations best prepared for what comes next may not be the ones that can produce the longest list of weaknesses. They'll be the ones that can recognise which few become something much bigger when they connect.

EM360Tech will continue following that shift, from the techniques changing how attackers move through enterprise environments to the security strategies helping leaders reduce the paths available to them.