The Defense Design Method

Introduction

A checklist tells you what to turn on. A method tells you what to do with a control you have never seen before. This section is the six steps, and the two that get skipped. You will finish able to take any identity attack and produce a policy, a verification query and a recorded decision.

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 this course, 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.

Six steps, and two of them are the ones that get dropped.

A checklist says "require MFA", "block legacy auth", "enable PIM". Each is accurate today, and each goes silent the moment the portal moves a setting or an attack arrives that was not on the list.

A method says something different: name the attack, locate the control, design the policy, measure before enforcing, verify with a query, record the decision. None of those six mentions a product, which is exactly why they survive the product changing.

And it produces something a checklist cannot. A checklist produces a configuration. The method produces a configuration plus a reason and a test, which are the two things a successor needs and the two things that are never in the portal.

  1  Name the attack
  2  Locate the control
  3  Design the policy
  4  Measure before enforcing
  5  Verify with a query
  6  Record the decision

The test for which one you have is short: could somebody challenge your configuration from your own documentation? If the answer is no, you have a checklist with more words.

That test is the one ARC402 14.10 arrives at from the architecture side. A configuration can be rebuilt from the console and a reason cannot be rebuilt from anything, so what is expensive to lose is exactly what a checklist never records.

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.

"Improve identity security" has no failure condition, so it can never be finished and never be wrong. That is what disqualifies it as a step 1.

Name one of the seven patterns from 0.4 instead. "Stop AiTM session capture on administrators" names a mechanism, a population and a state you can check, which is three properties a goal needs and a slogan lacks.

The test for a good name is whether you can write the query that would prove it worked. Per ei01, if you cannot, then step 5 has nothing to verify and the policy ships unmeasured.

Name the population here too, not later. "Administrators" and "everyone" are different projects with different rollout plans, and deciding it later means discovering it in report-only, which is an expensive place to have that conversation.

// EI0.8: could you prove "stop AiTM on administrators" worked?
let admins = IdentityInfo
    | where TimeGenerated > ago(1d)
    | where isnotempty(AssignedRoles)
    | distinct AccountUPN;
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in (admins)
| where ResultType == 0
| mv-expand Step = AuthenticationDetails
| extend Method = tostring(Step.authenticationMethod)
| summarize Sign-ins = count() by Method
| order by ['Sign-ins'] desc
// If you cannot write this, step 5 has nothing to verify

Naming the population here rather than at step 3 is what keeps the rollout honest. An attack named without a population produces a policy whose scope is decided by whoever writes it, and that is the decision most likely to be widened quietly later.

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.

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

$p = Get-MgPolicyAuthenticationMethodPolicy
$p.AuthenticationMethodConfigurations |
    Select-Object Id, State,
        @{n='Targets';e={($_.AdditionalProperties.includeTargets |
            ForEach-Object { $_.targetType + ':' + $_.id }) -join ','}}

Read the Targets column rather than the State column. Per ei02 2.3 a method enabled for a group nobody is in is enabled and inert, and that is visible here and not in the blade.

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.

  AiTM capture      the authentication METHOD    ei02
  Password spray    legacy auth blocking         ei02
  Consent phishing  consent settings             ei09
  Token replay      token protection, revocation ei07

Read the column that is missing. Three of those four are answered somewhere other than Conditional Access, and Conditional Access is the control with the dashboard.

Each has a specific reason it is not a policy problem. Requiring MFA does nothing against AiTM, because MFA completed. Legacy protocols bypass Conditional Access rather than failing it. Consent phishing involves no credential at all, so nothing authentication-related reaches it. And token replay happens after a sign-in that already succeeded.

The count in that last line is the reason step 2 exists as its own step. Conditional Access is the most visible control and the wrong answer to three of these four attacks, so an instinct that starts at the policy blade produces work that looks like defense and does not touch the attack.

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 and is not challenged at all. 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).

1. Step 1, name the attack. One of the seven patterns from 0.4, so you know what success looks like. "Stop AiTM session capture" is testable; "harden identity" is not.
2. Step 2, locate the control. Per 0.3, which link acts. AiTM is answered at the authentication method rather than at Conditional Access, so a policy is the wrong instrument entirely. **Getting this wrong produces a correct policy against the wrong stage**, which is the most expensive mistake available here because everything about it looks right.
3. Step 3, design the policy. Four parts, and the fourth is the one that gets forgotten.

  SCOPE      which identities
  CONDITION  when it applies
  CONTROL    what is required
  EXCLUSION  break-glass, per ei03

