← All Minis/Defender Launchpad
Security & Trust · Agentic planning

Defender Launchpad

Type one deployment goal — "launch Microsoft Defender for Endpoint across all Windows and iOS devices" — and a planner agent decomposes it across Microsoft Entra, Intune, and Defender for Endpoint, sequences it into phases for each platform, and writes you a complete rollout runbook.

Defender for Endpoint Intune Entra ID Windows + iOS Agentic
PLANNER your goal ENTRA INTUNE DEFENDER WINDOWS iOS

🚀 The problem: one goal, many products

Ask any endpoint team to "roll out Defender for Endpoint to all Windows and iOS devices" and the real work is hidden: it spans three Microsoft products and two very different OS paths, in a specific order, with dependencies between them. Windows onboards through an Intune EDR policy; iOS needs the Defender app plus a VPN profile for web protection. Both feed device-risk signals back into compliance, which a Conditional Access policy then enforces in Entra.

Defender Launchpad shows what an agent can do with that mess. You give it the goal in plain English; it produces a cross-product plan, a phased timeline (Prepare → Pilot → Ring 1 → Broad → Operate), and — the part teams actually want — a finished rollout runbook with the Windows and iOS build steps, validation tests, and a rollback plan.

From goal to runbook

01Goal inDescribe the deployment in one sentence.
02DecomposeAgent maps work to Entra, Intune & Defender.
03SequenceTasks ordered into phases with dependencies.
04SplitSeparate Windows and iOS build tracks.
05DocumentA complete runbook you can copy & adapt.

The live demo animates this exact flow — the board assembles itself, then the agent streams the runbook.

🗺️ A plan across three products

For this concrete scenario the agent lays the work into three product lanes. Each task is tagged by platform (Windows, iOS, or both) and slotted into a rollout phase.

🪪
Microsoft Entra IDIdentity & access
  • Dynamic device groups (Windows, iOS)
  • Pilot rings per platform
  • Conditional Access: require compliant device
📱
Microsoft IntuneDevice management
  • Connect Intune ↔ Defender
  • Windows EDR onboarding + ASR rules
  • iOS Defender app + VPN/web-protection profile
  • Compliance policies (machine risk)
🛡️
Defender for EndpointSecurity portal
  • Licensing + Intune connection
  • Device groups, roles, notifications
  • Confirm onboarding & reporting
  • Alerts, vulnerability management

🧭 Windows vs. iOS build

The crux of the scenario: the same goal, two genuinely different onboarding paths. The runbook spells out both.

🪟 Windows

  1. Enable the Intune connection in the Defender portal.
  2. Create an EDR onboarding policy → Windows group.
  3. Turn on Tamper Protection; ASR rules in audit.
  4. Confirm devices report in the Defender portal.
  5. Add compliance: require machine risk low/clear.
  6. After review, switch ASR audit → block; broaden.

iOS

  1. Add the Microsoft Defender iOS app → iOS group.
  2. Create an app configuration policy (web protection).
  3. Deploy a VPN profile so web/network protection works.
  4. Confirm devices show Active, web protection ON.
  5. Add compliance: require machine risk low/clear.
Then both converge: device-risk signals flow into Intune compliance, and an Entra Conditional Access policy enforces "require compliant device" — so only healthy, onboarded Windows and iOS devices reach corporate resources.

🎯 Use cases

🛡️
Security rolloutsPlan an MDE, Defender for Cloud Apps, or attack-surface-reduction launch across mixed device fleets.
🏛️
Regulated & federalProduce a documented, phased rollout with validation and rollback — the artifacts auditors expect.
📋
Runbook generationTurn a one-line ask into a sharable runbook with RACI, timeline, and per-platform steps.
🤝
Cross-team alignmentGive identity, endpoint, and security teams a single map of who does what, when.
🎓
Onboarding & trainingShow new admins how a multi-product Microsoft rollout actually fits together.
Pre-sales & scopingSketch a credible deployment plan in minutes to frame a project or proposal.

