Merger, Acquisition, Forgotten Domain: How M&A Activity Quietly Expands Your Attack Surface

M&A attack surface is the set of internet-facing assets an acquirer inherits when a deal closes, including domains, subdomains, cloud accounts and legacy systems that nobody listed. It grows because the target’s own team often does not know about forgotten assets. Standard due diligence relies on a self-reported inventory, so these assets stay hidden until an attacker or an outside scan finds them.

Every merger and acquisition closes with a handover document. Asset lists, systems inventories, license agreements, infrastructure diagrams. These documents are the output of weeks or months of due diligence: financial, legal, operational, and increasingly, technical. But one category of asset almost never appears in a handover document. The organization being acquired did not know it existed. Neither did the acquirer, until an attacker found it first.

Forgotten domains. Abandoned subdomains. Cloud accounts that were provisioned for a campaign that ended two years ago and were never decommissioned. Legacy application environments still receiving traffic from old DNS records pointing to infrastructure that has not been patched since the previous administration. These assets survive a transaction unseen. They carry the security debt of the organization that created them. The acquirer inherits it, and its security team does not know to look for it.

The moment an acquisition is announced, threat actors begin mapping the target’s external surface. They are not waiting for the handover document. They scan certificate transparency logs, passive DNS databases, and historical WHOIS records. The goal is to find every domain, subdomain, and IP range ever linked to the target. The acquiring organization inherits those exposures whether or not they appear in any internal inventory. The attackers already know the full picture. The security team does not.

What Does the M&A Attack Surface Include That Nobody Inventoried?

The scope of the inherited attack surface in a typical acquisition is substantially larger than the acquiring organization expects. Most enterprises have more externally exposed assets than their security team is aware of. In the context of an acquisition, where the acquirer starts from zero visibility into the target’s external footprint, the gap is routinely much larger. Organizations that have run EASM assessments immediately post-close consistently report finding assets that represent years of unmanaged infrastructure accumulated by the acquired company.

These assets fall into predictable categories that repeat across every acquisition, regardless of sector or company size.

Forgotten Domains and Lapsed Registrations

Every organization collects domain registrations over time:

• Product launch domains
• Regional variations of the main brand
• Marketing campaign microsites
• Domains registered for acquisitions that never closed
• Names bought defensively to prevent brand squatting

Over the years, many of these domains lose their link to any active service but stay registered. Some still point at infrastructure that responds. Others simply sit in a registrar account that nobody checks.

When a company is acquired, these domains transfer with the legal entity. The acquiring organization’s IT team inherits a collection of domain registrations it has never seen and has no process for. Some will lapse in the months following the acquisition when auto-renewal fails on a credit card that no longer exists. When a corporate domain lapses, anyone can register it. Threat actors can then exploit the trust the domain still carries with browsers, email systems, and existing business relationships.

Abandoned Subdomains and Dangling DNS

Subdomains accumulate faster than domains. Every product feature, every regional deployment, every third-party integration, every development environment gets a subdomain. Organizations routinely create subdomains for projects that end, services that get decommissioned, or integrations that get replaced. When the underlying service is removed, the DNS record often remains. This is called a dangling CNAME. It is a subdomain that points at a cloud service, a CDN, or a SaaS platform where the organization no longer has an account.

The risk of a dangling CNAME is direct: any attacker who registers the abandoned account on the target platform can claim the subdomain. At that point, they control a subdomain that carries the acquired company’s brand and is trusted by browsers because it resolves correctly. They can serve content, capture credentials, or host phishing pages under a domain that passes basic visual inspection.

In 2025, researchers re-registered approximately 150 abandoned cloud storage accounts that had formerly belonged to governments, Fortune 500 companies, and security vendors. This shows that this class of exposure is neither theoretical nor rare.

Unpatched Legacy Infrastructure

The assets with the highest immediate risk of exploitation are internet-facing systems that have not received security updates. There are three common reasons:

• The team responsible did not know the systems were still running.
• They were deprioritized in favor of active production systems.
• Patching them would need downtime that the previous administration could never schedule.

Legacy infrastructure is a common weak point after a deal. These systems are often the first targets in post-acquisition campaigns, because they are the path of least resistance:

• The new security team has not yet mapped them.
• The old team no longer exists.
• The systems have months or years of unaddressed vulnerabilities.

Cloud Accounts Without Owners

Cloud infrastructure created by the acquired company does not transfer automatically into the acquirer’s cloud governance framework. Several kinds of cloud resources may keep running in their original accounts, outside the acquirer’s monitoring tools and access control policies:

• Developer accounts
• Departmental cloud subscriptions
• Staging environments
• Data pipelines
• Object storage buckets set up for specific projects

Credentials for these accounts may exist only in the memories or personal password managers of employees who did not survive the acquisition process.

These accounts are unmonitored compute and storage infrastructure. They may hold sensitive data from the acquired company’s customer base. They may carry open security group rules that allow inbound traffic from anywhere. They have no process for security patches or configuration audits. They are, in the most direct sense, attack surface that the security team does not know it owns.

What Attackers Do the Moment an Acquisition Is Announced

Dark web forum analysis consistently shows that M&A announcements trigger targeted reconnaissance. Threat actors post about acquisition targets on criminal forums and share infrastructure enumeration results. They also discuss the security weaknesses of transition periods, when IT teams focus on integration logistics rather than security monitoring. The acquisition announcement is the starting gun. From that moment, actors actively map the target’s external attack surface, including every forgotten domain and abandoned subdomain. They want to exploit the window between announcement and full security integration. That window, in most organizations, lasts months.

Why Does Standard Due Diligence Not Catch This?

Cybersecurity has become a standard component of M&A due diligence. Legal teams request security questionnaires. Technical teams review incident history and compliance certifications. IT teams may audit the target company’s active infrastructure and review network diagrams.

But the standard due diligence process has a structural limitation that makes the forgotten asset problem almost invisible. Due diligence assesses what the target company knows it has. It reviews the systems the target’s IT team is responsible for. It covers the domains the web team actively manages and the cloud infrastructure the operations team monitors. It does not systematically discover what the target company’s teams have forgotten or never knew about.

The Self-Reported Inventory Problem

Most cybersecurity due diligence begins with a request for the target company to complete an asset inventory: domains, IP ranges, cloud accounts, internet-facing systems. This inventory is necessarily self-reported. It reflects what the target company’s current IT team knows about. It does not reflect the subdomain a departing developer set up three years ago and never documented. It does not reflect the cloud account provisioned by a marketing contractor for a campaign that was canceled. It does not reflect the legacy application environment that IT decided to leave running because migrating it was too complex.

The assets that create the highest post-acquisition risk are precisely the ones that do not appear in a self-reported inventory. They are the unknown unknowns, and no questionnaire process can surface them, because the organization being questioned does not know the answers.

The Timeline Problem

Even where cybersecurity due diligence is conducted rigorously, the timeline of an M&A transaction creates a window during which the inherited attack surface is unmonitored. Due diligence typically concludes before deal close. The integration process begins after deal close. Between those two points, the inherited infrastructure exists under a legal ownership transition, with uncertain responsibility for monitoring and response. This transition window is exactly the period that threat actors target.

Research indicates that in many cases a threat actor is already in the target company’s environment before the acquisition closes. The actor got in through one of the forgotten assets that due diligence did not surface.

The acquirer’s first sign of this presence is often an incident during integration. The target’s infrastructure is being connected to the acquirer’s network, which creates a lateral movement path that did not exist before.

The Verizon-Yahoo Precedent

The Verizon acquisition of Yahoo is the defining case study in M&A cybersecurity failure. An undisclosed data breach affecting hundreds of millions of accounts, according to the SEC, was only disclosed in 2016, while Yahoo’s operating business was being sold to Verizon. The final settlement included ongoing obligations for Yahoo’s successor entity.

It also established that an undisclosed breach found during or after an M&A transaction creates direct financial liability. That liability can fall on the acquired company, the acquiring company, and potentially the executives who signed the deal documents. The Yahoo case established that what a company does not know about its own infrastructure is a financial and legal liability, not merely a technical inconvenience

How Inherited Assets Become Active Threats: The Post-Close Timeline

The inherited attack surface does not become dangerous after the acquisition. It becomes visible as a risk after the acquisition, because the acquiring organization’s security team begins discovering it. The actual risk often predates the deal. Understanding the post-close timeline is essential for designing an integration program that addresses the inherited attack surface before it is exploited.

Why EASM Is a Non-Negotiable Step in M&A Due Diligence

External attack surface management removes the limit of a self-reported inventory. It finds assets from the outside in, using the same reconnaissance techniques attackers use. It needs no cooperation or prior knowledge from the target company. An EASM assessment of an acquisition target surfaces what the target knows about and what it does not, in the same process, in hours rather than weeks.

