Why "Ecosystems" Fail: Lock‑In, Security, and the Myth of One Vendor to Rule Them All

The holiday wake-up call

I feel compelled to write this because whilst many people were enjoying the holiday period, the team at GEN took on a new client who was desperate for help after their Microsoft 365 tenancy was compromised.

The initial compromise appears to have occurred earlier, but the criminals waited for the quiet period to apply pressure: they leveraged social engineering, gained access to banking, emptied accounts, siphoned data from OneDrive and SharePoint, and then locked the business out. This is not a small organisation (around 120 staff across two sites). They were left with no systems, no cash, no clear picture of what had happened, and no meaningful escalation route.

Weeks earlier we saw a similar pattern with another new client, this time on Google Workspace. Their Google account was compromised and subsequently terminated. In practical terms that meant the business lost email, documents, and access to the identity backbone that tied everything together. In that case we were simply unable to persuade Google to do the right thing because there was nobody to contact. The client lost a small fortune in disrupted work during the week it took to rebuild services, notify customers, update public facing channels, and restore basic operations.

These incidents are not “edge cases”. They are the logical conclusion of putting too much of your business inside a single vendor ecosystem.

What you really lose when you buy an ecosystem

Ecosystems are sold as convenience: one login, one portal, one bill, one “platform”. The trade is rarely described as bluntly as it should be. When you buy into an ecosystem, you typically lose:

• Best tool for the job: you stop choosing the best mail platform, the best file platform, the best backup tooling, the best identity model. You choose “whatever is built in”.
• Data sovereignty: your data location, access patterns, retention, and egress are dictated by the vendor’s design and legal posture, not your needs or your country’s regulatory expectations.
• Compartmentalisation (blast-radius control): when identity, email, files, devices, and SSO are one tightly coupled stack, a single breach can cascade everywhere. Separation is a security control.
• Negotiating power: pricing changes, licensing changes, forced upgrades, feature removals, and “new terms” become something you absorb rather than choose.
• Operational independence: migration becomes harder over time (data gravity is real). The longer you stay, the more expensive it becomes to leave.
• Support you can actually use: “support” often means forms, bots, community threads, and long queues. When you need a human escalation today, you discover you don’t have one.

Yes, there are benefits:

• Simplified billing (sometimes): fewer suppliers, fewer invoices, fewer purchase orders.
• Single sign-on: less password sprawl if implemented properly with good identity hygiene.
• Rapid adoption: it’s easy to “turn on” another product in the same ecosystem.

The problem is that the benefits are operational convenience, while the costs are strategic and existential.

Lock‑in is not a side effect — it’s the business model

“Lock‑in” is when a vendor makes it economically, technically, or operationally painful to leave. Not “impossible”, just painful enough that most customers won’t do it.

Lock‑in happens through a combination of:

• Bundling: attractive pricing for the suite, unattractive pricing for the parts.
• Identity coupling: your login becomes your control plane for everything else.
• Data gravity: email archives, SharePoint sites, Teams history, Drive documents, permissions models, integrations… they become your business memory.
• Proprietary semantics: even when export exists, you often lose permissions, metadata, workflows, history, and governance context.
• Third‑party dependence: your suppliers and line-of-business apps increasingly assume the ecosystem is “the default”.

Once you understand that, a lot of ecosystem behaviour makes sense. It also makes the right response clear: reduce coupling, increase portability, and design for exit.

The best-of-breed alternative: separate the things that shouldn’t be one thing

The goal is not to create a fragile collection of random tools. The goal is to build a deliberate stack where each component can be changed without collapsing the entire business.

A practical “de-ecosystemed” approach often looks like this:

• Email on a dedicated enterprise email platform that does one job extremely well, with strong deliverability, proper support, and explicit security controls.
• Calendar and contacts on open standards (CalDAV/CardDAV) or on a platform you control, so that losing mail does not mean losing identity and collaboration.
• File storage either on‑premises (where appropriate) or with a UK provider offering clear data residency, human support, and straightforward export/migration options.
• Websites and DNS hosted separately from your office suite. Your public presence should not depend on your collaboration vendor’s account status.
• Backups that are independent. Backups stored “inside the same ecosystem” are not a resilience strategy; they are a convenience strategy.

