After a merger or acquisition, we’re likely to inherit systems that have accumulated years of permissions, integrations, service accounts, and undocumented trust relationships. Especially of late, when attention wanes with the uncertainty of a merger looming on the horizon. They worked well enough in their previous environment, but once we connect them to a new identity provider, new cloud accounts, and new users, their blast radius changes overnight.
That makes legacy cloud security less about old technology and more about inherited trust.
- According to PwC’s 2026 Global M&A Industry Trends, worldwide deal activity is still on the up, with global transaction value expected to approach $4 trillion, increasing the number of organizations integrating complex cloud environments.
- At the same time, the Cloud Security Alliance’s Top Threats to Cloud Computing 2026 ranks Identity and Access Management (IAM) as the industry’s leading cloud security concern, highlighting excessive permissions, federated trust, non-human identities, and unmanaged credentials.
Those two trends aren’t unrelated. Legacy doesn’t always mean insecure. It’s tempting to assume every legacy platform needs replacing. Usually, it doesn’t. An older application with well-understood permissions, clear ownership, and strong monitoring may present far less risk than a shiny cloud-native platform nobody fully understands.
One of the biggest challenges with legacy cloud security is invisible context. Mature environments accumulate years of undocumented dependencies, inherited permission models, one-off exceptions, and “temporary” fixes that quietly become permanent. On paper, many permissions look excessive. In reality, they may support a fragile business process that nobody has touched for years. The trick isn’t removing access indiscriminately; it’s separating genuinely necessary permissions from historical baggage before that baggage is inherited by the next organization.
The principal risk is rarely aged infrastructure. Often, it stems from systems whose trust dependencies and relationships have simply faded from view. The unknown. The hidden. The unexpected. That’s why we should inventory not only servers and applications, but also identities, permissions, APIs, automation, AI agents, and every machine and workload identity that silently keeps the business running.
1. Nobody owns the inventory
If nobody can confidently identify every AWS (Amazon Web Services) account, Microsoft Azure subscription, Google Cloud project, SaaS application, API, or service account, we already have our first warning sign.
Unknown assets quickly become unpatched assets.
This is where cloud sprawl becomes particularly dangerous, especially when development, acquisitions, and rapid growth have created environments that no one fully owns.
2. Identity ownership has become blurred
Acquisitions often create duplicate identities, dormant contractor accounts, shared administrators, and local accounts sitting outside the primary identity provider.
The technology may still work perfectly. The identity model usually doesn’t, and this kind of identity debt accumulates unseen until nobody can confidently answer a simple question:
“Who actually needs this access today?”
3. Permissions reflect history instead of business need
One administrator role becomes two. Two become ten. Eventually nobody wants to remove anything because “something might break.” Unfortunately, attackers appreciate historical permissions just as much as administrators do.
Reducing standing access and enforcing the principle of least privilege dramatically reduces the opportunities available if an account is compromised.
4. Machine identities have no obvious owner
People leave companies. Applications don’t.
Service accounts, API keys, automation credentials, certificates, those oh-so-helpful AI agent experiments, and workload identities often survive multiple organizational changes with little or no documentation.
- The Cloud Security Alliance’s January 2026 survey found 51% of organizations identified unclear ownership and over-permissioned access as significant challenges, while many still struggle to rotate credentials quickly after suspected exposure.
Understanding machine identity is just as important, arguably more so, as understanding human users.
5. Federation creates unexpected trust
A SAML (Security Assertion Markup Language) relationship or OAuth integration that was perfectly reasonable inside one organization may expose far more once two businesses become connected.
Every new federation changes the potential attack path, and rather than asking, “Can this identity authenticate?” we should ask:
“What else can it now reach?”
6. Logging can’t answer “who did what?”
Inherited environments frequently contain different logging standards, retention periods, and monitoring platforms.
If privileged activity can’t be tied back to an individual or workload identity, investigations slow, compliance becomes harder, and accountability quickly disappears.
Good logging shouldn’t simply collect evidence. It should explain trust.
7. Vulnerable systems are being connected before they’re remediated
Legacy vulnerabilities don’t become less dangerous after an acquisition.
They become better connected.
- Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches now begin with the exploitation of vulnerabilities, making software weaknesses one of today’s leading attack paths.
Before connecting environments together, we should understand which systems represent the largest potential blast radius.
8. Temporary access silently becomes permanent
Every acquisition creates temporary administrator accounts, migration roles, emergency permissions, and integration exceptions. The problem is that “temporary” often survives the project.
This is where just-in-time access becomes especially valuable. Instead of granting permanent privileges “until everything settles down,” organizations can approve access only when needed and automatically revoke it when the approved window expires.
That keeps migration moving while preventing transitional permissions from becoming tomorrow’s legacy architecture.
Legacy cloud security is really about inherited trust
The biggest mistake after an acquisition isn’t inheriting old technology. It’s inheriting old assumptions. Every cloud account, identity provider, service account, and automation workflow carries trust relationships built for yesterday’s business. Once two organizations connect, yesterday’s assumptions become today’s attack surface.
The goal shouldn’t be to modernize everything immediately. It should be to understand what exists, who owns it, what trusts it, and whether those permissions still make sense.
Start a free Trustle trial to discover your hidden identity debt, replace standing privileges with just-in-time access, and gain clearer visibility into who has access to what, before inherited trust becomes inherited compromise.
