From common pitfalls to blueprint-level governance — a practitioner's guide to designing, deploying, and managing Entra with architectural intent.
Let me tell you something I have observed across twenty years of enterprise IT. The technology itself is rarely the failure point. The failure is almost always in how identity was designed, governed, and allowed to drift over time.
Microsoft Entra ID — formerly known as Azure Active Directory — is now the identity backbone of hundreds of thousands of organisations globally. It governs who can access what, under what conditions, from where, and on which devices. Done well, it is an invisible, frictionless, and secure foundation for everything your business runs on. Done poorly, it becomes a fragile web of legacy policies, unmanaged service accounts, over-privileged roles, and conditional access gaps that keep security teams awake at night.
The reason identity architecture is genuinely difficult is not technical. The technical controls in Entra are mature, well-documented, and extremely capable. The difficulty is architectural and organisational: most organisations do not treat identity as an architecture discipline at all. They treat it as a configuration task.
"Most organisations do not have an identity architecture. They have an identity accumulation — a layered history of decisions made under pressure, without a blueprint, and never reviewed."
Velmurugan Miruthuinjayan — M365 Architect HubThis article is my attempt to change that framing — for administrators building their first Entra deployment, for architects inheriting a tenant that has grown without governance, and for business leaders who need to understand why identity is not an IT problem but a business risk problem.
I will walk through the most common challenges organisations face with Entra today, map the solution approach to the Microsoft Well-Architected Framework, situate the entire design within the TOGAF enterprise architecture model and the Microsoft Cloud Adoption Framework, and give you a practical blueprint for managing your tenant before, during, and after deployment.
This is not a feature walkthrough. This is how you think about Entra architecturally.
Before we discuss solutions, let us name the problems plainly. In my experience across regulated industries, these seven challenges appear repeatedly — regardless of organisation size or sector.
The single most common identity problem I encounter is Conditional Access (CA) policy sprawl. An organisation starts with one or two policies. Over time, exceptions are made. New use cases arise. Policies are created by different people, in different contexts, without a naming convention or governance model. The result is a tenant with forty, sixty, sometimes over a hundred Conditional Access policies — many of which conflict, overlap, or have unintended gaps.
The business impact: Users are either blocked from legitimate access (productivity loss, helpdesk cost) or slipping through gaps that create real security risk. Neither outcome is acceptable in a regulated environment.
If your Conditional Access policies do not have a documented owner, a naming convention, and a review schedule, you do not have a Conditional Access architecture. You have a Conditional Access accident waiting to happen.
The Entra solution: Implement a CA policy framework using the Microsoft-recommended policy tiers: Baseline, Privileged, and Application-specific layers. Use Entra's What If tool to test policies before enforcement. Maintain a policy register with owners, business justification, and review dates.
In almost every tenant I have reviewed, privileged access has grown without governance. Permanent Global Administrators assigned years ago who never needed that level. Service accounts with Directory roles because it was easier than scoping correctly. Break-glass accounts without audit trails. Role creep — where users accumulate permissions over time — is endemic.
The business impact: An attacker who compromises a highly privileged account can cause catastrophic, irreversible damage — across any organisation, in any sector. Permanent, unreviewed privilege is one of the most exploited attack vectors in enterprise environments today.
The Entra solution: Privileged Identity Management (PIM) is not optional in any serious deployment. PIM enforces Just-in-Time (JIT) access — privilege is requested, approved, time-bounded, and audited. Pair this with Entra's Access Reviews to systematically identify and remove unnecessary role assignments on a scheduled basis. Implement a tiered administrative model: Tier 0 (identity plane), Tier 1 (server/cloud), Tier 2 (workstation/end user) — each with separate, dedicated accounts.
Many organisations operate in a hybrid state — on-premises Active Directory synchronised to Entra ID via Microsoft Entra Connect. The problem is that hybrid identity was often set up as a migration step rather than as an architecture decision. Sync scoping is too broad. Password hash sync, pass-through authentication, and federation decisions were made without understanding the security trade-offs. Legacy authentication protocols remain enabled because "something might break."
The business impact: Legacy authentication protocols bypass Conditional Access entirely. This is not a minor technical detail — it means that a significant portion of authentication traffic in many organisations is invisible to the very controls that are supposed to protect it.
The Entra solution: Audit and remediate legacy authentication using Entra's Sign-In Logs filtered by authentication protocol. Implement a phased block of legacy authentication using Conditional Access — starting with reporting mode, then blocking. Document your hybrid identity architecture decision: for most organisations today, Password Hash Sync with Seamless SSO is the most resilient option. Passthrough Authentication introduces an on-premises dependency. Federation introduces complexity and a high-value on-premises attack target.
Identity Governance — the discipline of managing the identity lifecycle from onboarding through role changes to offboarding — is the area where most organisations have the largest gap between their stated security posture and their actual posture. Joiners, Movers, and Leavers (JML) processes are often manual, inconsistent, and delayed. Access packages are not used. Entitlement management is non-existent.
The business impact: Former employees retaining access. Contractors with over-provisioned access to sensitive systems. No audit trail for who approved what access, when, and why. This is both a security failure and a compliance failure.
The Entra solution: Entra ID Governance provides the full toolkit: Entitlement Management for structured access packages, Access Reviews for periodic attestation, Lifecycle Workflows for automated JML processes, and Privileged Identity Management for privileged access. The key architectural decision is to define your access model before you configure the tools.
Business-to-Business (B2B) collaboration has grown explosively. External partners, vendors, contractors, and guests in your tenant — often invited individually by internal users without any central governance. No lifecycle. No access scope. No review process. Guests accumulate over time and become invisible risk.
The Entra solution: Entra External ID provides the framework. Define a cross-tenant access policy. Use Entitlement Management to provide structured access packages for external partners. Implement B2B Access Reviews. Set a guest lifecycle policy — including automatic expiry.
Zero Trust is not a product you buy. It is an architectural philosophy: never trust, always verify. In practice, most organisations have deployed pieces of the Zero Trust puzzle without connecting them into a coherent architecture. MFA is enforced, but not contextually. Devices are managed, but device compliance is not a CA signal. Identity is monitored, but not correlated with endpoint and network signals.
The Entra solution: Entra ID is the identity plane of your Zero Trust architecture. It must be connected to Microsoft Intune (device compliance), Microsoft Defender for Endpoint (device health signals), and Defender for Cloud Apps (session controls). The architectural intent is that every access decision is informed by identity, device, location, and risk — simultaneously.
Finally — and this is the challenge that underpins all the others — most tenants are managed reactively. Changes are made to fix immediate problems. Configuration drift is accepted as inevitable. There is no documented baseline. No deviation detection. No change management process that treats the tenant as a production system.
The Entra solution: Treat your Entra tenant as infrastructure — with a documented configuration baseline, Infrastructure-as-Code representations of key policies, a change management process, and automated compliance scanning using tools like Microsoft Secure Score, Entra Recommendations, and third-party posture management tools. We will explore this in detail in the Blueprint section.
The Microsoft Azure Well-Architected Framework (WAF) provides five pillars for evaluating and designing cloud solutions. It is most commonly applied to infrastructure and workload design — but it translates directly and powerfully to identity architecture. Let me map each pillar to Entra explicitly.
Your identity platform must be available when your business needs it. Design for resilience: break-glass accounts, hybrid authentication fallback, PTA agent redundancy, and tested failover procedures.
Identity is the new perimeter. Every decision in your Entra architecture must be evaluated through a security lens: least privilege, Zero Trust, MFA enforcement, PIM, and continuous threat monitoring via Entra ID Protection.
Entra licensing is tiered. Ensure you are using the features your licence entitles you to — many organisations pay for P2 features (PIM, Access Reviews, Identity Governance) and use none of them. Licence sprawl is also a cost and compliance risk.
Your identity platform must be maintainable. This means documented architecture decisions, a change management process, runbooks for common operations, and regular architecture reviews. Operational excellence in identity is the difference between a resilient tenant and one that drifts into crisis.
In identity, performance means the user experience of authentication and authorisation. Sign-in friction directly impacts productivity. Design your CA policies to be appropriately strict — not maximally strict. Passwordless, SSO, and Continuous Access Evaluation all serve this pillar.
Microsoft now offers a Well-Architected Review for Identity — a structured assessment tool available in the Azure portal. Use it before any significant Entra change, and at least annually for ongoing governance. It produces a scored report with prioritised recommendations.
Before you configure anything, a WAF-aligned pre-build review should answer these questions across every pillar:
The TOGAF (The Open Group Architecture Framework) is the most widely adopted enterprise architecture framework globally. When applied to an Entra deployment — particularly in large, regulated organisations — TOGAF provides the vocabulary and structure to ensure that an identity platform decision is made at the right altitude, with the right stakeholders, and with proper architecture documentation.
The TOGAF Architecture Development Method (ADM) has phases that map directly to an identity platform programme:
| TOGAF ADM Phase | Entra Architecture Activity | Key Deliverable |
|---|---|---|
| Phase A — Architecture Vision | Define the identity strategy. What business problems is Entra solving? What does success look like in business terms? Engage senior stakeholders. | Identity Strategy Statement, Business Case, Stakeholder Map |
| Phase B — Business Architecture | Map identity to business processes. Which departments, roles, and workflows depend on identity? Where are the regulatory and compliance requirements? | Business Capability Map, Regulatory Matrix, JML Process Definition |
| Phase C — Information Systems Architecture | Define the data architecture (directory schema, attribute mapping, group strategy) and application architecture (which apps use Entra, SSO method, SCIM provisioning). | Directory Design Document, Application Register, SSO Architecture |
| Phase D — Technology Architecture | Define the infrastructure: hybrid connectivity, Entra Connect topology, network requirements, device management integration (Intune), and authentication protocol decisions. | Infrastructure Architecture Diagram, Hybrid Identity Design, Authentication Protocol Decision Record |
| Phase E — Opportunities & Solutions | Identify the implementation approach: phased rollout, parallel run, migration strategy, pilot scope. | Implementation Roadmap, Risk Register, Pilot Scope Document |
| Phase F — Migration Planning | Sequence the workstreams: Entra Connect, MFA rollout, Conditional Access, PIM enablement, Governance tooling. | Programme Plan, Dependency Matrix, Rollback Procedures |
| Phase G — Implementation Governance | Govern the deployment: architecture compliance reviews, deviation management, stakeholder reporting. | Architecture Compliance Framework, Design Authority Process |
| Phase H — Architecture Change Management | Manage ongoing changes: new application integrations, policy updates, licence changes, security incidents requiring architecture response. | Change Management Process, Architecture Review Board Terms of Reference |
The Microsoft Cloud Adoption Framework is Microsoft's prescriptive guidance for cloud adoption at enterprise scale. Its "Identity" discipline sits within the CAF's Govern and Manage methodologies — and it is structured in a way that complements TOGAF rather than replacing it.
Think of it this way: TOGAF provides the architectural governance model — the method, the deliverables, the stakeholder engagement. CAF provides the Microsoft-specific technical guidance — the controls, the design patterns, the Azure and Entra-specific recommendations. In a large organisation, you use both: TOGAF structures how you do architecture, CAF informs what the architecture should look like.
When presenting an Entra deployment to a board or executive team, use TOGAF language: capability, value, risk, and business outcome. When working with the technical team, use CAF language: design patterns, control implementation, and technical standards. The same architecture, two vocabularies — both necessary.
The most expensive mistakes in Entra deployments are made before a single policy is configured. They are made in the decisions — or non-decisions — that precede the build. Here is what must be resolved in the pre-build phase.
For most organisations, a single Microsoft 365 tenant is the right answer. Multi-tenant architectures introduce significant complexity in identity management, cross-tenant collaboration, and licence governance. The business case for multi-tenant must be explicit and justified — not the default. Define your tenant boundary policy clearly.
Your directory is a database. Design it like one. Before you create a single user account, group, or service principal, define your naming conventions, group taxonomy, attribute schema, and object lifecycle policy. Retrofitting naming conventions into a production tenant is painful and expensive. Design these standards upfront and enforce them via automation.
If you have an on-premises Active Directory, you must make an explicit, documented decision about how you will synchronise it with Entra ID. The three options — Password Hash Sync (PHS), Pass-Through Authentication (PTA), and Federation (ADFS) — have fundamentally different security profiles, resilience characteristics, and operational costs. For new deployments in 2025, PHS with Seamless SSO is the Microsoft-recommended default for the vast majority of organisations. Document your decision and the rationale, even if you choose PHS. This is an Architecture Decision Record (ADR).
Define which authentication methods you will allow, and for which user populations. The authentication methods policy in Entra governs this at scale. Establish your target state: Passwordless as the north star, with Microsoft Authenticator as the primary MFA method, FIDO2 security keys for privileged users, and legacy methods (SMS, voice) on a deprecation roadmap.
Define your tiered administrative model before deployment. Who are your Tier 0 identity administrators? What is the process for activating privileged roles via PIM? Who approves Global Administrator activation? These are not just technical questions — they are governance questions that require business stakeholder sign-off.
Design your CA policy framework on paper before you configure it in the tenant. Adopt the Microsoft recommended three-tier model: a Baseline layer (applying to all users), a Privileged layer (applying to administrator accounts), and a Workload layer (application-specific policies). Define a naming convention — for example: CA-[TIER]-[NUMBER]-[SCOPE]-[CONTROL]. Define your exclusion strategy — emergency access accounts must always be explicitly excluded.
The build phase is where architecture decisions become configurations. The principle that should guide every decision in this phase is: configuration as code, documentation as architecture, and testing as governance.
The order in which you deploy Entra capabilities matters architecturally. Here is the recommended sequence:
Never enable Conditional Access enforcement without first configuring emergency access accounts and testing them. A CA policy that locks out all administrators — including the emergency break-glass account — can require Microsoft support to recover and may take 24-72 hours. This has happened in production environments. Test before you enforce.
Treat your Entra configuration as infrastructure. Use Microsoft Graph PowerShell or Terraform (with the AzureAD provider) to document and deploy your Conditional Access policies, named locations, authentication methods, and PIM configurations as code. This serves two purposes: it creates a reproducible deployment baseline, and it enables change detection — you can compare the current tenant state against the documented baseline at any time.
Deployment is not completion. In identity, the post-build phase is permanent — because identity is a living system. Users join, change roles, and leave. Applications are onboarded and retired. Threats evolve. Regulatory requirements change. The question is not how to finish managing your Entra tenant, but how to manage it sustainably against a defined standard.
Your tenant will drift from its intended baseline. This is inevitable — changes are made urgently, exceptions are created, and features evolve. The discipline is detecting and responding to drift, not preventing it entirely. Implement Entra Recommendations (the built-in guidance engine), Microsoft Secure Score tracking for Identity, and periodic manual reviews against your documented architecture baseline.
Run a quarterly Access Review cycle covering: privileged role assignments (PIM), guest and external identities (B2B), application access (Entitlement Management), and group memberships for security-sensitive groups. This is not just a security practice — it is a regulatory compliance requirement across many industries. The automation tools in Entra ID Governance make this operationally feasible at scale.
Entra ID Protection generates risk detections: anonymous IP usage, leaked credentials, impossible travel, atypical sign-in behaviour. These detections must feed into your Security Operations Centre (SOC) workflow. Integrate Entra sign-in logs and audit logs with Microsoft Sentinel (or your SIEM of choice). Define playbooks for common identity threat scenarios — compromised account, mass MFA fatigue attack, insider privilege escalation.
A Solution Blueprint for Entra is a living document — it is the single source of truth for how your tenant is designed, why decisions were made, and how it should be maintained. It is the artefact that bridges the TOGAF architecture documentation and the day-to-day operational management of the identity platform.
A complete Entra Solution Blueprint contains the following components:
| Blueprint Component | Content | Owner |
|---|---|---|
| Identity Architecture Statement | One-page summary of the identity strategy, design principles, and business context. Written in business language for executive audience. | Enterprise Architect |
| Architecture Decision Records (ADRs) | Documented decisions: hybrid identity method, authentication methods policy, CA policy architecture, tiered admin model. Each ADR includes the decision, the alternatives considered, and the rationale. | Identity Architect |
| Directory Design Document | Naming conventions, group taxonomy, attribute schema, sync scoping rules, object lifecycle policy. | Identity Architect |
| Conditional Access Policy Register | Full register of all CA policies: name, purpose, scope, exclusions, enforcement mode, owner, last reviewed date. | Identity Operations |
| Privileged Access Model | Tiered admin model definition, PIM role configuration, break-glass account procedures, privileged access workstation (PAW) policy. | Security Architect |
| Governance Operating Model | Access Review schedule and ownership, Lifecycle Workflow definitions, Entitlement Management access package catalogue, B2B governance policy. | Identity Governance Lead |
| Monitoring and Alerting Runbook | Log destinations, key alert definitions, SOC integration, incident response procedures for identity threats. | Security Operations |
| Configuration Baseline Document | Documented tenant settings, authentication methods, cross-tenant access policy, external collaboration settings — with the rationale for each setting. | Identity Architect |
"A blueprint is not a snapshot. It is a contract between the architecture and the operations team — an agreement that the tenant will be kept in a known, understood, and intentionally designed state."
Velmurugan Miruthuinjayan — M365 Architect HubThe blueprint is only valuable if it is kept current and actually used to govern the platform. Here is a practical governance rhythm:
I want to leave you with a framing that I have found genuinely useful across every identity programme I have been part of — across two decades of enterprise environments where the decisions truly matter.
In modern cloud-first organisations, identity is not a component of the architecture. Identity is the architecture. Every service, every application, every data store, every endpoint is ultimately governed by an identity decision. The question is not whether identity matters — it is whether you have designed it with the care and intentionality that its centrality deserves.
Microsoft Entra gives you extraordinarily capable tools. Conditional Access, Privileged Identity Management, Identity Governance, ID Protection, Verified ID — these are not incremental improvements on directory services. They are a genuinely modern, capable identity platform that, when architected well, can provide both a frictionless user experience and a robust security posture simultaneously.
But tools do not create architecture. Architects do. And architecture without governance drifts back into the configuration accumulation I described at the beginning of this article.
The commitment I am making with this blog is to share the architectural thinking — the decisions, the trade-offs, the frameworks, and the hard lessons — that I have developed across twenty years in industries where identity failures have real and serious consequences. I hope this first article gives you a useful map for the journey.
In the next article, I will go deep on Conditional Access architecture — building a policy framework from scratch, the tiered policy model, What If analysis, and the governance process for managing policy change at enterprise scale.
Article 02: Conditional Access Architecture — Building a Policy Framework That Scales. Covering the three-tier model, naming conventions, report-only governance, and what enterprise CA looks like in large-scale regulated environments. Subscribe to be notified.