This gives you something ecosystems actively work against: failure isolation. If one system is breached, suspended, or experiences an outage, it should not automatically take everything else with it.

Security is not just MFA. It’s architecture.

Multi-factor authentication is essential, but it is not the whole story. Ecosystems tend to create single points of failure because identity becomes the universal key. When that key is copied (through phishing, token theft, consent attacks, SIM swaps, or compromised endpoints), the attacker can move laterally at speed.

Architectural controls that materially reduce risk include:

• Separation of duties: your banking access, domain registrar, DNS, and identity provider should not be behind the same admin account.
• Independent recovery paths: you should be able to regain control even if your primary provider is unavailable or unhelpful.
• Off-platform immutable backups: ensure that ransomware in one environment cannot delete or encrypt your last good copy.
• Least privilege by design: especially for admins. The “global admin that does everything” pattern is an attacker’s dream.

The uncomfortable truth about support

For many organisations, the most painful discovery is not technical. It is organisational: when an incident happens, there is no meaningful escalation route.

That gap is what created the modern “MSP middleman” industry: not because pushing buttons in portals is complicated, but because customers need a human being to answer the phone when things go wrong.

However, if your architecture makes one vendor the only real gatekeeper of your business, your MSP (or internal IT team) can become helpless in the moment that matters. The answer to that is not “a better MSP”. It is to stop making your business dependent on a single third party’s goodwill and queue length.

Why we’re seeing a shift away from mega-cloud ecosystems

Across the industry we are seeing a growing appetite for more controllable systems: private cloud, sovereign hosting, on‑prem where it makes sense, and best-of-breed combinations that preserve optionality.

This is happening for several reasons:

• Risk is now obvious: high-profile compromises and account lockouts have made “vendor dependency” a board-level issue.
• Costs keep moving: licensing changes and bundled pricing games make long-term forecasting difficult.
• Regulation and procurement: governments and large organisations increasingly demand clear data residency, auditability, and contractual accountability.
• Geopolitics: for many organisations, “where is the data and who can compel access” is no longer an abstract question.

Windows is becoming the ecosystem’s delivery mechanism

Microsoft in particular has been steadily embedding its ecosystem deeper into Windows: sign-in flows nudging users into Microsoft accounts, aggressive OneDrive prompts, default browser steering, and “helpful” integrations that are difficult to disentangle later.

That is not accidental. If the operating system is the distribution channel, the ecosystem becomes the default. And if the ecosystem is the default, leaving becomes “unusual” — and therefore harder.

“Cloud hosting” is not magic. You can run your own.

Most “cloud” services are built on straightforward principles: virtualisation, redundant storage, networking, backups, monitoring, and good operations. At a technical level, there is nothing mystical about this.

For many organisations, a private cloud (or hosted private cloud) can be:

• More controllable: you choose residency, access, and change windows.
• More secure: tighter boundaries and fewer forced integrations.
• More cost predictable: you pay for resources, not for per-seat bundling that keeps changing.
• More supportable: because you have a provider who is contractually accountable and reachable.

At GEN we provide building blocks for this approach (enterprise email, UK hosted private virtual cloud, managed security, and real human support), but the broader point is simple: you have options.

Conclusion: design for exit, design for survival

Ecosystems are marketed as simplicity. In reality, they are concentration risk. If your email, files, identity, and devices all belong to one provider, then one compromise, one suspension, or one support failure can become an existential event.

The alternative is not chaos. It is deliberate separation: best tools for each job, open standards where possible, independent backups, and a provider ecosystem that includes people you can reach when you need them.

In 2026, resilience is not a feature you “add later”. It is architecture, and it starts by refusing to hand your entire business to a single vendor stack.