In this module
MSA0.2 The M365 Security Stack as Architecture
You've used the Entra admin center, the Microsoft 365 Defender portal, and at least some of the Purview, Intune, and Sentinel consoles. You know these products exist. This sub maps how they connect as an architecture — the signal chains, the integration points, the licensing boundaries — and uses Graph API queries to show you exactly where the connections are live, where they're broken, and where your licensing prevents them from existing at all.
The M365 security stack has dozens of products across identity, protection, detection, and governance. Each product has its own portal, its own configuration, its own documentation. The architectural problem isn't understanding each product — it's understanding how they connect, what signals flow between them, and where the connections break due to configuration gaps, missing licensing, or integration that was never enabled. This sub maps the stack as four architectural layers and gives you Graph API queries that prove whether each connection is live in your tenant.
Estimated time: 35 minutes.
Figure MSA0.2 — The M365 security stack as four architectural layers. Arrows represent signal chains — each is a dependency you can test with a Graph API query.
Why the stack matters as architecture, not a product list
Microsoft sells M365 security as a collection of products — Entra ID, Defender for Endpoint, Purview, Intune, Sentinel. Each has its own portal, its own admin experience, its own documentation. If you've taken an SC-300 or SC-400 prep course, you learned each product independently. That's administration.
Architecture is different. Architecture treats these products as layers in a connected system where signals flow between them. Identity Protection generates a risk score. Conditional Access consumes that score to make an access decision. Intune evaluates device compliance. That compliance signal feeds back into Conditional Access. Sensitivity labels classify data. DLP policies enforce protection rules based on those labels. Each product produces or consumes signals — and the connections between them are where the security value lives.
The MCRA organises these connections into four layers. This sub walks each layer, tests the signal chains with real queries, and shows you where the connections break. By the end, you'll have a table showing which signal chains are live in your tenant and which are missing — and that table becomes the first input to your architecture package.
Layer 1 — Identity and access control
Every authentication, every authorization, every access decision flows through Entra ID. Conditional Access is the Zero Trust policy engine at the center of the architecture. When a sign-in request arrives, CA evaluates signals from multiple sources before making a decision: who is authenticating, what authentication method they used, what device they're on, whether that device is compliant, where they're connecting from, which application they're accessing, and what the real-time risk level is.
The architectural insight is that Conditional Access is a signal consumer. If a signal source doesn't exist, the policy engine makes decisions without that input — and the decision may look like it's working when it's actually incomplete.
Test whether Identity Protection is feeding risk signals to CA. This requires Entra ID P2 (included in E5):
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All"
Get-MgRiskDetection -Top 5 |
Select-Object RiskEventType, RiskLevel, DetectedDateTime,
UserDisplayName, IpAddress, ActivityRiskEventType RiskLevel DetectedDateTime UserDisplayName IpAddress Activity
------------- --------- ---------------- --------------- --------- --------
unfamiliarFeatures medium 2026-04-12T08:14:22Z SOC Analyst 2 203.0.113.45 signin
anonymizedIPAddress high 2026-04-11T22:31:05Z SOC Analyst 1 198.51.100.88 signin
impossibleTravel medium 2026-04-10T14:02:17Z the CISO 192.0.2.33 signin
leakedCredentials high 2026-04-09T06:45:33Z the security architect (offline) signin
maliciousIPAddress high 2026-04-08T19:22:41Z the IT Director 203.0.113.91 signinIf this returns results, Identity Protection is active and evaluating sign-ins. Each RiskEventType represents a specific detection algorithm — unfamiliarFeatures analyses sign-in properties against the user's learned baseline, anonymizedIPAddress flags known VPN/proxy/Tor exit nodes, impossibleTravel detects geographically impossible movements between sign-ins, leakedCredentials correlates against Microsoft's database of compromised credential pairs, and maliciousIPAddress matches against known attacker infrastructure.
If the query returns an empty set or a 403 Forbidden, either Identity Protection isn't licensed (E3 tenants with Entra ID P1 don't have it), or the permissions aren't granted. For E3 tenants, this means the riskLevelDuringSignIn field in every sign-in log will be "none" regardless of how suspicious the sign-in actually is — and any CA policy that conditions on signInRiskLevels has no signal to evaluate.
Now check whether authentication strength policies exist. These are the mechanism from MSA0.1 that differentiates phishing-resistant MFA from push notification MFA:
Get-MgPolicyAuthenticationStrengthPolicy |
Select-Object Id, DisplayName, PolicyType,
@{N='Combinations';E={$_.AllowedCombinations -join ", "}}Id DisplayName PolicyType Combinations
-- ----------- ---------- ------------
00000000-0000-0000-0000-000000000002 MFA builtIn password,microsoftAuthenticatorPush; password,soft...
00000000-0000-0000-0000-000000000003 Passwordless MFA builtIn windowsHelloForBusiness; fido2; x509CertificateMu...
00000000-0000-0000-0000-000000000004 Phishing-resistant MFA builtIn windowsHelloForBusiness; fido2; x509CertificateMu...Three built-in policies exist by default in every tenant. The AllowedCombinations column is what matters — it shows exactly which authentication method combinations satisfy each policy. The "MFA" policy accepts everything including password,microsoftAuthenticatorPush (push notification MFA). The "Phishing-resistant MFA" policy only accepts windowsHelloForBusiness, fido2, and x509CertificateMultiFactor — methods that cryptographically bind to the legitimate server's TLS session and can't be intercepted by a proxy.
What matters architecturally is whether any CA policy actually references these. If all your CA policies use builtInControls: ["mfa"] instead of pointing to an authentication strength policy, the distinction between phishing-resistant and non-phishing-resistant authentication doesn't exist in your policy layer. The policies are present but unused.
Layer 2a — Data protection
The data protection layer centers on Microsoft Purview. Sensitivity labels provide the classification taxonomy. DLP policies enforce protection rules. The architectural challenge is making them work together — a DLP policy can only enforce rules on labelled content, and labels only work if they're applied.
Test whether sensitivity labels are published and in use. This endpoint requires the beta API (sensitivity label management hasn't been fully promoted to v1.0):
Connect-MgGraph -Scopes "InformationProtectionPolicy.Read"
$labels = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/security/informationProtection/sensitivityLabels"
$labels.value | Select-Object name, id, isActive,
@{N='Scope';E={$_.scope -join ", "}},
@{N='AutoLabel';E={if ($_.autoLabeling) { 'Configured' } else { 'None' }}}name id isActive Scope AutoLabel
---- -- -------- ----- ---------
Public a1b2c3d4-e5f6-7890-abcd-ef1234567890 True file, email None
General b2c3d4e5-f6a7-8901-bcde-f12345678901 True file, email None
Confidential c3d4e5f6-a7b8-9012-cdef-123456789012 True file, email None
Highly Confidential d4e5f6a7-b8c9-0123-def0-234567890123 True file, email ConfiguredFour labels exist. Three have AutoLabel: None — they rely entirely on users applying them manually. One has auto-labelling configured, but auto-labelling for files and emails requires E5 licensing (specifically, the Microsoft 365 E5 Compliance or Microsoft 365 E5 Information Protection & Governance add-on). On E3, auto-labelling is limited to client-side labelling in Office apps with the Azure Information Protection unified labelling client.
The architectural question: are the labels being applied? Labels that exist but sit unused mean DLP policies built to trigger on "Confidential" or "Highly Confidential" content are protecting nothing. You can check label usage through the Purview compliance portal's activity explorer, but there's no simple Graph API query that tells you what percentage of documents are labelled. This is a governance gap — MSA5 covers how to build label adoption monitoring into the architecture.
Four sensitivity labels published. Auto-labelling not configured (requires E5) or configured only for the "Highly Confidential" label. No user training on manual labelling. Result: 90–95% of documents and emails carry no label. DLP policies that trigger on "Confidential" or "Highly Confidential" labels protect a fraction of the data they should. The DLP dashboard shows policies are active and processing content. Coverage is minimal — because coverage depends on labelling, and labelling depends on either auto-labelling (E5) or user adoption (training). The dashboard doesn't show you what it isn't seeing.
Layer 2b — Endpoint and application protection
The endpoint layer produces the device compliance signal that Conditional Access consumes. This is the signal chain that connects Layer 2 to Layer 1 — and it's the one most likely to be configured but architecturally broken.
Test whether Intune compliance policies exist and what they evaluate:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
Get-MgDeviceManagementDeviceCompliancePolicy |
Select-Object DisplayName,
@{N='Platform';E={
$odata = $_.AdditionalProperties.'@odata.type'
switch -Wildcard ($odata) {
'*windows10*' { 'Windows' }
'*iosCompli*' { 'iOS' }
'*android*' { 'Android' }
'*macOS*' { 'macOS' }
default { $odata }
}
}},
@{N='Created';E={$_.CreatedDateTime.ToString("yyyy-MM-dd")}}DisplayName Platform Created
----------- -------- -------
Win11 - Standard Compliance Windows 2024-09-15
Win11 - High Security Compliance Windows 2024-09-15
iOS - Corporate Devices iOS 2024-11-03
Android - BYOD Minimum Android 2024-11-03Four compliance policies. Each defines what "compliant" means for that platform — things like OS version requirements, encryption enabled, firewall active, not rooted/jailbroken, threat protection status from Defender for Endpoint.
The critical architectural question is the grace period and the default behavior. When a device is first enrolled, or when a compliance policy changes, Intune gives the device a grace period to become compliant. During that grace period, the device may be marked as "compliant" even though it hasn't been evaluated against the new policy. Check the tenant-level default:
$settings = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/deviceManagement/settings"
$settings | ConvertTo-Json{
"deviceComplianceCheckinThresholdDays": 30,
"isScheduledActionEnabled": true,
"secureByDefault": false
}deviceComplianceCheckinThresholdDays: 30 — a device that hasn't checked in for 30 days is marked non-compliant. But 30 days is the default. A device can go a month without evaluating compliance and still pass the CA compliantDevice check. If your CA policy requires device compliance for Exchange and SharePoint access, and a device stops reporting for three weeks, it still gets in.
secureByDefault: false — this is the setting that determines whether devices with no compliance policy assigned are treated as compliant or non-compliant. If false (the default), a device with no assigned compliance policy is treated as compliant. That means if you add a new device platform (say, Linux or ChromeOS) and don't create a compliance policy for it, those devices automatically pass the compliantDevice check in CA. The signal chain looks connected — but the upstream signal is meaningless for that platform.
An architected tenant sets secureByDefault: true and reduces deviceComplianceCheckinThresholdDays to 7 or 14. These two settings change the trust model from "compliant unless proven otherwise" to "non-compliant unless proven compliant." MSA6 covers this in depth.
Layer 3 — Security operations
Defender XDR correlates signals across Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Entra ID Protection. When a phishing email is delivered (Defender for Office 365), a user clicks the link (Defender for Endpoint), and the stolen credential is used to sign in from a new location (Entra ID Protection), Defender XDR correlates these into a single multi-stage incident rather than three independent alerts.
Test whether the correlation engine is producing incidents:
Connect-MgGraph -Scopes "SecurityIncident.Read.All"
$incidents = Invoke-MgGraphRequest -Method GET `
-Uri 'https://graph.microsoft.com/v1.0/security/incidents?$top=5&$orderby=createdDateTime desc'
$incidents.value | ForEach-Object {
[PSCustomObject]@{
Title = $_.displayName
Severity = $_.severity
Status = $_.status
Created = $_.createdDateTime
Alerts = $_.alerts.Count
}
}Title Severity Status Created Alerts
----- -------- ------ ------- ------
Multi-stage incident involving phishing and credential theft high active 2026-04-12T14:22:00Z 4
Suspicious inbox manipulation rule detected medium resolved 2026-04-10T09:15:33Z 2
Anomalous token usage from unfamiliar location medium active 2026-04-09T16:44:21Z 3The first incident has 4 correlated alerts — that means four separate Defender products detected different stages of the same attack and XDR linked them. If this query returns nothing, either nothing has triggered (unlikely in a tenant with 800+ users) or the Defender products aren't feeding into the XDR engine. The most common cause is that data connectors between Defender for Identity (on-premises AD monitoring) and the unified XDR portal aren't configured — MSA10 and MSA11 address this.
Sentinel sits alongside Defender XDR as the SIEM for data sources beyond Microsoft's first-party telemetry, the SOAR layer for automated response playbooks, and the UEBA layer for behavioral analytics. The architectural decision between Sentinel and Defender XDR — when to use which, how they coexist, where to ingest which data — is one of the most consequential design choices in this course. Most organizations with E5 run both, and the duplication and handoff between them is a frequent source of architectural confusion. MSA8 through MSA11 address this in depth.
Layer 4 — Governance and posture
Governance closes the feedback loop. Access reviews find stale permissions that the identity layer should revoke. Compliance Manager identifies control gaps. Secure Score provides quantified posture feedback.
Query your Secure Score:
Connect-MgGraph -Scopes "SecurityEvents.Read.All"
$scores = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/v1.0/security/secureScores?`$top=1"
$latest = $scores.value[0]
[PSCustomObject]@{
CurrentScore = $latest.currentScore
MaxScore = $latest.maxScore
Percentage = [math]::Round(($latest.currentScore / $latest.maxScore) * 100, 1)
Date = $latest.createdDateTime
}CurrentScore MaxScore Percentage Date
------------ -------- ---------- ----
287 398 72.1 2026-04-15T00:00:00Z72.1% sounds respectable. But Secure Score is not a security measure — it's a feedback signal. The architectural question is what the missing 27.9% contains. Query the recommendations that aren't fulfilled:
$scores.value[0].controlScores |
Where-Object { [double]$_.score -lt [double]$_.maxScore } |
Sort-Object { [double]$_.maxScore - [double]$_.score } -Descending |
Select-Object controlName, score, maxScore,
@{N='Gap';E={[double]$_.maxScore - [double]$_.score}} -First 8controlName score maxScore Gap
----------- ----- -------- ---
AdminMFAV2 0 10 10
SigninRiskPolicy 0 9 9
UserRiskPolicy 0 9 9
BlockLegacyAuthentication 5 10 5
OneAdmin 4 8 4
SelfServicePasswordReset 0 4 4
IntuneMDMRequired 2 5 3
UseAuthenticatorApp 3 5 2AdminMFAV2 at 0/10 — admin MFA isn't fully enforced. That's the the IT Director problem from MSA0.1. SigninRiskPolicy and UserRiskPolicy both at 0/9 — Identity Protection risk signals are generated but no CA policy acts on them. The signal chain between Identity Protection and Conditional Access doesn't exist in policy, even though both products are licensed and active.
OneAdmin at 4/8 — more than one permanent Global Administrator exists. Secure Score recommends a maximum of 5 GA accounts, ideally 2 (one primary, one break-glass). Permanent GA assignments (not eligible via PIM) are an architectural problem — they create standing privilege that attackers exploit.
An architected tenant uses these recommendations as ADR inputs. Each unfulfilled recommendation either gets an implementation plan with a timeline, or a documented decision to accept the gap with compensating controls. A configured tenant treats the score as a number to improve.
The licensing boundary that shapes everything
The most significant architectural constraint in M365 security isn't technical — it's licensing. Query your tenant's license inventory:
Get-MgSubscribedSku |
Where-Object { $_.SkuPartNumber -match 'SPE_E3|SPE_E5|EMSPREMIUM|AAD_PREMIUM|AAD_PREMIUM_P2|IDENTITY_THREAT_PROTECTION' } |
Select-Object SkuPartNumber,
@{N='FriendlyName';E={
switch ($_.SkuPartNumber) {
'SPE_E3' { 'Microsoft 365 E3' }
'SPE_E5' { 'Microsoft 365 E5' }
'EMSPREMIUM' { 'EMS E5 (standalone)' }
'AAD_PREMIUM' { 'Entra ID P1 (standalone)' }
'AAD_PREMIUM_P2' { 'Entra ID P2 (standalone)' }
'IDENTITY_THREAT_PROTECTION' { 'Entra ID P2 + Identity Threat Protection' }
default { $_.SkuPartNumber }
}
}},
ConsumedUnits,
@{N='TotalUnits';E={$_.PrepaidUnits.Enabled}}SkuPartNumber FriendlyName ConsumedUnits TotalUnits
------------- ------------ ------------- ----------
SPE_E5 Microsoft 365 E5 210 250
SPE_E3 Microsoft 365 E3 560 600
EMSPREMIUM EMS E5 (standalone) 40 50This tenant has 250 E5 licenses and 600 E3 licenses. 210 users have E5. 560 have E3. The 40 EMS E5 standalone licenses add Entra ID P2 + Intune P2 to 40 additional users who have E3 as their base license — a common pattern for giving Identity Protection and PIM to administrators who don't need the full E5 suite.
The architectural consequence: every feature that requires E5 or P2 is available to 250 users (or 290 with the EMS add-on) and absent for the remaining 560. The CA policy "Block High Risk Sign-ins" only evaluates risk for users with Entra ID P2. E3 users with P1 don't generate risk signals. The policy exists for everyone in scope but protects only the P2-licensed population.
E3 includes Entra ID P1 (Conditional Access, basic MFA, self-service password reset), Intune (device management, compliance), basic DLP (manual labels, limited DLP policies), and Defender for Office 365 Plan 1 (Safe Links, Safe Attachments). E5 adds Entra ID P2 (Identity Protection risk policies, PIM, access reviews), Defender for Endpoint Plan 2 (full EDR, automated investigation, vulnerability management), Defender for Office 365 Plan 2 (Attack Simulation, threat investigation), Defender for Cloud Apps (shadow IT discovery, session controls), Purview auto-labelling, Insider Risk Management, and the advanced analytics that make Sentinel and Defender XDR effective.
E3 provides the individual capabilities. E5 provides the signals that connect them. Without Identity Protection (P2), CA can't evaluate real-time sign-in risk. Without Defender for Endpoint Plan 2 (E5), the device health signal lacks threat intelligence context. Without auto-labelling (E5), sensitivity labels depend on manual user application — and adoption rates below 10% are normal without enforcement. This course covers the E3 alternative for every E5-dependent design decision. Where E3 can't match E5's capability, the course teaches you to document the gap as residual risk with compensating controls — which is architecture, not a workaround.
This licensing split is why architecture matters more than configuration. A well-architected E3 tenant with documented decisions, mapped dependencies, and honest risk statements is more secure than a poorly-architected E5 tenant where every feature is enabled but nothing is connected. The features don't protect you. The connections between them do.
Before moving on, verify your understanding: Name the four architectural layers and give one example of a signal that flows from one layer to another. Run the query that tests whether that signal chain is live in your tenant. If the query fails or returns nothing, explain what that means for the downstream policy. Run Get-MgSubscribedSku against your tenant. Identify how many users have E5 vs E3 licensing. Name two specific signal chains that exist for E5 users but not for E3 users. For each, explain what the CA policy does when the signal is absent.
Reusable script — the commands from this sub assembled for operational use:
Run the six signal-chain queries from this sub against your tenant. For each, record the state: live (signal flowing, consumed by downstream policy), configured but disconnected (product active, signal not consumed by any policy), not licensed (E5 feature on E3-only tenant), or not deployed (feature available but not configured).
# Signal chain audit — run each, record the result
# 1. Identity Protection → CA risk policies (Layer 1 internal)
Get-MgRiskDetection -Top 1 # Returns data = signal exists
# Then: any CA policy with signInRiskLevels or userRiskLevels populated?
# 2. Authentication strength → CA grant controls (Layer 1 internal)
Get-MgPolicyAuthenticationStrengthPolicy # Policies exist — but referenced?
# Then: any CA policy with authenticationStrength not null?
# 3. Intune compliance → CA device trust (Layer 2b → Layer 1)
Get-MgDeviceManagementDeviceCompliancePolicy # Policies exist?
# Then: any CA policy with compliantDevice in builtInControls?
# 4. Sensitivity labels → DLP coverage (Layer 2a internal)
# Beta: GET /security/informationProtection/sensitivityLabels
# Are labels published AND applied? (Check Activity Explorer in Purview)
# 5. Defender products → XDR correlation (Layer 2 → Layer 3)
# GET /security/incidents — is XDR producing correlated incidents?
# 6. Secure Score → governance feedback (Layer 4 → all layers)
# GET /security/secureScores — what's unfulfilled?This audit produces a table: six signal chains, four possible states. Gaps in this table are the architectural priorities for your MSA architecture package. Bring this audit to MSA0.5 when you assess your environment's current state.
You're reading the free modules of m365-security-architecture
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.