1 Introduction

Employees’ simple and reliable access to digital resources and software applications is one of the essential prerequisites for many organizations’ operation (Smith and McKeen 2011). In practice, however, it is difficult for IT managers and users to set up, maintain, and use this access, and it comes at a high cost (Casassa Mont et al. 2003; Sinclair and Smith 2008; Windley 2005), especially when businesses grow and their technology environment becomes increasingly heterogeneous (Bradford et al. 2014). Complexity is also a driver for security incidents like data breaches that can result in unexpected remediation costs and damage to company reputation (Enterprise Management Associates, Inc. 2020), customer churn (Ponemon Institute 2019), and severe fines for violating data protection regulation (LogMeIn 2019; Schlackl et al. 2022). The situation was further aggravated during the COVID-19 pandemic with an estimated 70% of employees working from home (Sadler and Hancock 2020) and a corresponding increase of cyber-attacks; mainly phishing (Naidoo 2020). Several studies found that employees feel more tired, unmotivated, and distracted when working from home (e.g., Velocity Smart Technology 2021). As a result, mistakes and a lack of vigilance appear more frequently (Irwin 2021), and the likelihood of employees giving away their passwords in a phishing attempt increases (Sadler and Hancock 2020).

Besides offering better password management for employees, identity and access management (IAM) systems provide enterprises with tools to support them in handling and monitoring a growing number of identities beyond employees, such as external partners, customers, and – driven by the growing relevance of the Internet of Things (IOT) – smart devices (Haber 2020). 77 % of enterprises aim to increase their budget for IAM to mitigate cybersecurity risks (Globenewswire 2020). In contrast, only 38% of companies used dedicated IAM software in 2017 (IDG Business Media GmbH 2017), illustrating the considerable challenges and costs involved with setting up and maintaining these systems. Consequently, enterprises also take complementary approaches, such as raising the awareness of cybersecurity among employees and deploying anti-virus software (Deloitte 2020), or look into new approaches, for instance, zero-trust architectures (Puchta et al. 2019; Buck et al. 2021).

At the same time, the threat of being subject to cybersecurity incidents for companies is increasing. In 2019, the global cost of data breaches alone was $ 2.1 trillion, and it is expected to rise further to $ 5 trillion in 2024, according to Juniper Research (2019). More conservative estimates still suggest that data breaches account for a significant share of the total annual costs of cybercrime of $ 1 trillion (Dyble 2020). 43 % of data breaches involve attacks on web applications, of which more than 80 % can be traced back to brute force attacks on employees’ passwords or the use of lost or stolen credentials (Verizon 2020). Consequently, every third data breach can be linked directly to password management. Taking into account that data breaches are only one of the potential consequences of poorly implemented IAM, the need to improve related solutions seems to be widely recognized by researchers and practitioners (Smith and McKeen 2011; Puchta et al. 2019). However, there has been surprisingly little holistic academic research on the requirements of IAM systems, which we deem essential to designing and evaluating new solutions. Consequently, this study seeks to identify and categorize enterprise requirements for employee IAM solutions, leading to our first research question (RQ):

RQ1: What are the requirements of IAM in enterprises?

One of the most prominent new paradigms for digital identity management and in particular authentication is decentralized digital identity management or self-sovereign identity (SSI) (Gartner Inc. 2020; Sedlmeir et al. 2022; Soltani et al. 2021). SSI is not specifically targeting IAM but rather end users’, organizations’, and smart devices’ digital identity management in general. It provides users with digital wallet apps on their mobile phones and empowers them to self-manage digital representations of identity documents such as passports, qualifications, access authorizations, or membership cards (Sartor et al. 2022; Richter et al. 2023). This paradigm, which is often associated with blockchain technology (Mühle et al. 2018; Sedlmeir et al. 2022), has received increasing support from industry consortia and governments in recent years (Kubach and Sellung 2021; Schmidt et al. 2021). Despite these developments, there is still a lack of research in the academic literature on how SSI can improve digital identity management in organizations in general and in IAM in particular. While some research has started investigating different technical aspects of SSI in the context of established IAM standards (Yildiz et al. 2021; Di Francesco Maesa et al. 2023), this study is to the best of our knowledge the first to holistically investigate the extent to which the SSI paradigm in IAM is suitable for meeting IAM system requirements (see RQ1). Our second research question, therefore, is as follows:

RQ2: How can SSI help address the requirements of IAM in enterprises?

To explore the requirements of IAM systems and potential improvements through SSI, we choose a design science research (DSR) approach (Hevner et al. 2004; Peffers et al. 2007). DSR uses scientific methods to design new artifacts or modify existing ones to solve relevant practical problems (Venable and Baskerville 2012; Johannesson and Perjons 2014) and is, therefore, suitable for identifying the challenges of today’s IAM in enterprises and designing corresponding solutions. Our study finds that both technical considerations and the role of enterprise IT management and employees as end users are essential for deploying IAM solutions in practice. We first identify four categories of requirements for IAM and use them to discuss how SSI can contribute to creating more secure and manageable IAM solutions.

The remainder of this paper is as follows: Sect. 2 introduces the theoretical background and salient research on identity and access management and SSI. We then describe our DSR approach (Sect. 3), which we use to identify and analyze IAM requirements (Sect. 4). Section 5 presents our SSI-based IAM prototype, followed by its evaluation by experts (Sect. 6) that sheds light on the potential benefits of SSI-based IAM. We also discuss limitations that point to avenues for future research and conclude with Sect. 7.

2 Related Research

2.1 Identity and Access Management

IAM encompasses both “identity management” and “access management” (Thakur and Gaikwad 2015), i.e., it involves the management of identities as well as the processes associated with authentication and authorization processes in organizations. Identities can be claimed by human and non-human entities (Windley 2005). In an enterprise context, the human entities of employees, suppliers, partners, and customers can be distinguished (Mezler-Andelberg 2008). Non-human entities cover organizations, machines, or software applications (Windley 2005).

Authentication is the process of proving control of an identity but does not yet grant access rights (Haber and Rolls 2020). Such proofs of identity involve credentials, sometimes called authenticators, which can be divided into three categories: “what you know” (e.g., a password), “what you have” (e.g., a physical key), and “who you are” (e.g., represented by a fingerprint) (O’Gorman 2003). These credentials can be used also in combination in so called multi-factor authentication (MFA) to increase the level of assurance and, thus, security (Windley 2005). The form of authentication that a system admits generally depends on the type of access and the associated risks (Mezler-Andelberg 2008). In 2019, the use of MFA by companies reached around 57% worldwide, a significant increase from the previous year (LogMeIn 2019). However, MFA not only increases security, it can also increase cost and complexity for organizations and negatively impact user experience (Windley 2005; Yubico and 451 Research 2021; Acemyan et al. 2018).

Once a user is authenticated, access is granted or denied during authorization (Haber and Rolls 2020). An access control list (ACL) of authorized users, i.e., to implement read and write permissions, can be attached to resources (Ferraiolo et al. 2007). By configuring and maintaining such a list, it is easy to keep an overview of which user has which kind of access to the respective resource. However, at the same time it is often difficult to determine to which resources an individual user has access (Ferraiolo et al. 2007), especially in an enterprise with thousands of software applications, some of which are hosted by third parties. As the number of users and resources increases, the costs of managing ACLs hence increase substantially, making the approach inappropriate for larger organizations (Oh and Park 2003). Moreover, while adding permissions is easy, revoking permissions for a particular user is difficult with ACLs (Ferraiolo et al. 2007). Consequently, more common access control models used in enterprises are discretionary access control (DAC), role-based access control (RBAC), and attribute-based access control (ABAC).

