The Hidden Control-Plane Problem: SSO, Email, DNS, and File Storage
Most organisations think about cloud dependency in terms of individual tools. The real risk sits in the control plane: the four systems that every other system depends on. When those are concentrated in one vendor, every migration starts from a position of structural weakness.
When organisations list their cloud dependencies, they typically produce a tool inventory: we use Slack for chat, Salesforce for CRM, Jira for project management. Each tool gets its own line item, its own risk rating, its own migration plan.
This approach misses the point. The tools are the visible layer. Underneath them sits a control plane: a small set of services that every tool depends on and that determines who can access what, where data flows, how systems find each other, and where files live. The control plane is the real dependency. And in most European organisations, the entire control plane is operated by one or two US companies.
What Is the Control Plane?
The control plane for a typical organisation consists of four components:
1. Identity (SSO/IdP)
The identity provider decides who is allowed to do anything. When an employee opens Salesforce, the first thing that happens is an authentication request to the identity provider. If the identity provider says yes, the employee gets in. If it says no, or if it is unavailable, the employee is locked out.
Azure Active Directory (Entra ID) and Google Workspace serve as the identity provider for the vast majority of European organisations with 10 to 50 employees. Every SSO connection to every SaaS tool passes through this one chokepoint.
The identity provider is not just a login service. It also controls:
- Conditional access. Which devices can connect, from which locations, under which conditions.
- MFA enforcement. Whether a second factor is required and which methods are accepted.
- Service principal authentication. Automated systems, background jobs, and API integrations that authenticate using service accounts in the identity provider.
- Group membership and role assignment. Who has admin access, who can approve purchases, who can see financial data.
If the identity provider goes down, every connected application goes down with it. Not because those applications are broken, but because nobody can prove they are allowed to use them.
2. Email
Email is the second control-plane component because it serves as the notification and recovery backbone for everything else.
Password reset emails go through your email provider. Security alerts from SaaS tools go through email. Two-factor authentication codes (for services that use email-based MFA) go through email. Invoice notifications, contract approvals, client communications: all email.
When email and identity are provided by the same vendor (Microsoft providing both Exchange and Entra ID, or Google providing both Gmail and Google Identity), losing access to one means losing access to both. You cannot receive the password reset email because the email provider is the same provider you are locked out of.
This circularity is the most dangerous pattern in the control plane. It means there is no recovery path that does not depend on the system that failed.
3. DNS
DNS is the address book of the internet. Every time a user opens a website, sends an email, or connects to an API, a DNS query translates a human-readable domain name into a server address.
If your DNS provider goes down, your website disappears, your email stops flowing (MX records become unresolvable), and your API endpoints become unreachable. From the outside, it looks like your entire company has vanished from the internet.
DNS is the most overlooked control-plane component. Most organisations set it up once and never think about it again. Many do not know which provider handles their DNS without checking. It is often Cloudflare or AWS Route 53, both US companies.
The good news: DNS is also the easiest control-plane component to move. A migration to a European DNS provider (Hetzner DNS, deSEC, Gcore) takes hours and can be done with zero downtime.
4. File Storage
The file storage layer holds the accumulated output of your organisation: documents, contracts, templates, project deliverables, financial records. It is a control-plane component because other systems depend on it:
- Collaborative editing depends on the file storage platform.
- Automations trigger on file events (new file uploaded, document approved).
- Teams channels, Slack integrations, and project management tools embed files from the storage layer.
- Search across organisational knowledge goes through the file storage index.
When file storage is provided by the same vendor as identity (Microsoft’s SharePoint with Entra ID, Google’s Drive with Google Identity), the integration is deep and convenient. It is also a concentration risk: losing access to the vendor means losing both your login mechanism and your documents simultaneously.
The Concentration Pattern
Here is what the control plane looks like in a typical European organisation:
Scenario A: Google-centric
| Control-Plane Component | Provider |
|---|---|
| Identity | Google Workspace |
| Google Workspace (Gmail) | |
| DNS | Cloudflare (US) |
| File Storage | Google Workspace (Drive) |
Three of four control-plane components are operated by Google. DNS is operated by another US company. The entire control plane is US-controlled.
Scenario B: Microsoft-centric
| Control-Plane Component | Provider |
|---|---|
| Identity | Microsoft Entra ID |
| Microsoft Exchange Online | |
| DNS | Cloudflare or AWS Route 53 (US) |
| File Storage | Microsoft SharePoint / OneDrive |
Three of four components are Microsoft. Same concentration pattern, different vendor.
Scenario C: Mixed but still concentrated
| Control-Plane Component | Provider |
|---|---|
| Identity | Microsoft Entra ID |
| Gmail (Google Workspace) | |
| DNS | Cloudflare (US) |
| File Storage | Microsoft SharePoint |
This looks more diversified, but identity is still a single point of failure, and all four components are still US-controlled.
Why This Matters More Than Individual Tools
Individual tools (CRM, project management, design tools) are replaceable because they sit on top of the control plane. They consume identity services, receive email notifications, and store files. If you replace Salesforce with a European CRM, the new CRM still authenticates through Azure AD, still sends notifications through Exchange, and still stores attachments in SharePoint. You have changed the tool but not the underlying dependency.
The control plane is the layer where sovereignty risk concentrates. If a US legal order compels your identity provider to revoke access, every tool in your stack becomes inaccessible. If sanctions affect your email provider, your communication and your recovery mechanisms stop working simultaneously.
This is why organisations that replace individual tools but leave the control plane untouched have not materially reduced their risk. They have rearranged the furniture while the foundation stays the same.
Deconcentrating the Control Plane
The goal is not to eliminate every US dependency. The goal is to ensure that no single jurisdiction controls all four control-plane components. Here is what a deconcentrated control plane looks like:
| Control-Plane Component | Provider | Jurisdiction |
|---|---|---|
| Identity | Keycloak (self-hosted on Hetzner) | EU (Germany) |
| Proton Mail for Business | Switzerland | |
| DNS | deSEC | EU (Germany) |
| File Storage | Nextcloud (managed hosting on OVHcloud) | EU (France/Germany) |
Four different providers, all under EU or Swiss jurisdiction. No single vendor controls more than one component. A failure or legal action affecting one provider does not cascade to the others.
This is the strongest position. It is also the most work to reach. For most organisations, the practical path is incremental:
Phase 1: Fix DNS (same day)
Move DNS to a European provider. This is the fastest win and the only one with zero organisational disruption. Change your nameservers, verify propagation, done.
Phase 2: Add identity redundancy (weeks)
Deploy Keycloak or Authentik alongside your existing identity provider. Connect your three most critical applications to both. This does not replace the existing IdP yet, but it creates a fallback. If the primary identity provider becomes unavailable, you have a working alternative.
Phase 3: Move email (months)
Migrate email to a European provider. This breaks the circularity between identity and email: your recovery path (password reset emails, security alerts) no longer depends on the same vendor as your identity.
Phase 4: Move file storage (months)
Migrate file storage to Nextcloud or another EU-hosted platform. This is the largest data migration and requires careful planning for permissions and collaborative editing workflows.
Phase 5: Complete identity migration (months)
Once email and files are on independent providers, complete the identity migration by removing all SSO connections from the original provider and making the European IdP primary.
The order matters. DNS first because it is easy. Identity redundancy second because it provides a safety net. Email third because it breaks the most dangerous circularity. Files fourth because the data volume makes it the longest migration. Full identity migration last because it depends on the other components being in place.
How to Assess Your Control Plane
Answer these four questions:
- Who provides your identity? Check which service your employees use for SSO. Count how many applications depend on it.
- Who provides your email? Is it the same vendor as identity? If yes, you have the circularity problem.
- Who provides your DNS? Check your domain registrar’s nameserver settings. If you see Cloudflare, Route 53, or Google Cloud DNS, it is US-controlled.
- Who provides your file storage? Is it the same vendor as identity? How much data is there?
If the answer to three or four of these questions is the same US vendor, your control plane is concentrated. The risk is structural, and it will not be addressed by swapping individual SaaS tools.
Sovereign Shift assesses your full control plane and builds a deconcentration plan tailored to your stack. Learn about our dependency audit →