Your Attack Surface Is Bigger Than You Think

The attack surface the security team has been defending is a fraction of the actual surface. The asset the security team knows about, the system the security team has patched, the application the security team has tested, the surface that…

A single brass snow globe on a dark wood surface, dim warm amber side light, deep navy shadows, no people visible.

The attack surface the security team has been defending is a fraction of the actual surface. The asset the security team knows about, the system the security team has patched, the application the security team has tested, the surface that the attacker does not even bother with because the attacker has found something the security team has not been looking at. The honest framing matters here, because the attack surface the security team has been reporting to the board counts as the the attack surface the breach disclosure will reveal was a fraction of the actual surface.

What follows runs as the working version of the field guide. The shorter version is what the security team actually has time to read.

Where the hidden surface lives

Three places, in roughly that order of how much each one contributes. The first runs as the shadow IT, where the SaaS subscription the line of business bought without asking the IT team, the cloud account the developer created with the personal credit card, the SaaS and the cloud account that the security team does not know about, the shadow IT that. the the entry point the attacker finds through the public DNS record. The second runs as the forgotten subdomain, where the subdomain the marketing team set up for the campaign three years ago, the subdomain that still points to the cloud storage bucket, the subdomain that the security team did not decommission when the campaign ended, the forgotten subdomain that is what the entry point the attacker finds through the certificate transparency log. The third runs as the legacy integration, where the API the production system calls, the API the original developer wrote, the API the original developer left in production, the API the security team did not test because the security team did not know the API was still in production, the legacy integration that , the the entry point the attacker finds through the documentation leak.

How the attacker finds it

Three ways, in roughly that order of how much each one works. The first runs as the certificate transparency log, where the attacker watches the certificate transparency log the CA publishes, the log that lists every certificate the enterprise has issued, the log that reveals the subdomain the security team did not know about, the log the attacker queries for free. The second runs as the DNS enumeration, where the attacker runs the DNS enumeration (the subfinder, the amass, the crt.sh) to find the subdomain, the subdomains the security team has been hiding through the obscurity the attacker has been bypassing for years, the enumeration that produces the entry point the attacker uses. The third runs as the leaked credential, where the attacker buys the credential dump from the previous breach, the credential the employee reused across the SaaS the IT team did not know about, the credential the attacker tests against the public SaaS, the leaked credential that grants the access the attacker uses to land inside.

How to find it before the attacker does

Three moves if you are the security team that wants to know the actual attack surface, not the attack surface the security team has been reporting. Run the external attack surface scan, because the scan (the Shodan, the Censys, the runZero) the security team can run quarterly, the scan that finds the subdomain, the open port, the forgotten cloud asset, the scan that gives the security team the picture the security team has been missing. Audit the SaaS, because the SaaS the security team should audit (the SaaS Management Platform, the manual review of the expense report), the audit that finds the subscription the line of business bought, the audit that brings the SaaS under the security review the SaaS should have had. Decommission the legacy integration, because the legacy integration the operations team has been postponing, the integration that the next quarter’s roadmap should include, the decommission that removes the entry point the attacker would have found, the decommission that the operations team should have done three years ago. The security team that scans externally, audits the SaaS, and decommissions the legacy serves as the team that has the attack surface the security team has been reporting.

Abstract attack surface as glowing cyan expanding ripple on a dark navy surface, dramatic chiaroscuro lighting from above.
The hidden attack surface in 2026: 3 places the surface hides, 3 ways the attacker finds it, 3 moves to map it before the breach.

The bottom line

The attack surface in 2026 is essentially the the surface the security team has been reporting and the surface the attacker has been using, with the gap between the two being the breach waiting to happen. The shadow IT, the forgotten subdomain, the legacy integration, those three are the hidden places. The certificate transparency, the DNS enumeration, the leaked credential, those three are how the attacker finds it. The external scan, the SaaS audit, the legacy decommission, those three are how the security team gets ahead. The team that does the three holds the line. The team that has not done the three serves as the team that finds out the surface during the breach.

Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading