AD0.9 The Security Improvement Sequence
Figure AD0.9 — The security improvement sequence. Identity first (weeks 1-2) because it prevents 80% of attacks. Email second (weeks 3-4) because it reduces the phishing that reaches users. Devices third (weeks 5-6) because it blocks unmanaged access. Data, monitoring, and response last (weeks 7-10) because they build the operational cadence. Each phase has dependencies on the previous phase.
Why the sequence matters
The sequence exists because security controls have dependencies. Conditional access policies can require compliant devices — but that only works if compliance policies exist in Intune. Email protection reduces phishing volume — but the phished credentials are only useful to the attacker if identity controls are weak. Device compliance blocking unmanaged devices only matters if conditional access enforces the requirement. Each layer builds on the one before it.
Getting the sequence wrong creates one of two problems. If you deploy controls that depend on prerequisites you haven’t built, you get false confidence — the control is “configured” but the dependency isn’t in place, so it doesn’t actually protect anything. If you deploy enforcement controls before you’ve identified and handled exceptions, you get user lockouts and helpdesk floods — which generates backlash against the security programme and makes future improvements harder to justify.
The sequence in this course is designed for an IT administrator working part-time on security. Each phase takes 1-2 weeks of effort alongside a full IT workload. The total timeline to reach a solid security posture from NE’s starting point is approximately 10 weeks. That’s not 10 weeks of full-time security work — it’s 10 weeks of 5-8 hours per week dedicated to security improvement.
Phase 1: Identity (weeks 1-2)
Identity controls come first because they have the highest impact with the lowest dependency chain. You don’t need device compliance, email protection, or data classification to deploy MFA and conditional access. You just need to know your environment (which you do — you’ve been administering it) and understand the three policies you’re building.
The pre-work: create two break-glass accounts, identify legacy authentication dependencies in your sign-in logs, and communicate the upcoming changes to your users. The deployment: build three conditional access policies (MFA for all users, block legacy auth, require compliant device for sensitive apps — the third in report-only mode initially), disable security defaults, and configure self-service password reset.
The result: after week 2, your tenant has deterministic MFA enforcement, legacy authentication is blocked, and you have break-glass accounts for emergency access. Your identity posture score goes from 3/10 to 7/10. This single phase prevents 80% of credential-based attacks against your environment.
Here’s the concrete pre-work checklist you’ll complete before building your first conditional access policy. Do these steps this week so you’re ready to deploy when Module AD1 walks you through the configuration.
First, create two break-glass accounts in Entra ID. Name them something non-obvious (not “BreakGlass1”) — use names like “EmergencyAccess-Alpha” and “EmergencyAccess-Bravo.” Assign them the Global Administrator role. Set long, complex passwords (20+ characters) and write the passwords on paper stored in a physical safe or sealed envelope. These accounts should not have MFA registered — they exist for the scenario where MFA itself is the problem. You will exclude these accounts from every conditional access policy you create.
Second, run the legacy authentication check you learned in AD0.8. Navigate to entra.microsoft.com → Monitoring → Sign-in logs → filter by Client App → select legacy protocols. Export the results. For each user still authenticating via legacy protocols, determine whether it’s the user’s email client (upgrade to Outlook desktop or mobile), a shared mailbox accessed by a scanning device (configure modern auth or create an exception), or a third-party application (contact the vendor about modern authentication support). You need these dependencies resolved before you block legacy auth.
If you have users who you know will struggle with MFA — executives who travel frequently, field engineers who use shared tablets, or staff who do not have smartphones — identify them now and plan individual support. A 10-minute call explaining what is changing and why is more effective than an email they will not read. For users without smartphones, Microsoft Authenticator supports phone call verification as a fallback, or you can provide FIDO2 security keys for users who need a hardware token. Plan these exceptions before deployment, not during the helpdesk flood on enforcement day. Third, draft a brief communication to your users: “We’re upgrading our security controls over the next two weeks. You may be prompted to register for multi-factor authentication if you haven’t already. This protects your account from unauthorised access. If you need help with registration, contact the helpdesk.” Send this the week before you enable the conditional access policies. No surprise is a small surprise.
Phase 2: Email (weeks 3-4)
Email protection comes second because the remaining 20% of attacks after identity controls typically involve phishing emails that are more sophisticated than basic credential theft. Safe Links catches malicious URLs at click time, Safe Attachments detonates suspicious documents in a sandbox before delivery, and email authentication (SPF, DKIM, DMARC) prevents attackers from spoofing your domain.
The pre-work: review your current EOP filter effectiveness (how much spam and phishing is getting through?), identify any email workflows that might be affected by URL rewriting (marketing platforms, automated systems), and gather the DNS access credentials you need to add SPF, DKIM, and DMARC records.
You can check your current email authentication status right now without configuring anything. Open a command prompt or terminal and run these DNS lookups against your domain:
| |
Look for a record starting with v=spf1. If it exists, you have SPF configured. If not, anyone can send email pretending to be from your domain. For DKIM:
| |
If this returns a CNAME pointing to Microsoft’s DKIM infrastructure, DKIM is configured. If it returns “Non-existent domain,” DKIM is not set up. For DMARC:
| |
Look for a record starting with v=DMARC1. If it exists, check the policy: p=none means DMARC is monitoring only (not enforcing), p=quarantine sends failures to spam, and p=reject blocks failures entirely. If the record doesn’t exist, your domain has no DMARC protection.
Record these three results. Module AD2 walks through configuring each one — SPF, DKIM, and DMARC — with the exact DNS records and the deployment sequence that avoids breaking legitimate email.
The result: after week 4, phishing reaching user inboxes is reduced by 60% or more, malicious attachments are sandboxed before delivery, and your domain can’t be spoofed by external attackers. Your email posture score goes from 1/10 to 6/10.
Phase 3: Devices (weeks 5-6)
Device compliance comes third because it requires identity controls to be in place (conditional access enforces compliance) and because device policies affect every user’s daily experience (a non-compliant device blocks access, which generates immediate helpdesk tickets).
The pre-work: audit your Intune enrollment coverage, identify devices that would fail compliance checks (unencrypted, out of date, missing security software), and create a remediation plan for non-compliant devices. Build policies in audit/report-only mode first, verify the impact, then switch to enforcement with a grace period.
The result: after week 6, every device accessing M365 data meets your security baseline. Non-compliant devices are blocked until they meet requirements. Your device posture score goes from 2/10 to 6/10.
Phase 4: Data, monitoring, and response (weeks 7-10)
The final phase establishes the operational cadence — the ongoing work that keeps your security posture from drifting back to defaults. Basic sensitivity labels protect your most confidential documents. An alert monitoring cadence catches threats early. An incident response procedure tells you what to do when something happens. Secure Score tracking measures progress over time. Management reporting communicates the value of the security work you’ve done.
This phase is less about configuring controls and more about building habits. The weekly 30-minute alert review, the monthly Secure Score check, the quarterly management report. These become part of your operational routine alongside the IT work you already do.
You’ve completed Phase 1 (identity — conditional access deployed, MFA enforced, legacy auth blocked). You’re about to start Phase 2 (email protection). Your manager says: “Before you do email, the IT director wants device compliance done first because we just failed a client audit on endpoint encryption.” Do you change the sequence?
Option A: Yes — the audit failure creates urgency for device compliance. Swap email and device phases.
Option B: No — stick to the sequence because email protection reduces the phishing that targets users daily.
Option C: Split the difference — configure BitLocker enforcement (the specific audit finding) this week while continuing with email protection as planned.
The correct answer is Option C. The client audit finding is about BitLocker specifically, not the full device compliance stack. You can push a BitLocker enforcement policy through Intune this week (addressing the audit finding) while proceeding with email protection as planned. This satisfies the director’s immediate concern without disrupting the broader security improvement sequence. The full device compliance phase (compliance policies + CA integration + security baselines) still happens in weeks 5-6 as planned.
Try it: Build your 10-week plan
Using the four-phase framework, write your own 10-week security improvement plan. For each phase, list: the controls you’ll configure, the pre-work required (dependency checks, communication, testing), the success criteria (how you’ll know the phase is complete), and the estimated time investment per week.
Phase 1 (Weeks 1-2): Identity — what specific CA policies will you build? Which legacy auth dependencies exist? Who needs to be notified?
Phase 2 (Weeks 3-4): Email — which Defender for Office 365 policies will you configure? Do you have DNS access for SPF/DKIM/DMARC?
Phase 3 (Weeks 5-6): Devices — what compliance requirements will you enforce? How many devices will fail initially? What’s the grace period?
Phase 4 (Weeks 7-10): Operations — what’s your monitoring cadence? Who reviews alerts? How will you report to management?
This plan is your deliverable from Module AD0. The remaining modules walk you through executing each phase.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.