IAM Architecture Patterns — On-Premises, Cloud, Hybrid

Your IAM architecture is the foundation everything else sits on. Whether you realise it or not, your organisation already has an IAM architecture — the question is whether it was designed deliberately or grew organically through years of ad-hoc decisions. This lesson explains the three dominant patterns, their trade-offs, and how to evaluate which model fits your business.

Getting architecture right matters because it determines how quickly you can onboard staff, how securely you can control access across systems, and how much operational overhead your IT team carries every day. A poorly chosen architecture creates compounding technical debt that becomes exponentially harder to fix.

The Three Architecture Patterns

Every organisation’s IAM infrastructure falls into one of three broad categories. Understanding where you sit today — and where you need to be — is the first step toward a mature identity programme.

On-Premises Architecture

The traditional model centres on Microsoft Active Directory (AD), which has been the backbone of enterprise identity since the early 2000s. In this pattern, a domain controller running inside your data centre or server room is the single source of truth for all user identities. Every workstation, file server, and internal application authenticates against AD using protocols like LDAP (Lightweight Directory Access Protocol) and Kerberos.

This model works well when most of your workforce operates from a single office, your applications run on-premises, and you have dedicated IT staff to maintain domain controllers. The advantages include complete control over your directory data, mature tooling, and well-understood security boundaries. However, on-premises AD was designed for a world that no longer exists for most organisations. It struggles with remote access, integrates poorly with SaaS applications without additional middleware, and requires ongoing server maintenance, patching, and disaster-recovery planning.

Vendor landscape: Microsoft Active Directory Domain Services remains the dominant on-premises directory. Alternatives like OpenLDAP and FreeIPA exist but are rarely seen outside of Linux-heavy environments.

Cloud-Native Architecture

In a cloud-native model, your identity provider lives entirely in the cloud. There is no on-premises domain controller. All authentication and authorisation decisions flow through a cloud-hosted service such as Microsoft Entra ID (formerly Azure Active Directory), Okta, Google Cloud Identity, or Ping Identity.

Cloud-native IAM is increasingly the default for organisations founded in the last decade, or for those that have fully migrated away from on-premises servers. The advantages are significant: no infrastructure to maintain, built-in high availability, automatic updates, native integration with SaaS applications, and seamless support for remote workforces. Licensing is subscription-based, turning capital expenditure into predictable operating expenditure.

The trade-offs are real, though. You are placing total trust in your cloud provider’s security and availability. You have less granular control over the underlying infrastructure. And if your organisation still runs legacy on-premises applications that require Kerberos or NTLM authentication, a pure cloud model may not work without significant application modernisation.

Vendor comparison: Microsoft Entra ID dominates in Microsoft-centric environments and offers the tightest integration with Microsoft 365 and Azure. Okta is widely regarded as the most flexible independent identity platform, with deep SaaS integration capabilities. Google Cloud Identity is the natural choice for Google Workspace organisations. Ping Identity is often chosen by large enterprises with complex federation requirements. AWS IAM governs access within the Amazon Web Services ecosystem but is not a general-purpose identity provider for workforce identities.

Hybrid Architecture

Most mid-to-large organisations today operate a hybrid model — and this is where the majority of complexity lives. In a hybrid architecture, an on-premises Active Directory remains the authoritative source for some or all user identities, but those identities are synchronised to a cloud identity provider using tools like Microsoft Entra Connect (formerly Azure AD Connect) or Okta AD Agent.

This model preserves your existing investment in Active Directory while extending identity to cloud services. Users get a single set of credentials that works both on the corporate network and for cloud applications like Microsoft 365, Salesforce, or ServiceNow. The synchronisation process keeps attributes, group memberships, and (optionally) password hashes in sync between on-premises and cloud.

The challenge with hybrid is that you now have two directories to manage, monitor, and secure. Synchronisation introduces latency — a disabled on-premises account may take 30 minutes to propagate to the cloud. Security teams must understand that compromising either environment can compromise the other. Misconfigured sync rules are a common source of both security gaps and operational disruption.