DAC allows a resource’s owner to decide who is granted access, and entities that have access can in turn delegate, i.e., pass on, this permission (Ferraiolo et al. 2007). In contrast, RBAC assigns roles to specific access rights (Benantar 2006; Mezler-Andelberg 2008). Users can then be assigned one or multiple roles and receive the associated permissions (Ferraiolo et al. 2007). RBAC is the access control model most used by enterprises (IDG Business Media GmbH 2017); yet it causes considerable problems. For instance, when employees change jobs, access rights and roles need to be adjusted, which represents a major administrative burden and cost factor for companies (Kern and Walhorn 2005; Li and Karp 2007; Fuchs and Pernul 2013; Oh and Park 2003; Zhao and Johnson 2010). ABAC aims to address these challenges by granting or denying access based on users’ and resources’ attributes and environmental conditions. Since attributes can be specified and combined more flexibly than roles, ABAC enables particularly fine-grained access control (Hu et al. 2015). If a change of access rights is necessary, the underlying rules can remain untouched and the modification of a single attribute associated with a user is sufficient (Hu et al. 2015).

Regardless of the choice of access control model, there are generally acknowledged principles that should be applied in IAM systems. The principle of least privilege states that users should only possess the minimum rights necessary for their tasks (Ferraiolo et al. 2007). If a user has significantly more rights than necessary, they could cause excessive damage to the system in the event of an attack or misuse (Benantar 2006). Access rights should, therefore, be chosen carefully and reviewed from time to time. A similar guideline is the principle of least knowledge, which specifies that users but also IAM system administrators should only see the resources associated with their task (Alsmadi 2019). Moreover, to mitigate fraud, separation of duties can be used to ensure that not all steps of a critical operation can be performed by a single user (Ferraiolo et al. 2007).

IAM remains a major challenge for organizations, as attempts to improve the security of their employees’ passwords often prove ineffective. When employees are forced to reset their passwords on a regular basis, 49% of employees change only a single digit or character in their old passwords (Jacobson 2020). Employees who find password policies and management onerous also tend to experience security fatigue, making enterprise IT systems even more vulnerable (Cram et al. 2021).

2.2 Self-Sovereign Identity and Digital Wallets

SSI can be considered a paradigm that extends the use of asymmetric cryptography and, in particular, digital signatures beyond the identity management of web servers and makes it accessible to end users via digital wallets (Sedlmeir et al. 2022). Certificate-based identity management has been a backbone of cybersecurity for decades (Lioy et al. 2006), and SSI aims to apply this approach to identity management for end users, smart devices, and organizations (Preukschat and Reed 2021). It is seen as an answer to the security, usability, and efficiency challenges of logging in with usernames and passwords (Bonneau et al. 2012), and as an alternative to the privacy issues and lock-in effects related to the data silos of federated identity providers that offer a convenient single sign-on experience (Kubach et al. 2020; Ehrlich et al. 2021; Sedlmeir et al. 2022).

Certificate-based digital identity management for end users was already widely discussed in the computer science literature as early as the 2000 s (e.g. Backes et al. 2005; Lioy et al. 2006; Jøsang and Pope 2005; Ahn et al. 2009), but did not gain broad awareness or acceptance in practice until recently (Kubach et al. 2020). Potential reasons for the renewed interest in using this paradigm for end users’ identity management may be traced back to the increasing availability and capabilities of mobile phones (Sedlmeir et al. 2022). Moreover, it seems that the collaborative spirit in public and private ecosystems in the context of a broad enthusiasm for blockchain technologies, and the corresponding cryptographic key management, may have promoted the interest in identity management through digital wallets (Mühle et al. 2018; Jørgensen and Beck 2022). Although blockchain technology is not required for SSI (Chadwick 2020; Schlatt et al. 2022a), the technologies are strongly connected (Mühle et al. 2018; Čučko and Turkanović 2021), and many SSI frameworks leverage a blockchain for their underlying public key infrastructure (PKI) (Schmidt et al. 2021). In the context of SSI, also a new standard – verifiable credential (VC) – has emerged (Sporny et al. 2021). VCs aim to replace identity documents based on paper or “plastic cards” (Richter et al. 2023) by means of digital attestations and can be thought of as an extension and generalization of traditional, digitally signed documents, such as X.509 certificates that build the identity layer for web servers and JSON Web Tokens that are frequently used in enterprise applications leveraging federated identity management based on protocols like OpenID Connect (OIDC) (Babel and Sedlmeir 2023; Kuperberg and Klemens 2022).

SSI comprises three important roles: Issuers, holders, and verifiers (Soltani et al. 2021). An issuer digitally signs VC that contain claims about their subject’s attributes and sends them to the holder (Sporny et al. 2021). Holders request VC from issuers and store them in their digital wallets that often take the form of mobile apps for end users. Since holders store their VC locally, they have control over data disclosure (Sartor et al. 2022). They can then use their VC according to their preferences to create machine-verifiable proofs about claims concerning their identity in a verifiable presentation (VP) when interacting with a verifier (Sporny et al. 2021; Feulner et al. 2022). As digital information tends to leave unique traces, an important principle of SSI is that it is possible to reveal only certain parts (“selective disclosure”) or only properties derived from it (“predicates”), such as a proof of legal age (Feulner et al. 2022), and to allow the cryptographic verification of the VP’s authenticity despite hiding the unique value of the digital signature or the binding public key from the verifier (Babel and Sedlmeir 2023). These privacy-enhancing features are typically based on cryptographic zero-knowledge proof (ZKP) (Backes et al. 2005; Camenisch and Lysyanskaya 2001; Hardman 2020; Di Francesco et al. 2023). A ZKP gives evidence about the correctness of a statement (e.g., the result of a computation) without transferring any knowledge beyond the statement under consideration (Goldwasser et al. 1989).

A VP can involve one or several VC, and the corresponding proof is automatically checked by the verifier upon receipt (Preukschat and Reed 2021; Feulner et al. 2022). Due to the forgery-proofness of digital signatures, there is no need for communication between the issuer and the verifier. However, verifiers will in general only trust a verifiable credential (VC) used in a VP if they trust the corresponding issuer. Communication between parties takes place via end-to-end encrypted messaging between software components, so-called agents (Preukschat and Reed 2021; Schlatt et al. 2022b). Agents sometimes integrate a client for a blockchain that is used to store issuers’ public signing keys, standards, and revocation information (Schlatt et al. 2022a). The latter is required as VC reside in the holder’s wallet, so they can no longer be removed reliably after issuance (Ruff 2018). Revocation is often implemented via revocation registries. For the identity management of servers, there is no big issue with publicly available revocation information; however, from an end user’s perspective, this approach poses privacy challenges (Babel and Sedlmeir 2023). For this purpose, some SSI implementations hide credentials’ unique identifiers in VPs, proving only set membership or non-membership in the public revocation registry by using a ZKP (Hardman 2020; Schlatt et al. 2022a).

