Your Identity System Is Held Together by Duct Tape

Recommendations

• Evaluate identity architecture as enterprise infrastructure rather than an administrative IT service when making technology investment decisions.
• Treat identity architecture as a strategic capability that should evolve alongside cloud, security, and digital transformation initiatives.
• Create a complete inventory of authoritative identity sources, synchronization processes, and provisioning workflows before launching any identity modernization initiative.
• Evaluate identity performance across the entire identity lifecycle—from onboarding through offboarding—rather than relying solely on authentication metrics.

Why Identity Architecture Has Become One of the Enterprise’s Largest Sources of Technical Debt

Walk into almost any enterprise IT department and ask a simple question:

“Can you explain how every employee, contractor, application, API, cloud workload, and AI agent receives—and eventually loses—access across the organization?”

Very few people can answer with complete confidence. The explanation usually begins with a story rather than an architecture diagram: “Originally we used Active Directory.” “After the acquisition, we added another identity provider.” “That synchronization script has been running for years, and no one wants to touch it.”

None of these decisions were mistakes. Each addressed a legitimate business need at a particular moment in time. Acquisitions required integrating new directories, cloud migrations demanded identity federation, SaaS platforms introduced their own authentication models, and project deadlines often justified temporary workarounds that became permanent. Individually, these choices were practical. Collectively, they created identity environments that evolved organically rather than being intentionally designed.

That evolution has transformed identity into one of the enterprise’s most critical—and most overlooked—infrastructure capabilities. Identity now determines who can access financial systems, modify production infrastructure, deploy software, retrieve customer information, approve transactions, and increasingly, what autonomous software agents are permitted to do on the organization’s behalf. Yet many enterprises continue to support these responsibilities with disconnected identity stores, overlapping providers, custom synchronization scripts, manual provisioning processes, and undocumented exceptions that persist long after their original purpose has been forgotten.

The result is not necessarily a broken identity system. Most continue to function remarkably well on a day-to-day basis. The problem is that many have become fragile. Like an aging machine held together with layers of duct tape, they continue operating until a merger, cloud migration, security initiative, or new AI program exposes just how dependent the organization has become on accumulated workarounds rather than deliberate architectural design.

This challenge extends well beyond cybersecurity. Identity architecture now shapes operational resilience, regulatory compliance, employee productivity, cloud governance, and an organization’s ability to adopt emerging technologies safely. What was once considered an administrative IT function has quietly become foundational business infrastructure.

Recommendation: Evaluate identity architecture as enterprise infrastructure rather than an administrative IT service when making technology investment decisions.

Identity Has Outgrown Its Original Purpose

Identity management was never designed for the enterprise we operate today.

Directory services such as Microsoft Active Directory emerged when employees primarily worked inside corporate offices, applications resided in company-owned data centers, and the network itself represented the primary boundary of trust. Identity systems had a relatively straightforward mission: create user accounts, authenticate employees, assign group memberships, and provide access to internal applications.

That operating model no longer reflects reality.

A single employee may authenticate through Microsoft Entra ID, access Salesforce using single sign-on, collaborate in Microsoft Teams, deploy workloads into AWS, manage Kubernetes clusters, retrieve information from ServiceNow, and interact with dozens of SaaS applications before the end of the day. Behind those visible activities exists an even larger population of machine identities—including APIs, cloud workloads, containers, service accounts, automation platforms, and software agents—that operate continuously without direct human involvement.

The scale and diversity of these identities have fundamentally changed the role of identity management. What once functioned as a directory service has become the operating system for digital trust, governing virtually every interaction between people, systems, and business data.

Academic research increasingly reflects this transition. Researchers examining the convergence of human and machine identities argue that organizations should no longer govern these populations separately. Modern enterprises rely on both to execute business processes, making identity a unified architectural concern rather than an administrative capability. NIST reaches a similar conclusion through its Zero Trust Architecture guidance, positioning identity—not network location—as the primary basis for establishing trust and making access decisions.

The significance of this shift cannot be overstated. Identity is no longer simply supporting enterprise operations—it has become one of the primary mechanisms through which those operations are governed. Unfortunately, the architecture supporting identity has not evolved at the same pace as the business processes that now depend on it.

Recommendation: Treat identity architecture as a strategic capability that should evolve alongside cloud, security, and digital transformation initiatives.

