The Defense Design Method

Why a method, not a checklist

Most identity security guidance comes as checklists: enable MFA, deploy Conditional Access, configure PIM, block legacy authentication. Checklists tell you what to do. They don't tell you why you're doing it, what specific attack each control stops, how to verify the control works, or what to do when it doesn't.

The difference matters operationally. A checklist produces a configured environment. A method produces a defended environment — one where every control has a defined purpose, a verification mechanism, and a documented design decision. When the environment changes (a new application deployed, a new user population onboarded, an attacker technique that evolves), the method tells you which controls need re-evaluation and how to verify they still work. The checklist just tells you to check the boxes again.

The Defense Design Method is six steps applied to every identity security control in this course. Every module from EI2 onward follows this method. By the time you finish EI17, you will have applied it to authentication methods, Conditional Access policies, named locations, Identity Protection risk policies, PIM configurations, token protection, session controls, application consent governance, workload identity policies, access reviews, and detection rules — every control in the Entra ID security stack. You'll have a documented, verifiable identity security architecture that you can defend to auditors, explain to leadership, and maintain over time.

Step 1: Identify the attack

Every control starts with a specific attack technique — not a product feature, not a compliance requirement, not a best practice recommendation. The question is: what attack does this control stop?

This is where Sections 0.4 and 0.5 become operational. When EI2 teaches authentication method deployment, the attack is AiTM credential phishing. When EI4 designs Conditional Access policies, the attacks are token replay, legacy protocol spray, and unmanaged device access. When EI9 configures consent governance, the attack is OAuth consent phishing. The control exists because the attack exists. If you can't name the attack, you don't know why you're deploying the control.

This step also identifies the kill chain stage. AiTM is stage 2 (initial access). Consent phishing creates stage 3 (persistence). Knowing the stage tells you what the attacker has already accomplished and what they'll do next if this control fails.

Step 2: Locate the control

Where in the Entra ID stack is this control configured? Section 0.3 mapped the seven components. Step 2 identifies the specific component, the specific blade in the admin center, and the specific Graph API or PowerShell command for programmatic configuration.

For phishing-resistant MFA, the Graph API endpoint is authenticationMethodsPolicy. The PowerShell cmdlet is Update-MgPolicyAuthenticationMethodPolicy. Knowing both the portal path and the programmatic path means you can configure the control through whatever interface matches your operational model — portal for initial design, code for deployment at scale.

Step 3: Design the policy

Design is where most organizations fail. They enable a feature without making specific design decisions about scope, exceptions, and interaction with other controls. The result is policies that have gaps, conflicts, or unintended consequences that only surface during an incident.

The design questions are consistent for every control. Who does this apply to — all users, specific groups, specific roles? If groups, are the group memberships current? What applications or resources does it cover — all cloud applications, specific applications, or application categories? What are the exceptions, and are they documented with justification? A policy that excludes break-glass accounts is a designed exception. A policy that excludes "the CEO because she complained" is a gap disguised as an exception. Every exception must have a documented rationale and a compensating control.

How does this control interact with other controls in the stack? A Conditional Access policy requiring phishing-resistant MFA interacts with the authentication method policy (are phishing-resistant methods enabled and registered?), the Identity Protection risk policy (does the risk policy also require MFA, creating a redundant challenge?), and the PIM activation requirements (does PIM also require phishing-resistant MFA for role activation, or does it accept any MFA?). These interactions must be mapped during design, not discovered during troubleshooting.

What is the expected behavior for legitimate users? The user signs in from a compliant device with a FIDO2 key — access granted seamlessly. What is the expected behavior for attackers? The attacker replays a token from an unmanaged device — blocked at device compliance. The attacker uses a push notification through an AiTM proxy — blocked at authentication strength. Specifying both expected behaviors during design ensures the policy is evaluated against the correct criteria.

For authentication strength, the design decisions include: which methods qualify as phishing-resistant (FIDO2, passkey, certificate-based authentication — not Authenticator push, not TOTP, not SMS), which user groups are required to use them (administrators first, then all users), which applications require the strongest authentication (all cloud applications, with specific exclusions documented), and the rollout timeline (administrators in week 1, pilot group in week 2, all users in week 4).

Step 4: Deploy in report-only first

Every Conditional Access policy deploys in report-only mode before enforcement. Report-only mode evaluates the policy against every sign-in but doesn't enforce the result. The sign-in log records what would have happened — would the sign-in have been granted, blocked, or challenged — without affecting the user.

This step prevents the most common deployment failure: a policy that blocks legitimate users. A policy requiring compliant devices that doesn't account for the mobile devices your sales team uses will block every sales team sign-in. A policy requiring phishing-resistant MFA that doesn't account for service accounts using legacy authentication will break automated processes. Report-only mode reveals these conflicts before they become outages.

The report-only period should be at least one week — long enough to capture the full range of sign-in patterns, including weekly batch processes, monthly report generation, and users who sign in infrequently. During this period, you run the Step 5 verification query to identify any legitimate sign-ins that would have been blocked.

Step 5: Verify with KQL

