MSA0.5 Your Tenant Baseline Assessment

Why your starting point matters more than the ideal end state

Architecture projects fail when they start from the ideal — a clean tenant, unlimited licensing, no legacy constraints, no political exceptions. Real environments have organic growth, undocumented decisions, inherited configurations, and licensing splits that determine what controls you can deploy and what gaps you document as residual risk. The architecture you build across this course starts from where your tenant actually is, not where you wish it was.

This sub gives you a framework for documenting your own tenant's current state. You'll record the infrastructure, the licensing, the security gaps, and the people involved. This baseline assessment becomes the first artifact in your architecture package — the document that every subsequent module references when it says "this is what you're fixing."

If you're using a developer tenant (set up in MSA0.6), the baseline will be clean — minimal users, default settings, no legacy. That's fine. The assessment framework still applies: you'll document the starting state and build from there. If you're running this course against your production environment in parallel, the baseline will be messy. That's the point.

Estimated time: 20 minutes.

Documenting your infrastructure

Every M365 security architecture exists within constraints. Your infrastructure determines what's possible, what's difficult, and what's blocked. Record these for your tenant:

Identity environment. Is your tenant cloud-only or hybrid? If hybrid, what sync method — Entra Connect Sync, Cloud Sync, or federation? Is the sync server current, or has a legacy server been decommissioned but not cleaned up? Run the sync status query from MSA0.2 and record the result.

Endpoint fleet. How many Windows, macOS, mobile, and Linux devices? Which are managed by Intune? Which are BYOD? Are compliance policies assigned, or is the fleet relying on the default (which, as MSA0.1 showed, may mean secureByDefault: false)?

Server estate. How many Windows and Linux servers? Are any integrated with Entra ID? Do any run legacy applications that can't support modern authentication?

Network architecture. Centralised internet breakout or distributed? VPN for remote workers? SD-WAN? These affect named location trust decisions in MSA3.

Managed security partners. Do you use an MSSP or managed SOC? What access do they have — read-only Sentinel workspace, or administrative access to the tenant? What's the escalation path?

Record these in a structured document. You'll reference it in every module.

Documenting your licensing

Licensing determines your security ceiling. M365 E5 includes capabilities that E3 does not — and the architectural decisions for E5 users are different from the decisions for E3 users.

Query your tenant's license distribution:

Connect-MgGraph -Scopes "Directory.Read.All"

# Get license summary
$subs = (Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/subscribedSkus?`$select=skuPartNumber,consumedUnits,prepaidUnits" `
  -OutputType PSObject).value

$subs | ForEach-Object {
  [PSCustomObject]@{
    SKU       = $_.skuPartNumber
    Total     = $_.prepaidUnits.enabled
    Consumed  = $_.consumedUnits
    Available = $_.prepaidUnits.enabled - $_.consumedUnits
  }
} | Format-Table -AutoSize

The SKU part numbers that matter for security architecture:

ENTERPRISEPREMIUM — M365 E5. Includes Identity Protection, PIM (P2), Defender for Endpoint P2, Purview auto-labelling, Defender for Office 365 P2, Cloud App Security.

ENTERPRISEPACK — M365 E3. Includes basic Conditional Access, Defender for Endpoint P1 (if added), Purview manual labelling, basic DLP. Does NOT include Identity Protection risk signals, auto-labelling, PIM advanced features, or Defender for Endpoint P2 automated investigation.

SPE_E5 and SPE_E3 — Microsoft 365 E5 and E3 (the bundle SKUs that include Windows and Office). Same security feature split.

Record how many users have E5 vs E3. If you have a split, note which departments or roles have which license. This split directly affects your architecture in MSA2 (authentication strength policies only evaluate for licensed users), MSA3 (risk-based CA requires Identity Protection, which requires P2), MSA5 (auto-labelling requires E5), and MSA8 (Defender for Endpoint P2 telemetry only from E5 endpoints).

If every user has E5, record that too — it simplifies your architecture because you don't need to design two-tier controls.

Documenting your security gaps

Run the diagnostic queries from MSA0.1–0.4 against your tenant and record what you find. The common gaps map to course modules:

Authentication gaps. Run the authentication strength check from MSA0.1. Are any CA policies using builtInControls: ["mfa"] without authenticationStrength? Record the count. Each one is a policy that accepts push notification MFA — which AiTM attacks bypass. MSA2 designs the fix.

Privilege gaps. Count your Global Administrators. Are any shared accounts? Is PIM deployed? Are any admin accounts excluded from MFA? Record each finding. MSA4 designs the privilege architecture.

Data protection gaps. Are sensitivity labels published? Are they applied? Check the auto-labelling configuration. Record the label adoption rate. MSA5 designs the data protection architecture.

Device compliance gaps. Check secureByDefault and the compliance check-in threshold. Record both values. MSA6 designs the endpoint architecture.

CA coverage gaps. Are there risk-based CA policies? Is legacy authentication fully blocked? Are there exception groups with stale members? Record each finding. MSA3 designs the CA architecture.

Detection gaps. Which Sentinel connectors are enabled? Are there custom analytics rules, or only Microsoft defaults? Record the current state. MSA8 and MSA9 design the detection architecture.

Application consent gaps. What's the user consent policy? Can users consent to applications requesting sensitive permissions without admin approval? MSA4 covers application governance.

Data lifecycle gaps. Are retention policies configured? Is there a legal hold process? MSA5.6 covers retention architecture.

For each gap, record three things: what the gap is, what the architectural consequence is (not just "it's missing" but what breaks or is vulnerable), and which course module addresses it. This becomes the first page of your architecture package — the baseline against which every subsequent module measures improvement.

Identifying the people

Architecture doesn't exist in a vacuum. Someone approves the design decisions. Someone implements them. Someone lives with the consequences. Record the key roles for your environment:

The decision-maker. Who approves security architecture changes? The CISO, the IT Director, the CTO? This person is the audience for the Communication field in your ADRs. When you write "explain this to a CISO in 30 seconds" throughout the course, you're writing for this person.

The implementer. Who configures the M365 tenant? The security team, the IT ops team, a managed service provider? Understanding who implements helps you design architecture that's maintainable by the people who'll actually maintain it.

The constrained stakeholders. Who pushes back on security controls? The IT Director who needs availability? The department head who requests exceptions? The procurement team with a limited budget? These are the constraints your architecture must accommodate — not override.

The compliance driver. Who needs the ADRs as audit evidence? The GRC analyst, the compliance manager, the external auditor? This determines how much detail your ADRs and risk register need.

What you'll build across this course

Across fifteen modules, you'll produce a complete M365 security architecture package for your environment. This package is the capstone deliverable — by MSA14, you assemble it and present it as a coherent architecture. The components build module by module:

30+ Architecture Decision Records. One for every significant design decision — authentication method selection, CA policy design, privilege model, data classification taxonomy, detection rule architecture, governance framework. Each with evidence attachments.

Decision matrices. Completed trade-off tables for authentication methods, CA policy personas, DLP scope, endpoint compliance, Sentinel data tiers. Filled in for your constraints.

Risk register. Every unimplemented control linked to residual risk, compensating controls, and a remediation timeline. The honest document that says "here's what we can't do yet, here's what we're doing instead, and here's when we'll close the gap."

Executive summary. The one-page document your decision-maker presents to the board. Architecture translated into business language — risk reduced, controls implemented, gaps documented, roadmap defined.

Before moving on, complete your baseline assessment: run the diagnostic queries against your tenant, record the infrastructure, licensing, gaps, and people. If you found no gaps, your tenant may already be well-architected — or your diagnostic queries may need to go deeper. The course will show you which.