Why identity architecture is the hardest problem in the enterprise — and how to design Entra as a true platform, not a configuration accumulation.
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 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. 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 HubBefore we discuss solutions, let us name the problems plainly. These seven challenges appear repeatedly — regardless of organisation size or sector.
The most common identity problem: CA policy sprawl. Policies created without a naming convention or governance model result in tenants with sixty, sometimes over a hundred Conditional Access policies — many conflicting, overlapping, or with unintended gaps that create real security risk.
If your Conditional Access policies do not have a documented owner, a naming convention, and a review schedule, you do not have a CA architecture. You have a CA accident waiting to happen.
Permanent Global Administrators. Service accounts with Directory roles. Break-glass accounts without audit trails. Role creep is endemic — and one of the most exploited attack vectors in enterprise environments today. An attacker who compromises a highly privileged account can cause catastrophic, irreversible damage.
Legacy authentication protocols remain enabled because "something might break" — yet these protocols bypass Conditional Access entirely, making a significant portion of authentication traffic invisible to the very controls that are supposed to protect it.
Joiners, Movers, and Leavers processes are often manual, inconsistent, and delayed. Former employees retaining access. Contractors with over-provisioned access. No audit trail — both a security failure and a compliance failure.
B2B guests invited individually without central governance. No lifecycle. No access scope. No review process. Guests accumulate over time and become invisible risk.
Most organisations have deployed pieces of Zero Trust without connecting them into a coherent architecture. The architectural intent must be that every access decision is informed by identity, device, location, and risk — simultaneously.
Most tenants are managed reactively. Changes made to fix immediate problems. No documented baseline. No deviation detection. No change management process. This challenge underpins every other challenge listed here.
The Microsoft Azure Well-Architected Framework provides five pillars for evaluating cloud solutions. Applied directly to identity architecture, each pillar maps precisely to the decisions that determine whether a tenant is resilient or fragile.
Break-glass accounts, hybrid auth fallback, tested failover procedures.
Least privilege, Zero Trust, MFA enforcement, PIM, Entra ID Protection.
Many organisations pay for P2 features (PIM, Access Reviews) and use none of them.
Documented decisions, change management, runbooks, and architecture reviews.
Passwordless, SSO, and Continuous Access Evaluation reduce sign-in friction.
Microsoft now offers a Well-Architected Review for Identity — a structured assessment tool in the Azure portal. Use it before any significant Entra change, and at least annually for ongoing governance.
The TOGAF Architecture Development Method (ADM) maps directly to an identity platform programme. 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 Entra-specific recommendations. In a large organisation, you use both.
| TOGAF ADM Phase | Entra Architecture Activity | Key Deliverable |
|---|---|---|
| Phase A — Vision | Define the identity strategy and engage senior stakeholders. | Identity Strategy Statement, Business Case |
| Phase B — Business | Map identity to business processes and regulatory requirements. | Business Capability Map, Regulatory Matrix |
| Phase C — Info Systems | Directory schema, attribute mapping, SSO architecture, SCIM provisioning. | Directory Design Document, Application Register |
| Phase D — Technology | Hybrid connectivity, Entra Connect topology, Intune integration. | Infrastructure Diagram, Hybrid Identity Design |
| Phase F — Migration | Sequence workstreams: Connect, MFA, CA, PIM, Governance tooling. | Programme Plan, Dependency Matrix |
| Phase H — Change Mgmt | Manage ongoing changes: new apps, policy updates, security incidents. | Change Management Process, Architecture Review Board ToR |
The most expensive mistakes in Entra deployments are made before a single policy is configured — in the decisions, or non-decisions, that precede the build.
For most organisations, a single tenant is the right answer. Multi-tenant architectures introduce significant complexity. The business case must be explicit and justified.
Your directory is a database — design it like one. Define naming conventions, group taxonomy, attribute schema, and object lifecycle policy before creating a single account. Retrofitting conventions into a production tenant is painful and expensive.
PHS, PTA, or Federation — document your decision and the rationale as an Architecture Decision Record. For most new deployments, Password Hash Sync with Seamless SSO is the Microsoft-recommended default.
Passwordless as the north star. Microsoft Authenticator as primary MFA. FIDO2 for privileged users. Legacy methods (SMS, voice) on a deprecation roadmap.
Define your tiered admin model before deployment. Who activates Global Administrator via PIM? Who approves it? These are governance questions requiring business stakeholder sign-off.
Design your CA framework on paper before configuring it. Adopt the three-tier model: Baseline (all users), Privileged (admin accounts), Workload (application-specific). Define a naming convention — e.g. CA-[TIER]-[NUMBER]-[SCOPE]-[CONTROL]. Emergency access accounts must always be explicitly excluded.
Deploy in layers, not all at once: Foundation → Hybrid identity → Authentication → Conditional Access → Privileged access → Governance → Monitoring and response.
Never enable Conditional Access enforcement without first configuring and testing emergency access accounts. A CA policy that locks out all administrators 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 to document and deploy your Conditional Access policies, named locations, authentication methods, and PIM configurations as code. This creates a reproducible deployment baseline and enables change detection.
Deployment is not completion. Identity is a living system. The post-build phase is permanent. Three disciplines sustain a well-managed tenant:
A Solution Blueprint is the single source of truth for how your tenant is designed, why decisions were made, and how it should be maintained — the artefact that bridges TOGAF documentation and day-to-day operational management.
| Blueprint Component | Content | Owner |
|---|---|---|
| Identity Architecture Statement | One-page strategy summary for executive audience. | Enterprise Architect |
| Architecture Decision Records | Hybrid identity method, auth policy, CA architecture, tiered admin model. | Identity Architect |
| CA Policy Register | All CA policies: name, purpose, scope, exclusions, enforcement mode, owner, review date. | Identity Operations |
| Privileged Access Model | Tiered admin model, PIM configuration, break-glass account procedures. | Security Architect |
| Governance Operating Model | Access Review schedule, Lifecycle Workflows, Entitlement Management catalogue, B2B policy. | Identity Governance Lead |
| Monitoring & Alerting Runbook | Log destinations, alert definitions, SOC integration, incident response procedures. | Security Operations |
| Configuration Baseline Document | Tenant settings, auth methods, cross-tenant access, external collaboration — with rationale. | 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 HubIn 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. But tools do not create architecture. Architects do. And architecture without governance drifts back into the configuration accumulation described at the beginning of this article.
In the next article: 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.
20+ years in enterprise IT. 10+ years specialising in Microsoft 365, Microsoft Entra, and identity architecture across highly regulated and complex enterprise environments. Writing about the architecture decisions that actually matter — with the real-world context that most articles leave out.
A plain-English look at what E7 actually means for IT leaders, finance teams, and anyone wondering whether to upgrade.
On 9 March 2026, Microsoft quietly dropped something that will reshape enterprise licensing conversations for the next several years. Microsoft 365 E7 — officially the Frontier Worker Suite — is the most significant change to the M365 enterprise stack since E5 launched in 2015.
I want to cut through the noise and give you a clear-headed view of what this actually is, what it costs, who should care, and what you should do about it before 1 May 2026, when it launches commercially.
"E7 isn't just a new price point — it's Microsoft telling the world that AI agents are now a permanent fixture of the enterprise stack, not an optional extra."
At its core, E7 is a bundle of three things you've probably already been looking at separately:
The fact that Agent 365 comes bundled into the enterprise tier — rather than sold as a premium add-on — tells you everything about where Microsoft sees AI governance heading. This isn't a feature for early adopters; it's infrastructure for every organisation serious about deploying AI responsibly.
Here's what Microsoft's pricing looks like from July 2026:
| Plan | USD / User / Month |
|---|---|
| M365 E3 | $39 |
| M365 E5 | $60 |
| M365 E7 (new) | $99 |
| Copilot Add-on (standalone) | $30 |
The maths is fairly straightforward. If you were to buy E5, Copilot, and Agent 365 separately, you'd be looking at roughly $117 per user per month. E7 brings that down to $99 — a saving of around 15%. Across a large user base, it adds up. More importantly, it simplifies your licensing estate considerably.
E7 makes strong sense if you:
Sticking with E5 for now makes sense if you:
"70% of E5 customers are using fewer than half its features. Before you jump to E7, it's worth asking whether you've actually got value from what you're already paying for."
What I find genuinely interesting about E7 isn't the features list — it's what it signals. Microsoft is formalising AI agents as a platform layer, not an add-on product. By bundling Agent 365 into the enterprise subscription, they're essentially saying: AI agents working alongside your staff isn't a future scenario, it's the baseline assumption.
That's a significant philosophical shift, and it has implications well beyond licensing. Questions around AI governance, identity, data access, and accountability are no longer theoretical — they're operational concerns that IT and security teams need answers to right now.
Before any decision is made, do three things:
E7 is essentially E5 + Copilot + Agent 365 + full Entra, bundled at roughly a 15% saving versus buying separately. It's purpose-built for enterprises that are serious about AI. If that's you, the conversation is worth having. If you're still finding your feet with E5, maximise what you've got first — then revisit E7 with a proper plan behind you.
This is a genuinely exciting moment for Microsoft licensing in the UK. E7 gives organisations a clear, structured path into enterprise AI — and for those ready to take it, the timing couldn't be better.
Velmurugan Miruthuinjayan
Microsoft Licensing & Enterprise Technology