Identity and Access Management (IAM) is moving beyond IT security and compliance to become a valuable enabler that drives business performance, digital transformation and competitive advantage. But planning and deploying IAM is not without its challenges.
Discover first-hand opinions, lessons learnt and recommendations from senior peers in several global brands who have experienced the trials and triumphs of implementing their own IAM programs. Get practical advice and fresh insight to help you avoid common pitfalls and obstacles. Understand how business and IT departments can work together to deliver a smooth experience to users and stay agile to accommodate future requirements.
Identity and Access Management is not a simple program to deploy and manage. It is best run as a series of separate projects that encompass different departmental roles, technical components and processes. To help mitigate the risks of IAM failure, insights from interviews with your peers have been simplified into eight clear recommendations that will greatly help on your own journey to IAM success.
Everything starts with getting backing for your IAM program from the different parties in your business. While IAM is commonly understood as an IT task, it is much more than that. HR systems are an important source of data. The business must request, approve, and review access entitlements. And every single user is going to demand a simple experience when logging on, from anywhere.
Timo Ahomäki, Portfolio and Business Development Lead at Tieto puts it clearly, "IAM programs tend to fail when you are too focused on solving IT problems and too late in bringing in other stakeholders. Not bringing in the business early is disastrous." And it's important that the business understands the benefits of IAM. Scott Cornfield, Identity and Directory Services Manager at Sky distilled the benefits into three areas: "It make the end user's life easier. It helps you get compliant. It delivers security."
There are many areas in IAM programs that affect the day-to-day work of users. The most visible to them are the way they sign in to systems and applications, their access, and the smoothness of processes during job changes. Understanding this is essential. The Director of Identity Architecture of a world-leading consumer goods manufacturer said that it's one of the challenges of IAM programs: "When something goes wrong, everyone up to senior management knows that it's gone wrong."
While it is the experience of users that is most visible, it is your auditors that you want to get on board. They can be your best option when looking for stakeholders for the IAM program. Auditors have the same success metrics as IAM programs and, as he recommends, "It is not about 1,000s of application owners, many of the owning applications that are not built for security." Aligning your IAM program with the focus areas of your auditors can be a real advantage.
There are many potential stakeholders out there. And you need them to make your IAM program a success. Getting them on board early is essential.
Another interesting suggestion was made by the Enterprise Security Architect of a large bank in the APAC region: "Have one of the Big Four as partners. They have conversations with the business people anyway. This makes it easier to sell your program to the organization."
IAM is more than just identity provisioning or access governance or single sign-on or any one of the various other disciplines. That is why success is based on moving from single, isolated, technical initiatives to a full IAM program. However, as a huge topic with many facets, the program needs to be well-planned, with a clearly defined architecture and roadmap. Slicing the elephant into pieces you can swallow is essential, or as Scott Cornfield recommended, "Be careful of doing too much in the initial phases. Agree on what to do first." The Director of Global Identity & Access Technologies at a Global insurance brokerage and risk management services firm, agrees, "To meet expectations, it's better not to bite off more than you can chew. It is important to phase it. To do a big deployment to a huge organization is just not realistic and sets you up for failure."
The APAC bank's Enterprise Security Architect places emphasis on the need to understand the problem areas first and then to run a "capability-driven" program, by looking at which capabilities IAM consists of and which of them are already good, which aren't yet good enough, and which are lacking. That helps in setting the right focus and defining a roadmap that meets expectations.
Setting the right expectations is the advice given by many of the interviewees and it is closely related to many of the other areas, such as getting stakeholder buy-in and defining the stages of an IAM program and the capabilities to be delivered at each stage.
"Make it clear what IAM is and what you are really trying to achieve with your project. Define a purpose and clearly articulate it" as Tom Golson, Associate Director IT Security at Texas A & M University concludes. It is essential that stakeholders and all other parties involved are clear about what is to be done, what is to be expected, and when. Timo Ahomäki added that, "It is essential for the success of an IAM program to set realistic expectations."
Regardless of how realistic your expectations are, if success isn't demonstrated, the IAM program will fall into trouble. Success requires continuous communication with stakeholders and other parties – an aspect that will be touched on later in this paper – but also a determined focus to demonstrate improvements at the early stages of the IAM program.
Quick wins don't happen by chance – you need to plan for them. The roadmap must be built so that it allows for quick wins, by doing simple things first that deliver a visible benefit to the users. Scott Cornfield underlined the point by saying, "Identity is not as tangible as a new laptop. It is not as appreciated. You need to deliver a visible impact, e.g. the integration with physical access to buildings, so that physical access and system access can be enabled and disabled within a single process."
Making users' lives easier is the best way for most IAM programs to show a quick win. However, if auditors are the main stakeholder, you need to take a slightly different approach, because auditors want to see some quick improvements. The Identity Management lead of a major European bank made this point, "Understand how your IAM program will deliver to the audit pressure." If you deliver on the biggest pressure early, that is a quick-win.
What also helps is to define and measure Key Performance/ Risk Indicators (KPIs and KRIs), to demonstrate a tangible improvement, e.g. in the time it takes for the onboarding processes of users or applications or the reduction of orphaned accounts.
An IAM program is not an infrastructure-only initiative-it involves many parties. The larger the organization is, the more important it is to understand specific requirements. Successfully running an IAM program requires a team that knows the organization. The Identity Management Lead of a leading European bank brought this up: "Organizations have specific challenges. It is hard to fully understand these, particularly for large organizations."
Understanding problem areas and the organization as a whole is a many-faceted challenge. It is about understanding what goes well in the organization and what does not. Timothy Forde recommends "Don't start with the product, but understand the problems and processes in your organization first." This requires people in the team that know the organization, well beyond the technical aspects of IAM.
Making your IAM program a success very much depends on having the right resources and skill sets to hand. A large banking and financial services institution´s Enterprise Security Architect articulated the challenge most organizations are facing today, "Skilled people are rare." However, he also came up with good advice on how to address that challenge within the organization, "Go for the ERP people. They know workflows. They know about data consolidation. They know rule engines. Data and processes in ERP must work together, the same as in IAM. They are familiar with similar problems." What could be added is greater knowledge about the business side of the organization
Many of the interviewees emphasized that the challenge of having the right resources and skills can't be solved by simply hiring externals. Understanding the problem areas requires understanding of the organization. However, that must be done by the internal team. Tom Golson concluded, "The organization itself must have the business skills. Process knowledge resides internally." Scott Cornfield added, "To a large degree, Identity should be done internally. You need to be close to the business."
It is a common view among the interviewees that it is easier to build up sufficient skills in IAM tools than to train externals in understanding the organization's specifics and to try and create an intimate understanding of the business that is required for making the IAM program a success. Scott Cornfield said, looking at the interplay with system integrators, "Have them help, but not control it. Be in control of vendor selection. Choose the technology you have skills in."
Understanding the required skills, getting the right people on board for the IAM program, and educating the team are among the key success factors for IAM programs. As the Director of Global Identity & Access Technologies at Global insurance brokerage and risk management services firm said, "Education is key to success as well."
Many IAM programs get into trouble because the processes they implement are not what the users expect. Scott Cornfield sees, "process optimization as an important element" of IAM programs.
The APAC bank's Enterprise Security Architect adds that IAM programs, "must focus on processes, not technology. Sometimes, it took two years to figure out that an implemented process was incorrect." Defining processes first helps in achieving the quick wins and reaching the goal of the IAM program, but also in reducing the cost of IAM programs. Customizing tools and processes is an expensive element in IAM programs. This becomes far more straightforward and efficient if processes are defined first, not during customization
A specific area of processes that has been highlighted by the practitioners is between HR systems, IAM, and the target systems, which heavily affect the quality of Identity information that can be achieved.
Tom Golson put it clearly: "IAM is many times more complicated than everyone believes. You must define the data flow and processes to achieve the required quality of Identity information." He also pointed out another pitfall, "There is the misconception that IT or data owners are the only people who care about the quality of data."
Wolfgang Zwerch, Identity Management Lead at Munich Re was even more direct: "Garbage in, garbage out. Bad security models at the system level and bad data will not be healed by just implementing an IAM tool. It becomes transparent, but without well-thought-out processes it will not become fixed."
Scott Cornfield also commented on data quality: "HR data can vary in quality and may not be as reliable as expected. Look at it and understand how good or bad it is. Optimize the process and the quality of data delivered. Also look at the other data sources for IAM and how good they are." He also recommends taking a broader view: "Look at processes end-to-end, from HR to IAM to the target systems, not as siloed processes."
Solving challenges in data quality requires a strong backing by stakeholders, because it is about the intersection between HR, IAM, and the system owners of other source and target systems. However, the most important advice came again from Scott Cornfield: "Talk with them." Getting the other parties on board, figuring out the responsibilities for data quality and optimizing the processes can only be successful in a collaborative effort.
There is little to add to these recommendations. Stakeholder buy-in, well-thought-out program planning with projects of reasonable size, demonstrating quick-wins, resource planning, etc. are essential for successful IAM programs. I want to highlight three aspects which are key success factors: processes, blueprint, and KPIs.
Processes must be defined as part of the planning. This includes defining the process on paper, using a standard methodology. It involves defining the process owners, but also the other participants, and defining responsibilities and accountabilities, as well as educating all parties about these processes. This might involve a lot of communication and negotiation with various departments, but it is the foundation for rapid and cost-efficient implementation of these processes and their acceptance once they go live.
Blueprints are frequently missing. However, a blueprint showing the building blocks of the future IAM infrastructure and their relationships as a foundation for both the detailed architecture and the roadmap planning is essential. This helps in understanding what is needed and how various components interact with each other and with other systems in the IT infrastructure. Spending some time creating a blueprint helps with streamlining investments.
Finally, KPIs that are measured before the start of the program and once it is in flight, help in proving the improvements. They help to demonstrate tangible success, such as the growth in the number of onboarded systems, the reduction of orphaned accounts, or process runtime improvements.
Looking at the various recommendations made by the interviewees for running a successful IAM program, it becomes obvious that choosing the right tool is one success factor, but that IAM programs will only realize their goals when organizational and process
aspects are solved.
As a project involving multiple parties, it is essential to define responsibilities and accountabilities. Good IAM programs are backed by an official IAM guideline or policy that defines the various roles, their accountabilities, and their responsibilities.
Wolfgang Zwerch said, "Without good processes and clearly defined responsibilities, your IAM program will not succeed." It must be clear from the very beginning who is responsible for what. This becomes particularly important when looking at access reviews that involve various parties from IT providing the tools to managers, role owners, and system owners doing the review, to the required responsibility for setting up and managing the review process. It soon becomes obvious that an IAM program might also lead to new organizational units and to additional or changed responsibilities. IT can't solve this alone and needs tight collaboration with the business.
On the other hand, as Tom Golson said, "IAM is the one opportunity for IT to interoperate with the business and demonstrate its value." He also stated that, "IT plays a major role in IAM. Not as the owner but as the enabler."
Another aspect discussed during the interviews is what a good IAM organization should look like.
While running the program, Timo Ahomäki recommends working with virtual teams and governance bodies: "Create virtual teams and governance bodies. These teams should include Risk Management, IT Governance, HR, system owners, etc. Such teams will help you make tough decisions, because everyone is involved."
Many interviewees highlighted the need for implementing a separate IAM organization. Having just a few people as part of the IT infrastructure department or the IT Security department is not considered sufficient by many of the domain experts we spoke with.
Tom Golson takes the position that, "IAM needs to be a separate organization within IT, mainly focused on business requirements, business data, and integration with the target systems." Wolfgang Zwerch adds that the IAM organization in itself must consist of various parts: "There is, for example, architecture and process modelling on one side, and service delivery on the other."
The Identity Management Lead of a major bank highlighted some of the most important lessons they learned: "Having IAM as a technology department only with operations and security, where security takes the responsibility on behalf of the business, is not a good solution for business involvement." IAM can demonstrate real business value in delivering service to the application and system owners.
The Director of Identity Architecture we interviewed also strongly recommends a clear structure of the IAM organization into architecture, development, and operations. From his experience, the department is best placed in Information Security, directly under the CISO: "If it is not in the IT Security organization, it becomes the 'ugly stepchild' and does not get the care and feeding it needs."
Another aspect to add in the context of responsibilities and accountabilities – and their interaction with business, is governance. There is a need for an organizational entity that is in charge of aspects such as managing access reviews, supporting role definition, and management process. And in supporting the entire process around SoDs (Segregation of Duties), from the definition of SoD policies to the decisions about compensatory controls in case of policy violations.
During the runtime of the IAM program, and from the very beginning, communication is essential. The Director of Global Identity & Access Technologies at a Global insurance brokerage and risk management services firm said, "There's way more to it than just launching it, there's getting people used to using it, there's the communication piece, there's the education piece - and so you need to have all those ducks sitting in a row." Tom Golson was even more succinct: "Communicate well."
Scott Cornfield made some clear recommendations: "Involve the business. Do show cases, e.g. bi-weekly. Demonstrate what's new to the services. Do it agile." Such an approach helps with staying in contact with the business and stakeholders, but also helps in constantly demonstrating progress and at least some small quick wins, plus it ensures that feedback is gathered early and regularly.
Planning ahead as to who communicates what and when, even going so far as to have a separate communications manager in the IAM program, helps in demonstrating the progress and success of the IAM program. And in educating people in the business that are affected positively (e.g. simplified sign-on) or negatively (e.g. by running access review) about the changes and the rationale behind these changes.
IAM programs are rarely, if ever, run only with internal staff. Experts from the tool vendor(s) as well as system integrators commonly support organizations at various stages, from planning to roll-out and customization – and even in daily operations. The need for keeping control inside and building up a skill set internally has been already covered earlier in this paper. Beyond that, there are further recommendations from the interviewees.
The APAC bank's Enterprise Security Architect draws attention to two important aspects: "The system integrator will always be less connected. And they will leave at some point." That affirms the need for having internal staff in the team that know the organization and the business, and to build skills internally to stay in control of IAM if you don't want to become dependent upon the system integrator.
The Director of Identity Architecture said they, "used the system integrator for the big builds and projects, but running the IAM program has to be a core capability of the IT organization. Identity holds the key to the kingdom and, if anything goes wrong, it is incredibly painful and visible to the organization." He strongly recommends clearly defining what a system integrator has to do and then also trusting him to do those things right.
"A challenge might arise from a lack of sufficiently skilled people at the system integrators", as the Identity Management Lead of a major bank observed. This might be a reason for relying more on the tool vendors' resources than on a system integrator. When opting for a system integrator, he recommends a well-thought-out selection process: "Identify the trustworthy ones. It is the same as with vendor relations."
As the name indicates, an IAM program requires a temporary organizational structure, including program management. In large and geographically dispersed organizations, having a dedicated communications person or even team counts amongst the key success factors. Communication is about educating both the business and IT about the changes, the rationale behind changes, and the benefits to the organization and the individuals.
However, a well-thought-out IAM program organization is not enough. It also needs a defined IAM organization when the project transitions into full adoption. Both that organization and the transition process must be defined early.
IAM programs are not static. IAM is constantly evolving with new business requirements due to digital transformation, new regulations, and the availability of new technologies that enable new and better services to the users. As part of the interviews, we talked about the major trends in IAM.
One big area is IAM for the cloud, as opposed to IAM from the cloud. And the interplay between internal IAM deployments and Identity as a Service (IDaaS) is a trend recognized by some.
The Identity Management Lead of a major European bank looks at, "adding cloud applications. However, some of them have their own entitlement solutions, so we are also looking for IDaaS."
For Scott Cornfield, cloud support is top of the list of things to add within the next 12 months. The APAC bank's Enterprise Security Architect is also looking intensively at how to work with managed service providers (MSPs), cloud services, and mobile users. Supporting cloud services, from ramping up users to managing and governing access, has become an essential capability of today's IAM. It must become part of every IAM program.
The second major trend is about multi-factor authentication (MFA) and adaptive authentication (AA). The APAC bank's Enterprise Security Architect has this high on his list, while also looking at adaptiveness in authorization through risk-based authentication (RBA). Scott Cornfield has it, "on the radar for improving security." Others have already started projects for deploying AA solutions.
The Director of Identity Architecture sees it as a way of, "getting rid of passwords and raising confidence without having users storming the doors of IT with torches and pitchforks."
AA is an essential element of today's IAM programs. Supporting the authenticators that work well for users while achieving an adequate level of security is essential when balancing convenience and security.
With the evolution of cloud services and mobile users, the traditional perimeter of the enterprise IT diminishes. Identity is seen as becoming the new perimeter. The Director of Identity Architecture sees this as very positive in the context of selling the IAM program internally: "Security and risk managers, even at board level, now view Identity as being important to the organization."
Another trend that was mentioned is the need for going beyond an employee-centric IAM to support the customer and consumer identities. Some of the trends seen there are self-sovereign identities and Blockchain IDs, which are still not considered as being mature and reliable enough. The Director of Identity Architecture takes the position that, "there is a lot of hype, but no really good business case for that around Identity." However, others like Timo Ahomäki see growing potential here, particularly when it comes to relying on centralized ID systems for external parties, such as consumers.
Many of the experts are also looking at user behavior analytics (UBA). Wolfgang Zwerch expects that, "these systems will help us identify appropriate entitlements faster". The APAC bank's Enterprise Security Architect sees the value around, "improving risk-based authentication and understanding the real risk of access at runtime."
While there are some pitfalls around UBA, particularly when having strong workers' councils and regulations, there is potential in these technologies for optimizing entitlement management and authentication – and in identifying attacks more rapidly through detecting anomalies and outliers in user behavior.
A final topic that is high on the list of many organizations, which some already consider an established and mature technology is Privilege Management or Privileged Access/ Account Management (PAM). It's on the to-do-list for the next 12 months of several of the interviewees. PAM clearly counts among the must-have elements in every IAM program. Managing, restricting, and monitoring the use of elevated privileges is not only part of IAM, but essential in mitigating the risks of both internal attacks and cyberattacks.
IAM is evolving continuously. Adaptive Authentication (AA) is a hot topic, well-beyond the Finance Industry; it is about balancing user experience and a convenience with security. Done right, AA allows users to rely on a convenient authentication mechanism, while enforcing the required level of authentication strength whenever needed.
Another big trend is expanding IAM beyond the traditional employee focus. Nowadays, IAM must support all types of identities; employees, business partners, customers and consumers, and even things.
The third big evolution is driven by the evolution in the field of Cognitive Security, which delivers new options to improve or add new capabilities. UBA is one of the fields where such technologies help in moving IAM to the next level.
Making your IAM program a success is not rocket science. But following the guidance provided in this paper will help you avoid the common pitfalls. To wrap it up, here are the five most important things to remember to make your IAM program a success: