Digital Identities and their Management: Common Mistakes to Avoid

Digital identities are central to every Zero Trust architecture and thus to every robust IT security strategy. Since security incidents, whether caused by cybercriminals or careless or malicious employees, almost always begin with the misuse of digital identities, these must be particularly controlled and protected. This applies first to the digital identities of one's own workforce – a use case that affects every company – as well as to digital machine identities, whose number is growing rapidly, and ultimately to all other identities that come into contact with the company: from end customers to suppliers to business partners. Most organizations are now aware of this, yet the management of digital identities often leads to fundamental errors that undermine investments in IT security. Avoiding the following five mistakes will significantly enhance your company's security.

1.     Lack of Overview – Permissions as a Labyrinth

The classic mistake in identity management is the lack of a structured overview of who has which permissions. In practice, role groups and permission structures evolve over the years, developed from ad-hoc requirements. One employee needs access to one system, the next to another – and suddenly you have a data landscape that no one can fully oversee anymore.

The biggest problem with this situation is the resulting paralysis: administrators no longer dare to make changes because they fear damaging the system or destroying important functionalities. This fear leads to inaction, where necessary adjustments are neglected, and permission structures continue to ossify.

The solution is to conduct a complete, automated audit of all existing permissions and create a clear, documented structure using a central Identity Management or Identity Governance and Administration (IGA) system and clear role-based access control (RBAC) models. Modern solutions are increasingly using AI to automatically generate overviews and detect orphaned accounts, over-privileged accounts, and accounts with unusual permission combinations. Additionally, regular access reviews and recertifications ensure that this structure remains permanently up-to-date and does not become unmanaged again. Only on this basis can targeted cleanups and adjustments be made.

2.     Flawed Authentication and Authorization – The Creeping Security Crisis

Another common mistake lies in the inadequate implementation of proper authentication and authorization. This often arises from inexperience or the concern that overly strict controls might impede essential work processes. The consequence of this reluctance is fatal: even in critical systems, global administrative roles are often assigned, even when entirely unnecessary.

A particularly problematic scenario arises when system applications themselves are equipped with overly extensive rights and do not operate contextually within limited areas. This creates the conditions for so-called "privilege escalation attacks," where users or applications can unlawfully expand their permissions.

To avoid this error, the principle of least privilege should be consistently implemented from the outset, and a detailed authentication and authorization policy should be established.

3.     Proper Dependencies or "The Lost Identity"

A particularly insidious mistake occurs in modern, distributed systems and microservice architectures. Here, a cascade of accesses arises: A user initiates a process, this system communicates with an intermediate system, which in turn addresses further systems – and ultimately, the result is displayed. The problem is that the system at the end of the chain no longer knows who triggered the original action and therefore cannot verify whether that person had the necessary permissions.

There is a loss of traceability between individual systems. The original identity is lost, and only machines communicate with each other – with overly broad or uncontrolled permissions. This happens when there is no consistent model for end-to-end management of identities, authorizations, and access within the company. A comprehensive identity and access management model provides a solution by tracking the identity of the original initiator across all system boundaries and validating and propagating permissions at every step. This is becoming increasingly important, especially for machine entities and agentic AI.

4.     Undesirable Dependencies or "Vendor Lock-in"

From a technical perspective, a major problem arises when proprietary technology and interfaces are chosen over open standards for identity management systems. This decision leads to dependence on the respective vendor ("Vendor Lock-in"), the consequences of which often only become apparent later.

Eventually, when new use cases are added – such as the integration of end customers, business partners, or additional proprietary systems – it becomes clear that the system is not extensible. A system that might have been installed as an on-premise solution in the nineties suddenly can no longer be adapted. In contrast, using open standards from the outset provides the necessary flexibility and prevents a company from ending up in a technical dead end. The problem worsens over time: IAM systems are deeply integrated into the entire IT landscape, making a later vendor change practically impossible. Moreover, open standards and data portability are no longer merely a technical nicety but are also legally enshrined – for example, by the EU Data Act. Anyone who loses control over their identity infrastructure will also, in the long run, lose control over central parts of their digital value creation.

5.     Growing Pains

Many organizations underestimate the importance of automated Joiner-Mover-Leaver processes in Identity Lifecycle Management – and this applies not only to their own workforce but also to partners, customers, and other external identities. When processes are manual – from onboarding to role changes to offboarding – this not only creates sources of error but also significant scalability issues. It becomes particularly problematic for systems that must be designed for a large number of end customers: Many traditional Identity and Access Management systems are not designed for such scenarios at all. Systems primarily designed for employee authentication reach architectural limits in highly scalable CIAM scenarios with millions of identities and peak loads.

Furthermore, there is often a lack of flexibility between on-premises and cloud environments. Organizations are practically forced into the cloud by vendors or find themselves trapped on-premises, even though they want to operate in a hybrid manner. Hybrid scenarios can be beneficial – for example, if a particularly critical part of the infrastructure is operated on-premises, while the rest can run in the cloud to minimize internal effort. It is crucial to choose a vendor that allows flexible switching between on-premises and SaaS, supports hybrid scenarios, and can easily handle fluctuating peak loads in SaaS operations. These thus offer the necessary flexibility and scalability for future requirements.

Holistic Thinking Required

Ultimately, all these errors stem from insufficient planning and a lack of overall coherence. With increasing regulatory requirements such as NIS2 or stricter data protection regulations, it becomes clear that Identity Management is not an optional IT optimization but a strategic component of corporate security. Effective Identity Management requires a consistent architecture, clear role and policy models, automated lifecycle processes, token-based authentication according to open standards, and an exit-ready system landscape without proprietary dependencies. This also enables the necessary flexibility for future growth. Organizations should therefore act proactively, audit existing systems, and focus on transparency, standards, and scalability from the outset during new implementations.

Disclaimer: The information regarding NIS2, the EU Data Act, and other regulatory requirements is for general guidance and does not constitute legal advice. Please assess the applicability to your company individually.

‍