Choosing the Right Pattern

The right architecture depends on your organisation’s current state and strategic direction. Consider these factors:

• Application portfolio: If 80% or more of your applications are SaaS, cloud-native is likely the right direction. If you still run critical on-premises applications that require AD authentication, hybrid is unavoidable in the short term.
• Workforce model: Fully remote or distributed workforces benefit enormously from cloud-native identity. Office-bound workforces with on-premises infrastructure may not see the same urgency.
• IT maturity and staffing: On-premises AD requires dedicated expertise. Cloud-native reduces operational burden but requires different skills around API integration, conditional access policies, and vendor management.
• Compliance and data residency: Some regulated industries require identity data to remain within specific geographic boundaries. Cloud providers now offer regional data residency options, but this must be verified.
• Budget model: On-premises is capital-intensive (servers, licences, staff). Cloud is operational expenditure (monthly subscriptions). Hybrid carries costs from both models simultaneously.

LDAP, Kerberos, and Why They Still Matter

Even in cloud-first organisations, understanding LDAP and Kerberos is important because they underpin legacy systems you may still depend on. LDAP is a protocol for querying and modifying directory information — think of it as the language applications use to ask the directory “does this user exist, and what groups are they in?” Kerberos is the authentication protocol Active Directory uses to verify identity without transmitting passwords across the network.

Many line-of-business applications — particularly older ERP, HR, and finance systems — still rely on LDAP binds for authentication. If your roadmap includes moving to cloud-native identity, you need to audit which applications have hard LDAP dependencies and plan their migration or retirement accordingly.

Why This Matters

Architecture decisions are the hardest to reverse. Choosing the wrong IAM pattern — or failing to choose deliberately — creates years of workarounds, security gaps, and wasted budget. Organisations that built their entire IAM capability on on-premises AD without planning for cloud are now facing expensive, disruptive migration projects. Conversely, organisations that jumped to cloud-native without accounting for legacy applications created shadow IT and integration gaps.

From a security perspective, your IAM architecture determines your attack surface. Every directory, every sync connector, every protocol endpoint is a potential target. Understanding what you have and why you have it is a prerequisite for securing it.

What to Do Now

• Document your current IAM architecture — where do user identities live today? On-premises AD, cloud IdP, or both?
• Create an inventory of every application that authenticates against your directory, noting which protocol it uses (LDAP, Kerberos, SAML, OIDC, or local credentials).
• Identify whether you have synchronisation between on-premises and cloud directories, and who is responsible for monitoring it.
• Ask your IT team: if our primary directory went down for four hours, what would the business impact be?
• Review your cloud identity provider’s licencing tier — many advanced security features (conditional access, identity protection) require premium licences.

Evidence to Collect

• An architecture diagram showing your current IAM topology (directories, sync tools, authentication flows).
• A complete application inventory with authentication method for each system.
• Documentation of your directory synchronisation configuration and monitoring setup.
• A record of your cloud IdP licence tier and which security features are enabled vs available but unused.
• Disaster recovery documentation for your identity infrastructure.

Common Mistakes

• Running hybrid indefinitely without a target state. Hybrid should be transitional. Organisations that treat hybrid as permanent end up maintaining two full sets of infrastructure, doubling cost and complexity without a plan to simplify.
• Ignoring synchronisation health. Entra Connect sync failures are one of the most common causes of authentication outages. If no one is monitoring sync status, you won’t know it’s broken until staff can’t log in.
• Assuming cloud-native means zero maintenance. Cloud identity providers still require active management — conditional access policies, group lifecycle, licence assignment, and security alert triage all require ongoing attention.
• Forgetting service accounts. Architecture discussions often focus on human users and overlook the service accounts, API credentials, and machine identities that also depend on your directory infrastructure.

---

Knowledge Check

---