Architecture models

How a well-designed Microsoft 365 security stack fits together.

These are the architecture patterns used across real engagements — not vendor diagrams. Each one reflects how the components actually connect and where the dependencies between them matter.

Identity architecture

Conditional Access Framework

The foundational access control model. Every sign-in is evaluated against a policy set that considers user, device state, location, application target, and real-time risk signals. The outcome is a grant, step-up authentication requirement, session restriction, or block.

Entra ID as the policy evaluation engine

Identity Protection risk signals feeding real-time decisions

Device compliance state from Intune as an access condition

Named locations for trusted network enforcement

MCAS session controls for app-layer enforcement

Minimum: Entra ID P1 (Business Premium or E3)

Identity Security service →

Detection architecture

Defender XDR Integration Model

Four Defender workloads feed into a single unified investigation model. Incidents are correlated across endpoint, email, identity, and cloud app signals — eliminating the fragmented alert view that comes from each product operating independently.

MDE — endpoint detection, ASR rules, attack surface coverage

MDO Plan 2 — email threat protection, attack simulation training

MDI — identity threat detection, lateral movement visibility

MDCA — cloud app governance, OAuth control, session monitoring

Sentinel integration — centralised SIEM with XDR bidirectional sync

Minimum: E3 + Defender add-ons, or E5

Defender XDR service →

Security programme

Zero Trust Layer Dependency Model

Zero Trust is not a feature — it's a dependency chain. Identity enforcement has to be solid before device trust signals are meaningful. Device trust has to be reliable before application session controls add value. The order of implementation matters as much as the implementation itself.

Layer 1: Identity — the non-negotiable starting point

Layer 2: Device — trust signal to identity decisions

Layer 3: Application — session and OAuth governance

Layer 4: Data — classification and enforcement

Layer 5: Monitoring — correlation and response readiness

Minimum: E3 + Defender add-ons. Full: E5

Zero Trust programme →

SOC architecture

Microsoft Sentinel SOC Architecture

Log sources ingest into the Sentinel workspace, analytics rules generate incidents from correlated signals, and SOAR playbooks automate the first-response actions. The diagram shows the data flow from source to actionable incident — and where cost control decisions happen.

Data connectors and ingestion tier management

Analytics rules written in KQL against your log tables

Workbook dashboards for SOC visibility

Logic App playbooks for automated incident response

Threat hunting queries for proactive investigation

Minimum: Sentinel add-on to E3 or E5 with Sentinel included

Sentinel Strategy service →

Automation architecture

Security Workflow Automation Model

Power Automate orchestrates the automation logic. Microsoft Graph API executes the Microsoft 365 actions. SharePoint provides the audit log and metadata store. Power Apps surfaces operational visibility and self-service request intake. The pattern applies to email remediation, access reviews, governance workflows, and joiner-mover-leaver processes.

Trigger types — event, schedule, or user-initiated via Power Apps

Power Automate — orchestration, conditions, error handling

Graph API — the action layer against Microsoft 365

SharePoint — audit log, metadata, approval record

Power Apps — visibility dashboard and request intake portal

Any M365 plan with Power Automate included

Security Automation service →

Want this architecture
designed for your environment?

These diagrams show the pattern. The implementation details depend on your specific tenant configuration, team capacity, and existing deployments. That's what the assessment and architecture engagement addresses.

Book a free call View all services