Why The Most Dangerous Attack Surface Is The One Nobody Can See

There was a time when finding an organisation’s attack surface was relatively straightforward. You found the servers connected to the internet. The applications employees used. The endpoints sitting on the network. 

Then you looked for vulnerabilities, weak configurations, exposed ports, outdated software and anything else an attacker could use to get inside. None of that has stopped being important. Vulnerabilities still get exploited, credentials still get stolen and forgotten internet-facing systems still create very real security problems.

But modern enterprises no longer work as collections of relatively independent systems. An employee signs into one application through an identity provider. That application connects to another through an API. A service account moves data somewhere else. An automation triggers a workflow in another SaaS platform. 

An AI agent may have permission to access several of those systems and act on a user's behalf. Every individual connection can be completely legitimate. The problem starts when you try to understand what all those connections create together.

The invisible attack surface isn't necessarily made up of systems an organisation doesn't know exist. Increasingly, it's made up of relationships between systems it knows very well, where permissions, authority and trust can travel much further than anyone intended. 

And attackers are getting very good at finding those paths.

The Attack Surface Has Changed Faster Than Our Definition of It

For years, enterprise security had a fairly practical question to answer: what can an attacker reach? That thinking shaped attack surface management. Find the assets. Understand what's exposed. Identify vulnerabilities. Reduce unnecessary access. Keep watching for anything new.

It still makes sense. The difference is that enterprise architecture has changed around it. Cloud computing moved infrastructure outside traditional network boundaries. Software-as-a-Service (SaaS) platforms created sprawling ecosystems of connected business applications. 

APIs made it easier for those applications to exchange information. Federated identity allowed employees to move between services without signing in every time. Automation began connecting workflows that used to require people to move data manually.

Now AI is adding another layer, with agents and assistants being given access to enterprise applications, databases and business processes so they can do more than generate an answer on a screen. The result isn't simply a larger attack surface. It's a different kind of one.

An organisation may have a perfectly accurate inventory showing that it uses Microsoft 365, Salesforce, ServiceNow, Slack and dozens of other platforms. It might know exactly which servers it owns and which cloud workloads are running. What the inventory can't necessarily tell you is how authority moves between them.

• Which applications can access Microsoft 365 on behalf of employees? 
• Which integrations can pull information from Salesforce? 
• Which service accounts have administrative permissions? 
• Which API token created three years ago still works? Which automation can trigger another automation?
• More importantly, what happens when one of those trusted relationships is compromised?

That question is becoming harder to answer because many of the pathways attackers use don't exist as standalone assets. They exist between assets. If attackers increasingly abuse trusted relationships rather than broken systems, are organisations looking in the right place?

Modern Enterprises Run on Trust Rather Than Direct Control

None of these connections appeared because security teams stopped paying attention. They exist because modern businesses need them. Imagine asking employees to create a separate account for every SaaS application they use, with no single sign-on or federated authentication. 

Or requiring someone to manually transfer information between every business application because APIs aren't allowed. The security implications might look appealing for about five minutes. Then the business would grind to a halt. Modern enterprise architecture depends on systems trusting other systems enough to work together.

Identity providers tell applications that a user is who they claim to be. APIs let applications exchange information. Service accounts allow automated processes to work without someone signing in every time. Third-party integrations connect platforms from completely different vendors.

Then there are non-human identities, the credentials used by machines, applications, workloads and automated processes rather than people. These can include service accounts, API keys and authentication tokens.

AI agents make the relationship even more interesting because they're increasingly being designed to take actions. An agent might read an email, retrieve customer information, update a record, create a support ticket and notify another system without someone manually performing each step.

For any of that to work, something has to trust something else. And there are now a lot of somethings. Cloud Security Alliance's January 2026 research into non-human identity and AI security found that 78 per cent of organisations don't have documented, formally adopted policies for creating or removing AI identities. 

Only 12 per cent said they were highly confident in their ability to prevent attacks through non-human identities. Those numbers become easier to understand when you consider how these identities develop. A developer creates an API key for a project. A team connects another SaaS platform six months later. 

Someone gives a service account additional access because a workflow changes. An employee leaves, but the integration they configured is still needed. Then another system starts depending on it. Each decision can make complete sense at the time. Three years later, the organisation may be left with a chain of dependencies nobody deliberately designed.

So the real question isn't whether enterprises should stop creating trust relationships. They can't. It's whether anyone can still explain all the trust they've already created.