Several businesses and organizations have already started to provide software solutions based on SSI. In particular, companies such as esatus, Evernym (recently acquired by Avast), or Trinsic, as well as public-private initiatives like IDunion that involve many public and private sector stakeholders, implement digital wallet apps for end users that already offer a decent level of standardization and interoperability (Sartor et al. 2022). The EU has also passed a law that mandates member states to provide their citizens with digital wallets and to enforce their use for login with digital service providers in the course of the revision of the electronic identification, authentication and trust services (eIDAS) regulation (European Commission 2021; Schwalm et al. 2022). The range of SSI use cases and potential benefits covers, for instance, passwordless digital authentication and digital proofs of attributes or permissions through digital ID cards, driver’s licenses, credit cards, or COVID-19 vaccination certificates (Sedlmeir et al. 2022). In domains such as access control for web applications (Braun et al. 2023), managing know your customer (KYC) processes (Schlatt et al. 2022a), digital diplomas (Grech et al. 2021), and event tickets (Feulner et al. 2022), researchers have already studied the improvements that SSI can provide for individuals’ authentication and authorization processes. On the other hand, businesses such as esatus, IdRamp, MATTR, or Workday advocate the potential benefits of an SSI-based flexible and passwordless digital identity management for enterprise IAM and offer corresponding software solutions. Kuperberg and Klemens (2022) recently surveyed the compatibility of and technical bridges between technical components and protocols associated with legacy IAM and SSI, and Belchior et al. (2020) proposed and implemented an SSI-based identity management across organizations.

3 Research Approach

To determine how SSI can improve enterprise IAM, we follow a DSR approach (Hevner et al. 2004; Peffers et al. 2007). DSR had long a tradition in software engineering before it found its way into the field of information systems (Peffers et al. 2007), combining elements from engineering (Eekels and Roozenburg 1991) and behavioral sciences (Hevner et al. 2004). In general, DSR involves the development of an artifact, such as methods, products, processes, or services, to address a general problem, and an evaluation of the solution’s fitness to solve the problem (Venable and Baskerville 2012). DSR therefore aligns with the goals of information systems research, which also employs build-and-evaluate processes to study the interaction of technical and social systems and find solutions to practical challenges (Lee 2001).

Commonly, DSR encompasses three different phases: first, the relevance cycle that identifies the practical problem that needs to be solved and the corresponding requirements for research (Hevner et al. 2004; Hevner 2007; Peffers et al. 2007). The next phase, also known as the design phase, is concerned with building and evaluating the design artifact (Hevner 2007). This is followed by a rigor cycle to ensure that artifacts are useful contributions to research and not routine designs (Hevner et al. 2004; Gregor and Hevner 2013). Since it can be challenging to balance the need for practical contributions in a changing technological environment with generalizing and theory building (Baskerville et al. 2018), an expansion of the knowledge base or the implementation of a novel IT artifact that provides solutions to practical problems can already be an appropriate contribution to research (Beck et al. 2013; Gregor and Hevner 2013; Baskerville et al. 2018). In the following, we will further elaborate on our research design and the involved methods. Figure 1 displays our DSR approach and the involved methods that we will describe in more detail below.

Fig. 1
figure 1

Phases of the design science research approach

Full size image

In the relevance phase, we first conducted a systematic literature review (SLR) to identify IAM requirements in enterprises (Levy and Ellis 2006). Next, we coded all publications using Saldaña (2015)’s approach and clustered the requirements using a distance metric derived from related sub-requirements. This generated an initial structured collection of IAM requirements that served as design objectives for the artifact (Peffers et al. 2007). To increase relevance, we then conducted interviews with twelve domain experts with the goal of (1) completing the perspective on IAM requirements and (2) refining the categorization. After examining the state of the art of research on SSI in an enterprise context, we took the results as input for a design cycle in which we conceptualized and instantiated a prototype for SSI-based IAM (Sect. 5). In a subsequent rigor cycle (Hevner et al. 2004), we again used expert interviews to assess whether the implementation sufficiently addresses the previously defined opportunities or problems (Hevner 2007). Furthermore, we present new knowledge generated in our DSR in the form of structured requirements and our prototype to the scientific community (Peffers et al. 2007) and demonstrate how SSI can contribute to improving IAM in enterprises. This involves both the dissemination of this manuscript and the disclosure of our demonstrator’s source code.Footnote 1

4 Analysis of IAM Requirements

4.1 Systematic Literature Review

To identify and structure the requirements associated with IAM systems in enterprises (see RQ1), we rely on a SLR consisting of three steps: inputs, processing, and outputs (Levy and Ellis 2006). We then use the results of this analysis as input for the design of our artifact as part of the DSR (as described in Sect. 3). In general, literature reviews support the proposed research question and provide a solid foundation for the research endeavor (Levy and Ellis 2006). The first step is to identify the relevant literature to ensure a certain level of quality of the literature (Levy and Ellis 2006; Kitchenham et al. 2009). This can be achieved through various techniques, such as applying inclusion and exclusion criteria and documenting the search process (Kitchenham et al. 2009). Next, the processing step involves either analyzing, synthesizing, applying, or evaluating the identified literature. The final step is to present the results in a comprehensive and understandable way. We will elaborate more on these steps below.

4.1.1 Procedure

Following Levy and Ellis (2006), we selected the articles for the SLR using a keyword search, followed by forward and backward searches. To determine a suitable search string that is broad enough to cover existing work on IAM in enterprises but at the same time has a sufficiently high density of relevant hits, we performed a keyword search in several databases with many synonyms for IAM, combined with synonyms for enterprises using the logical operator “AND”. We screened the first pages of results and focused on works with many citations or where the abstract matched our research topic. Due to the large number of potentially relevant articles we found in the initial search, we decided to limit our focus to enterprise IAM for employees. The final search string we used for the SLR was

(“Identity Management” OR “Access Management” OR “Access Control”)

AND Employe*

AND (Busines* OR Compan* OR Enterpris* OR Organi*)

