Identity and Access Management (IAM) is often associated with the processing of personal data. During login, for example, information such as an email address and password is typically transmitted and compared with stored data that can be clearly linked to an individual. In addition, other information such as phone numbers, dates of birth, or IP addresses may also be processed. Access credentials often provide the key to further information that a user has access to. If the Identity and Access Management system is compromised in any way, identities may be stolen or valuable data exposed.
IAM must therefore always comply with data protection requirements, especially the GDPR. How can this be achieved?
Every company has the choice of developing its own IAM solution internally or outsourcing it to an external provider. Both approaches are evaluated below.
What “Compliant” Means in 2026
Before weighing the two options, it is worth asking what the yardstick actually is.
Article 32 GDPR requires technical and organizational measures (TOMs) that reflect the “state of the art”. That is a very intentionally moving target. What counted as adequate protection in 2020 does not count today. It is rather shaped by what has become common practice, and by what attackers have learned to do. An IAM system is not compliant once and forever, but only as long as it keeps up.
If your login involves biometrics, Article 9 GDPR applies additionally. Biometric data processed for the purpose of uniquely identifying a person is a special category, and the general legal bases of Article 6 are not sufficient. In a consumer-facing login, explicit consent under Article 9(2)(a) is in practice the only workable ground – which means the biometric route always needs a non-biometric alternative beside it, because consent that cannot be refused is not consent.
And for a growing number of companies the GDPR is no longer the only law to follow. Article 21(2)(j) of the NIS2 Directive lists multi-factor authentication among the risk management measures that essential and important entities must take, qualified by “where appropriate”. Article 9(4)(d) of DORA requires strong authentication mechanisms of financial entities without that qualifier. If you fall under DORA, the discussion about whether MFA is proportionate is over before it starts.
Both of the options that follow have to be measured against this.
Do it yourself (DIY) IAM and its Pitfalls
Developing your own identity and access management solution may initially seem simple if only a basic login function is required. However, later requirements to add additional functionality, such as single sign-on, enterprise login, social login, passwordless authentication, biometric methods, two-factor authentication, etc., significantly increase the complexity.
In addition, with a self-developed IAM solution, compliance with privacy requirements becomes difficult once the system exceeds a certain size. An IAM solution must not only be developed in compliance with data protection regulations, but also continuously adapted to the latest technological standards. At the same time, the demands for scalability, functional expansion, and operation across different systems and domains are increasing. This is often not economically feasible. Further complexities arise if the task has to be handled by an IT department that is not specialized in IAM.
As a result, once a solution is developed, it often stagnates and is not updated for years. However, using outdated software that does not meet current requirements is in itself a breach of data protection. That is what the state-of-the-art standard in Article 32 GDPR means in real-life: the software does not have to get worse for the gap to open. The benchmark simply moves. Data protection authorities have already imposed fines in similar cases. Worse still, in the event of a data breach, this can easily lead to directors and managers being held liable.
Depending on the number of managed users and the sensitivity of the data, an IAM solution must also be monitored and checked during operation. Regular penetration tests may be required. In many cases, certifications are also necessary and extensive documentation requirements must be fulfilled. Compliance must be demonstrated in data protection audits.
Outsourcing the Identity and Access Management
A good solution to these challenges is to outsource IAM to a cloud-based IAM provider (Identity as a Service, IDaaS). Cloud-based providers are typically well-versed in common standards such as OpenID Connect (OIDC), offer scalable solutions, and continuously develop them further.
Furthermore, they already provide many key functions as standard, including single sign-on, multi-factor authentication, passwordless login methods, and integrations with existing systems. Features such as multi-tenancy, a customized look and feel in line with corporate identity, and secure user identity management are also typically integrated.
Companies thus benefit from a ready-to-use, professionally operated solution that is continuously maintained and adapted to new technical and regulatory requirements.
Challenges of IAM Outsourcing With US Solution
There are also data protection pitfalls here. This is because almost all relevant IAM providers are based in the USA. If data is transferred to these companies, this constitutes a data transfer to a third country, since the GDPR does not apply in the USA.
In the past, such transfers have been cumbersome and complicated because of the need to use standard contractual clauses (SCCs) as a transfer tool. The situation has changed for the better with the EU Commission’s adequacy decision, which allows transfers without having to assess each case individually.
However, this is only true if the recipient of the data is actually certified under the EU-US Data Privacy Framework (DPF), which is not always the case. The DPF has meanwhile survived its first court test. In September 2025 the General Court of the EU dismissed an action for annulment brought by the French member of parliament Philippe Latombe. The judgment is under appeal before the European Court of Justice (ECJ), Case C-703/25 P, and no hearing date has been announced.
This is particularly significant because the ECJ has invalidated two earlier, comparable transfer mechanisms (Safe Harbor and Privacy Shield). Therefore, it is by no means certain that the EU-US DPF will remain available as a permanent transfer mechanism.
Since then, things have changed quite a bit.
When the EU-Commission declared US data protection adequate, it did not simply take Washington’s word for it. It pointed to specific American watchdogs and argued that they were independent enough to hold US companies and agencies to the promises made. Those assumptions seem to not hold any longer.
The first of those watchdogs is the Federal Trade Commission, the authority that enforces the framework against certified US companies. On 29 June 2026 the US Supreme Court ruled that the President may dismiss its commissioners at will and without giving a reason, overturning a rule that had held since 1935. An authority whose members serve at the pleasure of the President is impossible to describe as independent.
The second is the Privacy and Civil Liberties Oversight Board, the body that reviews US intelligence activities. Since January 2025 it has had too few members to take decisions at all, and the annual reviews of the framework have been suspended ever since.
Neither event was about data protection as such, but both let us at Engity ask: is anyone still watching?
None of this has invalidated anything per se. The DPF is in force, and certified US recipients may still receive data. But an adequacy finding rests on the independence of the institutions it names, and two of those institutions no longer look the way they did when the Commission described them. That is not a reason to panic. Yet. But it is a reason not to build an identity infrastructure that survives a post-DPF world.
What’s more, the transfer mechanism leaves intact U.S. laws such as the Cloud Act and the Patriot Act, and Section 702 of the Foreign Intelligence Surveillance Act. These force IAM providers to hand over data, including that of European customers, to U.S. authorities and intelligence agencies upon request. Unfortunately, this is true even if the data is stored on European servers.
Therefore, European servers alone are not a GDPR-compliant solution. For this reason, data transfers to the US will continue to be an issue for organizations that process sensitive data.
Partial Outsourcing by Using European IAM Provider
In general, outsourcing often offers many advantages over a fully in-house IAM solution. However, since there are not many relevant GDPR-compliant vendors, partial outsourcing can be considered. With this approach, an open-source solution from a third-party provider is used and operated on the company’s own servers. Despite the greater control this provides, the challenges associated with operating the solution in-house must be taken into account, particularly with regard to maintenance, scalability, and security.
The Ground Is Shifting: eIDAS 2 and the EU Digital Identity Wallet
And there is “one more thing”. So far we have asked: which solution is compliant? From here on it is also: which solution will still be connectable in eighteen months?
The revised eIDAS Regulation (EU) 2024/1183 entered into force in May 2024. By December 2026, every Member State must make at least one certified European Digital Identity Wallet available to its citizens and residents. By December 2027, organizations that are legally required to use strong user authentication – banks, telecommunications providers and other regulated sectors – must accept that wallet when a user presents it.
For identity management this is an architectural change. The wallet acts as an identity provider, and the protocol vocabulary is largely the one an OpenID Connect team already speaks. What is new is the credential formats, selective disclosure, and the requirement that relying parties register with a national authority before they may request a presentation at all.
European identity infrastructure has so far been the compliant choice. It is becoming the default one. Whoever builds or buys an IAM system today is also deciding whether it will be wallet-capable when the deadlines arrive – and that is a question a provider outside the European regulatory perimeter has little reason to answer first.
A European IAM Solution is Needed (And We’ve Got One)!
In summary, the only viable solution is to choose a European provider for the IAM solution. This way, the benefits of outsourcing to a cloud-based or cloud-native solution provider are combined with data processing in the European Union. GDPR compliance is achieved.
In addition, organizations that need an IAM solution can be confident that their users’ data is adequately protected, and that data processing is compliant with applicable legal requirements. In addition, they do not need to hire specialized experts to build and maintain an adequate DIY IAM solution.
At Engity, we are convinced that a European, cloud-based IAM solution combines security, scalability, and regulatory compliance in a way that represents the most sensible approach for most companies today.
Note: This article was first published in April 2022 and last updated and corrected in October 2026