This capability makes EASM uniquely suited to the M&A due diligence context. It does not depend on the accuracy of the target’s self-reported inventory. It does not require access to the target’s internal systems. It does not need the target’s IT team to be available or cooperative. It discovers the complete external footprint from public information, exactly as an attacker would. The result shows inherited risk, including the unknown assets that questionnaire-based due diligence cannot find.

What EASM Provides at Each Stage of the M&A Process

The Seed Set Problem: Why EASM Must Start from Entity, Not Domain

An EASM program that starts from a list of known domains will find everything connected to those domains. It will not find the domains that are not on the list. In a standard deployment, the security team gives the EASM tool a seed set of domains and IP ranges. The tool then discovers everything reachable from there.

In an M&A context, this approach fails for the same reason the problem exists. The unknown assets are unknown because they are not connected to the known seed set. A seed-set scan will not show:

• A forgotten domain registered under a subsidiary entity name.
• A cloud account set up with a personal email address by a former employee.
• A subdomain pointing to infrastructure in a cloud region the acquiring company does not know the acquired company used.

Effective M&A attack surface assessment requires starting from the organizational entity itself, not from a domain list. This means building from legal entity names, historical domain registrations, certificate transparency logs, WHOIS records, and passive DNS data. Together they give a complete picture of everything the acquired organization has ever operated on the internet. That includes things it has stopped operating but never cleaned up. The difference between entity-first and seed-set discovery is the difference between finding the known assets and finding the complete inherited attack surface.

The Integration Checklist Gap

Most M&A integration checklists include IT system migration, identity consolidation, network integration, and application rationalization. Very few include a line item for external attack surface discovery of inherited assets. The gap is not because security teams do not care about it. It is because the tools required to perform entity-first external discovery have historically been specialized and expensive. EASM as a continuous capability changes this. An organization that already runs EASM against its own footprint can extend the same program to an acquisition target from the day of announcement. It needs no special configuration or extra tooling. The acquisition simply becomes an additional entity in the discovery scope, and the unknown assets surface alongside everything else.

What Does a Security-Integrated M&A Program Look Like?

Closing the inherited attack surface gap in an M&A process requires four changes to the standard integration program.

1. EASM Assessment Before Due Diligence Begins

The external attack surface assessment of an acquisition target should begin before the target’s security team is engaged in the due diligence process. An entity-first EASM scan of the target uses public data alone. It gives a baseline picture of inherited risk before any information sharing has occurred. That picture can inform due diligence scope, negotiation posture, and risk-adjusted pricing.

The output of this pre-engagement scan should shape the questions asked in formal due diligence. Does the scan show legacy infrastructure assets the target is aware of? Are there credentials exposed in dark web markets associated with the target’s domains? Are there subdomains pointing at cloud infrastructure that has been abandoned?

2. Continuous Monitoring From Announcement Through Integration

The period between announcement and full integration is the highest-risk window in the acquisition lifecycle. An EASM program that monitors the inherited attack surface continuously during this period gives early warning of three things:

• Threat actor reconnaissance
• Pre-close compromise attempts
• New exposures in infrastructure that neither organization’s security team actively manages

Continuous monitoring during this window is distinct from a one-time due diligence scan. The attack surface changes during the transition period. Domains lapse, certificates expire, and cloud accounts lose their owners. The public announcement of the deal also draws new threat actor interest. Only continuous monitoring catches these changes as they occur.

3. Day-One Remediation Priority List

The integration security program should have a prioritized list of inherited assets requiring immediate remediation ready on day one of post-close integration. Organize the list by exploitability and business impact. It should include:

• Dangling CNAMEs that an attacker can claim at once.
• Unpatched internet-facing systems with known exploited vulnerabilities.
• Legacy domains close to lapsing that still carry brand trust.

The remediation program for inherited assets requires a distinct ownership model from the standard vulnerability management process. Nobody in the acquiring organization previously owned these assets, so they will not appear in any existing owner mapping. A named owner must be assigned for each category of inherited asset before remediation tickets can be routed.

4. Long-Tail Monitoring Beyond the Integration Window

The most dangerous inherited assets are the ones not found in the initial integration window. They stay unmonitored for months or years after the formal integration program closes. A continuous EASM program that includes the acquired entity’s historical domain registrations and organizational identifiers in its seed set will surface these assets as they become relevant. Examples are a domain approaching lapse, a certificate expiring on a forgotten subdomain, or credentials from an old account appearing in a dark web market.

The integration program ends. The inherited attack surface does not.

How Brandefense Supports M&A Attack Surface Management