Digital footprint analysis and security costs: what the data actually shows
Julian ThorneApril 29, 2026
Key takeaways
In Vulnox assessments across 84 client environments, 73% had at least one forgotten subdomain pointing to a live server running outdated software — assets the security team did not know were active and externally reachable.
SOC2-compliant organizations showed only a 12% reduction in externally facing vulnerabilities compared to non-compliant peers in the same assessment set, because SOC2 does not require external attack surface enumeration.
58% of assessed organizations exposed data through publicly accessible cloud storage buckets — not through breaches, through misconfiguration that had been in place since initial deployment.
The external attack surface expands continuously without action: every new SaaS integration, developer sandbox, and marketing subdomain adds potential exposure that internal vulnerability scanners never see.
The breach cost calculation that justifies digital footprint analysis is not the average breach figure — it is the expected cost weighted by the probability of an externally-initiated compromise, which is higher for organizations with unmonitored external assets.
One action this week: run a passive subdomain enumeration on your primary domain using a tool like dnsx or a service like SecurityTrails. Count the results. Compare that number to the assets your security team actively monitors. The gap is your unmonitored attack surface.
TL;DR
The external attack surface grows faster than internal security teams track it. Forgotten subdomains, misconfigured cloud buckets, and exposed API endpoints are not edge cases — they are consistent findings across organizations that passed their last compliance audit. Digital footprint analysis is the practice of finding these assets before an attacker does. The cost argument is not complicated: finding and closing an exposed asset costs less than responding to the breach it enables. The hard part is getting organizations to pay for the prevention of incidents that, by definition, never appear in the incident log.
The asset no one remembered owning
A 300-person fintech operating in Southeast Asia engaged us after a regulatory inquiry flagged suspicious outbound traffic from an IP address registered to their organization. The IP was not in their asset inventory. It was not monitored by their SIEM. Their IT team had no record of deploying anything at that address. What the address resolved to was a staging environment for a product that had been deprecated 18 months earlier. The subdomain had been created by a developer during a pilot, pointed at a cloud instance that was never terminated, and forgotten when the project was shelved. The instance was running a web framework version with a known remote code execution vulnerability published 14 months prior. Someone had found it, not through targeted reconnaissance against this company specifically, but through automated scanning of the IP ranges associated with their cloud provider. The entire initial access chain — discovery, exploitation, persistence — had happened on infrastructure the security team did not know existed.
The question the CISO asked after the assessment was the right one: how do we find the things we do not know we have? The answer is not a better internal scanner. Internal scanners operate against known assets. External attack surface enumeration starts from the attacker's position — what can be found from outside, with no prior knowledge of the internal inventory.
How external attack surface exposure actually accumulates
The external attack surface of a mid-market organization expands through three mechanisms that operate largely outside the visibility of the security team. The first is organic infrastructure growth: developers spin up cloud instances, create subdomains for testing, and deploy staging environments on schedules that do not include security review. These assets are created with intent, used temporarily, and then forgotten without being decommissioned. The second is SaaS and third-party integration: every new platform connected to organizational identity — a marketing automation tool, a CRM integration, a developer tool — creates an external-facing authentication surface. OAuth grants accumulate. API keys are issued and not rotated. The third is acquisition and organizational change: companies that have been acquired, merged, or restructured carry legacy infrastructure from predecessor organizations. The original team that understood the architecture is gone. The assets remain.
Example
The subdomain lifecycle is the clearest illustration. A developer creates a subdomain for a product launch: launch.company.com. It points to a cloud instance running a web application. The launch completes. The subdomain is left in DNS because removing DNS records requires a process no one prioritizes. The cloud instance is eventually stopped but not terminated. Six months later, a different team spins up a new instance and the stopped instance auto-starts on a scheduled task no one remembers configuring. The subdomain still resolves. The instance is now running software that is 18 months behind on patches. It is reachable from the internet. It does not appear in any asset inventory because the asset management process starts with 'what do we know we have,' not 'what can be found from outside.'
Passive subdomain enumeration using certificate transparency logs — specifically the crt.sh database, which logs all certificates issued by trusted certificate authorities — reveals subdomains that were never intended to be public but had TLS certificates issued for them. Every subdomain that received a certificate appears in the CT log permanently, regardless of whether the subdomain is still active or the organization remembers creating it. This is the first data source an attacker uses. It is also frequently the last one an internal security team checks.
What the assessment data shows across 84 client environments
Assessment base: Vulnox assessment data, 2024-2025, 84 client environments across fintech, SaaS, healthcare, and logistics sectors in Europe, Southeast Asia, and North America
Forgotten subdomains with live vulnerable software: 73% of assessed environments
In 73% of the 84 environments assessed, we found at least one subdomain that pointed to a live server running software the organization no longer actively managed. In most cases, the client's security team had not included these subdomains in their vulnerability scanning scope because they did not appear in the internal asset inventory. The servers were externally reachable, indexed by search engines in many cases, and running software versions with published CVEs. The median age of the forgotten asset from last intentional access to our discovery was 14 months.
The security team's vulnerability management program was accurate for what they knew they had. The problem was the assumption that internal asset inventory reflected external exposure. It does not. Every asset management program has a boundary condition: it tracks assets that were added to it. Externally-initiated enumeration has no such boundary.
Publicly accessible cloud storage without access controls: 58% of assessed organizations
In 58% of assessed organizations, we found at least one cloud storage bucket — S3, Azure Blob Storage, or GCP Cloud Storage — configured for public access. The contents ranged from marketing assets (low sensitivity) to database backups and API configuration files containing credentials (high sensitivity). The misconfiguration was not the result of an attacker changing settings. It was the original deployment configuration, often because the developer creating the bucket had set public access to facilitate sharing during development and the setting was never reviewed before production.
The client assumption in almost every case was that storage buckets were not public because no one had intentionally made them public. The actual configuration had been public from day one. This class of misconfiguration is invisible to internal network scanning because the buckets are not on the internal network — they are cloud-hosted, externally reachable, and only visible through external enumeration of the organization's cloud footprint.
SOC2 compliance correlated with only 12% reduction in external vulnerabilities
Across the assessed environments, organizations with active SOC2 certification showed a 12% reduction in externally facing vulnerabilities compared to non-certified peers. The client complaint, paraphrased from multiple engagements: 'We passed the SOC2 audit last quarter. How is this possible?' The answer is that SOC2 Trust Services Criteria address availability, confidentiality, processing integrity, privacy, and security — but the security criteria focus primarily on logical and physical access controls, change management, and risk assessment processes. None of the Trust Services Criteria require external attack surface enumeration or subdomain inventory.
Passing a SOC2 audit is meaningful for the controls it tests. It is not a signal about external attack surface posture, because external attack surface management is not what SOC2 tests. Organizations that treat compliance certification as a proxy for security posture create a gap between what the audit confirmed and what an attacker can find. That gap is what digital footprint analysis closes.
The organizations with the most mature internal security programs have the largest unmonitored external footprints
Common belief
Organizations that have invested heavily in internal security — SIEM, EDR, vulnerability management programs, regular internal penetration tests — have proportionally stronger external security posture because security maturity compounds across all domains.
What we found
In assessments of organizations with dedicated security operations teams and established vulnerability management programs, we consistently found larger external footprints than in smaller organizations — not because the security teams were worse, but because the organizations were larger and had more historical infrastructure. A 500-person company that has been operating for eight years has had eight years of developer activity, product launches, marketing campaigns, and abandoned projects, each of which may have left external-facing assets. The security team inherited all of it.
Internal security maturity and external attack surface visibility are not correlated because they are built by different teams using different processes. A mature internal security program is built around known assets: servers in the inventory, endpoints on the MDM, applications in the CMDB. External attack surface is built around unknown assets: the subdomain created by marketing, the developer sandbox in a personal cloud account, the OAuth integration a product manager configured without IT involvement. The same organizational scale that produces security maturity also produces more shadow IT, more SaaS sprawl, more developers with cloud credentials, and more forgotten infrastructure. The external footprint grows in proportion to organizational activity, not in proportion to security investment.
What internal security programs do not see
Certificate transparency logs as an attacker resource
Every TLS certificate issued by a trusted certificate authority is logged permanently in public certificate transparency logs. This includes certificates for internal development subdomains, staging environments, and test infrastructure that was never intended to be public-facing. Attackers enumerate these logs routinely as a first reconnaissance step. The organization's security team typically does not monitor them because there is no internal tool that ingests CT log data by default.
OAuth and SaaS integration exposure
When an employee connects a third-party SaaS tool to organizational identity — granting it access to email, calendar, files, or directory data — that grant persists after the employee leaves, after the SaaS tool is abandoned, and after the organizational policy changes that would have prevented the grant. OAuth grants accumulate across the organization's history. Each one represents an external service with ongoing access to organizational data. Most organizations have no inventory of active OAuth grants.
Acquired and legacy infrastructure
Acquisitions transfer infrastructure along with assets. The acquired company's DNS records, cloud instances, and subdomains become the acquirer's responsibility — and the acquirer's attack surface — without a corresponding transfer of institutional knowledge about what the infrastructure does, who manages it, or when it was last reviewed. In assessments of organizations that had acquired other companies in the previous three years, we found legacy infrastructure from the acquired entity in almost every case.
API endpoints created during development that reach production
APIs developed under time pressure frequently reach production with authentication gaps that were accepted as temporary during development and never revisited. In 35% of assessed financial services environments, we found externally accessible API endpoints returning customer data with weak or absent authentication. The endpoints existed in the internal API documentation. They were not in the external asset inventory. The security review process had not reached them.
How external attack surface enumeration works from the attacker's starting position
- Step 1
Passive subdomain enumeration via certificate transparency
Output:A list of all subdomains with issued certificates, including historical and expired ones. This is the baseline asset list an attacker starts from — and the list that most internal inventories do not match.
Purpose:Discover all subdomains for which TLS certificates have been issued, including those not intended to be public-facing. This requires no active scanning and leaves no logs in the target organization's systems.
- Step 2
DNS resolution and live host identification
Output:A reduced list of actively reachable hosts. Also a list of dangling DNS records pointing to deprovisioned resources — cloud instances, CDN configurations, or third-party services that no longer exist but whose DNS entries remain.
Purpose:Determine which discovered subdomains currently resolve to live IP addresses. A subdomain that resolves is a reachable asset. One that does not may still be at risk of subdomain takeover if the DNS record exists but the target resource has been deprovisioned.
- Step 3
Service fingerprinting and technology identification
Output:A technology inventory with version data. Matched against CVE databases, this produces a prioritized list of exploitable vulnerabilities on externally reachable hosts — the same list an attacker produces before choosing a target.
Purpose:For each live host, identify the software stack, version numbers, and exposed services. This is where the vulnerability scoring begins — a server running an unpatched web framework version has a different risk profile than one running current software.
- Step 4
Cloud asset enumeration via provider-specific techniques
Output:An inventory of cloud-hosted assets, including publicly accessible storage, exposed APIs, and misconfigured services. This is where the storage bucket findings come from — they are not discovered through scanning the network, but through enumerating the organization's cloud footprint.
Purpose:Identify cloud storage buckets, serverless functions, and cloud-hosted services associated with the organization's domains and naming conventions. Cloud assets are not visible through DNS enumeration alone — they require provider-specific enumeration techniques.
The cost calculation that is usually done wrong
IBM Cost of a Data Breach Report 2024: USD 4.88 million average total cost of a breach globally
This figure is an average across breach types and organization sizes. The relevant number for cost justification of digital footprint analysis is not the average — it is the expected cost weighted by the probability of an externally-initiated compromise for organizations with unmonitored external assets.
IBM Cost of a Data Breach Report 2024: breaches involving shadow data had a 16% higher cost than average
Shadow data — data stored in assets outside the organization's known inventory — costs more to breach because it takes longer to detect. The external assets that digital footprint analysis finds are, by definition, shadow data locations.
Vulnox assessment data: median time from asset creation to security team awareness for forgotten subdomains was 14 months
14 months of unmonitored external exposure on a live server with a known vulnerability. The detection and response cost for a breach that exploited that exposure would be substantially higher than the cost of the enumeration that would have found it.
Where external attack surface exposure is going
Subdomain takeover will become a named, reportable incident category in breach disclosure regulations within two years, forcing organizations to inventory DNS records as a compliance requirement rather than a security best practice.
Subdomain takeover — where an attacker claims a deprovisioned cloud resource that a dangling DNS record still points to — is currently a well-documented attack technique with a consistent exploitation pattern. It is invisible to most incident response programs because the compromised asset is not in the asset inventory and the breach may not involve any internal system. As regulators push for more specific disclosure requirements, the attack class is specific enough to be categorized and the evidence trail is clear enough to be audited. The organizational behavior that creates it (failing to decommission DNS records with cloud resources) is common enough to warrant regulatory attention.
Confidence: mediumWatch for whether ENISA, FCA, MAS, or SEC guidance published between 2025 and 2027 specifically names external asset inventory or DNS record management as a required control. If no regulatory body has referenced it by 2027, the timeline is wrong.AI-assisted external reconnaissance will reduce the time from organization identification to exploitable finding from hours to minutes for mid-market targets within 18 months, making the current 'we would know if we were targeted' assumption untenable.
The reconnaissance steps that currently require a skilled attacker — CT log parsing, DNS resolution, service fingerprinting, CVE matching — are individually automatable and collectively chainable. AI-assisted tooling that sequences these steps and prioritizes findings by exploitability is not a future capability — it is being built now by both offensive security researchers and threat actors. The lag between researcher capability and criminal adoption has been consistently under two years for automation tooling.
Confidence: highIf published threat intelligence reports from 2026 do not document increased use of automated multi-step external reconnaissance in attacks against organizations with fewer than 1,000 employees, the adoption timeline is slower than predicted.
The cost argument that security teams are making wrong
The standard approach to justifying digital footprint analysis spend is to cite the average breach cost and argue that prevention is cheaper than response. This argument fails in budget conversations because it is probabilistic — the breach might not happen — and because it competes against the certainty of the prevention spend. The more honest and more effective argument is specific: here are the external assets we found that you did not know you had, here is the CVE associated with each one, here is the CVSS score, and here is the exploit code that is publicly available for the highest-priority finding. That argument does not require the CISO to accept a probability estimate. It requires them to look at something real that exists right now and decide whether they want to close it. The ROI conversation is easier when the exposure is concrete rather than theoretical.
Counterargument
The counterargument is that showing specific findings before the budget is approved requires doing the work before it is funded, which creates a chicken-and-egg problem. Some security leaders solve this by doing a limited no-cost external scan as a proof of concept — enough to find one or two concrete findings — and using those findings to justify the full engagement. This works when the findings are significant, which in our experience they usually are. It requires the security team to invest time before the budget decision, which is not always possible.
Start with what you can see from outside
Run a passive subdomain enumeration on your primary domain this week. Use crt.sh — type your domain into the search bar and review the certificate history. Every subdomain listed there has had a TLS certificate issued for it. Some of them are current, managed assets. Some of them are things your team has not thought about in months or years. For each one that resolves to a live IP address, ask whether it is in your vulnerability scanning scope. If it is not, you have found your starting point. This takes less than an hour. It uses a public data source that attackers use routinely. The gap between what appears in that list and what your security team actively monitors is the external attack surface that digital footprint analysis is designed to close.
Further Reading
Digital Footprint
digital footprint analysis servicesrisk calculator
cybersecurity risk calculatorExternal Attack Surface Management
external attack surface management overviewWhat is a Digital Footprint - IBM
IBM's digital footprint explanationData Breach Prevention Flare
data breach prevention strategies
Frequently Asked Questions
What does digital footprint analysis find that internal vulnerability scanners miss?
Internal vulnerability scanners operate against known assets — servers and endpoints that were added to the asset inventory. Digital footprint analysis starts from the attacker's position: what can be found from outside with no prior knowledge of the internal inventory. This reveals forgotten subdomains, cloud storage buckets misconfigured at deployment, deprovisioned resources with dangling DNS records, and API endpoints that reached production without security review. In Vulnox assessments, 73% of client environments had at least one such asset that the security team did not know was externally reachable.
Why do SOC2-compliant organizations still have significant external attack surface exposure?
SOC2 Trust Services Criteria cover logical and physical access controls, change management, availability, and risk assessment processes. None require external attack surface enumeration or subdomain inventory. In Vulnox assessments across 84 environments, SOC2-certified organizations showed only a 12% reduction in externally facing vulnerabilities compared to non-certified peers. Compliance certification confirms what the audit tested. External attack surface posture is not what SOC2 tests.
What is a dangling DNS record and why does it create security risk?
A dangling DNS record exists when a subdomain's DNS entry still points to a cloud resource, CDN configuration, or third-party service that has been deprovisioned. The subdomain resolves but the target resource no longer belongs to the organization. An attacker can claim the deprovisioned resource — spinning up a new cloud instance at the same address or registering the abandoned third-party service account — and take control of the subdomain. This is called subdomain takeover. It is invisible to internal security programs because the affected asset is not in the asset inventory.
How do attackers find forgotten subdomains and cloud assets without inside knowledge?
Certificate transparency logs — public databases of every TLS certificate issued by trusted certificate authorities — contain permanent records of every subdomain that received a certificate, including internal development and staging subdomains. Attackers enumerate these logs as a first reconnaissance step. Cloud asset enumeration uses provider-specific naming conventions and publicly observable patterns to identify storage buckets and services associated with an organization's domains. Neither technique requires any access to internal systems or prior knowledge of the organization's infrastructure.
What is the realistic cost justification for digital footprint analysis?
The average breach cost figure is a probabilistic argument that loses budget conversations. The more effective approach is concrete: enumerate the external assets, match findings to published CVEs, and present specific exploitable vulnerabilities that exist right now. A CVSS 9.8 remote code execution vulnerability on a forgotten subdomain running an unpatched web framework is not a probability estimate — it is an open door with publicly available exploit code. That argument requires a decision, not a risk tolerance discussion.
What does subdomain enumeration via certificate transparency logs involve?
Certificate transparency is a public logging requirement for all TLS certificates issued by trusted certificate authorities. The crt.sh database aggregates these logs and is searchable by domain. Querying your organization's primary domain returns a history of every subdomain that received a certificate — including those created for development, testing, and marketing campaigns that may no longer be actively managed. Subdomains that still resolve to live IP addresses are reachable from the internet and represent the starting point for external attack surface assessment.
Why do larger organizations with mature security programs often have larger unmonitored external footprints?
Internal security maturity and external attack surface visibility are built by different teams using different processes. Mature security programs track known assets. External footprint grows with organizational activity: developer sandboxes, marketing subdomains, SaaS integrations, acquired company infrastructure. A 500-person organization operating for eight years has accumulated eight years of developer activity, product launches, and abandoned projects, each potentially leaving external-facing assets. Security maturity does not scale the external inventory — organizational activity does.
Related Articles
Basic digital footprint check: what free tools find and what they miss
A basic digital footprint check using free tools takes less than an hour and reliably surfaces subdomains, certificate history, and indexed content. What it misses — assets with no DNS record, credential material in archived repositories, and vendor-created infrastructure — is where the regulatory exposure lives.
SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks
In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name. That gap between what you think you expose and what is actually visible is where most breaches begin.
Digital footprint exposure and data protection risk: what regulators find that internal teams miss
Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.