Identity Technical Debt Doesn’t Arrive All at Once

Few organizations deliberately choose to build fragmented identity environments.

More often, they inherit them.

One acquisition introduces another Active Directory forest. A cloud migration requires synchronizing on-premises identities with Microsoft Entra ID. A business unit purchases a SaaS platform with its own identity model. Contractors receive temporary accounts outside the standard onboarding process because project timelines cannot accommodate existing governance procedures. Each decision solves an immediate operational problem, and each appears entirely reasonable when viewed in isolation.

Over time, however, these decisions accumulate into identity technical debt.

Unlike aging hardware or unsupported software, identity debt rarely announces itself through obvious failures. Employees continue logging into applications, authentication succeeds, and daily operations proceed with little visible disruption. Because the system continues functioning, the growing architectural complexity often goes unnoticed.

The warning signs tend to emerge elsewhere. Provisioning a new employee takes longer because multiple systems require manual intervention. Offboarding depends on service desk tickets instead of automated workflows. Employees accumulate unnecessary privileges as they move between roles. Legacy synchronization jobs continue running because no one fully understands the downstream consequences of removing them. Identity architects inherit environments containing multiple identity providers, redundant provisioning tools, overlapping authentication systems, and hundreds of custom integrations connecting platforms that were never designed to work together.

Industry research suggests this pattern has become widespread. The Identity Defined Security Alliance’s 2025 Trends in Securing Digital Identities identifies identity sprawl and fragmented governance as major obstacles preventing organizations from maintaining consistent security and operational control across increasingly complex digital environments.

This is not simply a technology problem. It reflects how organizations naturally evolve. Business priorities reward speed and adaptability, while architecture rewards consistency and standardization. Those objectives often conflict, and identity systems quietly absorb the resulting complexity.

As discussed in Our “Single Source of Truth” Has Four Versions, fragmentation rarely develops because organizations make poor decisions. More often, it emerges because they make many good decisions independently over time. Identity architecture follows exactly the same pattern.

Recommendation: Create a complete inventory of authoritative identity sources, synchronization processes, and provisioning workflows before launching any identity modernization initiative.

The Hidden Cost of Identity Sprawl

Most organizations recognize that identity is a security issue. Far fewer appreciate the operational consequences of fragmented identity architecture.

Consider the lifecycle of a new employee joining a global organization. Human Resources creates the employee record, identity management provisions an account in Microsoft Entra ID, group memberships grant access to collaboration platforms and business applications, and additional permissions are approved through separate workflows owned by different departments. From a process diagram, the workflow appears orderly. In practice, each step may depend on different systems, different owners, and different assumptions about how access should be managed.

The same fragmentation often becomes even more apparent during offboarding. Disabling a user account may revoke access to email while leaving API keys active, cloud roles assigned, service accounts untouched, or third-party SaaS accounts orphaned because they exist outside centralized governance.

The consequences extend well beyond the security team. Employees wait longer for system access, managers spend time approving duplicate requests because existing permissions are difficult to verify, help desks resolve thousands of authentication issues each year, auditors struggle to reconstruct access histories across disconnected systems, and cloud initiatives become more complicated because identities are distributed across multiple authoritative sources.

None of these problems originate from poorly performing technology. They emerge because the architecture connecting those technologies lacks cohesion.

Recent research examining identity governance in cloud-native environments reaches a similar conclusion, noting that fragmented identity ecosystems significantly complicate lifecycle management, policy enforcement, and governance as organizations expand across distributed cloud platforms and machine identities.

One reason these costs often remain hidden is that organizations measure identity performance using operational metrics such as password resets, authentication success rates, or login times. Those metrics reveal very little about architectural health. A fragmented identity environment can authenticate users successfully every day while simultaneously slowing onboarding, increasing administrative effort, complicating compliance, and creating unnecessary operational risk.

Architecture determines far more than authentication.

It determines how efficiently the enterprise itself operates.

Recommendation: Evaluate identity performance across the entire identity lifecycle—from onboarding through offboarding—rather than relying solely on authentication metrics.

Identity Architecture Is Becoming a Business Capability

Perhaps the most important change occurring in identity management is not technological—it is organizational.

Identity is no longer owned exclusively by infrastructure teams. Human Resources initiates workforce lifecycle events, procurement manages supplier relationships, legal governs third-party access, security defines authentication policies, cloud teams provision machine identities, application owners determine authorization models, and AI initiatives introduce autonomous software agents that require identities, permissions, and governance. Identity has become the connective tissue linking these functions together.