Table 1 features the databases we searched with this search string and the corresponding numbers of hits. We considered 10 hits as a page. Since many databases still yielded far too many initial hits, we decided to end the search once 20 hits in a row no longer yielded a relevant article after abstract and full-text screening. The decreasing trend of the number of relevant hits per page (see Table 1), as well as the limited number of works that the subsequent backward search (9 new articles) and forward search (no new articles) added, indicate that we were able to cover the field comprehensively with these heuristics. In the course of the search, we screened a total of 5,569 articles. After applying inclusion and exclusion criteria (Kitchenham et al. 2009), 40 articles remained for in-depth full-text analysis (see Table 1 in Appendix A.1; available online via http://link.springer.com). Inclusion criteria included selecting articles or book chapters that address enterprise IAM requirements or improvements for IAM approaches; exclusion criteria, on the other hand, applied to articles written in a language other than English or German and articles with IAM requirements for consumers or other stakeholders. In addition, articles to which the authors did not have access were not considered. These were 45 articles in the keyword search, 164 in the backward search, and 25 in the forward search.

Table 1 Number of relevant search results per database (keyword search)
Full size table

Among these 40 articles, Puchta et al.’s (2019) study is the only one that systematically structures requirements for IAM systems, using a literature review and expert interviews. The authors identify five current challenges for IAM. These are integration of identities beyond the employee level, heterogeneity, data quality and management, the transition from role-based to attribute-based approaches, and privacy. Puchta et al. (2019) also discuss how visual analytics can address the first three challenges to varying degrees. In contrast, our focus is not only on incremental improvements but on the suitability of an alternative, SSI-based solution for enterprise IAM. Consequently, for identifying comprehensive design objectives of a novel approach, we intend to cover not only current challenges of IAM but also general requirements. We will also see that SSI can contribute to the last two challenges of Puchta et al.’s (2019) study, thus complementing their research.

After screening papers of interest in accordance with RQ1, we continued with the processing step, which included the analysis and evaluation of the works to be reviewed. As proposed by Levy and Ellis (2006), we identified key IAM requirements germane to the research question and categorized thematically similar ones into groups. For generating categories, we used coding (Saldaña 2015). The coding was performed iteratively in MAXQDA by one researcher alone, which is a common procedure for less extensive research projects (Saldaña 2015). To ensure validity, the researcher shared her coding scheme captured in the codebook – a compilation of codes and brief examples – with the other researchers in the team to achieve group consensus (Harry et al. 2005; Saldaña 2015). The first cycle consisted of two steps: (1) the initial coding in which the relevant data were divided into smaller parts (Strauss and Corbin 1998) and (2) subcoding in which the obtained codes were further subdivided and refined (Saldaña 2015). For books, we only coded the relevant sections. During the first cycle, we identified 24 categories corresponding to 280 (sub-)codes. Figure 1 in Appendix A.2 illustrates how often the 24 categories appeared in the 40 articles.

In a second cycle, we relied on pattern coding to identify and group thematically similar codes together (Onwuegbuzie et al. 2016). We performed pattern coding using the unweighted average linkage method in MAXQDA, as it allows to merge the clusters with the highest similarity step by step (Forina et al. 2002). Our computer-assisted, statistical analysis may also allow for more rigorous analysis than human-based merging (Bringer et al. 2004). Structuring the codes from the SLR resulted in eight different requirement clusters that define our design objectives. Figure 2 in Appendix A.3 depicts how often codes from these clusters appeared in the articles overall, while Tables 2, 3, and 4 in Appendix A.4 present the number of overlapping subcodes, used to generate the distance matrix for pattern coding. Figure 3 in Appendix A.4 illustrates the corresponding distances between categories. The colors indicate which of the categories form a cluster. One theme (“control”) is missing in the distance matrix because the topic has insufficient links with other codes to calculate a meaningful distance matrix. Therefore, we have kept it as a separate cluster.

4.1.2 Results of the Literature Review

In the following, as part of the final step of the SLR (Levy and Ellis 2006), we present all eight clusters we identified in descending order according to the aggregate frequency of the codes they comprise:


Cluster 1 – Security, Compliance, Integrity, & Auditability: The first cluster consists of requirements associated with security risk avoidance, technical measures to increase security, as well as with auditing and monitoring. Security threats, for instance, should be minimized as far as possible or, if feasible, prevented altogether (Walter et al. 2004). Frequently, passwords are a root cause for security problems, so the usage of MFA that requires further credentials like biometric data or a physical token is increasing (Theofanos et al. 2016; Keszthelyi and Michelberger 2012). The continuous adaptation of security mechanisms is essential, as the methods used to break into a system are also constantly evolving (D’Costa-Alphonso and Lane 2010). To reduce risks, audits can be conducted (Damon and Coetzee 2018), for instance, to determine overprivileged users (Bradford et al. 2014). Monitoring employees’ activities is not only important from a security perspective but also with regard to ensuring integrity and compliance (Haber 2020). For instance, organizations today have to comply with several regulations that mandate the record-keeping and reporting of IAM-related information (e.g. Damon and Coetzee 2018; Hummer et al. 2018; Zhao and Johnson 2010), such as the Sarbances-Oxley Act.


Cluster 2 – Manageability, Efficiency, Automation & Cost: The large number of identities, databases, and applications that today’s IAM systems need to handle contribute significantly to obfuscating and ultimately inhibiting a holistic picture of users’ permissions, complicating manageability (Puchta et al. 2019; Pöhn and Hommel 2020; Osmanoglu 2014; D’Costa-Alphonso and Lane 2010). Consequently, it is important to track employees’ authorizations and activities to some extent to prevent fraud and facilitate audits (Smith and McKeen 2011; Osmanoglu 2014). Automating related processes, such as access reviews, certifications, and password resets, can help reduce the manual effort and increase efficiency (Osmanoglu 2014; Bradford et al. 2014) and reducing costs, for instance, for IT help desks (Osmanoglu 2014; Theofanos et al. 2016; Windley 2005). Other cost factors include modifications to role assignments and access lists – frequent processes that considerably increase the management workload (Kern and Walhorn 2005; Li and Karp 2007).


Cluster 3 – Standardization, Interoperability & Simplicity: Many companies face an organic growth of their digital resources and related IAM tools, without considering standards or interoperability (Bradford et al. 2014; Windley 2005). In addition, there are often differences in processes depending on the location or department (Osmanoglu 2014). The prevailing complexity from the company’s point of view is often underestimated and can lead to substantial problems, especially when introducing new IAM systems (Royer 2013). The use of and adherence to established standards can help mitigate these challenges with interoperability and integration as well as simplify IAM systems (Small 2006; Windley 2005). Furthermore, standards can help create a more consistent user experience and make it easier to realize a higher degree of automation (Damon and Coetzee 2013; Osmanoglu 2014; Sinclair and Smith 2008; Windley 2005). Complexity, on the other hand, can negatively impact manageability, security, and efficiency (D’Costa-Alphonso and Lane 2010) and imply high costs (Small 2006; Sinclair and Smith 2008).


Cluster 4 – Privacy & Trust: Employees’ personal data must be protected and proper use should be ensured by using data only to the required extent (Windley 2005). Users need to be able to trust identity and service providers as well as devices not to disclose unnecessary information (Bertino and Takahashi 2011; Walter et al. 2004). Concerns about data being accessed and correlated, sold, or misused in some other ways are frequently present (Casassa Mont et al. 2003). Privacy-enhancing mechanisms are also important to comply with data protection regulations (Bertino et al. 2001), for instance, the EU GDPR (Puchta et al. 2019). Owing to the presence of tradeoffs between privacy and accountability, the extent to which data is kept private may depend on the resource that is to be protected (Windley 2005).


Cluster 5 – Flexibility: Flexibility refers to the ability to adapt to the introduction of new IT solutions or security threats that need to be dealt with (Casassa Mont et al. 2003; Keszthelyi and Michelberger 2012). Furthermore, it also includes the capability of an implementation to grow with an increasing number of applications or users (Fairchild and Ribbers 2011).


Cluster 6 – Availability: Beyond a few critical special cases, access to systems and data should not depend on employees’ location or device, allowing tasks to be completed at all times (Walter et al. 2004) and from different places. This requirement has become apparent particularly in lockdowns and home office periods during the COVID-19 pandemic (Guggenberger et al. 2021). This means that every employee on site, as well as employees accessing them remotely, should have the necessary access to resources in a timely manner (Damon and Coetzee 2013, 2018; Zhao and Johnson 2010).


Cluster 7 – Control: Employees and users in general often feel that they have limited control over their identity data. While no attributes of their identity should be shared with a service provider without explicit consent (Hoepman et al. 2008), it is unclear how users are able to technically enforce this. Once their data is stored on different, unrelated sites or platforms (silos), they can no longer influence what is shared with whom. Hence, they call for more transparency and selective disclosure that allows only the minimum necessary information to be shared on request (Casassa Mont et al. 2003; Smith 2008).


Cluster 8 – Portability: Portability requirements apply to identities and accounts (Pöhn and Hommel 2020; Smith and McKeen 2011). Their usage should not be restricted to a single device or system (Hoepman et al. 2008; Smith and McKeen 2011). A lack of portability can be used by IAM service providers as part of their business strategy to increase the cost of switching. This aggravates the negative implications of lock-in effects for enterprises regarding their IAM system (Graef et al. 2013).

4.2 Refinement and Interview-Based Evaluation

We conducted semi-structured interviews with a total of twelve experts to complement and review the identified IAM requirements. The research team approached participants individually because of their expertise in the field of IAM or SSI. Of those who agreed to be interviewed, four work or have worked directly in the field of IAM, and four other experts have a background in IT management. In addition, eight of the twelve experts are working or have worked on novel forms of digital identity management, for example, based on blockchain and SSI. We include more details on the experts’ areas of expertise in Table 5 in Appendix B.1. To minimize response bias, we assured all respondents that their participation was voluntary and offered to anonymize their statements (Podsakoff et al. 2003). In addition, all interviews were conducted by the same researcher to ensure consistency in data collection (Brod et al. 2009).

Each interview followed a guideline in a semi-structured format (see Table 6 in Appendix B.2). In the beginning, questions focused on the experts’ general interest in IAM and their personal experience in this field. In the second, exploratory part of the interview, we asked the experts to report on what requirements and challenges they can identify in the use of IAM systems in companies, and where they currently see the greatest need to catch up. For instance, we asked “what benefits do you see for an organization by implementing an IAM system?” and “what are the possible drawbacks of such a system?”. In the last part of the interview, to avoid bias, we then discussed the design objectives we derived in Sect. 4.1.

We transcribed and coded the interviews as we did for our literature review. In the first cycle, we performed a structural coding to break down the data into segments (Saldaña 2015). We chose the segments based on our interview guidelines, resulting in 10 codes. Following Saldaña (2015)’s recommendation to use other first cycle methods as the next step (Saldaña 2015), we continued with an initial coding as a starting point for further analysis. In a second cycle, we then used axial coding to define the dimensions of a category, as categories are linked to subcategories (Saldaña 2015; Charmaz 2014; Strauss and Corbin 1998). At the end of this cycle, we had a total of 213 codes. We present the results according to the structure defined in the structural coding.

4.2.1 Open Collection of IAM Challenges

To compare the experts’ assessments of IAM system requirements with the result of our SLR, a researcher with knowledge in the field of IAM first coded the experts’ responses along the original 24 categories we derived from the literature review. We illustrate the frequency of appearances in Figure 4 (Appendix B.4). The in-depth analysis of the interviews reveals that the experts most frequently addressed topics from the cluster “Security, Compliance, Integrity, & Auditability”. From their perspective, organizations need IAM to better control access to resources from both a security and a governance perspective, addressing auditing and risk issues (Experts 1, 4, 5 & 12). They also mentioned that monitoring user rights is often a compliance issue, especially for insurance companies and banks:

“They [A/N: banks and insurance companies] are already required by their compliance frameworks, whether it’s COBIT or the Basel standards and anything else that’s out there, to clarify who has which authorization, and they have to fully delineate that.” (Expert 8)

The experts also see a substantial risk of security breaches when IAM systems are poorly implemented, as the following statement indicates:

“So if it’s poorly implemented [...], then under certain circumstances [...] you have the problem that the identity can be stolen [...].” (Expert 6)

Overall, the experts still see a great need to catch up in terms of the implementation of IAM systems, especially among medium-sized companies. During the interviews, some of them mentioned that enterprises’ IT departments often lack incentives to implement such a complex system, and the benefits are often not yet fully recognized, especially if IT is not part of the business model (Experts 9 & 10).

The second cluster most frequently addressed by experts was “Manageability, Efficiency, Automation & Cost”. The experts agree that IAM systems offer considerable advantages for overseeing systems and employees and their authorizations (Experts 1, 2, 6 & 10). When the size of a company reaches a certain threshold, they consider an IAM system indispensable (Experts 10 & 12). However, the experts note that managing an IAM system also involves increased effort, including costs (Experts 2, 3, 6, 9, and 10). With regard to efficiency, the experts contended that authorizations should be assigned as efficiently and quickly as possible to new employees to achieve first-day readiness. On the other hand, they also emphasized the importance of being able to revoke authorizations quickly (Expert 8). Some of the interview participants emphasized how a high degree of automation in IAM systems can help prevent unwanted access:

“It helps [...] to have strict identity and access management [...] so that [...] I can automate things and then no users [...] that have been retired for ten years have access to any systems.” (Expert 1)

As there are usually many different systems in large companies (Bradford et al. 2014), the effort required to maintain the IAM system increases and IAM staff can lose the global perspective (Experts 1, 6 & 10). When each system has its own independent process and assigns permissions individually, there is no longer a single comprehensive history of permission granting and revoking processes (Expert 10). Expert 8 noted that IAM systems can assist with these issues by mapping the organizational structure and managing employees’ permissions and roles.

Topics from the cluster “Standardization, Interoperability & Simplicity” were third-most mentioned. The experts see particular challenges when integrating a new IAM solution into existing systems. One of the experts pointed out:

“It’s [...] always difficult when you want to migrate from one system to another, and there’s kind of a [system] landscape already in place.” (Expert 1)

One expert also mentioned that businesses often avoid implementing IAM systems because they fear the corresponding complexity. The following statement addresses the potential hassle due to overlaps with other systems:

“Our whole structure is not designed for that at all. [...] We have the file server where all kinds of data converge, and to separate that [...], [everything] would have to be completely redone.” (Expert 4)

The experts also see room for improvement in terms of standardization and usability; for instance, to prevent the need for several roles across different systems (Expert 12). According to the experts, the heterogeneity and the number of isolated solutions affect not only security but also have substantial implications, as the following statement reasons:

“For the individual user, I would say, it [A/N: the implementation of an IAM] is certainly associated with certain fears because it of course makes it quite transparent who has access to what, and things that work in a shadow IT environment, like when users somehow book an app service or a cloud service themselves [...], are no longer that simple [...].” (Expert 1)

Besides these three clusters, the experts also referred to each of the clusters “Privacy & Trust” and “Flexibility”. Overall, the distribution of the experts’ responses is quite similar to the findings of the SLR, indicating that our findings are consistent. However, comparing the individual categories that they named, we notice some differences compared to related work (cf. Figures 1, 2, and 4 in the Appendix). The topic of security, which was one of the most mentioned in our SLR, was also mentioned several times by the experts, but not quite as frequently. A potential reason is that the security requirement is so obvious that the experts did not consider it worth discussing as much. The topic of manageability, by contrast, was mentioned considerably more often in interviews than in the literature, indicating that this is where current IAM solutions cause substantial difficulties for IT departments.

4.2.2 Refinement of the Clustering

After the initial discussion of requirements for IAM, we confronted the experts with the requirements we had identified in Sect. 4.1 through our SLR. For the most part, the experts agreed with the requirements and also found the scope and structure comprehensive and useful. In the following, we will present their remaining suggestions for improvement, which included merging and splitting some clusters and adding new topics. In addition, we will present the final structuring of our IAM requirements (see Fig. 2).

When asked what changes they thought were needed, the expert frequently suggested merging the “Privacy & Trust” and “Control” clusters, as indicated in the following statement:

“Privacy protection is always divided into two parts: On the one hand, there is the protection of privacy as ensured by governance frameworks [...] but on the other hand, there is also the issue of self-data protection. Do I have a way of exercising control over it?” (Expert 8)

Moreover, the experts suggested combining “Standardization, Interoperability & Simplicity” and “Portability” (Experts 6 & 8). One expert suggested that “Manageability, Efficiency, Automation & Cost” and “Availability” should either be merged or more clearly separated:

“In a way, automation [and] efficiency also means availability.” (Expert 6)

When asked about which topics need to be rearranged or removed from clusters, the experts mainly discussed the role of “Simplicity” in Cluster 3. In particular, they expressed concerns about the relationship between simplicity and the other two subcategories, “standardization” and “interoperability.” The following statement reflects their doubts:

“Whether, for example, standardization, interoperability, and simplicity, i.e., Cluster 3, fit together so well, I don’t know. [...] Standardization is a topic that does not necessarily have anything to do with simplicity.” (Expert 2)

When we asked the experts whether or not they see any topics that should be added to the clusters, they came up with several ideas. One of the experts, for instance, brought up future readiness, which describes the extent to which the requirements leave room for potential adjustments in the future. The following statement reflects his thoughts:

“For us what is always important is [...] the adoption somehow happening, [...] and is it future proof, so I can somehow adapt it in the future for things, but maybe that is also covered with [the cluster] flexibility.” (Expert 10)

Another expert suggested adding “effectiveness” to Cluster 2 (Manageability, Efficiency, Automation & Cost) but had to admit that it is probably already covered by manageability and automation (Expert 8). Finally, one expert recommended attaching concise labels to each cluster (Expert 7).

Drawing on the experts’ suggestions on the composition of the clusters, we made some adjustments: We combined “Privacy & Trust” with “Control”, we combined “Standardization, Interoperability & Simplicity” with “Portability”, and we added “Availability” to “Manageability, Efficiency, Automation & Cost”. Furthermore, based on the discussion above, we decided to split the category “Simplicity” from Cluster 3 (“Standardization, Interoperability & Simplicity”) and combine it with the new cluster “Control, Privacy & Trust”, as these all relate closely to the user perspective. As proposed by Expert 8, we added the aspect of “Effectiveness” to the second new cluster. We also added “Flexibility” to this cluster, as it concerns the design of the system. To make the newly formed clusters easier to understand and put the topics within the clusters into the right context, we gave them concise labels following Expert 7’s recommendation. Ultimately, our changes led to the following four clusters: “Security & Compliance”, “Operability”, “Technology”, and “User”. We illustrate the final structuring of IAM requirements in Fig. 2.

Fig. 2
figure 2

Requirements for an enterprise IAM system: consolidated results after the SLR and the evaluation with experts

Full size image

5 Prototype

In this section, we present the SSI-based prototype that we developed based on the requirements identified in Sect. 4. Our prototype allows an employee VC to be issued, used, and revoked as part of a simulated intranet login. There are three parties involved in the process: The human resources (HR) department, which issues and revokes VC, the employee, who receives and holds the VC and uses it to prove authorization for logging in, and the intranet login manager or gateway that ensures that only authorized users gain access. Both the HR department and the intranet login operate “institutional agents”, i.e., independent instances of the Hyperledger Aries Cloud Agent in Python (ACA-Py), as a microservice. ACA-Py is suitable for non-mobile environments and can be used to build decentralized identity applications (Linux Foundation 2020). It implements a RESTful API that allows an admin to manage cryptographic keys and VC in an SQLite database, integrates client functionalities to communicate with a public permissioned Hyperledger Indy blockchain, and provides an endpoint for standardized and encrypted peer-to-peer messaging (Schlatt et al. 2022b). As this messaging is often asynchronous (e.g., because a user’s confirmation is required to continue a credential issuance or VP process), ACA-Py also provides webhooks to notify an application’s controller about corresponding events.

The two ACA-Py agents for the HR department and the intranet login never communicate with each other in our prototype and do not use a shared directory. The employee runs an SSI wallet app on a smartphone that can generate and use cryptographic keys, receive and manage VC, and interact with verifiers in VPs (Schlatt et al. 2022a; Sartor et al. 2022). The wallet app can be thought of as having a subset of the ACA-Py’s functionalities. As such, the wallet also requires client capabilities for the Hyperledger Indy blockchain, so a user must currently choose the same blockchain that the other two agents are connected to within their digital wallet app. No other customizations of the mobile wallet were required for our prototype. We chose the esatus wallet, but there are other, compatible digital wallet apps such as Trinsic’s or Lissi’s that we could have used equivalently. We also built a web interface to run the demo using Django.

5.1 Connection Establishment

Establishing an initial connection between two agents is necessary for them to exchange information over a secure, end-to-end encrypted channel (Mühle et al. 2018). In this scenario, the employee’s wallet app requires a connection with the HR department’s agent (issuer) and with the intranet login manager’s agent (verifier). The procedures to establish these connections are almost identical: in both cases, the institutional agent creates a personalized invitation link that resolves to an endpoint of the agent that serves the agent organization’s name and public key for encrypted and authenticated messaging. Employees can either scan a quick response (QR) code that represents this link with their wallet app, or they can access it via a deep link that directly opens the payload in their digital wallet. As we illustrate in Fig. 3, the HR department can also personalize the invitation with an icon. To date, the QR code needs to be delivered through a trustworthy communication channel, like a personalized email or the company’s authentic website, secured by traditional website certificates: Manipulating the QR code by inserting another endpoint that serves another public key but the same organization name and icon would enable man-in-the-middle attacks (Babel and Sedlmeir 2023). This topic has been extensively discussed in the context of the German ID wallet (Lissi 2021; Schellinger et al. 2022). The corresponding vulnerability is currently being addressed by verifying that the connection’s service endpoint corresponds to the referenced public key and organization name, either via using existing public key certificates for web servers or via a lookup on the permissioned Hyperledger Indy blockchain (Lissi 2021; Schellinger et al. 2022).

If the employee then scans the QR code, the employee’s wallet creates a cryptographic key pair for this connection and asks the user whether he or she would like to accept the invitation. By accepting the invitation, the wallet sends a response to the HR department’s or intranet login manager’s agent respectively, i.e., to the service endpoint specified in the invitation, encrypted with the agent’s public key referenced in the connection invitation. After a standardized initial message and key exchange, there is now an active connection between the two parties. The wallet sends messages directly to the agent; in the opposite direction, the wallet app provider runs a so-called mediation service that collects messages and provides them to the wallet when it is online. Fundamentally, such a mediator agent could be provided by any party and does not need to be trusted concerning confidentiality owing to end-to-end encryption. Yet, switching to a custom mediation agent is not yet supported by the wallet, and implementations of mediation agents usually rely on the push notification services of Apple and Google to avoid periodic polling.

Fig. 3
figure 3

Establishing a connection between the HR department and the employee

Full size image

5.2 Credential Issuance

To issue VC representing attested attributes to employees, the HR department has to make some preparations to bootstrap their agent for issuance. The agent first needs to register its endpoint and public key on the Hyperledger Indy blockchain. After that, it may have to publish a new schema. The schema contains, among other things, the type of attributes that are to be issued to the employee, i.e., it can be regarded a template or standard for a VC type in a specific context. In our prototype, the schema references the attributes “employee name”, “company name”, “division”, and “job title”. After publishing the schema or deciding to use an existing one, an issuer-specific credential definition must be derived from it. This determines the issuer’s signing public key (more precisely, one key for each attribute) that is referred to in later proofs. If the agent is to revoke VC, it must also create and upload a revocation registry, which refers to a specific credential definition, to the Hyperledger Indy blockchain, and publish tails files – a list of public random numbers that the wallet needs for later ZKPs of non-revocation yet is too large to be uploaded to a blockchain (Babel and Sedlmeir 2023) – to a public repository, for which we chose GitHub.

Once the HR department has bootstrapped a credential definition and revocation registry, it can issue VC to employees. To do so, the process is initiated by the HR department which uses a web interface to define which values the attributes should have for the respective employee. We illustrate the form to enter the values in Figure 5 in Appendix C.1. In practice, HR departments would likely automate this by retrieving the attributes from an existing employee database. Next, the HR department’s agent creates a credential offer with these attributes and sends it to the respective employee via an existing connection. The mediation agent associated with employees’ wallets then pushes a notification on the smartphone, and employees can view and accept or reject the offer. If they accept the VC offer and respond with their binding public key to be included in the VC, the HR department agent creates and signs the VC and sends it to the employee’s wallet app, where the VC is stored. Now the employee is ready to use the VC for future VPs.

5.3 Credential Usage for a Verifiable Presentation

If employees want to log in to the intranet with their mobile wallet, they need a credential issued by the HR department and an active connection with the intranet login manager. The view of the login page differs depending on whether users are new or returning: By using a session key to recognize a user’s repeated logins, the intranet login manager can use a previously set-up communication channel instead of initializing a new connection through a QR code or deep link. We present both views in Figure 6 in Appendix C.2. After establishing a new connection or clicking the login button in the case of an existing one, employees automatically receive a proof request on their mobile wallet. The proof request asks for selected attributes from their employee VC. A proof request contains a random challenge (“noce”) to prevent replay attacks and “restrictions”, i.e., the VC must follow a specific schema or be issued by an issuer from a specific trusted list. Employees’ digital wallets automatically create a drop-down list of VC that include the required attribute and that satisfy the corresponding restriction for every attribute requested and preselect one. In our case, the only choice is the VC that the HR department has previously issued. We illustrate the corresponding view in the wallet app in Figure 7 in Appendix C.3. Employees can change the selection of VC (if applicable) and give consent to answer the request. Their wallet then queries the current state of the revocation registry on the Hyperledger Indy blockchain and uses it to create a cryptographic proof. This proof corresponds to a ZKP that – simplified – asserts that:

  • One of the issuers specified in the proof request’s restrictions digitally signed the VC used to generate the proof.

  • The user knows the private key associated with the (undisclosed) binding public key referenced in the VC.

  • The attributes requested have the values revealed in the proof.

  • The VC is not expired and not revoked.

Through the ZKP, as opposed to certificates based on conventional digital signatures that are used for authentication in some organizations, no additional information like the full VC including the value of the signature or the public binding key, is given to the verifier (Babel and Sedlmeir 2023). Moreover, it is possible to reveal attributes selectively, and verifiers cannot correlate them beyond the equality of the revealed attributes in repeated VPs that use the same VC (Hardman 2020). The wallet also supports predicates, e.g., it proves that the VC’s expiration date (as UNIX timestamp) is larger than a specific timestamp (e.g., the current time) specified in the verifier’s proof request, without disclosing the potentially correlated expiration dates themselves. Likewise, the ZKP proves set membership of the VC’s revocation ID in the revocation registry without revealing the revocation ID. The digital wallet then sends the cryptographic proof to the intranet login’s agent, which checks the status of the revocation registry and cryptographically verifies the proof accordingly. Afterward, the agent sends the proof verification result to the intranet controller – the core backend of an application that implements the overall process logic and potentially coordinates additional microservices, including databases – via a webhook. Only if the proof is valid, the employee can access the web application (intranet) based on the value of the revealed attributes. The sequence diagram for the verifiable presentation is depicted in Figure 8 in Appendix C.4.

5.4 Credential Revocation

If an employee retires, resigns, or changes the department in the organization (or other attributes), it may be necessary to revoke a VC to ensure access is no longer granted or to revoke and re-issue when attributes need to be updated. For this, an employee in the HR department can select the VC to be revoked. Automation would also be conceivable, for example, by revoking and re-issuing the VC after changes in the personnel database. The HR department’s agent performs the revocation itself by creating an update for the revocation registry on the blockchain and publishing it there. To do this, it must authenticate with the same cryptographic key that was used for creating the revocation registry in the bootstrapping process. If the employee wants to use a revoked VC, it is recognized as invalid: The state of the revocation registry no longer allows the creation of a ZKP of non-revocation for a current timestamp, making it impossible to log in to the intranet. For the purpose of the demo, the agent immediately publishes the update to the revocation registry, so that the VC is effectively revoked after a few seconds. In a real-life enterprise context, it would be more practical to publish aggregate changes to the revocation registry state on the blockchain in larger intervals, e.g., once a day: Writing data to distributed ledgers is costly in general owing to redundancy, and Hyperledger Indy in particular has considerable performance limitations when it comes to write throughput (Sedlmeir et al. 2021).

6 Discussion

6.1 Prototype Evaluation

To evaluate the potential contributions of SSI to improve enterprise IAM solutions, we presented our prototype to the same twelve experts who had already evaluated the IAM requirements in Sect. 4.2. The researcher introduced the prototype to the participants and walked them through its features and functionalities. To illustrate this, the experts were presented with the case of Alice, a new hire, who receives a VC from the HR department. The VC is stored in a digital wallet on her cell phone and is used to create a VP when she wants to log in to the company’s intranet. The login backend ensures that only authorized users have access. The interviewer explained all the roles (issuer, holder, and verifier) and also demonstrated how revocation works (for more details see Sect. 5). Participants were then asked to evaluate first the strengths and weaknesses of the prototype and then those of SSI-based solutions in general in a semi-structured way. We included the interview guideline in Table 6 in Appendix B.2. All interviews were recorded and transcribed with the consent of the participants. Again, one researcher coded the interviews along the coding dimensions identified in Sect. 4.2 (Saldaña 2015). Table 7 in Appendix B.3 displays an excerpt from the codebook with codes, subcodes, and brief explanations. Figure 4 in Appendix B.4 illustrates how often codes from the clusters were mentioned in these interviews.

Throughout the interviews, the experts agreed that our prototype suggests that SSI integrates very well with existing IAM systems. They, for instance, mentioned its strong similarity with OIDC-based solutions (Kuperberg and Klemens 2022), and that verifiable attributes retrieved from the VP can be used as part of a JSON web token for OAuth-based protocols. The following statement stresses these findings:

“[One] can make a gradual transition without hurting anyone, [...]. Otherwise, you would have to throw away all the investments you may have made, and of course no one in a large company makes that decision.” (Expert 10)

The experts, however, also noted that some of the technical wording in the frontend and wallet might be difficult for users to understand. Users who are not yet familiar with SSI may feel insecure because of the unfamiliar workflow and terminology, as the following statement suggests:

“I would like it to be a bit more user friendly, [...] [because] I wouldn’t understand anything at first, although I think I’m already halfway living in today’s time. Everything is very, I would say, technically formulated.” (Expert 4)

This perspective is also in line with the results of first user experience studies (Sartor et al. 2022; Guggenberger et al. 2023; Khayretdinova et al. 2022) that indicate usability challenges but also promising solution approaches. Other experts pointed out that it is important to delete also sessions to make revocation effective. In line with this, one of the experts suggested the following procedure:

“And when the credential is revoked, you can flag that right there [A/N] in the user database] and just delete the session. Then the session is basically sent there and the website realizes, oh, this one doesn’t exist anymore, and then you’re automatically redirected back to the login and can’t get in.” (Expert 6)

