MSA0.8 Module Summary

What Module 0 taught

Module 0 had one job: teach you to think architecturally about M365 security before you configure a single control. Seven subs built that foundation from different angles — the configuration-architecture gap, the stack as connected layers, the documentation methodology, the threat landscape, the scenario environment, the lab, and the deliverable structure. Here's what each one established and why it matters for the modules ahead.

MSA0.1 — What Security Architecture Actually Is

The central distinction of this course: configuration is the state of the tenant (what's enabled), architecture is the reasoning behind that state (why it was chosen, what depends on it, what risk it accepts). You saw this distinction made concrete through the Graph API. A Conditional Access policy JSON returned by Get-MgIdentityConditionalAccessPolicy tells you the policy exists, which users it targets, which grant controls it enforces, and which groups it excludes. It does not tell you why the exclusion group exists, whether the authenticationStrength: null field is a deliberate choice or an oversight, or what breaks if someone removes the exclusion.

You traced an MFA exclusion group to discover an admin user holding Global Administrator, Exchange Administrator, and SharePoint Administrator roles — excluded from MFA with no documented reason. You compared two sign-in log entries for the same user, same application, same IP: one from a tenant with configuration only (conditionalAccessStatus: "notApplied", authenticationMethod: "Password", deviceDetail.isCompliant: null) and one from a tenant with architecture (conditionalAccessStatus: "success", enforcedGrantControls: ["RequireAuthenticationStrength"], authenticationMethod: "FIDO2 security key", isCompliant: true). The sign-in log is the evidence of whether architecture exists.

The three diagnostic questions — why this and not something else, what depends on this, what risk do we accept — are the lens you'll apply to every security setting in every module.

MSA0.2 — The M365 Security Stack as Architecture

The M365 security stack isn't a product list — it's four connected layers where signals flow between them. Layer 1 (identity and access control) feeds into Layer 2 (protection) and consumes signals from it. Layer 3 (security operations) monitors what Layers 1 and 2 implement. Layer 4 (governance) closes the feedback loop by identifying decay.

You tested each signal chain with specific Graph API queries. Identity Protection risk detections (Get-MgRiskDetection) prove whether the risk signal exists. Authentication strength policies (Get-MgPolicyAuthenticationStrengthPolicy) prove whether the distinction between phishing-resistant and non-phishing-resistant MFA is available for CA policies to reference. Intune compliance policies prove whether the device compliance signal that CA consumes has substance — and you discovered that secureByDefault: false (the default) means unmanaged devices are treated as compliant, silently breaking the signal chain.

The E3/E5 licensing boundary shapes the architecture at every layer. E3 provides the individual capabilities. E5 provides the signals that connect them — Identity Protection, PIM, Defender for Endpoint Plan 2, auto-labelling, Defender for Cloud Apps. For a split environment, every module designs a two-tier approach: full architecture for the E5 population, documented residual risk with compensating controls for the E3 population.

MSA0.3 — Architecture Decision Records

The ADR format — context, decision, alternatives considered, consequences, residual risk, communication — is the documentation methodology for the entire course. You saw two complete worked examples. The first (authentication method selection) demonstrated a complex decision with four alternatives, each rejected for a specific constraint-based reason: FIDO2 keys rejected for procurement cost and timeline, CBA rejected for PKI infrastructure requirements, Windows Hello rejected for platform limitations, push MFA rejected for phishing vulnerability. The second (legacy auth blocking) demonstrated a simpler decision where the architecture is straightforward but the exceptions and consequences still require documentation.

Both examples included real tenant artifacts: Graph API output showing the current grantControls state, PowerShell commands implementing the change, CA What If evaluation JSON showing conditionsNotSatisfied: ["grantControls"] for users who haven't registered a phishing-resistant method, and post-enforcement sign-in log entries confirming the architecture is live.

The five ADR anti-patterns — "Microsoft recommended it," no alternatives listed, no residual risk statement, communication field equals decision field, no evidence attachments — are the traps that turn ADRs from architecture into paperwork.

MSA0.4 — Threat-Informed Architecture

Architecture designed from the feature list produces a tenant where features are enabled because they're available. Architecture designed from the threat landscape produces a tenant where controls are deployed because they stop specific attack patterns. The MCRA's prioritization model — prevalent threats first, proven threats second, potential threats third — determines the module sequence of this course.

You examined four prevalent M365 attack patterns through their actual telemetry. AiTM phishing produces a sign-in log entry with authenticationStepResultDetail: "MFA requirement satisfied by claim in the token" and deviceDetail.deviceId: "" — a replayed token on an unregistered device. Consent phishing produces an audit log entry with activityDisplayName: "Consent to application" and OAuth scopes including Mail.Read, Mail.Send, Files.ReadWrite.All, and offline_access. Token theft produces a sign-in log subtler than AiTM — the same "Previously satisfied" claim, but potentially from a location that looks normal if the attacker uses a residential proxy. Human-operated ransomware is a six-stage kill chain where most organizations' detection fires at stage 5 (encryption), but the architectural value is in controls that stop stages 1–3 (credential theft, privilege escalation, lateral movement).

Each pattern maps to specific course modules. AiTM → MSA2 + MSA3. Consent phishing → MSA4. Token theft → MSA2 + MSA3. Ransomware → MSA4 + MSA8–MSA11. The course sequence follows the prioritization.

MSA0.5 — The your tenant Scenario

Your tenant baseline assessment documented your starting point — infrastructure, licensing, gaps, and people.

The gaps you identified map to course modules — the architecture you build addresses each one systematically.

Six named personas ground the decisions in organizational reality. the CISO is your primary stakeholder — every ADR Communication field writes for her. the security architect knows where the bodies are buried. the IT Director (IT Director) represents operational constraints. the GRC analyst needs ADRs as audit evidence.

MSA0.6 — Lab Setup and Cost Management

The lab mirrors a realistic starting state — gaps included. Test accounts and security groups replicate the persona model. The IT Director test account starts in the MFA exclusion group deliberately — the course teaches you to diagnose and fix that gap.

MSA0.7 — Your Architecture Package

The architecture package is the primary deliverable of this course — not the tenant configuration. Five components — ADRs, decision matrices, risk register, architecture diagrams, and executive summary — capture everything a successor, auditor, or board member needs to understand, maintain, and defend the architecture. Each module contributes specific components. By MSA14, the package contains approximately 35 ADRs, 7 decision matrices, 25 risk register entries, 14 architecture diagrams, and one executive summary. The folder structure is created and the baseline documents are in place.

What you have now

After Module 0, your inventory:

Conceptual foundation. The configuration-architecture distinction. The four-layer stack model. The signal-chain mental model. The three diagnostic questions. The threat-informed prioritization framework. These concepts underpin every decision from MSA1 onward.

Documentation method. The ADR format with evidence attachments. The ADR template in your package. Two worked examples as structural references. Five anti-patterns to avoid.

Threat model. Four prevalent attack patterns with actual telemetry. The sign-in log and audit log fields that reveal each pattern. The architectural controls that stop each pattern. The module-to-threat mapping that explains the course sequence.

Lab environment. A working M365 E5 developer tenant with test persona accounts, security groups, and intentional gaps. An Azure subscription with Sentinel and budget alerts. All foundational services verified.

Architecture package baseline. The folder structure created. The gap assessment from MSA0.5. The threat-to-architecture map from MSA0.4. The ADR template from MSA0.3. Three documents in place. Approximately 80 more to come.

What Module 1 requires

Module 1 — Entra ID Identity Architecture — is the foundation. Every other module builds on identity because every authentication, authorization, and access decision flows through Entra ID. You'll make architectural decisions about tenant design (single vs multi-tenant, why this constrains everything downstream), identity types (cloud-only, synced, guest, workload, managed — each with a different threat model), hybrid identity (Entra Connect vs Cloud Sync, password hash sync vs pass-through auth vs federation, what breaks and what's legacy), directory structure (administrative units, scoped administration, why flat structures create privilege sprawl), the identity lifecycle (joiner-mover-leaver, the role-change problem where people accumulate access), and naming conventions (the boring infrastructure that prevents chaos at scale).

Each decision gets an ADR in your package. The module ends with a tenant identity assessment and a lab exercise building the identity baseline.

Prerequisites for Module 1: Your developer tenant is working (Get-MgUser -All returns test persona accounts). Your persona security groups are created and populated. Your Azure subscription has Sentinel enabled. Your architecture package folder structure exists with the baseline documents in place. If any of these are missing, complete MSA0.6 before proceeding.