This is the step that separates a configured environment from a verified one. Every control has a verification query — a KQL query that proves the control is working as designed. Without the verification query, you're trusting that configuration equals enforcement. The breaches in Section 0.7 demonstrate that it doesn't.

The verification query answers three questions. Is the control evaluating the sign-ins it should? Is it producing the expected result — grant for legitimate users, block for attackers, challenge for elevated risk? Are there any sign-ins that should be evaluated but aren't — the coverage gaps that represent your implicit trust surface?

Different controls have different verification patterns. For Conditional Access policies, the query checks the ConditionalAccessPolicies array in the sign-in log. For Identity Protection, the query checks RiskLevelDuringSignIn and the corresponding policy action. For PIM, the query checks AuditLogs for role activation events and their approval status. For consent governance, the query checks AuditLogs for new consent grants and their authorization context. The pattern is consistent — the specific fields change by control.

For a Conditional Access policy requiring phishing-resistant MFA for administrators, the verification query checks the ConditionalAccessPolicies array in the sign-in log for every administrator sign-in. It confirms that the policy was evaluated, that it produced the correct result, and that no administrator sign-ins bypassed the policy.

// Verify: are admin sign-ins using phishing-resistant methods?
// This is a Step 5 verification query for authentication strength
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0"
| where UserType == "Member"
| extend AuthMethod = tostring(AuthenticationDetails[0].authenticationMethod)
| extend IsAdmin = Identity has_any ("admin", "Admin")
    or AADTenantId == HomeTenantId and tostring(AuthenticationRequirement) == "multiFactorAuthentication"
| where IsAdmin
| extend IsPhishingResistant = AuthMethod in ("FIDO2 security key", "Passkey (Microsoft Authenticator)", "X.509 Certificate")
| summarize
    TotalAdminSignIns = count(),
    PhishingResistant = countif(IsPhishingResistant),
    Phishable = countif(not(IsPhishingResistant))
| extend ComplianceRate = round(100.0 * PhishingResistant / TotalAdminSignIns, 1)
// ComplianceRate should be 100% after policy enforcement
// Any Phishable admin sign-ins indicate a policy gap

This is a simplified example — EI2 provides the production-grade version that queries directory role assignments directly rather than matching on the "admin" string. The point is the pattern: the verification query produces a number that either confirms the control is working (100% phishing-resistant) or reveals a gap (any phishable admin sign-ins after policy enforcement indicate either a policy exception or a misconfiguration).

Every module in this course provides verification queries for every control it teaches. By the time you finish the course, you'll have a library of verification queries that collectively prove your entire identity security architecture is working — or reveal exactly where it isn't.

Step 6: Document the decision

The final step records the design decisions in a format that persists beyond the person who made them. This is not documentation for documentation's sake — it is operational continuity. When the security engineer who designed the policy leaves the organization, the documentation is what prevents the next person from changing the policy without understanding why it was configured that way.

The policy specification records: what attack this control prevents with the MITRE ATT&CK technique ID and kill chain stage (from Step 1), the design decisions including scope, exceptions, and interactions with other controls (from Step 3), the verification query with the expected result and the threshold for investigation (from Step 5), the approval date and approver, and the review schedule.

When a new team member asks "why is this policy configured this way," the specification answers. When an auditor asks "how do you know this control is effective," the verification query answers. When a new attack technique emerges and leadership asks "are we protected," the threat reference mapping identifies which controls are relevant. Without documentation, every question requires reverse-engineering the configuration from scratch — and the answers are often wrong.

The method applied: a worked example

Walk through the method for deploying phishing-resistant authentication for administrators — the control that would have prevented the Midnight Blizzard breach.

Step 1 — Attack: AiTM credential phishing (T1557 + T1539). Kill chain stage 2. The attacker operates an AiTM proxy that captures session tokens after MFA completion. Push notification and TOTP-based MFA are defeated. Only phishing-resistant methods that cryptographically verify the domain prevent the attack.

Step 2 — Control: Authentication strength in Conditional Access. Admin center: Identity → Protect & secure → Conditional Access → Authentication strengths. Create a named strength requiring FIDO2 or passkey only. Apply it in a Conditional Access policy targeting administrative roles.

Step 3 — Design: Scope: all users with active or eligible assignments to Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, and Privileged Role Administrator. Exceptions: break-glass accounts (excluded from all CA policies, monitored with separate Severity 1 alert). Timeline: immediate deployment to administrators, report-only for 7 days, enforcement on day 8.

Step 4 — Deploy: Create the authentication strength named "Admin phishing-resistant" with FIDO2 and passkey as the only allowed methods. Create the Conditional Access policy targeting the admin role group, requiring this authentication strength, in report-only mode. Monitor sign-in logs for 7 days.

Step 5 — Verify: Run the KQL query above. The report-only period reveals that 3 of 8 administrators haven't registered FIDO2 keys — their sign-ins would have been blocked under enforcement. Work with those users to complete registration. Recheck after 3 days. When 100% of admin sign-ins show phishing-resistant methods, switch from report-only to enforcement. Run the verification query again after 48 hours of enforcement to confirm the policy is evaluating correctly.

Step 6 — Document: Record the policy specification, the threat it addresses, the verification query, and the enforcement date. Add to the quarterly review calendar.