However, when the selective disclosure capabilities of SSI-based authentication prevent a direct mapping of a session to an employee and their VC, it may be necessary to delete all sessions periodically (e.g., once a day) or a subset of potentially matching sessions when revoking a VC.

Expert 11 suggested that a less similar layout for the two pages (issuance and verification) could help to visually make clear the separation of the HR department page and the intranet pages in the architecture for the end user. Expert 12 noted that if the credential contains only the four attributes “employee name”, “company”, “department” and “job title”, it may happen that two employees have the same name. He, therefore, suggested that a unique employee identifier be added as an attribute to overcome this problem, which also resonates with enterprises’ current management of employees in databases. We subsequently incorporated these changes into our prototype.

6.2 Benefits and Challenges of SSI-Based Solutions for IAM

In the following, we highlight the experts’ opinions on the hurdles and benefits of SSI-based solutions for IAM. The experts identified many benefits of SSI in terms of integration with existing IAM systems. They emphasized that SSI-based IAM solutions offer fine-granular access control and support the use of ABAC through the verifiable disclosure of identity attributes in VPs. Particularly the positive contribution of revocation to security was emphasized:

“And then if they [A/N: employees] resign or leave or are fired, then blocking them in the systems [...] is also faster. I think the technology stack [A/N: SSI], even if it still has weaknesses [...] is strong. With the revocation of keys, the technology stack generally resolves this tension between usability and security quite well.” (Expert 7)