Step 2 is where the method earns its keep. A control in the wrong place is indistinguishable from a working one until the attack arrives, and by then the evidence that it was misplaced is the incident.

The exclusion is part of the design rather than a caveat on it. A Conditional Access policy without a break-glass exclusion is a lockout that has not happened yet, which is why this course's spec makes it a shipping requirement for every policy artifact.

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.

Report-only is the step that turns a rollout plan from a guess into a number. The count of who would have been blocked is unknowable before this step and obvious after it, which is why skipping it moves the discovery from a report to a service desk queue.

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 4, report-only first. Per ei08 the policy evaluates without enforcing, so you learn who would have been blocked before anybody is. It gets skipped because it costs a week and produces no visible improvement, which is the same reason forensic readiness is deferred in ARC402 11.1. What it costs to skip is the phone calls from a population nobody counted.

Step 5, verify with a query. Per ei01, find sign-ins where the policy applied and the control was satisfied. That is the only evidence it works. It gets skipped because the portal says "enabled", which reads like confirmation and is not. What it costs to skip is a policy sitting in report-only for months that everybody believes is enforcing.

Both of the skipped steps are measurements. The four that survive are all decisions, and that pattern is worth noticing in your own process: measurement is what gets cut when a project is behind.

The pattern at the bottom generalizes past this method. The steps that get dropped are the ones producing a number rather than a change, so a method executed at speed keeps everything that feels like progress and loses both things that would have said whether it worked.

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.

What was decided, in words rather than a screenshot.

What the alternatives were. The option not taken is the half that makes a review possible: a record with one option in it cannot be challenged, only obeyed.

Why this one, and this is where the report-only number goes. Per ARC402 14.10 a decision whose evidence lives in another phase and was never carried across is unreviewable, and the agreement rate or the affected count is that evidence.

When to revisit, as a date. Per ei03's break-glass and exclusion handling, an entry with no date is a permanent decision recorded as a temporary one.

Four fields, all sentences. None needs a diagram, and none survives the person who decided it unless it is written down.

The third field is the one that decays fastest and matters most. A recorded decision without the number it rested on can be read but not argued with, so the report-only count from step 4 belongs in the record rather than in the ticket that closed.

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

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.
2. Control. Authentication strength in Conditional Access. Admin center: Identity → Protection → Conditional Access → Authentication strengths. Create a named strength requiring FIDO2 or passkey only. Apply it in a Conditional Access policy targeting administrative roles.
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.
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.
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.
6. Document. Record the policy specification, the threat it addresses, the verification query, and the enforcement date. Add to the quarterly review calendar.

Two rows carry the worked example. Step 2 is the one that would have been wrong: a policy requiring "MFA" does nothing here, because MFA completed, and a team that skipped step 2 would have shipped that policy and believed it.

Step 4's number is the rollout plan, not a preliminary to it. How many administrators have no FIDO2 key registered is unknowable before that step and obvious after it, and it is the difference between a cutover and a week of phone calls.

Step 5 has a failure mode worth knowing: a count of zero after enforcement does not mean success, it means the policy is not matching.

  step 1  attack       AiTM session capture
  step 2  control       authentication METHOD, not a CA grant
  step 3  scope         administrators
          condition     all cloud apps
          control       phishing-resistant MFA
          exclusion     2 break-glass accounts
  step 4  report-only   admins with no key registered: [count]
  step 5  verify        admin sign-ins by method
  step 6  document      what else was considered, and why not

Step 2 is where the worked example earns its place. The instinctive response to an MFA-defeating attack is a stronger Conditional Access policy, which produces a correct policy requiring a control the attacker already satisfied.

The method is easier to test backwards, on a policy already in production, than forwards on one that does not exist yet.

A checklist tells you what to turn on and a method tells you what to do with a control you have never seen, which is why none of the six steps mentions a product. Naming the attack gives you a failure condition, and locating the control is where the method earns its keep, because three of the four common patterns are answered somewhere other than Conditional Access and Conditional Access is the control with the dashboard. The two steps that get skipped are both measurements: report-only, which tells you who would have been blocked, and the verification query, which is the only evidence the policy works. The four that survive are all decisions. And the record needs the number the decision rested on, or it can be read but not argued with.