There is a very practical reason why Identity and Access Management (IAM) strategy is so often delayed. Strategy work requires an organization to interrupt its daily rhythm of tickets, projects, integrations, governance discussions, and operational escalations in order to step back and examine the broader picture. That pause is necessary, but it rarely feels productive in the immediate sense. A strategy does not deliver a connector, automate a process, or resolve a pressing operational issue by the end of the week. What it produces are decisions, priorities, guardrails, and a shared understanding of what IAM is supposed to achieve across the organization. Compared with the acquisition of a new platform, that can appear abstract, even though it is often the more valuable investment.
This is also the point at which many organizations choose the seemingly easier path. Instead of first clarifying the role IAM should play within the enterprise, they procure a solution that promises to address the most visible challenges. In one case this may be an Identity Governance and Administration (IGA) platform, in another a Privileged Access Management (PAM) solution, and in yet another a new identity provider (IdP) introduced to satisfy a specific project or architecture preference. The expectation is usually straightforward enough: once the tool has been implemented and the first use cases are live, IAM will begin to look more structured, more consistent, and more mature almost automatically.
In practice, the result is often quite different.
Rather than creating coherence, many organizations gradually assemble a landscape of IAM silos. Each tool is introduced for a plausible reason and each implementation addresses a legitimate requirement, but the overall environment evolves without a sufficiently clear common direction. Different teams optimize for their own needs, local decisions are taken in isolation, and each solution follows its own assumptions regarding processes, ownership, and integration. Over time, the landscape does not become more unified, but more fragmented. What emerges is not a coherent IAM capability, but a collection of partially connected systems with overlapping responsibilities, inconsistent data, and diverging governance models.
The underlying issue, in many of these cases, was never simply the absence of tooling. More often, it was the absence of a strategic framework that could guide the selection, positioning, and use of those tools.
The target state matters, but only in relation to the current reality
A serious IAM strategy does not begin with technology. It begins with a sober assessment of the current situation. That sounds obvious, but in practice this step is often shortened, simplified, or skipped altogether because it is perceived as time consuming and less immediately rewarding than designing a future state. Yet without a credible understanding of where the organization stands today, the definition of where it wants to go remains disconnected from operational reality.
This assessment needs to go well beyond an inventory of systems. It must consider architecture, processes, data quality, responsibilities, sourcing models, governance structures, and the actual decision making logic that shapes IAM in day to day work. Otherwise, the organization moves too quickly into discussions about target states and solution design without understanding the gap it must close in order to reach them.
This point has already been emphasized by my colleagues Matthias Reinwarth and Dr. Phillip Messerschmidt in the context of operationalizing the Identity Fabric and Reference Architecture (Advisory Note: Operationalizing the Identity Fabric and Reference Architecture). Defining a target state is certainly important, but it becomes strategically useful only when it is clearly related to the current environment and the conditions under which the organization actually operates.
This is not merely a methodological preference. It has very practical consequences. More than once, organizations have selected a modern IAM solution that appeared convincing in presentations and workshops, only to discover later that the effort required for implementation, customization, and organizational adaptation was far greater than expected. In some situations, implementations slowed down because the tool did not fit the existing application landscape. In others, the intended standard functionality was undermined by extensive customization. Sometimes the most fundamental issue was that the operating model implicitly required by the solution had never been discussed at all.
None of this means that existing architecture should be preserved simply because it already exists. Legacy is not a strategy, nor does technical history deserve protection for its own sake. However, if the defining characteristics of the current environment are not properly understood, then strategic and architectural decisions will be made without regard for the conditions they must eventually work within. That usually proves costly, both financially and organizationally.
A useful strategy therefore elevates architectural decisions to a level where they can provide direction in daily work. Consider a fairly typical example. A company operates several identity providers, each managed by different teams and each following slightly different integration patterns (e.g., federated authentication only, federated authentication with Just in Time provisioning or federated authentication with upstream provisioning and lifecycle management) . Application teams choose the most convenient option based on individual experience, local preference, or simple availability. Such a situation is often tolerated for a surprisingly long time, but it does not represent a deliberate architecture. It is a form of decentralized improvisation that has accumulated over time.
A strategy introduces clarity by making these implicit rules explicit. It identifies the primary identity provider, describes the preferred integration model at a high level, defines under which circumstances alternative patterns are acceptable, and assigns accountability for approving exceptions. Once this has been agreed with the relevant stakeholders, the endless discussion around which system should be used in which situation begins to lose momentum. That alone can save considerable time, reduce unnecessary friction, and improve the consistency of future decisions. At the same time it becomes clear that an IAM strategy is a cross-organizational project not a task of a single department.
IAM strategy becomes indispensable when symptoms start to dominate the agenda
Many IAM initiatives begin with visible operational problems. Identity data quality is poor, access request processes are too slow, joiner and mover events are handled inconsistently, recertification cycles create frustration, and audit findings return with uncomfortable regularity. All of these issues are real, and many of them require action because they also pose security risks. The problem is that organizations often react to these symptoms directly without first asking whether they are dealing with the actual cause or merely with its most visible consequence.
Without a structured assessment and a disciplined root cause analysis, IAM programs tend to become highly reactive. They address the symptoms that hurt most at a given moment, but they do so without creating sufficient transparency around the underlying drivers.
Bad identity data is a good example. The immediate response is often to improve handling within the IAM platform itself. Additional validation rules are introduced, manual correction processes are established, administrative checks are expanded, and workflow logic is added to compensate for missing or inconsistent information. From a purely technical perspective, this can reduce the immediate pain. From a strategic perspective, however, it often means that the organization has moved a structural problem into the IAM platform instead of resolving it at its source.
The actual cause may lie elsewhere. HR processes may not be sufficiently aligned with identity lifecycle requirements. Source systems may use inconsistent definitions of the same individual. Organizational functions may trigger lifecycle events in ways that are not coordinated. When that is the case, the IAM platform becomes the place where upstream inconsistencies are absorbed and concealed, rather than the place where a well governed identity model is executed.
This pattern explains a great deal about why IAM tools so often evolve into silos. Over time, they absorb unresolved questions of ownership, process design, and data quality from other parts of the organization. The platform becomes a kind of repair layer for problems that were never clearly assigned or addressed elsewhere.
A strategy is valuable precisely because it helps resist this tendency. It does not eliminate the need for tactical measures, nor does it prevent short term workarounds where they are necessary. What it does provide is a framework for deciding whether a given issue genuinely belongs in the IAM domain or whether IAM merely happens to be the point at which the issue becomes visible.
Central direction does not remove the need for decentralized adaption
When IAM is discussed at enterprise scale, centralization is often presented as the obvious answer. A central IAM function defines standards, owns the main platforms, governs the core processes, and ensures alignment with security and compliance requirements. This is indeed necessary, but in most large organizations it is not sufficient.
IAM only works when it is anchored in operational reality. Applications need owners who understand their entitlement models. Role structures require maintainers who know the underlying business logic. Identity data needs stewardship that is close enough to the source to identify inaccuracies and resolve them credibly. A central IAM team, however capable, cannot realistically possess all of this context for every application, process, and local requirement across the enterprise.
For that reason, many organizations operate with a model in which standards and key services are centralized, while important aspects of execution remain decentralized. That is not a design flaw. It is often the only workable approach.
The difficulty begins when this distribution of responsibilities remains ambiguous. In that situation, the central IAM function assumes that local units will maintain the relevant information, while local units assume that the central IAM team owns the tools and therefore also the ongoing effort required to make them useful. The platform is implemented, processes are formally defined, but no part of the organization feels fully accountable for the quality of execution.
This is why strategy alone is not enough. It needs to be translated into a Target Operating Model that defines who is responsible for what, where decisions are taken, how governance is exercised, and which organizational interfaces must function reliably if the strategy is to be effective in practice.
This becomes even more important in highly distributed organizations. A group function may define standards, provide shared services, and set governance expectations, while local entities or country organizations retain a degree of autonomy for legitimate operational and regulatory reasons. Such a model can work very well, but only if the boundaries are explicit and the responsibilities are actively managed. Global governance without local acceptance tends to create friction. Local flexibility without shared guardrails tends to create fragmentation. Neither outcome is desirable, and neither can be resolved by tooling alone.
A sound Target Operating Model therefore does not attempt to eliminate this tension through abstract organizational ideals. Its role is to make the division of responsibilities workable, transparent, and sustainable.
Tools become overloaded when strategy has not defined their purpose
One of the most common patterns in IAM environments is that the main platform gradually becomes the place where every unresolved issue is eventually deposited. If source data quality is inadequate, more logic is added to IAM. If ownership is unclear, additional workflows are introduced in IAM. If organizational decisions about responsibilities have not been made, control steps are implemented in IAM as a substitute. Over time, the platform stops being a focused control point and starts turning into a collection of compensating mechanisms for problems that originate elsewhere.
This is usually the point at which complexity grows faster than value.
IAM tools are powerful and in many cases highly flexible, but they are not a replacement for process ownership, data governance, or organizational clarity. The existence of a workflow engine does not mean that every unresolved process issue should be modelled inside the platform. The availability of custom logic does not mean that every inconsistency should be corrected within IAM itself. In some cases, these measures are necessary and justified. In many others, they only make the platform more complex, more difficult to maintain, and more dependent on a narrow group of specialists who understand the resulting customization.
A strategy provides an important corrective by defining what belongs within the scope of IAM and what does not. That sounds almost trivial, but it is one of the most valuable consequences of strategic clarity. Once an organization has agreed on the purpose of its IAM capability, it becomes much easier to decide which workflows, controls, and integrations genuinely belong inside the platform and which should remain the responsibility of adjacent domains.
Should an IGA solution orchestrate identity lifecycle processes? Certainly yes. Should it become the long term workaround for unresolved asset management processes, unstructured approval chains, or weak upstream governance? The answer should be “No”.
Without strategy, such decisions are taken reactively and often on a case by case basis. With strategy, they can be assessed against a shared set of principles and an agreed target picture.
Strategy only becomes valuable when it shapes operating reality
An IAM strategy is not the end result. It is the blueprint from which operating capability can be built.
Once a strategic direction has been established, the organization is in a position to derive the structures required for execution. This is where the Target Operating Model becomes particularly important, because it translates strategic intent into day to day reality. It clarifies which functions are needed, where responsibilities should sit, how governance is exercised, and which interfaces between teams must be designed deliberately rather than left to informal practice.
From there, further steps become much more concrete. Required skill profiles can be identified with greater precision. Staffing needs become visible. Existing capabilities can be assessed against future expectations. Skill gaps can be discussed with substance rather than assumption. The organization moves from abstract ambition toward a more practical and implementable design.
This is also where the strategic value becomes tangible. Not because the strategy document itself changes IAM, but because it improves the quality and consistency of the decisions that follow from it. Tool selection becomes more disciplined. Project scopes become clearer. Responsibility models become easier to define and defend. Architectural debates become less driven by individual preferences because there is a shared reference point against which proposals can be evaluated.
For that reason, IAM strategy should not be seen as a luxury exercise for organizations that have the time and resources to think at a higher level. In many environments, it is the necessary precondition for reducing inefficiency, avoiding avoidable complexity, and preventing the steady accumulation of disconnected IAM islands.
IAM strategy does not slow down execution, it prevents circular motion
The practical value of an IAM strategy is not that it produces an attractive document or a polished presentation. Its value lies in creating alignment around a common direction, which in turn reduces friction in day to day work and helps the organization focus on what IAM is actually supposed to achieve.
Without that alignment, tools are introduced as isolated responses to isolated problems. With it, they can become part of a coherent model that supports the broader objectives of security, governance, efficiency, and business enablement.
That is ultimately the key question. Organizations do, of course, need IAM tools. The more important issue is whether those tools are being deployed as part of a deliberate strategy or whether they are quietly taking the place of one.
Together with Oliver Schluga, I will present our approach to designing such a strategy at EIC in the session “From Capabilities to Clarity: Aligning IAM with the Identity Fabric at Scale”. We will discuss how a robust IAM strategy helps organizations reduce complexity, create alignment, and develop IAM into a manageable capability rather than a growing collection of silos. If the topic resonates with you, we would be pleased to welcome you to the session and hear your perspectives and experiences.