The experts also highlighted the benefits of SSI-based solutions in terms of speed, as the following statement reflects:

“On the one hand, you can integrate your new employees into the systems much faster, or rather you grant them access to the systems more quickly. And then when they resign or leave or are laid off, they’re also locked out of the systems faster.” (Expert 7)

However, one of the experts mentioned that providers of conventional IAM services are not yet showing much interest in the technology. This perception is supported by Glaude and Kudra (2021), who hypothesize that maintaining the existing complex and often non-interoperable landscapes is in the interest of IAM software providers as they want to secure their business models.

During the interviews, experts also discussed how SSI balances privacy and auditability features. They agreed that security is enhanced by passwordless authentication and native two-factor authentication, as VC are stored only on employees’ mobile phones and unlocking the digital wallet for a VP requires a valid PIN or biometric unlock. Some of the experts pointed to benefits of SSI in terms of usability and user-friendliness:

“The fact that you don’t have to come up with a different password for each system, or any password at all, but have the password in your wallet that you need to unlock your smartphone, or the biometric feature, makes it convenient.” (Expert 3)

In addition to increased usability, the experts considered improved privacy and control over information disclosure the main benefit for the user, especially as identity attributes only need to be stored in employees’ digital wallets. One of the experts stated:

“What I think is an advantage [...] is that I actually have full transparency in this wallet at all times [...] about who has somehow already queried my credentials then perhaps I could also somehow consolidate the whole thing at once and in principle say [...] I somehow don’t want to use them anymore [...].” (Expert 1)

In summary, the experts see several positive contributions that SSI can provide for IAM in all four clusters (please see Table 8 in Appendix B.5 for additional direct quotes from the experts indicating that they see potential improvements that SSI can provide for IAM systems in all four sets of requirements that we identified in Sect. 4). Nonetheless, the experts also pointed out some issues that need to be addressed in the future in order for such a solution to become established. These include, for example, the network connection that is required for checking (non-)revocation, standards that are still evolving, and the lack of availability of credential chaining, which is still a limitation for large-scale adoption from a technical point of view (Schlatt et al. 2022b; Babel and Sedlmeir 2023). Notably, the lack of maturity that is hard to deny after having implemented the prototype was not criticized by the majority of experts, as they consider a gradual introduction of SSI in IAM possible.

6.3 Limitations and Future Work

As with any research endeavor, our study comes with limitations that point to avenues for future research. First, we limited our literature review to employees in the enterprise context only. However, the perspectives and requirements of customers, suppliers, and partners could be also considered to further explore the potential benefits of SSI in an enterprise context. Another perspective we did not consider relates to the ongoing trend of IOT. First research in this domain has already appeared (Bartolomeu et al. 2019), but implementing SSI wallets on embedded devices is still an underexplored topic beyond working groups in SSI-related foundations like Sovrin and Trust over IP.