Complexity Creates an Attack Surface Nobody Designed

This is where the problem starts to look less like conventional vulnerability management and more like architecture. A single application can be properly configured and secure. So can the application connected to it. And the identity platform authenticating both of them. Yet the relationship between those systems can still create an exploitable path.

Take OAuth, for example. OAuth is an open standard that allows one application to access information or services from another without asking a user to hand over their password. It's why you can grant an application access to your Microsoft or Google account and revoke that access later. Used correctly, it's an important security mechanism.

But it also creates delegated authority. You're effectively telling one application that it has permission to do something somewhere else. Now multiply that across hundreds of applications, thousands of users and years of accumulated integrations. The same pattern appears with shared service accounts, inherited administrative permissions, long-lived API tokens and automated workflows.

An AI agent can add another link. Give one permission to read email, another to access customer records and another to update business systems, and the organisation hasn't necessarily created three separate risks. It may have created one connected pathway through all three.

This is delegated trust becoming part of the attack surface. The individual components don't have to be vulnerable in the traditional sense. Exploitability can emerge from how they have been combined.

Microsoft provided a useful real-world example in March 2026 when its researchers documented attackers abusing legitimate OAuth redirection behaviour in phishing and malware campaigns. The attackers weren't exploiting a software flaw in OAuth. 

They deliberately triggered standard authentication behaviour so victims could be redirected through trusted identity-provider infrastructure towards attacker-controlled destinations. Microsoft described it as a class of identity threat abusing OAuth's normal, by-design behaviour rather than exploiting a vulnerability or stealing credentials.

That's an important distinction. Traditional security often looks for something behaving incorrectly. But here, the technology can behave exactly as designed while an attacker uses that behaviour for a completely different purpose. The weakness exists in the assumptions around the interaction.

One team assumes an authenticated connection is trustworthy. Another assumes permissions granted to an application remain appropriate. Another owns the identity platform. Someone else manages the SaaS application. The vendor controls part of the underlying infrastructure.

Everyone understands their piece. Nobody necessarily owns the complete relationship. And if nobody understands the complete chain of trust, how do you verify it?

Attackers Are Increasingly Exploiting Trust Instead of Breaking Technology

Real-world incident data suggests attackers have already worked this out. Palo Alto Networks' Unit 42 analysed more than 750 major incidents for its 2026 Global Incident Response Report. Identity appeared in 89 per cent of investigations, while 87 per cent of incidents involved two or more attack surfaces. Another 67 per cent crossed at least three.

Think about what those numbers actually describe. An attacker doesn't compromise an endpoint and stay there. They might begin with social engineering, gain access to an identity, move into SaaS applications, reach cloud services and use legitimate permissions to keep moving.

The incident becomes a chain. That's why treating endpoint security, identity security, cloud security and SaaS security as entirely separate problems can create gaps even when each team is doing its job well.

Verizon's 2026 Data Breach Investigations Report shows another side of the same change. While vulnerability exploitation became the most common initial access route at 31 per cent of breaches, third-party involvement increased by 60 per cent and was present in 48 per cent of breaches.

Almost half of the breaches Verizon studied involved someone outside the organisation's direct environment. That's the uncomfortable reality of third-party risk in a deeply connected enterprise. A company can strengthen its own infrastructure, patch aggressively and carefully manage employee accounts. 

But if a trusted supplier, SaaS provider or connected application is compromised, the attacker may inherit a relationship that already crosses the boundary. They don't always need to break through the front door if someone inside has already authorised another entrance. 

CrowdStrike's 2026 Global Threat Report adds speed to the problem. It found AI-enabled adversary activity increased by 89 per cent year on year, while the average time taken for an eCrime attacker to move laterally after gaining access fell to 29 minutes. The fastest recorded breakout was just 27 seconds. 

CrowdStrike also observed intrusions moving through trusted identities, SaaS applications and cloud infrastructure in ways that can blend into normal activity. That last part is particularly difficult for defenders. Malware is malicious. A known exploit has recognisable characteristics.

But a valid user account accessing an application it's allowed to use looks very different. So does a legitimate OAuth token. Or a service account making an approved API call. Or an authorised application requesting information it has permission to access.

Attackers can perform malicious actions through legitimate mechanisms, which means the activity may satisfy the technical rules organisations created to decide what should be trusted. The security problem then changes from spotting something obviously bad to understanding whether something apparently normal still makes sense.

And that requires more than seeing it happen.

Visibility Alone Is No Longer Enough

Security teams have spent years trying to improve visibility, for good reason. You need inventories to know what assets exist. Attack surface management helps identify exposed systems and weaknesses. Endpoint and network telemetry show what systems are doing. Identity tools record authentication and access. 

Cloud platforms generate logs. Observability tools help teams understand what is happening across increasingly distributed environments. Removing any of those capabilities would leave organisations considerably worse off. But there's a difference between seeing something and understanding it.

• A dashboard might show that an application accessed customer data through an API. It can't automatically answer why the application has that permission in the first place. 
• An identity platform can show that a service account authenticated successfully. It may not tell you that the account was originally created for a project that ended two years ago, but five other processes now depend on it.
• An asset inventory can tell you which SaaS platforms the organisation uses. It can't necessarily show every downstream system that becomes reachable if one trusted integration is compromised.

This is where security visibility reaches its natural limit. The next question is context.

• Why does this relationship exist?
• Who owns it?
• What authority does it create?
• Is that authority still necessary?
• What else depends on it?
• And what happens if the thing being trusted stops being trustworthy?

Answering those questions turns visibility into verification. Instead of assuming a relationship remains safe because it was approved once, organisat ions can keep checking whether the original reason for granting trust still applies.

That might mean reviewing application permissions as workflows change, mapping the systems accessible through critical machine identities, removing integrations nobody owns, limiting long-lived credentials, or testing what an attacker could actually reach after compromising one trusted component.

The goal isn't to make every system independent. Modern enterprises couldn't operate that way. It's to make the dependencies understandable enough that security teams know what they're trusting before an attacker demonstrates it for them. Which moves the problem out of the security operations centre and into a much broader conversation about governance.

Security Leadership Must Start Governing Relationships, Not Just Assets

Boards have become much more comfortable asking questions about cybersecurity.

• How many critical vulnerabilities do we have?
• Are important systems patched?
• Have employees completed security training?
• What's our exposure to ransomware?

Those questions still deserve answers. But they don't tell leaders whether the organisation understands the security architecture its business now depends on. That requires a different set of questions.

For example:

• Which trust relationships would create the largest impact if compromised?
• Where has authority accumulated across multiple systems?
• Which machine identities or integrations have access nobody has reviewed recently?
• Which security assumptions have never actually been tested?
• Which third-party dependencies could give an attacker access to critical services?
• Can anyone explain how our most important business processes work end-to-end?
• Which AI agents can take actions, and how far can those actions travel?
• Where would an incident cross organisational or technology boundaries before someone noticed?

These aren't questions a CISO can necessarily answer alone. Identity teams may understand authentication. Application owners understand their platforms. Infrastructure teams understand networks and cloud environments. Procurement understands suppliers. Developers understand integrations. Business teams understand why certain workflows exist.

The problem is often found in the connections between their answers. That makes cyber governance increasingly dependent on shared understanding rather than simply shared policies. Critical trust relationships need ownership. Delegated authority needs limits. 

Third-party connections need to be considered as part of operational architecture rather than something that ends with procurement. Machine identities need lifecycles just as human accounts do. AI autonomy needs to be judged partly by what systems an agent can reach and what actions those systems will accept.

None of this means trying to eliminate trust. It means treating trust as something organisations actively govern rather than something technology quietly accumulates. Because once a business depends on hundreds or thousands of interconnected services, understanding those relationships becomes part of operational resilience itself.

Final Thoughts: The Greatest Security Risk Is Often Trusted by Design

The attack surface hasn't stopped including vulnerable software, exposed infrastructure or badly configured systems. It's simply grown beyond them.

Modern organisations run on networks of identities, applications, APIs, suppliers and automated workflows. Those relationships make businesses faster and easier to scale, but they also create paths attackers can exploit without breaking a single system.

The hidden attack surface isn't unknowable. But understanding it means looking beyond individual assets to the relationships, permissions and assumptions that connect them.

As enterprise environments become more autonomous and interconnected, cyber resilience will increasingly depend on that understanding. The organisations best prepared for what's next won't necessarily be those with the fewest vulnerabilities. They'll be the ones that recognise when legitimate trust has quietly become an opportunity for exploitation.

EM360Tech will continue examining how security, identity, infrastructure and AI are reshaping those relationships, and what enterprise leaders can do to stay ahead of the risks they create.