As a result, organizations that continue viewing identity as a collection of authentication technologies will find it increasingly difficult to support cloud adoption, Zero Trust, AI initiatives, and digital transformation. Those that recognize identity as an enterprise capability—with clear ownership, governance, architecture, and lifecycle management—will be better positioned to adapt as technology continues evolving.

That evolution becomes even more significant as autonomous systems enter the enterprise. Unlike human employees, AI agents may operate continuously, interact across dozens of business systems, and perform work on behalf of the organization without direct supervision. If today’s identity architecture already depends on manual processes and undocumented exceptions, introducing autonomous identities will amplify those weaknesses rather than solve them.

Organizations preparing for AI should begin with a much simpler question:

Do we actually understand the identity architecture we have today?

Recommendation: Establish executive ownership for enterprise identity architecture that spans business governance, enterprise architecture, security, HR, and digital transformation rather than treating identity as an infrastructure responsibility alone.

Identity Is No Longer Just About People

One of the most significant changes in enterprise identity management has received surprisingly little attention outside cybersecurity circles. The population of identities inside an organization is no longer composed primarily of employees.

Modern enterprises now depend on an expanding ecosystem of non-human identities that includes APIs, cloud workloads, Kubernetes clusters, service accounts, robotic process automation (RPA) bots, and autonomous software agents. Unlike employees, these identities authenticate continuously, interact with multiple systems simultaneously, and often possess elevated privileges because they execute business processes rather than simply consume applications.

This shift has profound architectural implications. Traditional Identity and Access Management (IAM) platforms were largely designed around predictable human lifecycle events—hire, transfer, promote, terminate. Machine identities operate according to an entirely different lifecycle. They may exist for only minutes in a cloud-native environment or persist indefinitely as embedded integrations that few people remember creating. As organizations adopt AI-driven automation, the number of machine identities is expected to grow even faster, further blurring the distinction between users and systems.

Research argues that organizations should stop governing human and machine identities separately. Instead, identity should be treated as a unified enterprise capability with common governance, lifecycle management, and risk controls regardless of whether the identity belongs to an employee, an API, or an autonomous AI agent.

This is one reason identity modernization has become far more than an infrastructure initiative. The objective is no longer simply improving authentication. It is creating an architectural foundation capable of supporting every trusted participant in the enterprise, whether human or machine.

Recommendation: Expand your identity governance program to include machine identities, service accounts, APIs, and emerging AI agents under the same lifecycle controls used for employees.

When Identity Architecture Fails, Business Operations Follow

Identity problems rarely announce themselves through dramatic technical failures. More often, they surface as operational friction that gradually becomes accepted as part of doing business.

A new employee waits several days for access because provisioning spans multiple disconnected systems. Managers repeatedly approve the same access requests because permissions cannot be easily verified. Contractors retain privileges long after projects conclude because offboarding depends on manual processes rather than automated workflows. Individually, these issues appear manageable. Together, they consume thousands of hours of administrative effort while quietly increasing operational and security risk.

Occasionally, however, weaknesses in identity architecture become impossible to ignore.

The 2023 cyberattack against MGM Resorts is a well-documented example. Public reporting indicates that attackers gained access by socially engineering the organization’s help desk into resetting authentication credentials. They did not exploit a sophisticated vulnerability in MGM’s infrastructure. Instead, they exploited an operational process that governed identity verification. The resulting disruption affected hotel operations, reservation systems, digital room keys, casino operations, and numerous customer-facing services.

The significance of the incident extends beyond cybersecurity. It illustrates that identity architecture encompasses much more than authentication technology. Business processes, governance, help desk procedures, and organizational policies all become part of the identity system. A weakness in any of those components can have enterprise-wide consequences.

Many organizations experience a quieter version of the same problem. Consider a company that has grown through several acquisitions over the past decade. Each acquisition introduces another directory service, identity provider, HR platform, and provisioning process. Rather than consolidating those environments, integration projects connect them through synchronization tools and custom scripts to meet business deadlines. Years later, the environment technically functions, but routine activities such as onboarding employees, integrating new applications, or conducting access reviews require navigating multiple overlapping systems with no single authoritative source.

Nothing appears broken.