The second limitation concerns the prototype. Even though we have tried to develop an application that is as close to reality as possible, some of the processes involved that promise to improve IAM have not yet been implemented in practice. One example is the automatic issuance of a credential based on identity information stored in the companies’ existing employee management system, or the distribution of a credential offer and the ensuing issuance to an employee who is not on-site, e.g., via e-mail.

Lastly, it is worth mentioning that our research focused on the authentication of employees, providing machine-verifiable attributes for ABAC, and managing the issuance and revocation of VC and the verification of VPs. Yet, some of the challenges of IAM systems as pointed out by Puchta et al. (2019), such as detecting entities with an unusual number of entitlements, might constitute a separate issue that can be addressed through complementary approaches like visual or automated data analytics. Future research could therefore investigate the additional adaptations that IAM software needs to monitor activities and manage access policies to resources based on verifiable attributes.

Another fruitful avenue for future work is a comparative analysis of our prototype with existing solutions such as Keycloak, as this would improve our understanding of which technology can best meet the IAM requirements and also identify more narrowly the potential for improvement of existing solutions.

Enterprise IAM is only one of many proposed applications of SSI. We believe that shedding light on where SSI can reduce complexities, increase security, and save costs is an interesting area for more interdisciplinary research, particularly in combination with other novel paradigms for enterprises’ IT security like zero trust (Buck et al. 2021) and the integration of smart devices. For example, researchers could study how the introduction of passwordless authentication affects technology adoption and user security behavior. With regard to the latter, they could investigate whether digital wallets mitigate security-related stress – a phenomenon that employees often experience when complex security measures are involved (Frank and Kohn 2021).

7 Conclusion

The goal of this study was to identify IAM requirements in enterprises and investigate the extent to which SSI is able to address and fulfill these requirements. Using a SLR refined by twelve domain experts, we were able to cluster IAM requirements into four categories: “Security & Compliance” covering the subcategories security, compliance, integrity, and auditability, “Operability” covering the subcategories manageability, efficiency, effectiveness, automation, cost, and availability, “Technology” covering the subcategories standardization, interoperability, flexibility, and portability, and “User” covering the subcategories simplicity, privacy, trust, and control. Building on these requirement categories and the new paradigm of decentralized identity management called SSI, we developed a prototype and had it evaluated by the twelve domain experts. Our prototype and the evaluation process suggest that integrating SSI into IAM systems can offer advantages in each of the four requirements categories. We conclude that SSI can indeed help improve IAM systems. These improvements encompass, for example, the possibility of selective disclosure, the fast onboarding and off-boarding of employees (revocation), consideration of the principle of least privilege, and the possibility of a higher degree of automation to improve efficiency and manageability.