Where does your Identity Governance and Administration (IGA) platform run? Who operates the underlying infrastructure? Which legal jurisdictions apply? And what happens if your organisation needs, or is forced, to change providers?
Until recently, questions like these were often treated as technical or contractual details. Today, they are becoming part of a much broader conversation about operational resilience, strategic dependencies, and digital sovereignty.
The conversation is gaining traction across Europe and is particularly visible in the Netherlands. Dutch regulators and government bodies are paying closer attention to the risks associated with dependence on a limited number of technology providers. The Dutch Central Bank and the Dutch Authority for the Financial Markets, for example, have warned that the financial sector’s reliance on a small number of non-European IT providers can create concentration and systemic risks.
As digital sovereignty gains importance, the debate risks swinging from one extreme to the other: from treating infrastructure and jurisdiction as secondary concerns to making European origin a decisive criterion in itself.
Neither extreme leads to better technology choices. Sovereignty should carry the weight that the organisation’s actual requirements justify, as part of a broader assessment of technology fit.
For organisations evaluating IGA technology, finding that balance deserves serious consideration.
Why digital sovereignty matters for IGA
An IGA platform is not simply another business application. It helps organisations determine who (both human and non-human) should have access to which systems and data, how that access is approved, and when it should be changed or removed.
Over time, such a platform becomes deeply embedded in identity processes across the organisation. It connects with HR systems, directories, business applications, cloud services and other critical infrastructure.
It contains sensitive information about identities, roles, entitlements and approval structures. It also provides the evidence organisations need to demonstrate that access is governed appropriately.
This makes the technology behind IGA strategically important.
Organisations need to evaluate what the platform can do, how effectively it supports their identity processes and whether it can scale with their requirements. But for some organisations, the assessment should go further.
They may also need to understand who ultimately controls the technology, the infrastructure on which it runs and the conditions under which it remains available.
Digital sovereignty is more than data residency
Digital sovereignty is often reduced to one question: where is our data stored?
Data residency matters, but it does not provide the full picture. Data can be stored in Europe while the technology, infrastructure, or operational chain remains subject to external providers and jurisdictions.
A more complete assessment should consider several forms of control:
- Infrastructure control: Can the organisation choose where and how the platform is deployed?
- Operational control: Who operates, maintains, and has administrative access to the environment?
- Data and encryption control: Who controls the data and the encryption keys protecting it?
- Jurisdictional control: Which laws and legal jurisdictions apply to the organisations involved in delivering the service?
- Continuity and exit control: Can the organisation continue operating or move to an alternative if circumstances change?
None of these considerations should be assessed in isolation. A sovereign deployment that cannot meet the organisation’s functional, security or scalability requirements is not the right solution.
Sovereignty should therefore be treated as one potential dimension of technology fit, not as a substitute for it.
Five questions to include in an IGA selection
The relevance of digital sovereignty will vary by organisation. It is likely to carry more weight in government, financial services, energy, utilities, healthcare and other regulated or critical sectors. For smaller or less regulated organisations, it may be a secondary consideration.
Rather than assuming that sovereignty is either essential or irrelevant, organisations can include five practical questions in their IGA selection process.
1. Can we choose where and how the platform is deployed?
Some organisations are comfortable with a standard multi-tenant SaaS model. Others may require a dedicated environment, a sovereign cloud provider, partner-hosted infrastructure or deployment within their own datacentre.
The right model depends on the organisation’s architecture, risk profile, internal capabilities and regulatory context. What matters is understanding which options are available and which dependencies each option introduces.
2. Who controls the infrastructure, data and encryption keys?
Ownership and control are not always the same thing. An organisation may legally own its data while relying on another party to operate the infrastructure, administer the environment or manage the encryption mechanisms protecting it.
For critical platforms, these responsibilities should be explicit. Organisations should know who can access which components, how that access is governed and whether they can retain control over their encryption keys.
3. Which jurisdictions and external dependencies apply?
Technology services can involve several parties: the software vendor, cloud provider, implementation partner, support teams, and subcontractors. These parties may operate from different countries and fall under different legal jurisdictions.
A proper assessment therefore looks beyond the location of the datacentre. It maps the wider legal and operational chain behind the service.
4. Can we maintain continuity if circumstances change?
Provider outages are not the only continuity risk. Acquisitions, changes in legislation, sanctions, commercial disputes, and geopolitical developments can also affect the availability or suitability of technology services.
Organisations do not need to predict every possible scenario. However, they need to understand their critical dependencies and have realistic contingency and exit options.
5. Does the solution still provide the IGA capabilities we need?
Sovereignty is only valuable when the underlying technology remains fit for purpose.
An IGA platform still needs to support identity lifecycle management, access requests, approvals, provisioning, access reviews, role management, segregation of duties, reporting, and integration with the wider application landscape. It must also be manageable, scalable and sustainable over the long term.
In practice, the best solution balances functionality, security, control and operational viability with the level of sovereignty the organisation genuinely needs.
How much control does your organisation actually need?
IdentIT can help you translate your architecture, regulatory context, dependencies and risk profile into clear IGA selection criteria.
Vendor-independent does not mean vendor-indifferent
At IdentIT, our recommendations always start with the organisation’s needs and the IGA technology that best fits them.
Different technologies have different strengths, limitations and architectural implications. Independent advisory means evaluating those differences objectively, not pretending they do not exist.
We understand a European origin alone is not a reason to recommend a technology. That is why we focus our attention on mature IGA platforms that introduce capabilities that directly address relevant requirements around infrastructure choice, operational control and jurisdiction.
Where Omada Identity Sovereign fits
Omada, one of the mature IGA platforms we work with, recently announced Omada Identity Sovereign, a new deployment option designed for European organisations with more demanding sovereignty requirements.
The fully containerised solution is being developed to allow customers to deploy and operate Omada’s IGA technology on infrastructure of their choice. This could include their own datacentres, a sovereign cloud provider or a partner-hosted environment.
Alongside this deployment flexibility, Omada is developing the solution to provide:
- feature parity with Omada Identity Cloud, including its AI-powered capabilities;
- customer-controlled encryption;
- freedom from dependency on a specific cloud provider;
- development and support based entirely within the European Union.
The solution is currently in development and is targeted for availability in early 2027.
The relevance of Omada Identity Sovereign will depend on the organisation’s requirements, existing architecture, operating model, maturity and risk profile.
But when digital sovereignty is a meaningful part of the strategic goals, Omada combines a strong IGA foundation with an approach that directly addresses infrastructure, operational and jurisdictional control.
Start with the requirements, not the label
Digital sovereignty should not become another technology label that organisations add to an RFP without defining what it means.
The real question is not whether an IGA platform can be called sovereign. The question is which forms of control the organisation actually requires and why.
For one organisation, data residency and contractual safeguards may be sufficient. Another may require control over infrastructure and encryption keys. A highly regulated or critical organisation may need the entire legal, operational and infrastructure chain to remain under European control.
This variation is also reflected in the European Commission’s Cloud Sovereignty Framework. Its Sovereignty Effectiveness Assurance Levels (SEAL) recognise different degrees of sovereignty rather than treating it as a binary characteristic.
These are materially different requirements and should inform technology decisions.
The selection process should therefore begin with architecture, identity use cases, regulatory context, dependencies and risk appetite. Once those requirements are clear, organisations can determine how much weight digital sovereignty should carry alongside functionality, security, scalability and cost.
Remember: control is what turns sovereignty from a label into a meaningful requirement.
Define what sovereignty means for your IGA landscape
We help you translate your architecture, regulatory context and risk profile into clear IGA requirements.