Yet every new business initiative becomes more difficult because the architecture itself has become the constraint.

As discussed in Our “Single Source of Truth” Has Four Versions, organizations often mistake operational complexity for unavoidable business reality. In many cases, the complexity is simply the accumulated result of years of disconnected architectural decisions.

Recommendation: Map every manual identity process that exists today and identify which ones compensate for architectural limitations rather than genuine business requirements.

Modernizing Identity Requires Architectural Thinking

Technology vendors often position identity modernization as a platform decision. Organizations are encouraged to evaluate identity providers, privileged access solutions, lifecycle management tools, or governance platforms. While those technologies are important, they address only part of the challenge.

The more difficult questions are architectural.

Which system serves as the authoritative source for workforce identities? Who owns lifecycle events across employees, contractors, and third parties? How are machine identities governed? How are permissions inherited, reviewed, and revoked? What policies will govern AI agents acting on behalf of employees?

These questions cannot be answered through software selection alone because they involve organizational ownership, governance, and enterprise design.

This explains why many identity modernization initiatives struggle despite significant technology investments. Legacy approval processes remain unchanged. Business ownership remains fragmented. Temporary exceptions become permanent operating procedures. New platforms simply inherit the complexity of the environments they replace.

Emerging academic research reinforces this concern. Researchers examining identity frameworks for agentic AI argue that future identity architectures must support dynamic delegation, contextual trust, and continuous policy evaluation rather than relying on static user accounts and predefined roles. Those requirements align closely with broader enterprise architecture principles, suggesting that identity modernization should be approached as an operating model transformation rather than a technology refresh.

Organizations preparing for AI would be well served to examine their identity architecture first. AI agents will amplify existing governance strengths, but they will also expose years of accumulated technical debt.

Recommendation: Begin identity modernization by documenting governance, ownership, and lifecycle architecture before evaluating replacement technologies.

Identity Is Becoming an Enterprise Capability

Perhaps the most important realization is that identity no longer belongs exclusively to the IT department.

Human Resources initiates identity lifecycle events. Security defines authentication policies. Enterprise architecture establishes governance standards. Procurement manages supplier access. Cloud operations provision service accounts and workload identities. Business leaders ultimately determine who should have access to critical information and systems. As AI becomes embedded within enterprise workflows, that circle of stakeholders will continue expanding.

This evolution reflects a broader pattern seen throughout digital transformation. Technologies that begin as technical capabilities eventually become enterprise capabilities because they influence how the entire organization operates. Identity has reached that point.

Organizations that continue viewing identity as a collection of authentication technologies will find modernization increasingly difficult because they are solving infrastructure problems rather than architectural ones. Organizations that recognize identity as a shared enterprise capability can build governance models that support cloud computing, Zero Trust, regulatory compliance, and AI adoption through a common operating framework.

Technology will continue to evolve. Identity providers will change. Authentication methods will improve. New categories of machine identities will emerge. What should remain stable is the underlying architecture governing how trust is established, managed, and continuously evaluated across the enterprise.

Recommendation: Establish enterprise-wide ownership of identity architecture that includes business leaders, enterprise architecture, security, HR, and cloud operations rather than treating identity as an infrastructure function alone.

Conclusion

Most organizations did not intentionally design fragmented identity environments. They accumulated them.

Every acquisition, cloud migration, SaaS implementation, and business exception solved an immediate problem. Taken individually, those decisions were often entirely reasonable. Over time, however, they produced identity architectures that are increasingly difficult to govern, secure, and evolve.

That accumulated complexity matters because identity now underpins almost every aspect of modern business. It governs access to cloud infrastructure, customer data, financial systems, development environments, third-party services, and emerging AI agents. It has become the foundation upon which digital trust is built.

“Identity fragmentation isn’t the result of one bad decision. It’s the accumulated complexity of many reasonable decisions—and solving it requires architecture, not another integration.”

The organizations that modernize successfully will not simply deploy newer IAM platforms. They will rethink identity as an enterprise capability with clear ownership, consistent governance, and an architecture designed to support humans, machines, and autonomous agents alike.

The duct tape holding many identity environments together is a symptom, not the problem itself. The real challenge is architectural. And like most architectural problems, it cannot be solved one integration at a time. It requires stepping back, understanding the system as a whole, and deliberately designing it for the way organizations operate today—and the way they will operate tomorrow.