⚖️ Pros, cons & limitations

✓ Pros

  • Turns a vague goal into a structured, phased plan.
  • Makes cross-product dependencies explicit.
  • Separates Windows and iOS build paths clearly.
  • Ends with a real, copyable deliverable (the runbook).
  • Great for alignment, scoping, and training.

✕ Cons / trade-offs

  • A starting plan, not a substitute for an engineer's review.
  • Real tenants have nuances a generic plan can't know.
  • Product UIs and steps change over time.
  • Doesn't execute anything — it plans and documents.

△ Limitations

  • This demo is illustrative — the plan is generated in-browser, not from your tenant.
  • Always verify steps against current Intune / Defender docs.
  • Licensing & prerequisites vary by organization.
  • Validate ASR/Conditional Access in audit/report-only first.

📦 Build your own

Two ways forward: drive the planning with a copy-paste prompt today, or wire it to a real agent that reads your tenant.

Paste this into GitHub Copilot Chat (agent mode), Microsoft 365 Copilot, or any capable model to generate the same kind of plan + runbook for your own scenario.

defender-launchpad.prompt.txt
You are a senior Microsoft endpoint security architect. I will give you a
deployment GOAL. Produce a complete, phased ROLLOUT PLAN and a RUNBOOK.

GOAL
  Launch Microsoft Defender for Endpoint across ALL Windows devices and ALL
  iOS mobile devices, managed via Microsoft Intune, with identity guardrails
  in Microsoft Entra ID.

DO THIS
1. Decompose the work into THREE product lanes — Microsoft Entra ID,
   Microsoft Intune, and Defender for Endpoint. For each task, tag the
   platform [Windows] / [iOS] / [Both] and the phase.
2. Sequence everything into phases: Prepare -> Pilot -> Ring 1 -> Broad ->
   Operate. Call out dependencies (what must happen before what).
3. Give SEPARATE step-by-step build tracks for Windows and for iOS
   (Windows = Intune EDR onboarding + Tamper Protection + ASR; iOS =
   Defender app + app config + VPN profile for web/network protection).
4. Show how device-risk signals flow into Intune compliance and how an
   Entra Conditional Access policy ("require compliant device") enforces it.
5. Output a RUNBOOK with: executive summary, prerequisites & licensing,
   cross-product plan, phased timeline, Windows build, iOS build, validation
   tests, rollback plan, and a short RACI.

CONSTRAINTS
  - Be specific and current; prefer Intune-managed/co-managed onboarding.
  - Put ASR rules and Conditional Access in audit/report-only first.
  - Keep pilot rings small to limit blast radius.
  - Note where I must verify against current Microsoft docs.

Ask me for any tenant specifics you need (licensing, BYOD vs corporate,
supervised iOS, co-management); otherwise produce the full plan + runbook.
Tip: swap the GOAL line for your own (different product, OS mix, or add macOS/Android) and the same structure produces a fresh plan.

To make it operate on a real tenant, give an agent read access to Microsoft Graph and let it ground the plan in what's actually there.

  • Grounding: query Microsoft Graph for device counts, existing compliance/EDR policies, and Conditional Access state (read-only, per-user via OBO — see the Identity Bridge mini for the auth pattern).
  • Planning: feed those facts + the prompt above to the model so the plan reflects current gaps, not a generic template.
  • Deliverable: render the runbook to Markdown/Word and drop it in SharePoint or a Loop component for the team.
  • Guardrails: keep it advisory — propose changes, require a human to apply ASR/Conditional Access enforcement.
Pattern: this is the classic plan-then-act agent shape — the demo shows the plan half; grounding + a human approval gate turns it into a safe assistant.

🎮 See the agent plan it live

Type the goal, press Plan the launch, and watch the board assemble across Entra, Intune, and Defender — then have the agent generate the full rollout runbook for Windows and iOS.

Launch the live demo